Re: Improving PIDF

Jon,

The splitting of this doc is pretty much along the lines of the CPIM split
both in terms of necessity and timing.

Historically, this WG has been mixing Presence with IM and although that has
been taken care of in most other places, PIDF still remains as a doc where
there is both P & IM in there.  IM is only *one* application or extension of
presence information.  There are plenty others besides IM and there is no
reason giving it special status and stuffing it together with the *Presence*
Information Data Format.

Sure, the IM elements in PIDF are optional, but I hope that you see that
using that argument, we could take presence attributes specific to
applications X, Y and Z and stick them in there too as optional, but we
wouldn't be doing the spec any good.

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

----- Original Message -----
From: "Peterson, Jon" <[email protected]>
To: "'Thanos Diacakis'" <[email protected]>; <[email protected]>
Sent: Wednesday, November 27, 2002 12:16 AM
Subject: 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]