Re: [Gen-art] Gen-ART LC review of draft-hanes-dispatch-fax-capability-06.txt

[Paul Kyzivat <[e-mail]>]

On 12/7/12 8:44 AM, Brian E Carpenter wrote:
> Kevin,
>
> Actually it looks to me as if this error case is underspecified in
> RFC 3840, which says:
>
>     The REGISTER request MAY contain a Require header field with the
>     value "pref" if the client wants to be sure that the registrar
>     understands the extensions defined in this specification.  This means
>     that the registrar will store the feature parameters, and make them
>     available to elements accessing the location service within the
>     domain.  In the absence of the Require header field, a registrar that
>     does not understand this extension will simply ignore the Contact
>     header field parameters.
>
> However, I can't see any description of what happens in the failure
> case (Require="pref" but the registrar does not understand). Maybe
> it's supposed to be a 400 response, but I'm not sure that follows
> inevitably from RFC 3840 and 3261.

RFC3261 has a specific error for this: 420 (Bad Extension).
This very standard behavior. There is no need for drafts that specify 
use of Require to spell this out.

	Thanks,
	Paul

> That isn't a problem that the current draft can fix. When the draft
> appears on the IESG agenda, I will update my review accordingly.
>
> Thanks
>     Brian Carpenter
>
> On 07/12/2012 11:22, Kevin Fleming wrote:
>> Paul already answered this question to Brian's satisfaction yesterday.
>>
>>
>> On Fri, Dec 7, 2012 at 4:01 AM, Gonzalo Camarillo <
>> [e-mail]> wrote:
>>
>>> Hi Paul,
>>>
>>> [I am adding Paul to this thread since he was a coauthor of RFC 3840]
>>>
>>> please, see below the exchange between Brian and Kevin regarding
>>> draft-hanes-dispatch-fax-capability-06.txt.
>>>
>>> This was Brian's original comment:
>>>
>>>> Minor issue:
>>>> ------------
>>>>
>>>>     ... A UA
>>>>     preferring the reception of fax calls MUST include the "sip.fax"
>>>>     media feature tag in the Contact header field of REGISTER messages.
>>>>     To confirm the registration of this preference, a SIP [RFC3261]
>>>>     Registrar MUST then include this tag in the Contact header field of
>>>>     its 200 OK response.
>>>>
>>>> If the Registrar does not do this (e.g. because it hasn't been updated
>>>> to support the new tag), what does the UA do when it receives the
>>>> 200 OK response that doesn't include the tag?
>>> Paul, can you share your views on this issue?
>>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>>
>>> On 05/12/2012 6:02 PM, Brian E Carpenter wrote:
>>>> On 05/12/2012 14:12, Kevin Fleming wrote:
>>>>> I suppose it could choose to unregister and re-register in some other
>>> way
>>>>> in order to achieve its goals of receiving FAX calls, if it was
>>> configured
>>>>> with enough network information to do so.
>>>>>
>>>>> Now that I think about it some more, is a registrar even allowed to
>>> return
>>>>> a Contact header that differs from the one the UA supplied in its
>>> REGISTER
>>>>> request? I suspect this is *not* allowed, and so if the registrar
>>> supports
>>>>> Caller-Pref but the specific tag(s) in question fail some sort of
>>>>> validation process, its only recourse would be to fail the REGISTER
>>> request
>>>>> with a suitable error response.
>>>> If that's the standard behaviour, it would of course answer my question.
>>>>
>>>>     Brian
>>>>
>>>>>
>>>>> On Wed, Dec 5, 2012 at 6:35 AM, Brian E Carpenter <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> On 05/12/2012 11:01, Kevin Fleming wrote:
>>>>>>> The language in RFC 3840 doesn't appear to contemplate the situation
>>>>>> you've
>>>>>>> proposed. In its world, registrars can either support prefs (and will
>>>>>>> accept "Require: pref") or they don't, and they don't have knowledge
>>> of
>>>>>>> which feature tags are registered with IANA and which are not. Of
>>> course,
>>>>>>> they *coud* attempt to validate the tags expressed by the UA, but I
>>> don't
>>>>>>> see an explicit way for the registrar to indicate that the UA included
>>>>>>> disallowed tags in its request.
>>>>>> Understood, but in that case I don't see what good the confirmation
>>>>>> of the tag from the registrar to the UA achieves - the UA is not going
>>>>>> to be able to do anything with it (except maybe log whether it was
>>>>>> received).
>>>>>>
>>>>>>      Brian
>>>>>>
>>>
>>
>