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

[Brian E Carpenter <[e-mail]>]

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.

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