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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Mar 2010 14:43:58 +1300

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

On 2010-03-06 12:30, The IESG wrote:
> 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
> [email-masked] mailing lists by 2010-03-19. Exceptionally, 
> comments may be sent to [email-masked] 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
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Mar 2010 12:11:12 -0600

I'm very support of this draft and think it should move forward but I have a NIT to pick with it.

It says the ABNF in 3261 is incorrect and this one corrects it. I don't believe that is correct. I believe the ABNF in this draft is more specific than the one in 3261 but they are both correct. I think this is an important distinction that should be corrected in the draft and I will try and motivate why. 

The ABNF is what helps an implementor know what sort of parse they need to write such that it can successfully parse over unknown extensions. It also constrain what future syntax extensions can use. There is a constant pressure to make it explicitly represent the current semantic limitations of the protocol. But the ABNF is not what defines the protocol, the text in the RFC does that. For example, most ABNF that have a port number would allow a number that was greater than 2^16. We could write ABNF that limited the port number to a 16 bit integer but typically we don't and instead define the port in the text. 

As far as I can tell, there is nothing "wrong" with the ABNF in 3261, it is just less specific than we would like and this new ABNF is more specific will limit future RFC and extensions to conform with the range of syntaxes allowed by this extortion. Because of this I don't believe this should "update" 3261. Every time we have an "update" to 3261 vendors have to go thought a huge exercise and discussion with customers if their products are still compliant etc. In the case of this draft that would be a huge waste of time as clearly no code is changed by this. 

Cullen <in my individual contributor role>

On Mar 5, 2010, at 4:30 PM, The IESG wrote:

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

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2010 09:47:50 +1300

Cullen,

I believe that the RFC 3261 ABNF *is* plain incorrect. It allows the
generation of text representations including ":::" and that is
clearly not intended to be allowed by the description in RFC 4291.
(Being precise, it says "The "::" can only appear once in an address."
whereas I can find it twice in ":::".)

Actually there is another bug too, as first noted by Markku Savela
in February 1999:

>> >However, appears that this doesn't allow "::123.222.2.22" type of
>> >addresses. On the other hand, it would pass dubious things like
>> >"FFF:::<ip4>", so I'm still looking for the correct syntax...

History: the faulty ABNF first appeared in RFC 2373 but was dropped
from RFC 3513 because it was known to be wrong. Unfortunately RFC 3261
picked it up from 2373.

Impact: http://[2001:4860:b006:::67] fails (with Firefox and IE; I have
no easy way to check it in a SIP implementation). It should fail, and
should never be generated.

However, I do agree that we could state in the document
that implementations which *cannot* generate the faulty ":::"
construct do not need to be changed and that implementations
that *can* accept the faulty ":::" construct do not need to
be changed.

Implementations that disallow "::<IPv4>" would need to be fixed,
but I suspect that is highly unlikely and a very marginal case.

Regards
   Brian

On 2010-03-19 07:11, Cullen Jennings wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>