Subject: RE: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Ref er status/adjustment]

From: "Sriram Parameswar" <[email-masked]>
Date: Mon, 24 Jun 2002 17:23:48 -0500

Robert,

Apologize for the delay in submitting comments - was on an extended
vacation. I have not fully caught up on my email so please pardon any
duplicate comments. Here goes:

1. The entity sending the REFER uses the Supported header with a option tag
'referevent' to which the responding UA sends the Require with referevent in
the 202. Given the way Supported and Require are defined in Bis09/3261 - it
does not allow the entity sending the REFER to invoke the following semantic
"If you are not going to be able to send a NOTIFY then dont process the
REFER". For this semantic we need the UA sending the REFER to be able to use
Require: referevent, or define another mechanism to do so.

2. Question - if there are multiple REFER's and you want to unsubscribe to a
particular REFER in that set, how is that possible? I am guessing the 'id'
associated with the REFER could be reflected in event of the SUBSCRIBE
(Event: refer; id=1234) - that would be one way to do it. At any rate - we
need a mechanism to perform selective unsubscribe and to be noted in the
draft.

3. Sec 3.10 - do we need a way for the REFER initiator to be able say -
"Just send me the immediate and final NOTIFYs only and none of the
intermediate NOTIFYs" and vice-versa i.e. indicate its interest in
intermediate NOTIFYs. I see some usefulness in such a mechanism, this allows
the REFER initiator control over the number/type of notifications he will
receive.

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-684-3986
Nortel Networks, Richardson USA  Email: [email-masked]

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Monday, June 17, 2002 9:14 AM
To: [email-masked]
Subject: IMPORTANT: Comments on REFER changes needed : [Fwd: [Sip] Refer
status/adjustment]

The message I sent last week (copied below) 
has generated no list comments. I hope it
was because I was too subtle with the subject
line.

I have asked the IESG to delay their consideration
of the REFER draft until these concerns have been
discussed on this list.

Please read the draft below and comment. If you 
agree with what's in the draft, please post a
note saying so.

RjS

-----Forwarded Message-----

> From: Robert Sparks <[email-masked]>
> To: [email-masked]
> Subject: [Sip] Refer status/adjustment
> 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

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 25 Jun 2002 10:17:07 -0500

On Mon, 2002-06-24 at 17:23, Sriram Parameswar wrote:
> 1. The entity sending the REFER uses the Supported header with a option
> tag 'referevent' to which the responding UA sends the Require with
> referevent in the 202. Given the way Supported and Require are defined
> in Bis09/3261 - it does not allow the entity sending the REFER to invoke
> the following semantic "If you are not going to be able to send a NOTIFY
> then dont process the REFER". For this semantic we need the UA sending
> the REFER to be able to use Require: referevent, or define another
> mechanism to do so.

Require: referevent is the right way to do what you want to do. The
draft doesn't preclude that normal use of Require in a request. I'll
add text explicitly calling it out.

> 
> 2. Question - if there are multiple REFER's and you want to unsubscribe
> to a particular REFER in that set, how is that possible? I am guessing
> the 'id' associated with the REFER could be reflected in event of the
> SUBSCRIBE (Event: refer; id=1234) - that would be one way to do it. At
> any rate - we need a mechanism to perform selective unsubscribe and to
> be noted in the draft.

Your guess of using the id parameter was correct. Again, I'll add text
making that explicit.

> intermediate NOTIFYs. I see some usefulness in such a mechanism, this
> allows the REFER initiator control over the number/type of notifications
> he will receive.

We're seeing a similar kind of pressure in other event packages. Often
its called event-filtering. I'm still not sure whether a filter approach
or a separate event is the better approach. In any case, this problem
is not an event refer specific one, so we shouldn't solve it in this
draft.
> From: Robert Sparks [ mailto:[email-masked]
> <mailto:[email-masked]> ] 
> <http://www.nostrum.com/~rjsparks/draft-sparks-sip-refer-3265disc-00.txt
> >  
> > 
> <https://www1.ietf.org/mailman/listinfo/sip>  
> <https://www1.ietf.org/mailman/listinfo/sip>