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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2001 15:50:06 -0500

Folks,

I just submitted an I-D that talks about subscribing to the entire
buddylist. This is a feature common in many systems, and I believe its a key
piece of making SIMPLE ideal for wireless. Until the draft appears in the
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-buddylist-package-00.tx
t

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: [email-masked]
Date: Thu, 15 Nov 2001 14:24:25 +0100

Hi,

A few comments on the Buddylist package ID:

I agree that it is definitely a needed functionality, especially for
wireless applications.

From section 2 BLSS Operation:
> The BLSS generates an immediate, empty NOTIFY as required by [2], and
then obtains the presence state of the users on the buddy list.

Does it have done in this order? Is there anything which prevents the BLSS
to subscribe to the buddylist users' presence before the user requests the
subscription, and send the aggregated state in the first NOTIFY?

> As notifications with presence data are received, they can be passed
onwards towards the subscriber.

Would it be allowable to forward the NOTIFIES from the users subscribed to,
to the subscriber as is? Would there be a problem with the subscriber
receiving NOTIFIES with an unknown Call-ID? Or could the BLSS reuse the
Call-ID from the subscriber?

From section 3.5 Notify bodies:
> Since the cpim-pidf+xml type contains the identity of the presentity
within it, it is clear for which buddy the presence data applies.

It would be nice if this draft could describe the behaviour of the BLSS if
a presence format used for the body does NOT contain the identity of the
presentity, but does instead refer to the presentity in the SIP headers.

> The second possibility for aggregation is to use a single body type
explicitly designed to support lists of presence data. This format,
????....

Why not use the format proposed to IMPP as specified in the expired draft
draft-rosenberg-impp-buddylist-00?

/Håkan

=======================================
Håkan Jonsson
BlueLabs South AB
Drottninggatan 18
21189 Malmö
Sweden
http://www.bluelabs.se

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Nov 2001 14:33:35 -0500

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 10:50 AM
> To: [email-masked]
> Cc: Jonathan Rosenberg; [email-masked]'
> Subject: Re: [Simple] new I-D on subscribing to buddy lists
> 
> > 
> > - 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.
> 
> 
> 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.

The draft already talks about the possibility of this being a more general
purpose sub-package. See section 5:

    1.   The concept here can be generalized into a sub-package.
             Effectively, it could be the "aggregation" sub-package for
             any package, and allow for subscriptions to a list of
             elements of the parent package type. The default body of
             the sub-package would be the same as the parent package,
             but also allow for multipart/mixed and possibly a type
             specific to the parent package. Therefore, instead of
             "buddylist", we would have "presence.aggregate".

I suspect that this generalization is a good thing, much like it was for
watcherinfo.

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

I don't like the idea of states of subscriptions affecting each other. It
makes a lot more sense to keep these separate. Indeed, there may very well
be reasons why a client wishes to have a group and an individual
subscription separately. You don't want the server to make assumptions about
what the client is trying to achieve.

-Jonathan R.

---

---

From: [email-masked]
Date: Tue, 27 Nov 2001 09:18:55 +0100

>what the client is trying to achieve.

Sorry for not being very clear. I just wanted the client to have the
possibility to request the joining of a presence subscription with a
presence.aggregate subscription, not an enforcement or guesswork from the
server. To use aggregate subscriptions, the client now has to update the
buddylist in some undefined way (if using SIP) from which the aggregate
subscription is generated, and then refresh it, get some undefined
authorization result back, in some undefined format (if using SIP). I would
prefer letting the client be able to arrange the subscription first, and
then join it with the aggregate. Does it make sense or am I just rambling?

Regards,

Håkan