Subject: Re: Question about Call comparaison

From: [email-masked]
Date: Thu, 16 Dec 1999 01:27:15 +0530

Well, since the RFC states that since 5060 is the default port, the second
message implicitly states that.
so yes, I would treat it as the same.
imho, if the app. sees a null port,it should implictly take it as 5060 and
then do the call leg identification as stated in the notes and
clarifications.
Is there any problem if this is the approach ?
Regds
Arjun
--
Arjun Roychowdhury @ Hughes Software Systems

Marc Petit-Huguenin <[email-masked]> on 12/16/99 01:01:56 AM

To:   IETF SIP <[email-masked]>
cc:

Subject:  Question about Call comparaison

Hi all,

Is the two following requests belongs to the same call or not (please
notes the difference in the port)

 INVITE sip:[email-masked] SIP/2.0
 From: Isabelle <sip:[email-masked]:5060>
 To: Marc <sip:[email-masked]>
 Call-Id: [email-masked]
 CSeq: 1 INVITE
 Via: SIP/2.0/UDP tarantula.8x8.com
 Content-Length: 0

[some other message...]

 INVITE sip:[email-masked] SIP/2.0
 From: Isabelle <sip:[email-masked]>
 To: Marc <sip:[email-masked]>
 Call-Id: [email-masked]
 CSeq: 2 INVITE
 Via: SIP/2.0/UDP tarantula.8x8.com
 Content-Length: 0

At least two implementations at the last bake-off does not like this.

Thank you for your help.

--
Marc Petit-Huguenin
Home: mailto:[email-masked]
Work: mailto:[email-masked]
"Everything I love is either immoral, illegal or makes you fat"

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 Dec 1999 01:14:31 -0500

Yes, I agree that these are the same. When matching the To and From
field for call legs, I would say that:

1. the display name is not included in the matching
2. the matching includes tags
3. the matching be based on the user, password, host and port components
of the URI, in addition to any parameters. The matching is semantic
based, so that if a default component is omitted, it still matches.
4. string comparisons are case insensitive
5. an IP address that is the result of a DNS lookup on a hostname does
NOT match that hostname. 

Matching based on URI parameters is debatable. But, we need at least the
user param, and rather than special case things, I'd like to make the
rule simple and consistent. So, lets include all parameters.

I think this is in line with rfc2396, which says:

> 6. URI Normalization and Equivalence
> 
>    In many cases, different URI strings may actually identify the
>    identical resource. For example, the host names used in URL are
>    actually case insensitive, and the URL <http://www.XEROX.com> is
>    equivalent to <http://www.xerox.com>. In general, the rules for
>    equivalence and definition of a normal form, if any, are scheme
>    dependent. When a scheme uses elements of the common syntax, it will
>    also use the common syntax equivalence rules, namely that the scheme
>    and hostname are case insensitive and a URL with an explicit ":port",
>    where the port is the default for the scheme, is equivalent to one
>    where the port is elided.

Note the last sentence on port.

So, the following pairs of To fields are "identical" as far as call leg
determination is concerned:

To: "J. User" <sip:[email-masked]:5060>
To: Joe <sip:[email-masked];transport=udp>

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Dec 1999 09:47:50 -0500

> rule simple and consistent. So, lets include all parameters.

This also agrees with RFC 2616 (http), which says:

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 rules have been added to the FAQ and revised spec. (The "ignore
display name" was already there.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 01:00:29 -0500

>         - Comparisons of scheme names MUST be case-insensitive;

Hmm, so this means that comparisons on the user and password are case
SENSITIVE, and that comparisons on parameters are also case SENSITIVE.
Its a bit yucky with these special cases, but I guess we should be
consistent with http and rfc2396. In that case, I think we should
explicitly say that the username, password, and parameters comparisons
are case sensitive.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Dec 1999 02:42:03 -0500

> explicitly say that the username, password, and parameters comparisons

This is somewhat tricky, since two related URL formats collide here:

1) The current version of the SIP spec says case-insensitive (CI), so
there's something to be said for keeping it that way.

