Subject: Re: Question about Call comparaison

From: Sean Olson <[email-masked]>
Date: Sat, 12 Feb 2000 14:34:33 -0600 (CST)

> Jonathan Rosenberg wrote:
> > 
> > Anders Kristensen wrote:
> > >
> > > > 1. matching over domain names are case insensitive, all others are case
> > > > sensitive.
> > >
> > > 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.
> > 

> > 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".
> 
Is this an argument for CS names or CS values?

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

We take a very similar approach.

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

Exactly.

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

I too think it is a very natural approach, however, some might want just
to deal with simple strings.

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

If parameter names are case sensitive, then what is the "correct" case for
the standard SIP URL parameters (is it "Transport", "TRANSPORT", "transport", 
etc?). Or are you saying that a SIP URL with a "transport=tcp" parameter
does not match a SIP URL with a "Transport=tcp" parameter (where both cases
would be interpreted as a correctly formatted transport parameter)?

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

--
Sean Olson <[email-masked]>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 13 Feb 2000 12:08:14 -0500

> Is this an argument for CS names or CS values?

Both are case sensitive.

> > that retrieval is faster than having to lookup in a hashtable or what

Thats fine, I still don't see why case insensitivity helps you. Consider
the tag parameter. The parameter is case sensistive, which means "tag"
is the one defined in rfc2543, and "TAG" is an other-param. So, when you
need to generate the message, read your tag parameter attribute from the
SipURL class, and then spit out "tag=" + myURL.tag(); or whatever. 

I can understand why you'd prefer case insensitive if "tag" and "TAG"
both refer to the same thing, but you needed to remember which was
received.

> would be interpreted as a correctly formatted transport parameter)?

Yes, that is what I'm saying. I believe this is what is implied in http
1.1 also.

-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