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.
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, but I expect you to parse
it correctly if you happen to receive one. The ABNF is the ABNF, whether
you like it or not. 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.
If nothing else, there is a whole set of torture tests that will try
such things on you. Like it or not, if you fail to process a valid
message because it doesn't adhere to your sensibilities, then it is
*your* implementation that that will be declared incorrect.
Also note that in any language, matching a lowcase string is easier and faster
than matching a case insensitive string (that involves a regular expression).
Faster, but not necessarily any easier. I guess that depends on what you
mean by "easier". If you have a tool that is generating the parser from
the ABNF then its not any harder for the implementor.
In case of REs, there are straightforward translations of the ABNF. E.g
/[Cc][Oo][Nn][Tt][Aa][Cc][Tt]/
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. But I
expect you can achieve ~90% of the performance using a parser that
handles the full syntax if you just concentrate on it.
Of course I know that SIP has many inheritance from HTTP and SMTP protocols
but I hope this is not an eternal burden and things MAY happen in order to
improve interoperability and facilitate the existence of RFC compliant stacks
(instead of what we have nowadays).
Is it a dream? will we always have to deal with case insensitive?
At least until sip/3.0. And AFAIK nobody is planning on starting work on
that. There just isn't any good way to start over with something that
isn't backward compatible.
Note, I agree with you that a syntax intended primarily for machines
rather than humans would be improved by leaving out a lot of these
options. But for sip that is water over the dam, and isn't a battle
worth fighting.
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.
Thanks,
Paul
_______________________________________________
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
