Subject: [sipcore] Forking and draft-ietf-sipcore-subnot-etags

From: Adam Roach <[email-masked]>
Date: Wed, 22 Apr 2009 11:13:49 -0500

[as an individual participant]

You've probably noticed a new version of the subnot-etags document just 
came out. This version incorporates some changes to resolve a 
last-minute technical issue with the way this document interacts with 
request forking. (There's also an ABNF change, but there's a separate 
thread going on that topic).

In previous versions of the document, the language allowed complete 
suppression of NOTIFY messages except when there were "reportable 
changes in the NOTIFY header". This criteria was somewhat ambiguous in 
the general case of establishing a new subscription (the transition of 
subscription state to "active" technically qualifies as a "reportable 
change in the NOTIFY header", but implementors were left to figure this 
out independently). To complicate matters, there were at least two 
passages in the document that strongly suggested that there may be 
circumstances in which the first NOTIFY in a subscription would be 
completely suppressed, which causes some serious issues with forking.

The complete suppression of NOTIFY messages was also explicit for 
resource state polling, which gives rise to similar issues.

The issue with suppressing the first NOTIFY message in a dialog is that 
a forked SUBSCRIBE message can land on several notifiers, each of whom 
may well accept the subscription. However, due to SIP forking 
processing, only one final response to the SUBSCRIBE will arrive at the 
subscriber.

Under the 3265 model, this is resolved by the use of an immediate NOTIFY 
in the reverse direction -- the subscriber learns about all the 
resulting subscriptions because it receives a NOTIFY message for each 
one. Removing this aspect of subscription establishment basically 
re-creates a variant of the HERFP problem, except much worse: instead of 
failing to learn about various request failures, the subscriber fails to 
learn about various successful dialog establishments.

The most recent version of the document addresses this by:

   1. Cleaning up the passages that implied suppression of the initial
      NOTIFY message in a dialog

   2. Making explicit the previously implicit behavior of not
      suppressing initial NOTIFY message in a dialog

   3. Changing poll behavior to require empty NOTIFY messages instead of
      completely suppressed NOTIFY messages

Only the third change is an actual change in behavior. The first two are 
simply making previously implied behavior explicit.

I realize that this is a bit of deep RFC 3265 arcana, but please weigh 
in on the changes so we can move the document over the finish line soon. 
Thanks!

/a