Re: PIDF for buddylists

Jonathan - more comments below.

	Paul

Jonathan Rosenberg wrote:
> 
> > 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.
> 
> Right. My preference is to have a separate package for that. Indeed,
> there are several "lists" that one might have and wish to watch for
> changes in - authorization lists, deny lists, group lists (for group IM,
> for example), and so on. Itd' be nice those were all handled consistently.

Whether there is a separate package or not, there may still be a need for diff information. 

The presence event package doesn't provide for diffs. In the absence of filters, it returns all information about the presentity, including all tuples, in each
notification.

Your proposal has distinguished buddylist from presentity. The buddylist eventpackage returns a full set of information about all buddy presentities upon an initial
subscription, and thereafter effectively returns diffs in the sense that it only returns information about individual buddies whose presence status has changed.

So the effect is that there is support for diffs on some but not all of the information. This makes sense if you assume that there might be a lot of buddies per buddylist,
but not a lot of tuples per presentity. But this is only an assumption. There are plausible cases where there might be many tuples for a presentity.

Now I have suggested we merge the concept of a buddylist that has a number of presentities with the concept of a presentity that has a number of tuples. If we do this, then
it gets harder to distinguish when to use a diff behavior and when not to. While this presents a problem to be solved, once it is solved, it will work when the application
is conceptually a presentity with lots of tuples as well as when it is a buddylist with lots of buddies.

One solution would be analogous to what you have already proposed: use two different event package names to distinguish whether the returned notification stream uses diffs
or not. (Even though the addressed entity being subscribed to is an address of record in both cases.) But while this would still be possible, I think there is probably a
better choice. For instance, this might be incorporated into a filter definition.  

> > 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.
> 
> I am still very uncomfortable with this. If an INVITE arrives for that
> "address of record" the call will fork to the people in your buddy list.
> I don't think this is what you really want to have happen. Probably you
> really want a conference call. Thats generally different from a call to
> an AOR that represents a user, as we know it today. Since I personally
> would only communicate with one of my registered contacts, forking and
> then cancelling unanswered branches makes sense. However, if the AOR
> represents a group, all of the "registered contacts" would communicate,
> and therefore, the conference call makes more sense.

Which makes sense depends on context. There are lots of useful examples of a group address that I might want to call and really only want to talk to one member of the
group. For instance I might want to call anybody in a particular household, or in a department of an organization.

Nor do I think a given list will only be used one way or the other. There are times when I might want to send a reminder to all members of a group, and other times when I
just need to deal with some member of the group. So this is a matter of expressing the desired manner of using the list, rather than a characteristic of the definition of
the list.

> At the very least, I think users who subscribe to this thing will want
> to know the difference.

If we can come up with a clear definition of what the difference is, then it should be relatively simple to encode that in a presence document, e.g. as a new sort of status
value.

The hard part is defining the difference. This is *already* a problem: suppose I have two devices, a phone that does voice, and a PC that does chat. I register them both
with the same address of record: sip:[email protected]. If this same information is translated or rerepresented as a presence document, then it will appear as two tuples for the
presentity. 

What are the implications of doing this:

1) Suppose you have a device capable of either voice or chat. It can generate in invitation offering both. If you send an invitation to my address of record, it will
presumably be forked, and one or the other of my endpoints will be chosen, but you will have little choice in which.

2) A suitable presence client will show them both, perhaps annotated to indicate what media each supports. Using the same device as above, coupled to the presence client,
you can choose which device to send an invitation to. If you wish, you can initiate an invitation to each, and so use both media.

3) In (2) I assumed that your presence-coupled UA sent invitations to the contact address of a tuple. If instead it send the invitation to the presentity address (address
of record) then the results are more like (1), but more disconcerting. I may think I am calling your phone but get your chat UA instead.

There would perhaps be a better, or at least more consistent, result if we consider the location service to have the full set of information that the presence document
represents for a presentity. A forking proxy for an address-of-record would be able to use all of this information to process a call. But to get reasonable and consistent
behavior for calls that are presence driven and those that are not, the presence information almost certainly needs to be enriched to indicate *why* multiple tuples are
present and how choices among them should be made. This is similar to the information provided by callerprefs, but may need further enrichment.

> 
> Beyond that, there is likely to be differences in the information you
> would want to convey at each level. Indeed, in PIDF today, very little
> information exists at the presentity level; its all at the contact
> level. To show that your model is sensible, I think you need to
> demonstarte that the same information and state applies to any level in
> the hierarchy above.

The presentity level information is pretty minimal in pidf today. Its not clear whether this is a problem or not. In large measure the extra information at the tuple level
is there to characterize the differences between the tuples, or the intended role of each tuple. As long as you assume there is a single top level element, then it needs
less of this information.

OTOH, there is some merit in producing a rollup for the top of the hierarchy - e.g. a status value that somehow represents the aggregate status. This is probably pretty
easy as long as you restrict status to OPEN and CLOSED. (Presentity is OPEN if any of the tuples are OPEN.) However this is probably simplistic. There may be no general
algorithm for deriving the status of the presentity from the status' of the tuples. If this has to be explicitly generated, then it may not be worth providing.

One simple way of reflecting the general model would be to change the schema so that a <contact> could contain another <presentity> as an alternative to anyURL. This would
permit the hierarchy to be exploded in a single document. But even without this, there is nothing to prevent interpretation of the URL in a <contact> as a reference to
another presentity.

> 
> Don't get me wrong - I am not saying that what you are proposing is a
> bad idea. In fact, its quite intriguing. But, its a big deviation from
> PIDF today, and from the architectural model that has been the
> foundation of PIDF for some time (RFC 2778).

Hey, I'm happy not be be considered insane for proposing it. :-)

I reread that, and I don't think what I am suggesting does a violence to that model. Of course that model doesn't suggest or imply this sort of implementation, but neither
does it seem to prevent it. But were we to go in this direction it would probably be advisable to discuss these concepts specifically.

I realize that this is still half baked. I'm just testing the ideas now. My earlier comments on the registration event package were also part of this same concept. I
haven't responded to your comments on that because that part is still in the oven.

	Paul



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