Re: PIDF for buddylists

Paul Kyzivat wrote:
 >>
>>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.

Well, the question is whether this package is the right thing to let 
someone know that the list itself has changed, as opposed to just the 
presence of a user on the list changing.

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


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

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.




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

Generally, call forwarding.

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

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

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.

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

-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




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