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

[Jonathan Rosenberg <[e-mail]>]

comments:

1. the title should indicate that this draft has something to do with SIP.

2. Abstract is too short. It will be bounced by rfc-ed in this form. You 
need to provide a little more context here.

Propose:

The REFER method has been defined for the Session Initiation Protocol 
(SIP) for the purposes of asking a user agent to generate a request to a 
specified Uniform Resource Identifier (URI). Sending a REFER request 
creates an implicit subscription that allows the referor to get updates 
on the status of the request generated by the REFER. However, experience 
has shown that in many cases this implicit subscription is not 
desirable. This specification defines a new SIP option tag value that 
causes the recipient of the REFER to suppress the implicit subscription.

3. The introduction seems stranded without the motivation. I would 
rename "Motivation" to "introduction" and copy the only paragraph in the 
introduction to the end of the motivation section.

> REFER-Recipient to the REFER-Issuer.  The REFER-Recipient may choose
>     to cancel the implicit subscription with this NOTIFY.  

by setting the Subscription-State header field value in the NOTIFY to 
"terminated".

> 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.

I think we need to say how it knows that. Sending the REFER to the GRUU 
is one way. Its really the only reliable way I think....

>  The REFER-Issuer can place the "norefersub" option tag either in the
>     Require header or in the Supported header of the REFER request,
>     subject to application requirements.

note on terminology: the right term here is "header field" and not 
"header". "header" refers to everything from the start line to the 
message body, and thus includes all of the header fields.

> 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.
> 

This is not correct usage of Supported/Require. If you place Supported 
in a request, it means that an extension is understood. If the server 
sends a response which requires that the client understand the extension 
in order to process it, it includes a Require in the response. Thus, in 
the case above, the norefersub needs to appear in a Require in the 2xx, 
not a Supported.

That said, I see little value in having the REFER-Recipient make the 
choice about whether to create the implicit subscription. Isnt it the 
REFER-issuer that really understands the usage behind the REFER, and 
thus, whether notifies are needed? I'd propose that it be used only in 
the Require header field in the SUBSCRIBE.

> Preventing Forking of REFER Requests
> 
>     The REFER specification allows for the possibility of forking a REFER
>     request which is sent outside of an existing dialog.  The
>     REFER-Issuer can ensure that REFER doesn't get forked by sending
>     REFER to a REFER-Recipient which has GRUU properties according to
>     definitions of [5].

ahh, here is that text. I'd propsoe moving it up into the previous 
section where you say that you MUST only use this when you know it won't 
be forked.

That said, we don't have a way for a UA to look at a URI and determine 
that it has the GRUU property. How then can this requirement be met?

> Example
> 
>     An example of REFER which suppresses the implicit subscription is
>     shown below:
> 
>     REFER sip:[e-mail] SIP/2.0
>     Via: SIP/2.0/TCP issuer.tradewind.com;branch=z9hG4bK-a-1
>     From: <sip:[e-mail]>;tag=1a
>     To: <sip:[e-mail]>
>     Call-ID: [e-mail]
>     CSeq: 234234 REFER
>     Max-Forwards: 70
>     Refer-To: <sip:[e-mail];method=INVITE>
>     Require: norefersub
>     Accept-Contact: *;audio;require
>     Contact: sip:[e-mail]
>     Content-Type: message/sipfrag
>     Content-Id: <[e-mail]>
>     Content-Length: ...

all example messages have to use domains from example.com or 
example.org. You cannot use tradewind.com.

The tag in the From is invalid. It is insufficiently random. See section 
  19.3 of rfc3261. Same with call-id.

The message indicates that the body is a sipfrag, but it is not present 
thus the message is invalid. Why do you want to put a sipfrag in there 
anyway?

The message uses caller prefs headers. I suggest not to do that, it 
complicates the story.

If you use the ellipses (...) to avoid calculating the content-length, 
you must state that explicitly.

> This document defines a new option tag, "norefersub", which specifies
>     that no implicit subscription should be created as a result of
>     accepting the REFER request.  This option tag is only meaningful for
>     the REFER request defined in RFC3515.

this doesn't follow standard templates for iana registrations. I promise 
you will introduce delays like this.

Suggest:

This specification registers a new SIP option tag, as per the
    guidelines in Section 27.1 of RFC 3261.
    Name: norefersub
    Description: This option tag specifies
     that no implicit subscription should be created as a result of
     accepting the REFER request.  This option tag is only meaningful for
     the REFER request defined in RFC3515.


btw, based on this definition even, it only makes sense to place ths in 
Require.

> Security Considerations
> 
>     This extension doesn't introduce new security threads beyond those
>     identified and addressed in the core SIP specifications.

You are going to need to explain why.

> Acknowledgements
> 
>     The SIP community would like to thank Sriram Parameswar for his ideas
>     being originally presented in draft-parameswar-sipping-norefersub-00
>     and incorporated in this document.

usually the acknowledgements are from the authors, not the community. 
its a nit...

> 10.2  Informational References
> 
>     [5]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
>          (UA) URIs (GRUU) in the  Session Initiation Protocol (SIP)",
>          draft-ietf-sip-gruu-02 (work in progress), July 2004.

careful here...

you specify that a client MUST only send a refer to a URI if it doesnt 
fork, and then say later that this is done with gruu. This would make 
gruu a normative reference I think.

-Jonathan R.

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 [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip