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

[Robert Sparks <[e-mail]>]

On 11/10/14 10:54 AM, Brett Tate wrote:
>>>> Was that text problematic for you?
>>> 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.
>> 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.
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.
> 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).
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.

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