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@ietf.org mailing lists by 2010-03-19. Exceptionally, >> comments may be sent to i...@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-implement...@cs.columbia.edu for questions on how to develop a SIP >> implementation. >> Use dispa...@ietf.org for new developments on the application of sip. >> Use sipc...@ietf.org 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
