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
