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

From: Rohan Mahy <[email-masked]>
Date: Mon, 24 Jan 2005 15:07:34 -0800

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

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Jan 2005 16:22:00 -0600

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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 31 Jan 2005 11:34:28 -0600

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