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

From: Brett Tate <[email-masked]>
Date: Mon, 10 Nov 2014 14:07:02 -0500

Hi,

The following are some comments concerning
draft-sparks-sipcore-refer-explicit-subscription-02.

Thanks,
Brett

-------

If something within this draft allows a RFC 6665 compliant notifier to not
supply a GRUU Contact within call's dialog, please clearly indicate it.
For instance if true, indicate that the notifier is not required to supply
a GRUU Contact if notifier supports 'nosub' (even if referrer does not
support 'nosub').

Section 6 indicates the following:

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

 OPEN ISSUE: This description of the use of 421 is not yet perfectly
 aligned with RFC3261's definition."

I think that the open issue should be closed by not mandating the 421
response (at least if REFER was sent within dialog).  Similar to the RFC
3262 behavior, the UAS can indicate it is being used by including
option-tag within Require header of 2xx response.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Nov 2014 09:13:02 -1000

> option-tag within Require header of 2xx response.
Hi Brett -

I sent text last week proposing how to address this (Subject 'Open issue 
in refer-explicit-subscriptions').
Was that text problematic for you?

RjS

---

From: Brett Tate <[email-masked]>
Date: Mon, 10 Nov 2014 15:19:51 -0500

Hi Robert,

Thanks for the response; reply is inline.

> > If something within this draft allows a RFC 6665 compliant notifier to
> > not supply a GRUU Contact within call's dialog, please clearly indicate
> > it.
> > For instance if true, indicate that the notifier is not required to
> > supply a GRUU Contact if notifier supports 'nosub' (even if referrer
> > does not support 'nosub').
> >
> I sent text last week proposing how to address this
> (Subject 'Open issue in refer-explicit-subscriptions').

The proposal continues to mandate that the option-tag only be honored if
received within a Require header of REFER.

If REFER is received within dialog, mandating that the UAS return a 421
appears to do nothing but require extra messaging for those attempting to
use it.  I recommend allowing behavior similar to RFC 3262 so that the
option tag can be within Supported of mid-dialog REFER and Require of
REFER's 2xx response.

Thanks,
Brett

---

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Nov 2014 10:23:49 -1000

> option tag can be within Supported of mid-dialog REFER and Require of
We _specifically_ avoided that design. It takes us into the "I don't 
know if this
will create a subscription or not when I send the REFER" territory.

You have Supported around _before_ you get to sending the REFER require
to help you avoid discovering lack of support by trying to require it if
you care about that extra messaging.

---

From: Brett Tate <[email-masked]>
Date: Mon, 10 Nov 2014 15:54:57 -0500

> > The proposal continues to mandate that the option-tag only be honored
> > if received within a Require header of REFER.
> >
> > If REFER is received within dialog, mandating that the UAS return a
> > 421 appears to do nothing but require extra messaging for those
> > attempting to use it.  I recommend allowing behavior similar to RFC
> > 3262 so that the option tag can be within Supported of mid-dialog
> > REFER and Require of REFER's 2xx response.
>
> know if this will create a subscription or not when I send the REFER"
>territory.

If referrer sends a REFER within dialog without using the Require, they know
that it might create a subscription since they don't know if the option-tag
is supported.  The 2xx response can indicate if it did create a subscription
by supplying Require indicating what occurred.

If the desire is to allow RFC 6665 compliant device to send REFER over
dialog during GRUU situation, they would need to use the Require (AFAIK).

I still haven't noticed how the draft avoids RFC 6665 compliant notifier
from needing to supply GRUU Contact within call dialog.

> You have Supported around _before_ you get to sending the REFER
> require to help you avoid discovering lack of support by trying to
> require it if you care about that extra messaging.

If the REFER was sent within dialog, the lack of support/use would be
observed by receiving REFER's 2xx response without Require option-tag.

The referrer can use Require when REFER sent outside of dialog (or within
dialog if desired) if they want to avoid ambiguity during forking situation.

Thanks,
Brett

---

From: Robert Sparks <[email-masked]>
Date: Mon, 10 Nov 2014 11:19:01 -1000

>> know if this will create a subscription or not when I send the REFER"
So, there are two things I think you're trying to talk about. I'm going 
to draw
lines around them just to double-check that I'm hearing you correctly.

First is the suggestion to change how we're using Supported/Require.

I don't understand yet why you would _want_ to send a REFER with
Supported: explicitsub and learn later whether the other side chose
to use an implicit subscription or an explicit subscription, signaled
in the 200 OK to the REFER.

Essentially, you are positing "I don't care as a client, you choose as
the server". I don't think we have a need for that, and trying to support
something like it is what led norefersub to being what it is.

It's even _less_ obvious what the semantic would be if you did this with
nosub.

When you are in a dialog, you have the opportunity to see that the extension
is supported before you start preparing your in-dialog refer by watching 
Supported
in the transactions earlier in the dialog. If your peer hasn't been 
playing nicely and
telling you about what it supports, you can probe by  sending the REFER 
with the
require and see the 421. That is not new behavior defined by this draft 
- it's basic 3261.

Our case here is different from 100rel. The semantic there is that the 
server gets to
invoke _using_ the extension because it's the thing that knows whether the
extension is needed. It's been a fundamental point of this proposal from 
the beginning
that this is a decision that the client is going to make.
> dialog during GRUU situation, they would need to use the Require (AFAIK).
If I'm reading you correctly, your second comment is that the draft isn't
clear enough that if you are requiring explicitsub (or nosub), the REFER
request itself isn't bound by the requirements of 3265 since its contact
isn't used in setting up a subscription. I'll go look at the draft between
meetings (I'm in other sessions right now), and see if I can pump that up.

---

From: Brett Tate <[email-masked]>
Date: Tue, 11 Nov 2014 07:39:20 -0500

Hi,

> >>> The proposal continues to mandate that the option-tag only be
> >>> honored if received within a Require header of REFER.
> >>>
> to draw lines around them just to double-check that I'm hearing
> you correctly.
>
> I don't understand yet why you would _want_ to send a REFER
> with Supported: explicitsub and learn later whether the other
> side chose to use an implicit subscription or an explicit subscription,
> signaled in the 200 OK to the REFER.
>
> Essentially, you are positing "I don't care as a client, you choose
> as the server". I don't think we have a need for that, and trying
> to support something like it is what led norefersub to being
> what it is.

That is not my proposal.  If the client cares, they can use Require or not
include option-tag within Supported.  My proposal is that if the client sent
mid-dialog REFER with Supported indicating one or both new option-tags,
there is no reason to mandate returning 421 if the UAS desires to use the
feature.

Why do you want to restrict the functionality so that it can only be used if
option-tag sent within REFER's Require header?  The working group (and RFC
4485) typically discourages the use of Require within requests unless truly
needed.  Depending upon interpretation of RFC 4485's "basic SIP services",
the use of Require is potentially "NOT RECOMMENDED".

> Supported in the transactions earlier in the dialog. If your peer hasn't
> been
> playing nicely and telling you about what it supports, you can probe by
> sending the REFER with the require and see the 421. That is not new
> behavior
> defined by this draft
> - it's basic 3261.

I agree.  However, it isn't basic SIP to restrict option-tag related
functionality to only occur when the request uses the Require header unless
there is truly a need for the restriction.

> server
> gets to invoke _using_ the extension because it's the thing that knows
> whether the extension is needed. It's been a fundamental point of this
> proposal from the beginning that this is a decision that the client is
> going to
> make.

If they want/have to make the decision, they can use the Require.  If they
don't want/need to decide, they should be able to use Supported within
mid-dialog REFER without requiring the subsequent 421 to occur.

> > If referrer sends a REFER within dialog without using the Require,
> > they know that it might create a subscription since they don't know if
> > the option-tag is supported.  The 2xx response can indicate if it did
> > create a subscription by supplying Require indicating what occurred.
> >
> clear
> enough that if you are requiring explicitsub (or nosub), the REFER request
> itself isn't bound by the requirements of 3265 since its contact isn't
> used in
> setting up a subscription. I'll go look at the draft between meetings (I'm
> in
> other sessions right now), and see if I can pump that up.

