RE: Improving PIDF

inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Thanos Diacakis [mailto:[email protected]]
> Sent: Wednesday, November 27, 2002 8:05 AM
> To: Peterson, Jon; [email protected]
> Subject: 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.
> 

Well, the split of CPIM into IM & Presence documents was motivated, from my
perspective, by the fact that a domain could deploy a presence gateway
without deploying an IM gateway, and that the IM & Presence gateways in a
given domain could actually operate on separate machines with no
interdependencies.

However, I don't think this is how your proposed split operates. Most
significantly, your split does not merely separate presence from IM, because
status is not an IM-specific concept - a disposition towards communication
is intrinsic to the concept of presence. I am not eager to accept a new
definition of presence in which it expresses a form of disposition unrelated
to communications at this stage in the game.

Saying that the <status> element should be separate from PIDF suggests that
a minimal implementation of PIDF is useful without the <status> element.
However, it isn't at all clear to me what the semantics of a <tuple> without
<status> would be. This introduces an opportunity for modularity -
presumably that something other than <status> could be in a <tuple> - which
remains unmotivated, and of which I am skeptical. Can you help me out with
this at all? What do you want to do with status-free tuples? In any event,
if support for the <status> element in not mandatory-to-implement (as your
draft appears to suggest), this separation will significantly diminish the
chances for interoperability.

> 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.
> 

The proposition that <status> is specific to IM strikes me as misplaced.
Actually, I think that even <basic> status is useful for telephony, Internet
gaming, videoconferencing, and any other conceivable form of real-time
communication, although certainly all forms of real-time communication could
probably benefit from further extensions to <status>.

It is also worth mentioning, since location has frequently been raised as an
application of presence that is independent of means of communication, that
there is another group in the Apps Area of the IETF that is exploring means
of distributing location (geopriv). Currently, this is not presence-based
work. The applicability of presence to this work remains undecided, but were
it to be incorporated I don't see any obvious reason why the semantics of
'status' wouldn't be appropriate to describe it.

> 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.
> 

And my argument is that <status> has applicability to many other forms of
communication aside from IM. I think a minimal implementation of PIDF should
support <status>. I think one subscribes to presence because you are
potentially interested in interacting with the target.

> 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]