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

[Robert Sparks <[e-mail]>]

On 11/10/14 10:19 AM, Brett Tate wrote:
> 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').
>>>
>>> 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.
>> 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?
> 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.

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.
>
> Thanks,
> Brett