Subject: RE: [SIP] URL comparison

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Nov 2000 05:27:00 -0500

> -----Original Message-----
> From: Stuart Wray [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 10:15 AM
> To: [email-masked]
> Subject: [SIP] URL comparison
> 
> 
> 
> 
> Henning Schulzrinne suggested that I submit the following 
> questions about URL
> comparison to the SIP list.
> 
> On page 21 of rfc2543bis02 , it says
> 
> (call this clause A)
> "user, password, host, port and any url-parameter parameters 
> of the URI must
> match. If a component is omitted, it matches based on its 
> default value."
> 
> So far, this is clear, but the paragraph goes on to say that
> 
> (call this clause B)
> "Components not found in both URLs being compared are ignored"
> 
> Now consider these two URLs:
> 
>      sip:[email-masked]:6666
>      sip:[email-masked]
> 
> Clause A means that these URLs compare as unequal, but clause 
> B means that they
> compare as equal.
> 
> Should clause B actually start with the word "other"?
> 
> (clause B')
> "Other components not found in both URLs being compared are ignored"
> 
> (If so, is this actually the correct judgement? I would have 
> thought that a URL
> should not compare equal to a URL with an extra component. 
> Why is it useful for
> them to compare equal?)

Hmm. Good question. I honestly can't recall why we said this. I would tend
to agree that:

sip:user@host:5050;foo=bar

and

sip:user@host:5050

are not the same.

Unless someone can come up with a good reason why this should stay, I would
argue that we change this to say "If one of the URLs has a component that is
not present (and has no default value) in the other URL, the URLs are not
equal".

> 
> And now another separate point: the text on page 21 goes on to say:
> 
> "Note that the two URLs example.com and example.com:5060, 
> while considered
> equal, may not lead to the same server, as the former causes 
> a DNS SRV lookup,
> while the latter only uses the A record".
> 
> However, this is not true --- on page 12 it says:
> 
> "3. The Request-URI is examined. If it contains an explicit 
> port number other
> than 5060, the next two steps are skipped".
> 
> The A record is only used if there is a port number other 
> than 5060 ---- so
> example.com and example.com:5060 both use the SRV record. (Of 
> course this may
> result in different machines actually being contacted, but 
> that's a different
> matter entirely, not to do with A records).

This is an error, I believe, resulting in the evolution of this text. We
modified the SRV procedure so that example.com and example.com:5060 were,
indeed, pointing to the same server, but didn't update the text on top which
pointed out the problem.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

---

From: Sean Olson <[email-masked]>
Date: Tue, 21 Nov 2000 09:35:04 +0100

> not present (and has no default value) in the other URL, the URLs are not

This depends on what semantics you apply to that additional component. I
would say in this case that these two URLs are equal when considered
in the context of a To: or a From:, but unequal in the context of a Request-URI.

If you want to make these two cases consistent, I would lean towards considering

these two URLs equal in both cases. Otherwise, we should just do a case
insensitive
string comparison, port included.

/sean

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 11:02:51 -0500

> > not present (and has no default value) in the other URL, the URLs are not

The problem is that with new parameters, older applications won't know
whether the parameter has a default value and what that might be. Thus,
you can either

- compare well-known parameters (RFC 2543) according to this rule and
new parameters according to "ignore" or "unequal if one has it, the
other doesn't" rule. This seems less than satisfactory in terms of
robustness and simplicity.

- Declare missing parameters as unequal to any existing parameter. That
doesn't work, due to default values.

- Ignore ;-parameters that are only present in one of the URLs being
compared. This seems to work for most practical cases. Any examples
where this would break things?

> in the context of a To: or a From:, but unequal in the context of a Request-URI.

Having two different comparison routines seems like a recipe for subtle
interoperation problems.

> these two URLs equal in both cases. 

That would be my preference. This is in the spirit of "you can add
parameters/headers, but don't expect them to matter unless Require'd".

> Otherwise, we should just do a case
> insensitive

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 21 Nov 2000 13:41:36 -0500

Jonathan Rosenberg wrote:

> indeed, pointing to the same server, but didn't update the text on top which

This should already be gone from the -02 draft draft.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs