Re: Re: URI comparison rules - IPv6 addresses

Dale.Worleycomcast.net wrote:
>    From: "Vijay K. Gurbani" <vkgalcatel-lucent.com>
>
>    Jeroen van Bemmel wrote:
>    > Vijay,
>    > It's not only IPv6: what about 127.0.0.1 versus
127.000.000.1?
>
>    Jeroen: Pedantically speaking, you are probably
right.  But
>    in practice we do not generally see leading zeros in
an IPv4
>    octet.
>
> Even worse, in some places, including some early RFCs,
the leading
> zero is used to indicate that the octet is represented
in octal!
>
> But I think Jeroen's point is actually well-taken, when
comparing
> representations of IP addresses (not DNS names), the
comparison is
> implicitly of the address represented, not the textual
> representation.  And this applies in IPv4 as well as
IPv6.
>
> In regard to loop detection, there are two approaches: 
(1) Whatever
> attempts to detect loops can canonicalize the addresses
before
> comparing them or whatever.  (2) Since there are a
limited number of
> likely representations of any address, having different
entities use
> different representations will only delay loop
detection, not prevent
> it.  And loops will be detected even if address
comparisons have
> occasional false negatives.
>   
Given that a particular IP address might serve many, many
different
URI's (think about the outsourced case), I doesn't seem to
me that this
would be a very good assumption. It might be perfectly
reasonable for
a method to traverse from IP address A and then back through
IP address
A again without being a loop since it might be
outsource1.com through
outsource2.com which is legal, right? This case certainly
comes up with
email and is actually really common(*).

It seems that the conclusion of Vijay and my violent
agreement is that
the entity inserting the URI better keep things consistent
as the loop
detector ought to just consider these things as opaque
blobs.

       Mike

(*) modulo DNSBL considerations.


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip