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

[Brett Tate <[e-mail]>]

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

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