Jeroen van Bemmel wrote:
Robert,
We cannot make the quotes optional in the challenge,
technically, or for reasons of backward compatibility?
Technically it would be ok as long as there was only one in the list.
(No commas.) But I guess you are stuck for backward compatibility.
but we could make
them mandatory in both cases. That would at least be easier to get
right. Parsers would still need to support unquoted responses though
Technically you could make them optional in the response.
But again backward compatibility causes trouble.
I don't see how you can improve things without breaking backward
compatibility.
Paul
Regards,
Jeroen
Robert Sparks wrote:
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?
Nobody that I've asked is actually re-using an HTTP parser for this,
and nobody seems to be getting the number of values for the parameter
wrong. Most of the folks I ask are building their parsers this way anyhow
What would be bad about making this change to the spec?
RjS
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
