> 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://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
