Subject: [Sip] note: change in URI comparison rules coming

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 21:28:28 -0500

Folks,

There is a change in the URI comparison rules that is coming. It has
already been discussed in draft-ietf-sip-srv, but I suspect that with
the volume of material flying around these days, it has been missed.

Previously, the following two URIs were considered equivalent:

sip:user@domain
sip:user@domain:5060

The reasoning was that we figured that the default port ought to equal
an explicit port equal to the default.

The problem is in the DNS resolution of the URI. There is wide agreement
that, when the port is present, you should use that port. This pretty
much rules out an SRV lookup, since SRV would provide an alternate port,
and there is no way you can use just the host and ignore the port. So,
you need to do an A record lookup. Now, presumably, two URI that are
equivalent ought to be looked up in the same way. So, we cannot look up
the two URIs above differently if they are equal. If we use SRV for
both, we end up ignoring the explicit port. THis results in serious
surprise; a URI pointing to port 5060 explicitly might end up going to a
different port, depending on the URI lookup. Very likely NOT what was
intended.

As a result of these problems, pointed out to us by DNS experts within
IETF, draft-ietf-sip-srv is simple on this one. If there is a port, you
use that port, and do A record lookup on the host value. No exceptions.
This means that the two URI above are NOT equal any longer.

This will be reflected in the URI comparison rules in bis-08.

Will this introduce interop problems? I tend to doubt it. Right now, URI
equality is needed in (1) dialog identification, (2) matching
address-of-records into location service, (3) checking whether a contact
has been updated in a registration. In the case of (1), its the From and
To fields, which almost never have ports, and anyway, you're not likely
to see someone put in a port and then someone strip it in a request in
the reverse direction. Regarding (2), AOR shouldn't really have ports,
(3) will only be an issue if the same UA decides to send one
registration for a contact without a port, and update it with a port. I
consider that unlikely too. So, I dont think there are any serious
repercussions here. However, if you think this is a problem for you,
please speak up.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Sean Olson <[email-masked]>
Date: Fri, 8 Feb 2002 19:42:42 -0800 (PST)

Please note that if your proxy implemenation is
inserting the default port (5060) into either
the To:/From:/Contact: (allowed, but questionable),
that it will cause all manner of problems. I always
hated the fact that the To:/From: were not immutable,
but now it may cause some very serious problems.

/sean

--- Jonathan Rosenberg <[email-masked]>
wrote:
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 23:36:44 -0500

> but now it may cause some very serious problems.

Well, then you'll like the other post I made this evening....
Basically, to propose that we revisit the decision not to use
tags alone as dialog ID, so that we can make the URI mutable 
when we go to draft.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 14 Feb 2002 09:32:23 -0600

The same argument applies to the transport parameter
sip:user@domain;transport=udp will always resolve to udp,
but
sip:user@domain may resolve to tcp through DNS.

The next version of bis will reflect

sip:user@domain:5060 != sip:user@domain != sip:user@domain;transport=udp

RjS