Re: [Sip] RE: Stateless Notification and Non-Subscribe subscriptions

Dale Worley wrote:

>But how to maintain the state that user foo@bar wants notification of X?  In
>practice this is often done by provisioning (foo goes to a web page to
>update his list of notifications), because the overhead cost of having an
>obsolete notification request in the database is small.  But we might want
>to use some variant of SUBSCRIBE to maintain notifications.
>  
>
I'd like to counter-propose a "subscription aggregator" -- that is, 
allow a single SUBSCRIBE request to establish a dialog upon which 
notifications for multiple event
sources might occur.

One might then define a metapackage that includes, for example, 
subscription to reg-event, mwi, config, presence resource-list, and all 
the other things that a UA might subscribe to on startup.

Jonathan has proposed making REGISTER create a dialog for the servicing 
of subscriptions. I think an aggregator would be much cleaner.

Now, as o how it might work -- the set of subscriptions to be aggregated 
should be defined dynamically. One idea would be to use the body of the 
SUBSCRIBE request to contain a URI list, with each such URI representing 
a resource to be SUBSCRIBEd to. This approach is consistent with the URI 
list work:
see 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-uri-list-subscribe-03.txt

Another approach would be to use a server-contained list that would be 
modified using XCAP. This is closer to the orignal resource-list work.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip