Re: PIDF for buddylists

Jonathan,

Maybe I missed a document. You mention below the importance of diffs when reporting presence for buddylists. But I don't find any mention of diffs in
draft-rosenberg-simple-buddylist-package-00. Or do you just mean that delivery of presence documents individually from each member of the buddylist as it changes is a form
of diff?

Upon thinking about this further, I think the existing presence document might be sufficient.

Consider - is there any fundamental difference between a named buddylist and an address of record? If I view a buddylist as an address of record, then to populate it I
simply REGISTER the addresses of the buddies as contacts. Then instead of a BLSS, I need a presence server with access to the location service populated by the registrar.
And instead of a presence document with multiple presentities, I get a presence document with a single presentity (my buddylist name) and a bunch of contacts for my
buddies. 

This would put a high priority on permitting diffs in the presence documents.

Having buddylists represented this way would provide other opportunities to use them.

	Paul

Jonathan Rosenberg wrote:
> 
> 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
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email protected] for questions on current sip
> Use [email protected] for new developments of core SIP



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