Subject: [Sip] Open issue #100: case sensitivity of URL parameter values

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Sep 2001 08:32:29 -0400

Problem: There is a lack of clarity as to which pieces of the URL should
be compared in a case-sensitive (CS) or a case-insensitive way. In
particular, there is some confusion between the BNF definition and
various statements in the text.

Proposal: In SIP URL comparison, only the user name is CS, everything
else is compared CI. The text will identify clearly where URL comparison
is needed. (Header names and values cannot appear in contexts that are
compared, so there is no need to define their CI/CSness.)

Rationale: Unfortunately, there is not much guidance in existing
protocols, as their URLs don't have nearly as many components.

CI seems to be more robust; it is difficult to explain to users that 

sip:alice@example;transport=udp
and
sip:alice@exampel;transport=UDP

mean something different.

Finally, since we'll be moving to RFC 2234 BNF notation, specifying CS
literals is very difficult:

   Section 2.3:

   Literal text strings are interpreted as a concatenated set of
   printable characters.

        NOTE:     ABNF strings are case-insensitive and
                  the character set for these strings is us-ascii.

   Hence:

        rulename = "abc"

   and:

        rulename = "aBc"

   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" and "ABC".

                To specify a rule which IS case SENSITIVE,
                   specify the characters individually.

Also, it would be helpful if we could enumerate the cases where URL
comparison is actually needed within the protocol. I suspect that many
of the corner cases don't appear. From what I can tell, we only need
this for To and From call leg matching and Contact headers for
registration matching. None of these contain, for example, headers.

Procedure: the usual drill - you have two weeks to object or discuss.

_______________________________________________
Sip mailing list  http://www1.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: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Sep 2001 08:43:12 -0400

Christer Holmberg wrote:
> 
> Hi,
> 
> If everything in the SIP URL is CS, why does the user part then have to
> be CS? Is there really a need for that?
> 

Yes. See RFC 2821 and RFC 2822. Since we want users to be able to re-use
their email address as their SIP address, this is non-negotiable.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2001 15:40:39 +0300

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2001 16:19:26 +0300

Hi,

>their email address as their SIP address, this is non-negotiable.

True. 

I wish we could use "this is non-negotiable" for a number of other
issues too :)

Regards,

Christer Holmberg
Ericsson Finland

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 26 Sep 2001 13:28:26 -0400

If memory serves me right, the last time this was discussed we settled
on CS comparisons of more than just username. In particular, I believe
parameter names were case sensitive. This seems to be in line with HTTP
and the overall philosophy that choice is bad.

Anders

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 26 Sep 2001 14:26:36 -0400

> and the overall philosophy that choice is bad.

At that time, we weren't thinking along RFC 2234 lines. Also, the HTTP
parameter case seems less than clear. I tried to re-locate the relevant
parts, but wasn't able to.

I'm trying to keep the rule as simple as possible. 
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 26 Sep 2001 16:36:52 -0400

> parts, but wasn't able to.

RFC 2616 has the following section:

3.2.3 URI Comparison

   When comparing two URIs to decide if they match or not, a client
   SHOULD use a case-sensitive octet-by-octet comparison of the entire
   URIs, with these exceptions:

      - A port that is empty or not given is equivalent to the default
        port for that URI-reference;

        - Comparisons of host names MUST be case-insensitive;

        - Comparisons of scheme names MUST be case-insensitive;

        - An empty abs_path is equivalent to an abs_path of "/".

   Characters other than those in the "reserved" and "unsafe" sets (see
   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

   For example, the following three URIs are equivalent:

      http://abc.com:80/~smith/home.html
      http://ABC.com/%7Esmith/home.html
      http://ABC.com:/%7esmith/home.html

The parts defining individual parameters say whether the *value* of that
param is CS or not. My reading is that param names always are CS.

> I'm trying to keep the rule as simple as possible.

A laudable goal.

Anders

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 26 Sep 2001 20:32:24 -0400

Anders Kristensen wrote:

> param is CS or not. My reading is that param names always are CS.

Unfortunately, the HTTP URL doesn't seem to have parameters (as in
;foo=bar).

Just to be sure we're talking about the same thing: there are two
parameters in SIP, the URL parameters (like transport and maddr) and the
header parameters (as those found in abundance in the Contact header
definition). There is no strict necessity that the two are treated the
same. It is, unfortunately, not even clear whether header parameters
(such as the 'q' parameter in HTTP) are CI or CS, although it is quite
possible that I overlooked some statement in 2616 to that effect. 

I just looked at 2617 (Basic and Digest Authentication), since it has
lots of parameters. According to Section 1.2:

   The realm directive (case-insensitive) is required for all
   authentication schemes that issue a challenge. The realm value
   (case-sensitive), ...

Thus, this is a case where the parameter name (realm, in this case) is
CI. The other parameters in 2617 don't seem to say.

However, according to the BNF,

  "literal"
      Quotation marks surround literal text. Unless stated otherwise,
      the text is case-insensitive.

Thus, all the others are also CI.

It would be helpful if we can get further evidence of common practice in
HTTP, SMTP or kin.