El Domingo, 10 de Agosto de 2008, Paul Kyzivat escribió: > Iñaki Baz Castillo wrote: > > Hi. > > > > 99% in SIP BNF is case insensitive (except quotted strings and method > > names). I know that common SIP devices and stacks don't do case > > insensitive matching, for example, they would search for a "Contact" > > header field name (or "m") but not for "CONTACT", "contact" or "M"). > > Can you name the stacks that have this problem? It is an egregious error.
Well, I've detected this problem is some SIP phones, softphones (I've already reported bugs to their authors). But this also occurs in programmable SIP stacks (like a very famous open sourse SIP proxy) in which the human implements the logic with a script and a custom language. This language is powerful, but however it doesn't invite to take in count things like case insensitive in headers and parameters (most of admins will check, for example, if the header is "From" or "f", but never "FROM"). > > I'm sure that the same occurs with typicall URI and header parameters > > (does some SIP stack expect to receive a valid "phoNE=USer" parameter? > > I don't expect you to generate such a thing, Of course I wouldn't do it, but anyone can do it if he wants (and is valid, that is the problem). > The ABNF is the ABNF, whether > you like it or not. Well, ABNF is done by humans, nothing forces ABNF to be case insensitive (for example methods are not case insensitive: "Invite" != "INVITE"). I see no benefit in allowing "LR" instead of "lr" as Route header parameter, do you? > If you start making your own value judgments about > which parts you do/don't like, then eventually you will run across a > case where you have made different assumptions than someone else. The fact is that I've done a parser (or I'm finishing it) that is 100% SIP ABNF compliant so don't worry about it. :) But it's not just the parser: note that when comparing URI's again we must match in case insensitive, with a very painful set of rules for comparing URI's parameters, etc etc... What I mean is that a SIP stack developer must invert too much time in order to handle any valid, even if it's too much strange, message it receives. At least this is my experience when doing it. > If you think it will make a big difference in your performance, I guess > you could implement a fast-path parser that works for messages that > adhere to the syntax subset that you like, and a fallback parser is only > invoked if a message fails to parse based on the fast path parser. I think things like this shoul never be necessary. :( > Instead, maybe you could concentrate on some of the many new things that > are being defined using XML that would be much better done some other way. Good point. Could you please tell me some of these new things definid with XML? Maybe you mean all the related to presence (XCAP and so...)? Thanks for your comment. -- Iñaki Baz Castillo _______________________________________________ Sip mailing list https://www.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
