Subject: RE: [Simple] collection template

From: [email-masked]
Date: Mon, 16 Sep 2002 15:51:57 +0300

Hi Jonathan,

It seems that this approach also makes the recursion of presence-list subscriptions easier. I had some doubts about the previous template package based proposal (especially the part about defaulting to presence from presence.collection), because of the fact that one could potentially have both presence *and* presence-collection events in the same SIP URI. 

So, I like this approach. Let's go for it.

Cheers,
Aki

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 12:26 AM
> To: [email-masked]
> Subject: [Simple] collection template
> 
> 
> Folks,
> 
> The current version of the old "buddy list" package now defines a 
> collection template that can allow a user to subscribe to a 
> list of URIs 
> for a particular package, such as presence.
> 
> It has occurred to me since the meeting that we can take this 
> one step 
> farther for a really generally useful tool.
> 
> The idea is to make this a collection PACKAGE, not a 
> template. The URI 
> that you subscribe to represents a list of URIs, each of which can be 
> for a different package. The list would also include 
> information on the 
> package that URI is associated with.
> 
> The idea here is that a UA could send a single subscribe to a server 
> which would, in turn, fan out subscriptions to each of the 
> events/URIs 
> the user was interested in.
> 
> Heres an example. Lets say a UA is interested in a 
> subscription to two 
> message waiting indicators and two buddy lists:
> 
> sip:[email-masked], mwi package
> sip:[email-masked], mwi package
> sip:[email-masked], collection package
> sip:[email-masked], collection package
> 
> the two buddy lists are themselves lists, each of which is a URI that 
> represents a presentity. We could assign a single URI to the two MWIs 
> and two buddy lists - sip:[email-masked]. The UA would 
> then do this:
> 
> SUBSCRIBE sip:[email-masked] SIP/2.0
> Event: collection
> Accept: text/collection-info, application/cpim-pidf+xml,
>    application/simple-message-summary
> 
> 
> The server would fan out a subscription to each element in the list 
> within the package for that element, copying the Accept 
> headers from the 
> collection SUBSCRIBE. The collection server would be responsible for 
> refreshing those fanned out subscriptions, and passing the content of 
> notifications towards the UAC. The collection server could be 
> ignorant 
> of the detailed operation of any of the packages, and could generate 
> subscriptions for packages it doesnt even understand.
> 
> If we envision that UAs will frequently have lots of long-lived 
> subscriptions to a number of things, this mechanism can save a lot of 
> overhead for wireless or other access constrained devices. It 
> increases 
> the administrative burden overall, since each collection URI needs to 
> specify a modereately complex data structure - a list of 
> elements, each 
> of which is a URI/event pair. But, I think this is a 
> worthwhile tradeoff.
> 
> Do people think this is a worthwhile approach?
> 
> 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: Sean Olson <[email-masked]>
Date: Mon, 16 Sep 2002 07:52:36 -0700 (PDT)

I would like to reiterate Ben's concerns over
negotiation of supported Event packages. I think
turning the collection template into a package
would go against the basic design of the SUB/NOT
mechanism. Having a collection template would still
be a big win in terms of bandwidth. Having to send
multiple <event>.collection SUBs is still a lot
better than having to do the individual SUBs.
 
At the very least, I would not rely on the Accept
headers for a pseudo-negotiation. Instead, I would
turn to an appropriate "filter" for the body of 
the SUBSCRIBE to create a meta-level of negotiation.
This is already feeling too complex to me, but we
should make this as clean a design as possible.

Sean Olson
Microsoft

--- [email-masked] wrote:
> Hi Jonathan,
> 
> It seems that this approach also makes the recursion
> of presence-list subscriptions easier. I had some
> doubts about the previous template package based
> proposal (especially the part about defaulting to
> presence from presence.collection), because of the
> fact that one could potentially have both presence
> *and* presence-collection events in the same SIP
> URI. 
> 
> > and two buddy lists -
> sip:[email-masked]. The UA would 
> > then do this:
> > 

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com