Subject: [sipcore] Open issue in refer-explicit-subscriptions

From: Robert Sparks <[email-masked]>
Date: Mon, 03 Nov 2014 15:08:35 -0600

-02 calls out one open issue - better aligning with 3261 
Supported/Require definitions, and using 421 correctly.

As most folks know, there has been many threads on the semantics of 
Supported and Require. We're avoiding the problems most of those threads 
call out by being very specific with when this extension can be used, 
and what to put in the messages when it is used. We're almost aligned 
with what's in 3261, but Ivo called my attention some time back to a 
rough edge with responses. Section 8.1.1.9 of RFC3261 requires 
responders to list any extensions applied to a result in a Require 
header field. Now we could burn a _lot_ more time arguing about whether 
doing so is worthwhile since we can only apply this extension if it was 
Required in a request, but I don't think it's worth the effort.

Instead, I think the following replacement for section 6 of the draft 
gets us to a place where we aren't in conflict with any 3261 text. You 
can find a side-by-side diff of this suggestion against the current 
section at <http://www.nostrum.com/~rjsparks/diff_before_after.html>.

If this works for folks, then I don't think we need time in Honolulu to 
discuss it.

------

6. The 'explicitsub' and 'nosub' Option Tags

    This document defines the 'explicitsub' option tag, used to signal
    the use of the extension defined in Section 4, and the 'nosub' option
    tag, used to signal the use of the extension defined in Section 5.

    The use of either option tag in a Require header field is only
    defined when it appears in a REFER request or a response to a
    REFER request.  A UA MUST NOT include the 'explicitsub' or 'nosub'
    option tag in the Require header field of any request other than
    REFER.  A UA MUST NOT include the 'explicitsub' or 'nosub' option
    tag in the Require header field of any SIP response other than a
    200 or 421 response to a REFER request.

    The 'explicitsub' and 'nosub' option tags MAY appear in the Supported
    header field of SIP messages, and in sip.extensions feature tag
    defined in [RFC3840].  This signals only that the UA including the
    value is aware of the extensions.  In particular, a UA can only
    invoke the use of one of the extensions in a request.  A UA MUST NOT
    include either option tag in the Require header field of a 200 response
    to a REFER request if that tag was not present in the Require header 
field
    of the request. A User-Agent Server (UAS) that is processing a REFER
    request that lists 'explicitsub' or 'nosub' in its Supported header 
field
    and wishes to use one of those extensions will return a 421 response
    indicating which extension is required.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Nov 2014 08:09:11 +0000

Hi,

In general I am ok with the approach seen in the diff.

However, related to the semantics, I think we in section 6 should make it more clear that, when present in the Require header field, the semantics means “MUST SUPPORT *AND* MUST USE”.

That could be done e.g. by extending the following sentence:

                  “The use of either option tag in a Require header field is only defined when it appears in a REFER request.”

…to:

                “The use of either option tag in a Require header field is only defined when it appears in a REFER request, and indicates that the receiver, if it accepts the request, must support and use the extension associated with the option-tag.”

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 3. marraskuuta 2014 23:09
To: [email-masked]
Subject: [sipcore] Open issue in refer-explicit-subscriptions

-02 calls out one open issue - better aligning with 3261 Supported/Require definitions, and using 421 correctly.

As most folks know, there has been many threads on the semantics of Supported and Require. We're avoiding the problems most of those threads call out by being very specific with when this extension can be used, and what to put in the messages when it is used. We're almost aligned with what's in 3261, but Ivo called my attention some time back to a rough edge with responses. Section 8.1.1.9 of RFC3261 requires responders to list any extensions applied to a result in a Require header field. Now we could burn a _lot_ more time arguing about whether doing so is worthwhile since we can only apply this extension if it was Required in a request, but I don't think it's worth the effort.

Instead, I think the following replacement for section 6 of the draft gets us to a place where we aren't in conflict with any 3261 text. You can find a side-by-side diff of this suggestion against the current section at <http://www.nostrum.com/~rjsparks/diff_before_after.html><http://www.nostrum.com/~rjsparks/diff_before_after.html>.

If this works for folks, then I don't think we need time in Honolulu to discuss it.

------

   to a REFER request if that tag was not present in the Require header field
   request that lists 'explicitsub' or 'nosub' in its Supported header field

---

From: Robert Sparks <[email-masked]>
Date: Thu, 06 Nov 2014 13:24:18 -0600

I really think the document covers this.

If the receiver accepts the request, and doesn't use the extension, it 
will violate one or more MUST requirements already in the document.
Saying more risks providing a place to argue (and for implementers to 
disagree) about what "use" means.

