> RFC3261 has a specific error for this: 420 (Bad Extension). OK, excellent. Sorry to have gone on about this but SIP is a big mouthful for a generalist reviewer.
Regards Brian Carpenter On 07/12/2012 15:59, Paul Kyzivat wrote: > 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 < >>> [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
