Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments

[Robert Sparks <[e-mail]>]

On 11/14/14 8:00 AM, Brett Tate wrote:
> Hi,
>
> Thanks for the response; reply is inline.
>
>> So that you don't end up with dialog reuse, which is an essential
>> goal of this extension.  If you allow the case you're suggesting,
>> where the REFER only contains Supported: explicitsub
>> and the server didn't implement the extension, or just chose
>> not to use it, then you end up with a shared dialog via an implicit
>> subscription.
> 1) RFC 6665 specifies that the referrer cannot send REFER over the dialog if
> target is a GRUU.
>
> 2) Draft-sparks-sipcore-refer-explicit-subscription section 6 allows number
> 1 to be ignored by sending REFER without Require and with Supported.
> Supposedly this is because the referrer is aware that one or both of the
> option tags are supported.
>
> "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."
I don't see how that text allows you to ignore 1). If I'm missing that,
please point it out and we'll fix it.

If you're in an INVITE dialog whose peer has provided a GRUU contact,
and you construct a REFER, and there's any chance you might create an
implicit subscription, you have to send it out of dialog. I don't see where
you draw the conclusion that allowing these tokens in Supported changes
that. To make sure I'm being clear, this means that you MUST NOT send
that REFER in-dialog with either of these tokens only in a Supported 
header,
because the far end has the option to create an implicit subscription, and
the draft already covers that case.

You _could_ chose to send the out-of-dialog refer with one of the tokens
in Supported, and none in Require. As the document is currently written,
the peer could choose to accept the REFER without invoking the extension,
creating a dialog through the implicit subscription that results. If the 
peer
was unwilling to do that, and wanted to use the extension, it would return
the 421 saying to do so.

I think your argument, then, reduces to the opportunity for optimizing
out the 421 and resubmission of REFER in that out-of-dialog case.
I don't believe we need that optimization, but the group should discuss it.

For completeness, if you're talking about an in-dialog REFER where the
peer has _not_ provided a GRUU as his contact, you're talking to a peer
that has not implemented 6665 yet - the backwards-compatibility
fallback is for things that are already deployed and that don't know
that the standard has moved on. Such things aren't going to know these
extensions either.


>
> 3) When number 2 occurs for a mid-dialog REFER,

>   the draft mandates returning
> 421 instead of allowing returning a 2xx with Require header containing the
> selected option-tag.
>
> I'm saying that number 3 is useless extra messaging.  Number 2 was compliant
> or non-compliant; there is no reason to require returning 421 since the 2xx
> can communicate the selected behavior.

>
>
>>> The working group (and RFC4485) typically discourages the
>>> use of Require within requests unless truly needed.
>> Preventing the dialog reuse is the essence of "needed" here.
> Number 2 was compliant or non-compliant; number 3 does not rectify anything.
>
> <snip>
>
>
>> This is confused, or I'm not following what you're looking for yet.
> Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the
> following.
>
> "A UA that will accept a REFER request needs to include a GRUU in the
>   Contact header field of all INVITE requests.  This ensures that out-
>   of-dialog REFER requests corresponding to any resulting INVITE
>   dialogs arrive at this UA.  Future extensions (such as
>   [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this
>   requirement by defining a REFER request that cannot create an
>   implicit subscription."
>
> If something within draft-sparks-sipcore-refer-explicit-subscription allows
> a RFC 6665 compliant notifier to not supply a GRUU Contact within call's
> dialog, please clearly indicate it.  For instance if the following is true,
> indicate that the notifier is not required to supply a GRUU Contact if
> notifier supports 'nosub' (even if referrer does not support 'nosub').
>
> Thanks,
> Brett