RE: Improving PIDF

I would prefer that we stick to the existing document format for PIDF. I
don't think this split really grants us any appreciable leverage. I believe
a presence document should carry presence status information - I don't think
we need to introduce some sort of modularity to allow presence information
to contain other sorts of things. This is also the eleventh hour for this
document (and the working group, we hope)... if this split does not address
some outstanding technical problem, I think we would best stay with our
course.

The objection I recall you raising in Atlanta, actually, was related to the
fact that <basic> status in presence information would not be needed in all
cases, and in fact <basic> is already explicitly optional in the current
draft. Personally, I feel that it is quite reasonable to say that location
is a type of "status".

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Thanos Diacakis [mailto:[email protected]]
> Sent: Tuesday, November 26, 2002 6:08 PM
> To: [email protected]
> Subject: Improving PIDF
> 
> 
> Following up on our discussion in Atlanta last week, in line with neatly
> separating the CPIM draft into three separate drafts, we need to split
PIDF
> into two.  As I mentioned last week, I'm not suggesting any functionality
or
> content changes.  We need all the content, just in two 
> separate drafts.
> 
> The logic behind this is that PIDF essentially contains two things:
> 
> a) a format to carry any type of presence data (generally speaking that is
> the <presence> and <tuple> elements)
> b) a set of attributes or presence schema pertaining to IM or perhaps more
> broadly interpreted "communications presence" (that is nearly everything
> inside the tuple, except e.g. timestamp)
> 
> It doesn't make sense to mandate that all presence documents that use (a),
> need to carry the elements in (b), of which indeed some are mandatory.
For
> example, a tuple that publishes one's location doesn't necessarily need a
> "status" field.
> 
> Also, the separation between the presence format, and particular attribute
> schemata will serve as a good example on how to add new schemata to cover
> other applications.  (e.g. the SIMPLE WG is working on a similar item
> [draft-lonnfors-simple-prescaps-ext-00]).
> 
> Lastly, we can better focus the main PIDF draft on issues related to
joining
> and splitting PI documents without needing to worry about what is in them
at
> the same time.
> 
> Having said that, I've performed this split and made the two resulting
> drafts available here:
> 
> http://www.diacakis.com/impp/draft-diacakis-ietf-impp-cpp-pidf-00.txt
> http://www.diacakis.com/impp/draft-diacakis-ietf-impp-cpp-pidf
-im-00.txt

In addition to the split, while I was at it, I added two more changes:
- Jonathan's "zero or more tuples" - I presume there are no objections to
that
- Misc fixes replacing CPIM with CPP & CPIM as necessary

After this is scrutinized and if there are no objections, I would propose to
make those two docs WG drafts.

Thanos
---
Thanos Diacakis
Openwave Systems
[email protected]
+1-303 385 6705







  [reminder: [email protected] for non-technical discussions, please]




  [reminder: [email protected] for non-technical discussions, please]