The draft might be adequate from referrer perspective (I didn't perform a
detailed search).  However as indicated below, I haven't noticed how the
draft enables a RFC 6665 compliant notifier from needing to supply GRUU
Contact within call dialog (i.e. as mentioned within
draft-sparks-sipcore-refer-clarifications-05 section 3 last paragraph).

> > I still haven't noticed how the draft avoids RFC 6665 compliant
> > notifier from needing to supply GRUU Contact within call dialog.
> >
> >
> > The referrer can use Require when REFER sent outside of dialog (or
> > within dialog if desired) if they want to avoid ambiguity during forking
> situation.
> >
> > Thanks,
> > Brett

---

From: Robert Sparks <[email-masked]>
Date: Thu, 13 Nov 2014 09:13:14 -1000

I think I found our disconnect:

On 11/11/14 2:39 AM, Brett Tate wrote:
> option-tag sent within REFER's Require header?
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.

> The working group (and RFC
> needed.
Preventing the dialog reuse is the essence of "needed" here.
>    Depending upon interpretation of RFC 4485's "basic SIP services",
This is confused, or I'm not following what you're looking for yet.

The point is that if you send a REFER within a dialog using these 
extensions,
you are guaranteed to not engage in sip-events as part of this dialog, 
so the
6665 requirements on what contact you provide in this dialog do not kick in.

The fact that the endpoint is otherwise an RFC6665 compliant notifier isn't
relevant to the dialog in this case (unless it might enter into _other_ 
sip-event
dialog-usages as part of this dialog.
>>> within dialog if desired) if they want to avoid ambiguity during forking
Thanks for helping work this through,

RjS