Subject: Re: [Sip] Abbreviated WGLC for draft-ietf-sip-refer-with-norefers ub-00.txt

From: Robert Sparks <[email-masked]>
Date: Tue, 1 Feb 2005 15:09:12 -0600

On Feb 1, 2005, at 2:50 PM, Elwell, John wrote:

> Robert,
>
> Section 3, 2nd paragraph: "One purpose of requiring the implicit
> subscription and initial NOTIFY is to allow for the situation where the
> REFER request gets forked and the REFER-Issuer needs a way to see the
> multiple dialogs that may be established as a result of the forked 
> REFER."
> Surely the REFER-Issuer will see the multiple dialogs as a result of
> receiving multiple 2xx responses to the REFER request?

Exactly not.

The issuer will only see one of those 2xx's.
Proxies only return one final response  to
non-INVITE transactions (like REFER).

That's why we have the immediate NOTIFY in SIP Events.

>
> Consequently, concerning the following statement in section 4: "The
> "norefersub" option tag MUST be used by the REFER-Issuer only when the
> REFER-Issuer can be certain that the REFER request will not be 
> forked." - is
> it really necessary for MUST strength?
Yes. For the reason above.

>
> Then at the end of section 4: "If the REFER-Recipient is willing to 
> grant
> the "norefersub" behavior for the issued REFER request, it MUST insert 
> a
> Supported: norefersub header in the 2xx response to the REFER-Issuer.  
> In
> this case no dialog is created."
> Surely a dialog is created by the 2xx response to REFER?

No, that's the point of the extension. No subscription. The norefersub 
REFER is a transaction
that stands alone and doesn't start any new usages (so it can't start 
any new dialogs).

>
> John
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Robert Sparks
>> Sent: 31 January 2005 17:34
>> To: Robert Sparks
>> Cc: SIP WG; Rohan Mahy; Orit Levin; Dean Willis
>> Subject: Re: [Sip] Abbreviated WGLC for
>> draft-ietf-sip-refer-with-norefersub-00.txt
>>
>> The LC the chairs initiated ends today.
>>
>> Please read this draft and comment. It's very short - please do this
>> now.
>>
>> We've talked about this idea a lot - let make sure the talk
>> is captured
>> in the draft.
>>
>> RjS
>>
>> On Jan 26, 2005, at 4:22 PM, Robert Sparks wrote:
>>
>>> Initial LC Comments:
>>>
>>> First paragraph of Section 3 calls out 481ing an initial
>> NOTIFY. The
>>> -dialog-usage-
>>> draft shows that is a bad idea, especially for in-dialog REFERs.
>>> Suggest trimming
>>> the sentence to end after (Expires 0).
>>>
>>> Section 4 fourth paragraph: It would help implementers to call out
>>> explicitly that the
>>> 200 response to the REFER will not contain a Supported or Require
>>> header containing
>>> the norefersub token.
>>>
>>> Section 4 fifth paragraph: This needs more definition. How is it
>>> rejected? 603, 420, or
>>> something else? Implementors will need some guidance here
>> on when to
>>> use which
>>> error response. I think (but am not dead certain at the
>> moment) that
>>> 420 is almost always
>>> what you want to use.
>>>
>>> Section 4 sixth paragraph: Is Supported: in the response
>> really the
>>> right thing? Eventlist
>>> uses Require: in the response to a SUBSCRIBE. The intent of the
>>> normative behavior in
>>> this paragraph is to let a Refer-issuer who only included
>> Supported:
>>> know whether or
>>> not a subscription was actually created. Require: (I'm using this
>>> extension) in the response
>>> fits that better than Supported: (I could use this
>> extension if you
>>> want to).
>>>
>>> Section 4 sixth paragraph: Suggest replacing "In this case,
>> no dialog
>>> is created" with
>>> "In this case, no implicit subscription is created. As a
>> consequence,
>>> no new dialog
>>> is created if this REFER was issued outside any existing dialog."
>>>
>>> Section 5: Probably worth also calling out using
>> Max-Forwards: 0 to
>>> prevent forking
>>> for those (rare now, but hopefully not rare forever) cases where
>>> signaling can get to
>>> the refer target without going through a proxy.
>>>
>>> Section 6: Must replace "tradewind" with "example" throughout.
>>>
>>> Section 8: "threads" should be "threats", It would be good
>> to pull any
>>> discussion
>>> that led to this conclusion together for when the IESG asks if we
>>> _really_ thought
>>> about this. Have we talked about what would happen if a SIP
>>> intermediary (or an
>>> unauthorized MitM) just injected a Require: norefersub into
>> a REFER
>>> request?
>>>
>>> RjS
>>>
>>>
>>> On Jan 24, 2005, at 5:07 PM, Rohan Mahy wrote:
>>>
>>>> Hi Folks,
>>>>
>>>> I'd like to begin an abbreviated WGLC for:
>>>>
>>>> 	http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-with-
>>>> norefersub-00.txt
>>>>
>>>> Since this document is extremely short and has been discussed
>>>> extensively, WGLC will end on February 1st.
>>>>
>>>> thanks,
>>>> -rohan
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> _______________________________________________
>> 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: "Elwell, John" <[email-masked]>
Date: Tue, 01 Feb 2005 20:50:55 +0000

Robert,

multiple dialogs that may be established as a result of the forked REFER."

Consequently, concerning the following statement in section 4: "The
"norefersub" option tag MUST be used by the REFER-Issuer only when the
REFER-Issuer can be certain that the REFER request will not be forked." - is
it really necessary for MUST strength?

Then at the end of section 4: "If the REFER-Recipient is willing to grant
the "norefersub" behavior for the issued REFER request, it MUST insert a
Supported: norefersub header in the 2xx response to the REFER-Issuer.  In
this case no dialog is created."
Surely a dialog is created by the 2xx response to REFER?

John

---

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Feb 2005 15:24:05 -0600

A late thought:

Please point out in the norefersub draft that REFER is a
target refresh request even when this extension is used.

RjS