Re: PIDF for buddylists

Comments inline. Best results when viewed in fixed width font.

	Paul

Jonathan Rosenberg wrote:
> 
> Paul Kyzivat wrote:
> > 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.
> 
> You're right, actually. I thought about this more since posting, and its
> not really needed. With watcherinfo (which does have diffs), you are
> again getting notified about a list of things. However, the list itself
> is dynamic and conveyed through the notifications itself. You therefore
> need to have a flag as to whether the update is full state or partial
> state, so that you know whether or not to delete a watcher because their
> entry is not in the list (delete for full state, don't for partial).
> 
> Now, in the case of buddylists, presumably the list itself is known to
> the client through other means, and therefore, this particular flag is
> not needed.

I'm not sure this is a reasonable assumption. As long as we remain silent on how the list is managed, it is risky to assume that every subscriber has complete knowledge of
the list content.

There seem to be two reasonable alternatives here: provide diff information on presence reports from buddylists, or else provide a defined way to monitor the content of a
buddylist itself.

> 
> > 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.
> 
> Wayne convinced me that we need to define a trivial new format; one that
> has a new top-level XML element, and the sub-element is presence from PIDF.

Depends on outcome of discussion below. Possibly some form of change will be required.

> 
> >
> > 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.
> 
> Are you proposing an actual REGISTER for this? I think this is a pretty
> big deviation from the meaning of REGISTER.

I am proposing (as a strawhorse) that the concept of buddylist be subsumed into a slightly broader role for address of record. This is largely a conceptual change - I don't
think the mechanics of managing address of record need to change.

It is already permissible to populate a location service with an address of record either by using REGISTER or by some other method. One other method might be by uploading
a buddylist.

> 
> > 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.
> 
> How would you have out the contacts for the buddies? You've shifted
> everything down a layer, so the bottom falls out as far as I can tell...

Yeah, I didn't bother to mention that, and you caught me. :-)

What I have in mind is that presence should be viewed as hierarchical. It is already that way, sort of, but only two levels are acknowledged in the hierarchy. The
presentity can have status, and each of the contacts can have status.

In registrations, it is permissible for the Contacts defining one address of record to themselves be addresses of record that have lower level definitions, etc. (I realize
there aren't many, if any, published use cases for this.)

If you want to understand the full hierarchical structure of registrations of that sort, you have to drill down one level at a time. It should be possible to do exactly the
same thing for presence. Alternately, it might be more helpful for a presence subscription to be recursive, perhaps optionally. (This would be something like what has been
proposed for the conference info event package.)

As an example, consider the following hierarchy:

                     [email protected]
                     /         |         \
    [email protected]  [email protected] [email protected]
          /             /      |        \        \
        ...            /       |         \       ...
                      /        |          \
                     /         |           \
[email protected] [email protected] [email protected];user=phone


These could all be valid sip addresses to call. They are also potentially all valid presentities to request presence documents for. What is the difference if I ask for the
presence of 'everybody' and get info about its three subordinates, or if I ask for the presence of 'fred' and get the status of his three alternate devices? 

Why does there have to be an arbitrary distinction that 'everybody' is a buddylist, but 'fred' is an address of record?

	Paul



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