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

[Robert Sparks <[e-mail]>]

I think I found our disconnect:

On 11/11/14 2:39 AM, Brett Tate wrote:
> Hi,
>
> Thanks for the response; reply is inline.
>
>>>>>> 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.
> 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?
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
> 4485) typically discourages the use of Require within requests unless truly
> needed.
Preventing the dialog reuse is the essence of "needed" here.
>    Depending upon interpretation of RFC 4485's "basic SIP services",
> the use of Require is potentially "NOT RECOMMENDED".
>
>
>> 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.
> 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.
>
>
>> 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 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.
>>>
>>> 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.
> 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).
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.
>
>
>>> 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
Thanks for helping work this through,

RjS