2) mailto URLs and email addresses are compared CI, if I remember
correctly (somebody should check RFC 822).

3) Unix user ids are CS, but I suppose that it is rare that there will
be two users whose names differ only in capitalization. Are NT user ids
CS or CI?

Thus, I'd prefer CI overall as this increases the chance of
interoperability. (I.e., since it is very unlikely that there will be
two truly distinct URLs that only differ in capitalization, CI
comparison is more likely to work correctly.)

Clearly, http doesn't have a choice, since path names clearly are often
CS.

Henning

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Dec 1999 11:50:16 -0500

> comparison is more likely to work correctly.)

This is my preference as well, then.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 17 Dec 1999 20:11:13 +0000

> correctly (somebody should check RFC 822).

Apart from the special user "postmaster" user id's in email adresses are
case sensitive.

> Clearly, http doesn't have a choice, since path names clearly are often

One could argue conversely that allowing more variations just decreases
the chances of interoperability.

HTTP has a good reason for saying that scheme and host names are case
insensitive, which is that cacheing would be adversely effected if
proxies weren't allowed to treat http://abc.com:80/ and http://ABC.com/
as identifying the same resource, as in fact they would be the same
resource since DNS is case insensitive.  Obviously this reason does not
apply to SIP.

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 17 Dec 1999 20:13:04 +0000

> rule simple and consistent. So, lets include all parameters.

This is something of a pain in the neck and possibly a good deal of
overhead. Also, the spec actually says that To and From URIs cannot
contain maddr, ttl, and transport parameters (table 2, p. 24), although
it doesn't mention 'other-params'.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Dec 1999 18:39:27 -0500

> resource since DNS is case insensitive.  Obviously this reason does not

Given that email id's are CS (with the irrelevant exception of
Postmaster), it probably would be wise not to deviate. However, since
RFC 822 also specifies

I like the idea of a canonical URL, in that we could strongly recommend
all lower-case representations for hostnames. Unfortuntely, the mailto
URL RFC (2368) is silent on this whole topic.

Also, I'm less concerned about call matching as about REGISTER and
whether a proxy detects a call as being its "responsibility", all of
which rely on URL matching.

Thus, summary:

- parameter names are CI

- rest is CS

- host names will have to be CI, even though that's a pain. Given the
precedence of RFC 822 and HTTP, it would be difficult to deviate here.
(This primarily matters for REGISTER matching, since people do have all
kinds of variations, particularly for CamelCase.)

- user names have to be CS, given RFC 822. It would be bad if an
installation had two user id's distinguished via case and then couldn't
assign these ids as SIP ids. (I suppose that having John and john for
John Sr. and John Jr. would not be a smart move to begin with...)

Besides having to pay more attention when building the URL comparer, a
pure strcmp or strcasecmp on two URLs can never work, so one has to
compare component-by-component. In that case, comparing sometimes via
strcmp and sometimes via strcasecmp is not likely to bloat the code,
just add a nuisance to programming.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Dec 1999 18:39:27 -0500

Thus, summary:

- parameter names are CI

- rest is CS

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 17 Dec 1999 18:39:27 -0500

Thus, summary:

- parameter names are CI

- rest is CS

- user names have to be CS, given RFC 822. It would be bad if an
installation had two user id's distinguished via case and then cX-Mozilla-Status: 0009ids as SIP ids. (I suppose that having John and john for
John Sr. and John Jr. would not be a smart move to begin with...)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Dec 1999 16:08:06 -0500

> just add a nuisance to programming.

And also that default values of parameters match non-inclusion (i.e.,
port 5060 the same as if no port were present).

Is there consensus on this approach? Please speak up if you have a
problem with this. Whatever we do, we should have a section in the
revised spec on URL comparisons that is absolutely clear on these
things.

-Jonathan R.