Subject: Re: Question about Call comparaison

From: Sunitha Kumar <[email-masked]>
Date: Thu, 10 Feb 2000 17:06:46 -0800

Hi:

Was any consensus reached on the URI equality.
also, when we say the optional parameters of the URI,  what are they? Do they
include other-parms?

Thanks!
sunitha

Jonathan Rosenberg wrote:

> Henning Schulzrinne wrote:
> >
> > Jonathan Rosenberg wrote:
> > >
> > > 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.
> > >
> >
> > 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;
>
> 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.
> --
> 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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Feb 2000 10:41:05 -0500

Yes, consensus was reached. The rules are:

1. matching over domain names are case insensitive, all others are case
sensitive. 
2. The matching is over all fields: user, password, domain, port AND all
parameters, including the optional and extension parameters
3. If a parameter is not present, but it has a default value, the
matching is based on the default (i.e., a URL without a port and a URL
with port 5060 match)
4. A URL with a domain name does not match a URL with an IP address,
where that address is the result of a DNS lookup of the domain name.

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 11 Feb 2000 18:21:44 +0000

> 1. matching over domain names are case insensitive, all others are case

I believe we agreed that parameter names are CI, also. Otherwise
implementations would have to remember not only, say, that a To tag had
value "xyz" but also the tag string itself just to get the case right.
Not very good.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Feb 2000 15:07:51 -0500

> value "xyz" but also the tag string itself just to get the case right.

Note that the "tag" is not part of the URL. Thus, call matching = URL
matching for From/To + tag matching for To + Call-ID matching.

I've added wording on call leg matching in the From header section.

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 11 Feb 2000 20:16:12 +0000

> matching for From/To + tag matching for To + Call-ID matching.

Right you are, so substitute "tag" for "transport" and the comment
holds.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Feb 2000 18:13:17 -0500

> value "xyz" but also the tag string itself just to get the case right.

I'm confused; having it CS is easier. I'll store the tag as a string,
and do a normal
string comparison on it to "get the case right". Whats the difficulty?

-Jonathan R.

---

From: Anders Kristensen <[email-masked]>
Date: Sat, 12 Feb 2000 14:00:10 +0000

Jonathan Rosenberg wrote:
> string comparison on it to "get the case right".

Right, actually it depends on the implementation. Currently our SipURL
class has attributes for RFC 2543 defined SIP URL parameters: user,
maddr ttl, transport, and method, whereas other-params are stored in a
map.

There are advantages and disadvantages to this approach. Amongst the
advantages is that it saves us from having to remember the actual
attribute name used on the wire for these "well-defined" attributes, and
that retrieval is faster than having to lookup in a hashtable or what
have you.

My posting was predicated on the assumption that people would naturally
want to store rfc 2543 SIP URL parameters different from other-params,
which I realize now isn't necessarily the case.

Anyway, I dont really feel very strongly about it. CS parameter names is
fine with me.

Anders