RE: [Simple] PIDF for buddylists, was: Re: [Sipping] request to a dopt registration package as WG item

> from a read of the schema its not clear to me that a single document
> with multiple presence elements is actually disallowed, in whcih case 
> its already there.

XML documents have a single root element.  In PIDF, presence is the root
element so there's only one presence element.  

Someone could define another XML format with some other root element that
included multiple PIDF presence elements inside that other root element. (or
some non XML format could carry multiple XML documents)

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email protected]]
> Sent: Friday, May 31, 2002 11:09 AM
> To: Paul Kyzivat
> Cc: Rohan Mahy; [email protected]; [email protected];
> [email protected]
> Subject: [Simple] PIDF for buddylists, was: Re: [Sipping] request to
> adopt registration package as WG item
> 
> 
> I think my comments on using PIDF for the reg package are covered in a
> separate email; I'll focus here on the PIDF v. buddylist concept.
> However, this is well into simple territory (and IMPP), so I am cc'ing
> those lists.
> 
> inline:
> 
> Paul Kyzivat wrote:
> > 
> > comments inline.
> > 
> 
> > > However, note that in cases of notifications of changes, 
> this issue
> > > becomes largely moot. Changes in presence of buddies 
> happen one at a
> > > time, so that each notify would usually contain just a 
> single presenec
> > > doc anyway. THe exception is if the buddylist server is 
> batching the
> > > notifies in order to reduce overhead.
> > 
> > I think batching is potentially an important application of 
> buddylists.
> > Buddylist servers may also be a good place to implement filtering to
> > further reduce the traffic that
> > the subscriber is exposed to. These potentials would be enhanced by
> > being able to return the presence of multiple presentities 
> in a single
> > presence document.
> 
> I agree it would be helpful, although the difference between multipart
> and multiple presentities in a single document is not huge. The real
> problem is that this is somewhat of a new direction for PIDF 
> late in the
> game, and in PIDF was engineered to be minimalistic. Adding 
> support for
> a new feature is likely to meet with some resistance. I 
> suppose we could
> define an extension to PIDF, although to be honest, from a read of the
> schema its not clear to me that a single document with 
> multiple presence
> elements is actually disallowed, in whcih case its already there. Of
> course, its not likely to be interoperable...
> 
> 
> > 
> > > > it would then make
> > > > sense to subscribe to presence of either presentities 
> or buddylists
> > > > without needed to know which is which.
> > >
> > > There are differences, most notably in the need for diffs 
> in the case
> > of
> > > buddylist.
> > 
> > Seems to me these aren't important differences. The 
> features that seem
> > important for buddylists and less important for presence of an
> > individual are also at least
> > potentially useful for the presence of an individual.
> 
> Well, the diff feature is critical for buddylist, and currently
> undefined for presence. Therefore, we need to have at least a new
> package for it. We would also need some new attributes to support the
> diffs (a partial/full flag, as we needed for watcherinfo), so 
> we are at
> least talking about an extension to PIDF even if multiple presence
> elements are allowed. I would be OK with doing that; the difference
> between it and multipart is not huge, but its definitely better.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email protected]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> _______________________________________________
> simple mailing list
> [email protected]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
> 


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