Subject: [Sip] Stateless Notification and Non-Subscribe subscriptions

From: "Nasir Khan" <[email-masked]>
Date: Fri, 1 Jul 2005 13:35:32 -0700

There is one question that I wanted to get an opinion on and also know
if it was ever discussed at some point (I could not get much from the
archives on this)

RFC 3265 is based on the premise of subscription state that is created
and maintained by SUBSCRIBE/NOTIFY exchange and leverages on SIP Dialog
machinery for ordering etc. This translates to a Dialog state creation
and maintenance at the Subscriber and Notifier end. The question that I
have is "Was a stateless notification service considered in SIP
framework?" 

By stateless notification I mean an entity subscribed to certain events
gets the notifications when the event is generated *without* having to
maintain any dialog state. Usually the notification will have some
semblance of versioning in the body and the consumer (subscriber) will
understand the event package and will be able to discard any
notification of a prior version (if required). 
The motivation for this line of thought is the usage similar to
http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-
06.txt where the information to be notified to the UA is not changing
very frequently but can change anytime, so you need a constant
subscription (infinitely lived) and would end up maintaining
subscription dialogs with very little notifications on that dialog. 

So what I am alluding to is a mechanism (in addition to RFC 3265) where
the SUBSCRIBE request behaves like a REGISTER in the sense that it
installs a subscription with the subscriber (to an abstract subscription
service) *without* creating any dialog, just like REGISTER registers an
AOR to a location service. (This subscription can also be installed by
some non-SIP means as referred to in 3265). When the event is generated
the subscription service sends a NOTIFY, again *without* creating any
dialog. This way the SIP Notification server shall not need to maintain
any state when it doesn't need to, particularly when the event stimulus
comes from outside and SIP Notification server may just send
notifications (by looking up the abstract subscription service if need
be). 

Thanks

Nasir Khan
BEA Systems, Inc.  

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 1 Jul 2005 16:54:25 -0400

> From: Nasir Khan
> maintain any dialog state.

This seems very difficult to do.  A publisher needs to keep a list of all
the subscribers to which it will send notifications.  And since the
publisher needs to be able to forget a subscription if it is not refreshed
after a while, the subscribers need to remember to refresh their
subscriptions.  Both of these require state.

The PUBLISH method avoids these problems, but in effect, by provisioning the
list of subscribers rather than constructing it dynamically.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Jul 2005 18:05:04 -0400

I will second Dale. I think of REGISTER as creating a sort of "poor 
man's dialog". Were we to start over I don't think you would see 
REGISTER again in its current form, but it is grandfathered in now.

Also, the way register works is based on the assumtion that REGISTER 
messages will not be forked to different candidate registrars. If that 
did happen, then register refreshing would not work right. You can't 
make the same assumption about subscriptions, so you need to retain the 
route to the server in order to properly refresh.

I've been having other discussions with people about "implicit 
subscription" or "unsolicited notification". These are all driven by the 
same desire to get rid of some state or the messages that establish it. 
For instance lots of people want to avoid the subscription for MWI.

But as yet nobody has proposed a viable way to do it. Stuff has been 
implemented to do this, but the cases I am aware of are hacks with major 
limitations.

I don't think a solution that requires "some" dyanmic state, but less 
that a dialog, is an interesting solution.

The most interesting case where I think it might be possible to come up 
with a solution is when the notifier knows a priori that it wants to 
notify all registered contacts for its own AoR. In that case the 
notifier has statically provisioned state about its own AoR and the need 
to notify that, but no dynamic state. (The MWI is an example of this 
case.) But I haven't yet found a good solution for even this case.

	Paul

---

From: "JOHN J. BARTON" <[email-masked]>
Date: Fri, 01 Jul 2005 17:00:27 -0700

I notice that Nasir specifically said "dialog state".  Perhaps he 
considers dialog state somehow different from the state needed to
maintain a subscription (expires, address, event I guess).

-- 
John J. Barton              IBM Almaden Research Center
http://www.almaden.ibm.com/cs/people/bartonjj/index.htm