What do you see going wrong if we leave the text as is?

RjS

On 11/4/14 2:09 AM, Christer Holmberg wrote:
> However, related to the semantics, I think we in section 6 should make 
> it more clear that, when present in the Require header field, the 
> semantics means “MUST SUPPORT **AND** MUST USE”.
>
>   “The use of either option tag in a Require header field is only 
> defined when it appears in a REFER request.”
>
> …to:
>
>               “The use of either option tag in a Require header field 
> is only defined when it appears in a REFER request, and indicates that 
> the receiver, if it accepts the request, must support and use the 
> extension associated with the option-tag.”
>
> Regards,
>
> Christer
>
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Robert 
> Sparks
> *Sent:* 3. marraskuuta 2014 23:09
> *To:* [email-masked]
> *Subject:* [sipcore] Open issue in refer-explicit-subscriptions
>
> Supported and Require. We're avoiding the problems most of those 
> threads call out by being very specific with when this extension can 
> be used, and what to put in the messages when it is used. We're almost 
> aligned with what's in 3261, but Ivo called my attention some time 
> back to a rough edge with responses. Section 8.1.1.9 of RFC3261 
> requires responders to list any extensions applied to a result in a 
> Require header field. Now we could burn a _lot_ more time arguing 
> about whether doing so is worthwhile since we can only apply this 
> extension if it was Required in a request, but I don't think it's 
> worth the effort.
>
> section at <http://www.nostrum.com/~rjsparks/diff_before_after.html> 
> <http://www.nostrum.com/%7Erjsparks/diff_before_after.html>.
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Nov 2014 19:42:52 +0000

Hi,

>If the receiver accepts the request, and doesn't use the extension, it will violate one or >more MUST requirements already in the document.
>Saying more risks providing a place to argue (and for implementers to disagree) >about what "use" means.
>
I just want to avoid future discussions (similar to ones we have had in the past) about whether Require for these tags only means must support, or must support or use.
Regards,
Christer

…to:

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 3. marraskuuta 2014 23:09
To: [email-masked]<mailto:[email-masked]>
Subject: [sipcore] Open issue in refer-explicit-subscriptions

Instead, I think the following replacement for section 6 of the draft gets us to a place where we aren't in conflict with any 3261 text. You can find a side-by-side diff of this suggestion against the current section at <http://www.nostrum.com/~rjsparks/diff_before_after.html><http://www.nostrum.com/%7Erjsparks/diff_before_after.html>.

------

---

From: Robert Sparks <[email-masked]>
Date: Thu, 06 Nov 2014 13:58:19 -0600

On 11/6/14 1:42 PM, Christer Holmberg wrote:
> will violate one or >more MUST requirements already in the document.
> disagree) >about what "use" means.
> >
> I just want to avoid future discussions (similar to ones we have had 
> in the past) about whether Require for these tags only means must 
> support, or must support or use.
>
I hear that. Lets see if we can come up with something in the hallway to 
bring back to the list that raises that highlight without adding the 
risk I point to above.
>     However, related to the semantics, I think we in section 6 should
>     make it more clear that, when present in the Require header field,
>     the semantics means “MUST SUPPORT **AND** MUST USE”.
>
>                   “The use of either option tag in a Require header
>     field is only defined when it appears in a REFER request, and
>     indicates that the receiver, if it accepts the request, must
>     support and use the extension associated with the option-tag.”
>
>     Regards,
>
>     Christer
>
>     *From:*sipcore [mailto:[email-masked]] *On Behalf Of
>     *Robert Sparks
>     *To:* [email-masked] <mailto:[email-masked]>
>     As most folks know, there has been many threads on the semantics
>     of Supported and Require. We're avoiding the problems most of
>     those threads call out by being very specific with when this
>     extension can be used, and what to put in the messages when it is
>     used. We're almost aligned with what's in 3261, but Ivo called my
>     attention some time back to a rough edge with responses. Section
>     8.1.1.9 of RFC3261 requires responders to list any extensions
>     applied to a result in a Require header field. Now we could burn a
>     _lot_ more time arguing about whether doing so is worthwhile since
>     we can only apply this extension if it was Required in a request,
>     but I don't think it's worth the effort.
>
>     Instead, I think the following replacement for section 6 of the
>     draft gets us to a place where we aren't in conflict with any 3261
>     text. You can find a side-by-side diff of this suggestion against
>     the current section at
>     <http://www.nostrum.com/~rjsparks/diff_before_after.html>