inline
Vijay K. Gurbani wrote:
Attending to pending email ... sorry for the delayed response.
On 03/05/2010 06:17 PM, Paul Kyzivat wrote:
I see this is very close to done.
I'm sorry to only be looking at it now.
While I don't see a problem with what is in this,
I do see a logical omission:
This calls out that comparison of the binary forms of the ip address,
and this fixes a problem with ipv4 as well as ipv6.
A similar problem exists for the port number:
are <sip:f...@bar:1234> and <sip:f...@bar:01234> the same???
ISTM that binary comparison should also be used for port numbers.
But is it worth pulling this back to fix that???
Paul: <sip:f...@bar:01234> could also be interpreted as the digits
comprising the port "1234" to be in base 8 (leading 0 signifies
an octal base.)
Well, it *could* mean that. (I was never a fan of that notation even
from day one in C.) There certainly is nothing in 3261 that would
suggest that the octal convention applies to hostport in sip URIs. The
ABNF currently is:
port = 1*DIGIT
If the octal notation was intended to apply, then I would expect that
the ABNF would be:
OCT-DIG = %x30-37
NON-OCT-DIG = %x31-39
port = (NON-OCT-DIG *DIGIT) | "0" *OCT-DIG
If there is any question that some might believe the octal notation
applies, then that is more reason to say something.
Writing leading zeroes for IPv4 address is not prevalent; by the
same token, representing ports in octal base is not prevalent either.
So I am inclined to let sleeping dogs lie.
However, if the sponsoring AD or anyone monitoring this list feels
strongly, I don't mind adding a sentence or two to this effect in
the draft.
I don't feel strongly about it. But now that you mention it, I think I
remember some question about octal ports coming up on one of the mailing
lists some time in the past.
I also don't feel *strongly* about it. Lets see if anybody else has
something to say about it.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP
specifications.
