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 < > [email protected]> 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 < >>>> [email protected]> 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 >>>>> >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
