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

[Robert Sparks <[e-mail]>]

The current proposal is no.

Those two URLs will resolve to the same host/port/transport, but
making the URLs equivalent will require separate equality rules
for when the hostpart is an IPv4 address vs a DNS name.

RjS


James Undery wrote:

> Is sip:10.0.0.1 == sip:10.0.0.1;transport=udp still going to hold?
> 
> James
> 
> 
>>-----Original Message-----
>>From: Robert Sparks [mailto:[e-mail]]
>>Sent: 14 February 2002 15:32
>>To: Jonathan Rosenberg
>>Cc: [e-mail]
>>Subject: Re: [Sip] note: change in URI comparison rules coming
>>
>>
>>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
>>
>>Jonathan Rosenberg wrote:
>>
>>
>>>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.
>>>
>>>
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use [e-mail] for questions on current sip
>>Use [e-mail] for new developments on the application of sip
>>
> 



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