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

[The IESG]

The IESG has received a request from the Session Initiation Protocol WG
(sip) to consider the following document:

- 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 '
<draft-ietf-sip-ipv6-abnf-fix-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
***@ietf.org mailing lists by 2010-03-19. Exceptionally,
comments may be sent to ***@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16959&rfc_flag=0

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

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:***@bar:1234> and <sip:***@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???

Thanks,
Paul

Post by The IESG
The IESG has received a request from the Session Initiation Protocol WG
- 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 '
<draft-ietf-sip-ipv6-abnf-fix-04.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16959&rfc_flag=0
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Vijay K. Gurbani]

Attending to pending email ... sorry for the delayed response.

Post by Paul Kyzivat
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,
This calls out that comparison of the binary forms of the ip address,
and this fixes a problem with ipv4 as well as ipv6.
ISTM that binary comparison should also be used for port numbers.
But is it worth pulling this back to fix that???

Paul: <sip:***@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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

inline

Post by Vijay K. Gurbani
Attending to pending email ... sorry for the delayed response.

Post by Paul Kyzivat
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,
This calls out that comparison of the binary forms of the ip address,
and this fixes a problem with ipv4 as well as ipv6.
ISTM that binary comparison should also be used for port numbers.
But is it worth pulling this back to fix that???

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.

Post by Vijay K. Gurbani
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 sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Vijay K. Gurbani]

Post by Paul Kyzivat
I also don't feel *strongly* about it. Lets see if anybody else has
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/
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Adam Roach]

Post by Paul Kyzivat

Post by Vijay K. Gurbani
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.

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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Kevin P. Fleming]

Post by Adam Roach
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.

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: ***@digium.com
Check us out at www.digium.com & www.asterisk.org
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Adam Roach]

Post by Kevin P. Fleming

Post by Adam Roach
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.

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.

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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Paul Kyzivat]

Post by Adam Roach
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.

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 sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Adam Roach]

Post by Paul Kyzivat

Post by Adam Roach
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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Brian E Carpenter]

I'd like to note that the authors are aware that
draft-ietf-6man-text-addr-representation-07 is now
proposed for the standards track, and this may mean
it becomes a normative reference for sip-ipv6-abnf-fix
(and applicable to SIP implementations).

Brian Carpenter

Post by The IESG
The IESG has received a request from the Session Initiation Protocol WG
- 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 '
<draft-ietf-sip-ipv6-abnf-fix-04.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-04.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16959&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
https://www.ietf.org/mailman/listinfo/ietf-announce