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: > 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: > >> 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@xxxxxxxx mailing lists by 2010-03-19. Exceptionally, >> comments may be sent to iesg@xxxxxxxx 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-implementors@xxxxxxxxxxxxxxx for questions on how to develop a SIP implementation. >> Use dispatch@xxxxxxxx for new developments on the application of sip. >> Use sipcore@xxxxxxxx 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 > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf