Subject: Re: [Sip] Last Call: draft-ietf-sip-ipv6-abnf-fix (Essential correction for IPv6 ABNF and URI comparison in RFC3261) to Proposed Standard

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Apr 2010 17:02:49 -0500

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:foo@bar:1234> and <sip:foo@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:foo@bar:01234> could also be interpreted as the digits
comprising the port "1234" to be in base 8 (leading 0 signifies
an octal base.)

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.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 19:02:42 -0400

inline

> comprising the port "1234" to be in base 8 (leading 0 signifies

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.

> strongly, I don't mind adding a sentence or two to this effect in

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 27 Apr 2010 08:22:54 -0500

> something to say about it.

OK.  Thanks.

For other folks still monitoring the sip list, if you think that
draft-ietf-sip-ipv6-abnf-fix should explicitly spell out that
port number comparison should be done on binary equivalency and
not textual equivalency, please let me know.

IESG last call is over on the draft, and I am trying to
wrap it up.  So please get back to me at your earliest
convenience.  I will revise and resubmit a new version next
week.

Thank you,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 08:33:16 -0500

On 4/26/10 18:02, Apr 26, Paul Kyzivat wrote:
> remember some question about octal ports coming up on one of the 
> mailing lists some time in the past.
>

For what it's worth, typing "http://www.ietf.org:080/" into Firefox, 
Safari, and MSIE all takes me to the IETF's web page (interpreting "080" 
as 80, not 64). So, at least for HTTP URLs, there's a de facto 
interpretation of leading zeros in a port as padding, not an indication 
of octal.

/a

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 27 Apr 2010 08:37:26 -0500

> interpretation of leading zeros in a port as padding, not an indication

But that still implies a binary comparison instead of a textual one,
unless the textual comparison is going to understand the zero-padding
and remove it first.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 08:43:40 -0500

> unless the textual comparison is going to understand the zero-padding

Yes, it does. The question is whether that belongs in the v6 document, 
or if we need to do a similar rev for port numbers. Seeing as how the 
issue applies equally to v4 and v6, I'd say that putting it in the v6 
document would be an expansion of scope that is inappropriate at the 
current state of the document's development.

We probably should log it in the bug tracker (bugs.sipit.org), and not 
address it in the document at hand.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2010 10:09:30 -0400

> address it in the document at hand.

That works for me.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 18:11:41 -0500

On 4/27/10 09:09, Apr 27, Paul Kyzivat wrote:
>
>
> Adam Roach wrote:
>
>> Yes, it does. The question is whether that belongs in the v6 
>> document, or if we need to do a similar rev for port numbers. Seeing 
>> as how the issue applies equally to v4 and v6, I'd say that putting 
>> it in the v6 document would be an expansion of scope that is 
>> inappropriate at the current state of the document's development.
>>
>> We probably should log it in the bug tracker (bugs.sipit.org), and 
>> not address it in the document at hand.
>
> That works for me.

It is now logged as http://bugs.sipit.net/show_bug.cgi?id=777

/a