Subject: [Sip] Avoid so many case insensitive in a future SIP?

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 10 Aug 2008 19:50:45 +0200

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").

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?

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).

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?

Thanks.

-- 
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Aug 2008 15:35:27 -0400

> not for "CONTACT", "contact" or "M").

Can you name the stacks that have this problem? It is an egregious error.

> 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.

> 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.

> 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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 10 Aug 2008 23:30:08 +0200

El Domingo, 10 de Agosto de 2008, Paul Kyzivat escribió:
> > 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").
>

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 

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.

> invoked if a message fails to parse based on the fast path parser.

I think things like this shoul never be necessary. :(

> 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.