Subject: Re: [SIP] Case sensitivity

From: Gethin Liddell <[email-masked]>
Date: Thu, 1 Jun 2000 10:43:19 +0100

Hi people.

I hate to go over this topic time after time and appologize in advance for
bringing it up again but I have to query the case sensitivity issue of the
"user" element in the Sip URL.

This message is in fact in response to Henning's posting one month ago 
(to the day!!) and again i appologise, this time for the lateness of this posting.

My query arrises because of the examples given in the bis Section 2 after table 2.

we have the example 

sip:[email-masked]

now this will be used, i suspect, by the gateway to convert to [email-masked] within
the gateway.com domain.  So the example.com has now become a host, which is 
case-insensitive (CI).  however the user is compared case-sensitive (CS).

so:

sip:[email-masked] 

will not equate to the former even though the gateway.com considers both to be the same.

is this a problem?
should the user not be CI as well as the host? 
then what if alice has a password?  

sip:[email-masked]

This would have to be CI as well.  But then passwords
are more often than not CS!!!

i fear i may be over-concerned about this and worrying about nothing. 
i.e. what the gateway.com does is out of the scope of SIP and not our concern

any thoughts?

On Mon, 01 May 2000, Henning Schulzrinne wrote:
> I believe we need to take a closer look at the annoying topic of
> case-sensitivity (or not).
> 
> A rough summary is:
> 
> Method              CS
> Header field name   CI
> Any Accept-* token  CI  (includes compression, language, media type)
> SDP encoding name   CI  (such as PCMU, L16, etc.)
> URL                 mostly CS (except host)
> 
> Some additional issues:
> (1) Parameters like ;level or ;q in Accept. Are ;LEVEL and ;Q the same
> thing? RFC 2616 seems to indicate this:
> 
> 3.7:
> 
> The type, subtype, and parameter attribute names are case-
>    insensitive. Parameter values might or might not be case-sensitive,
>    depending on the semantics of the parameter name.
> 
> 2.1 Augmented BNF
> 
> "literal"
>       Quotation marks surround literal text. Unless stated otherwise,
>       the text is case-insensitive.
> 
> [This would apply to most enumerated parameters, like "hop" or "hide"
> tokens in our case, or the "action" tokens in Contact or
> Content-Disposition or the Priority values.]
> 
> My general impression is that HTTP/1.x seems to treat tokens not
> enclosed in quotation marks as CI and anything in quotation marks as CS,
> with URLs as a separate matter.
> 
> (2) HTTP-date (and, thus, rfc1123-date) is case sensitive.
> 
> Any other cases?
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 01 Jun 2000 07:09:39 -0400

I agree that we're now getting into one of the more arcane areas. The
reason that user names are CS is that they are CS in a number of
operating systems and that RFC 822 defines local-part (the local name)
to be CS. It is then up to the gateway to treat a user name like foo@bar
appropriately. The CI/CS only matters for comparing registrations, for
example, where this form is not likely to occur in any event.