Subject: [Sip] comments on draft-ietf-sip-refer-with-norefersub-02

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 31 Jul 2005 07:31:57 -0400

> The REFER specification specifies that every REFER creates an
>    implicit subscription between the REFER-Issuer and the REFER-
>    Recipient.

You should add a reference to rfc3515 here.

> This document defines a new SIP header field: "Refer-Sub" meaningful
>    within a REFER transaction only.  This header field, when set to
>    "false", specifies that a REFER-Issuer requests that the REFER-
>    Recipient doesn't establish an explicit subscription and the
>    resultant dialog.

s/explicit/implicit

> This document defines a new SIP header field: "Refer-Sub".  This
>    header field is meaningful and MAY be used with a REFER request and
>    the corresponding 2XX response only.  This header field set to
>    "false" specifies that a REFER-Issuer requests that the REFER-
>    Recipient doesn't establish an explicit subscription and the

hmm, same thing here - I wonder if perhaps you are assuming that the 
addition of Refer-Sub makes this an "explicit" subscription? I take 
"explicit" to mean, through a SUBSCRIBE.

>  Refer-Sub             =  "Refer-Sub" HCOLON refer-sub-value extension-value
>     refer-sub-value       =  "true" / "false"
>     extension-value       =  *(TEXT-UTF8char / UTF8-CONT / LWS)

This grammar should follow the standards outlined in 
draft-ietf-sip-guidelines. The above grammar allows for the following:

Refer-Sub: trueHello

and I don't think you want that. I'd suggest:

Refer-Sub        =  "Refer-Sub" HCOLON refer-sub-value *(SEMI exten)
exten = generic-param

> The "Refer-Sub" header field set to "false" MAY be used by the REFER-
>    Issuer only when the REFER-Issuer can be certain that the REFER
>    request will not be forked.

the wording here doesn't provide any strength about knowing whether the 
request will be forked. Is it SHOULD? MUST?

> "Refer-Sub" header field set to "true" in the 2xx response), an
>    implicit subscription is created as in default case.

as in the default case

> If this is not known, the other way to ensure that forking will not
> 
> 
> 
> Levin                   Expires January 18, 2006                [Page 5]
> 
> Internet-Draft       SIP REFER without Subscription            July 2005
> 
> 
>    occur is to ensure that there are no proxies between the REFER-Issuer
>    and the REFER-Recipient.  This could be done by sending the REFER
>    with a Max-Forwards: 0 header field.  Any proxy receiving this
>    request will return a "483 Too Many Hops" response, indicating that
>    it is not safe to use this extension.

this isn't really likely to ever work, since there are just no practical 
use cases these days where there are no proxies.

>  If the capabilities of the REFER-Recipient are not known, using the
>    "norefersub" tag with the Require header field is NOT RECOMMENDED.
>    This is due to the fact that in the event the REFER-Recipient doesn't
>    support the extension, in order to fallback to the normal REFER, the
>    REFER-Issuer will need to issue a new REFER transaction thus
>    resulting in additional round-trips.

might be worth mentioning how the REFER-Issuer can know the 
capabilities. Main one is the presence of the option tag in the 
Supported header field of a dialog initiating request or response. 
Prescaps is the other.

> 6.  Example
> 
>    An example of REFER which suppresses the implicit subscription is
>    shown below:

this example message shows it being sent to sip:[email-masked], which
is probably not a gruu. Since the draft suggests that its primarily 
useful in sending a request to a gruu, I suggest that the syntax follow 
the examples in draft-ietf-sip-gruu.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip