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

From: Brett Tate <[email-masked]>
Date: Fri, 14 Nov 2014 09:00:56 -0500

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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Nov 2014 13:50:13 -0600

>   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

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Nov 2014 14:14:26 -0600

Replying to the other section of this mail (and snipping the part I just 
replied to):

> Hi,
<snip/>
> notifier supports 'nosub' (even if referrer does not support 'nosub').
Ah - ok - I think I understand, and I think I can build clearer text.

Nothing in draft-sparks-sipcore-refer-explicit-subscription will allow
an RFC 6665 compliant notifier to not supply a GRUU Contact withing a call's
dialog. What it does do is allow that endpoint to avoid becoming an RFC6665
notifier in the context of this dialog.

The statement about relaxing needs to make it clear that since the REFER
request cannot create an implicit subscription, accepting it doesn't 
make you
a notifier. In fact, SIP events is not involved at all, so none of 
requirements
in 6665 don't come to bear. I'll work on building words that makes that 
more obvious.