Oops, that crossed with my note. In that case maybe a small clarification *is* needed in the draft.
Regards Brian Carpenter On 07/12/2012 13:19, David Hanes wrote: > Hi Kevin, > > Actually, I had just copied the draft authors on that thread and Brian was > not on it. Below is Paul's response for everyone's clarification. > > Thanks, > David > > > > > > On 12/6/12 12:17 PM, David Hanes wrote: >> Hi Paul, >> >> I am hoping you can lend us a hand in answering a comment from Brian >> Carpenter (attached), who is the Gen-ART reviewer for our draft. Being >> an author of 3840 and instrumental in helping us revise our draft, you >> seem to be the best person to comment here. >> >> In the thread below, Kevin proposes the question, " is a registrar even >> allowed to return a Contact header that differs from the one the UA >> supplied in its REGISTER request?". I think that the answer to this >> question determines how we progress forward in addressing Brian's >> comment. We would appreciate your thoughts and guidance on this when you >> have a moment. > > I'll try. > > RFC 3261 doesn't say anything about the registrar saving or returning contact > parameters, other than the expiration time and q-value. > > RFC 3840 does that. *If* the registrar supports the "pref" option, then it is > required to save the feature parameters (aka feature tags or capabilities), > and to return them in queries. Returning them all is MUST strength, so it > doesn't have the option of selectively removing some. Things are written so > that the registrar need not be aware of *particular* feature tags to support > them. Newly defined ones (such as being defined here) are recognized > syntactically (via the leading "+"). > > If the registrar doesn't support "pref" it may or may not save and return > Contact header field parameters. (It is neither required to do so nor > forbidden from doing so.) In this case, I suppose it also *could* selectively > prune (or add) parameters. > > Also, the registrar has considerable latitude in its operation. As specified > in 3261, it stores the registration bindings in an abstract location service. > It is permissible for there to be other (unspecified) ways for the location > service to be populated and manipulated. (A common case would be for the > location service to be pre-populated with some default contacts.) Because of > this, one could justify removing parameters from a binding by saying it might > have been done by some external agent operating on the location service. > > In general, callee capabilities (feature tags) and caller preference support > by the proxy associated with the registrar are optional features, and you > shouldn't be too surprised if they aren't supported. > > In the case of the fax capability, I think you will probably want to include > it in the registration *without* Require:pref. If it doesn't show up in the > response to the REGISTER then you know it wasn't saved. If it did show up, > you still don't know if callerprefs pertaining to it will be supported or > not. What should you do? Nothing. You may get some non-fax calls and those > will then fail. Maybe they will then be forked to another contact that > succeeds, or not. That is not the concern of the fax device. > > Thanks, > Paul > >> Thanks, >> David > > > > > > > > > > > On Dec 7, 2012, at 6:22 AM, 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 >> >> >> >> > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
