Subject: Re: [SIP] URL comparison

From: "Stuart Wray" <[email-masked]>
Date: Wed, 22 Nov 2000 09:03:48 +0000

Henning Schulzrinne wrote:

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

I don't think this problem has a neat solution. I think what is really
wanted is that URLs which are semantically equivalent should
compare as equal. But if a new parameter changes the semantics
how can older applications ever make the right judgement?

> 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 this last case do you really mean to ignore the port number if it is not
present in both URLs?

  Stuart Wray

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 22 Nov 2000 09:15:57 -0500

> how can older applications ever make the right judgement?

There is a difference between changing the semantics and changing the
comparison rules. New parameters can well change the semantics without
affecting the To/From call leg comparison which is at issue here.
Semantics changes that are mandatory to implement obviously require a
Require header.

> In this last case do you really mean to ignore the port number if it is not

I worded my statement carefully to say ;-parameter. The port number does
not fall into this category.

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