Subject: RE: [Simple] new I-D on subscribing to buddy lists

From: [email-masked]
Date: Fri, 23 Nov 2001 11:16:54 +0100

Some questions:

- Why does the buddylist have a SIP URI of its own? A server supporting the
buddylist package has enough information in the from header to perform its
task. A PUA and a PA communicates without having to adress the PA
specifically.

- I think it should be possible to see that the buddylist event package is
a delegated presence subscription event package, by making it a subpackage
(or perhaps a superpackage), e.g. presence.buddylist (or
buddylist.presence). I should be possible to perform delegated
subscriptions to other event packages e.g. buddylist.myeventpackagename.
The word buddylist would then not be very useful in itself;
presence.delegate is my suggestion.

The latter could perhaps be used in some way to join subscriptions. Say
that I have made a SUBCRIBE request for the presence.delegate package and
later make a SUBSCRIBE request for an individual user, it would be very
useful to join the individual subscription to the delegated subscription. I
am not sure how though (yet).

Regards,

Håkan Jonsson

_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Mon, 26 Nov 2001 09:50:07 -0600

Hi, comments inline

> task. A PUA and a PA communicates without having to adress the PA

Well, aside from the fact that it is dangerous to attribute any meaning 
to the From header other than as part of call-leg/transaction 
identification, using the request-URI approach is much more flexible. 
For example, I might have multiple buddy lists for the same user. Or 
perhaps even more interesting would be to have a buddy list that can be 
used by more than one user.

> presence.delegate is my suggestion.

I don't suppose it really matters what you name it, although it might be 
useful to capture the idea, that in addition to delegation, you are 
agreggating subscriptions, that is, subscribing to more than one 
presentity in a single subscription.

> am not sure how though (yet).

Wow, the thought makes my head hurt :-) I suspect any _protocol_ level 
solution to that would add a lot of complexity for a corner use case. I 
think that sort of thing is better left to individual implementation 
decisions. (Assuming an app could detect the condition, it could 
disallow the second subscription, or drop the presentity from the 
current buddy list subscription, etc.)