Subject: [Simple] collection template

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Sep 2002 17:25:38 -0400

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: Ben Campbell <[email-masked]>
Date: Thu, 12 Sep 2002 16:43:31 -0500

Interesting. I am concerned, however, that the event negotiation part 
would now get lost. The event is now "collection" rather than 
"presence.collection" or whatever. By subscribing to <event>.collection, 
I am asserting that I care about and can do something useful with 
notifies with an event header of <event>. If I susbscrbe to "collection" 
without an event scope, I now have to expect NOTIFY requests for 
arbitrary events.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Sep 2002 23:15:09 -0400

We could do something similar to what I had suggested for the Accept 
header. The SUBSCRIBE has Allow-Events which lists the event types 
supported. If one of the URI in the list is of a type not indicated in 
Allow-Events, the subscription is rejected.

Not quite the intended use of Allow-Events, for sure....

-Jonathan R.

Ben Campbell wrote:
>> collection template that can allow a user to subscribe to a list of 
>> URIs for a particular package, such as presence.
>>
>> for a different package. The list would also include information on 
>> the package that URI is associated with.
>>
>> 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.
>>
>> 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.
>>