> We are _still_ seeing interoperability problems because
of
> quotes around the qop parameter value in challenges and
responses.
>
> What's specified now is that quotes MUST appear in
challenges
> (it's a list of things) and MUST NOT appear in
responses
> (it's a choice of one thing).
>
> This causes lots of people to write broken code.
>
> For the code that does work, this causes people to
either
> build separate parsers for headers with the same name,
using
> the knowledge of whether its a challenge or response to
> invoke the right parser, or to build parsers that don't
> follow the BNF we've provided.
>
> Would it make more sense to change the BNF to allow the
> quotes optionally in either the challenge or the
response?
< snip >
> What would be bad about making this change to the
spec?
For backward compatibility reasons, I don't think that the
BNF should
change.
However I agree that it is a common problem. If rfc3261bis
or
rfc4475bis gets generated, maybe the problem could be
highlighted with a
potential recommendation to accommodate such errant
devices.
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
