Subject: [Sip] Refer status/adjustment

From: Robert Sparks <[email-masked]>
Date: 12 Jun 2002 13:49:35 -0500

A set of converging concerns were raised about the 
REFER draft late in the review process, all centering
on draft's use of sip-events (soon to be RFC3265) and
the implicit subscription.

When investigating those concerns, several things became
clear. 

The draft did not provide sufficient discussion
around managing the lifecycle of the implicit subscription
(Can you refresh the implicit subscription? unsubscribe?
 How is the Subscription-State header supposed to be used?
 How do the two parties know when the subscription is over?)
and the draft did not clearly specify some of the things
RFC3265 requires of an event package. These need to be
corrected.

A larger issue centers around the following language from
sip-events:

  Note that any behavior designated with "SHOULD" or "MUST" in this
  document is not allowed to be weakened by extension documents;
  however, such documents may elect to strengthen "SHOULD"
  requirements to "MUST" strength if required by their application.

The current draft is not clear enough on one particular point - the
examples do not show immediate NOTIFYs for the implicit subscription.
I expect that many members of the community believe they are not 
required (I had drifted into thinking that way before the comments
caused me to look at this more closely). The normative text in the
current REFER draft calls to RFC3265, and immediate NOTIFYs are very
clearly required there. This needs to be pointed out more clearly
in the REFER draft.

Finally, the current draft makes instantiating a subscription a
SHOULD strength requirement, but provides no mechanism for the
agent sending the REFER to know whether or not to expect a NOTIFY.
We have repeatedly had discussions on the list about how long
the agent sending the REFER should keep state waiting for a NOTIFY -
and with discomfort deciding that is an implementation decision. 
Recent discussions have pointed out that there is disagreement about
what never receiving a NOTIFY means - should the REFERing party treat
that as an error and re-attempt the reference or should it just
assume no subscription was created? 

I've put together an individual submission that adds all the
above clarifications. It also proposes a new mechanism to 
address the problems in the previous paragraph. Basically, it
provides a way for the party sending the REFER to indicate
that it really wants to be notified, and a way for the agent
accepting the refer to signal that it will or will not send
notifies in the response to the REFER.

I just submitted this draft - until it appears in the repository,
you can get it from
http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt

I propose that this draft replace refer-05 before it advances further
in the standardization process.

RjS

_______________________________________________
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