Vernon opined: --- Besides, I didn't say that one should ignore the English, but that implementors give precedence to the ABNF. When you are writing an RFC that you hope will be implemented, you MUST remember that programmers are lazy. We transliterate the ABNF to build the parser and so implement the syntax and read the English to figure out and so build the semantics. As I said, if you must have contradictions between your ABNF and your English, you must accept the fact that most technical people will assume your ABNF is right and your English is wrong. That fact seemed to me to conflict with statements in this thread, and that suggests a problem in your working group and your RFC. --- I agree with your observations about programmers and their tendencies. I think we agreed to modify the ABNF slightly (to make the grandfathered production cleaner) as a result. In fact, I'd go further: the draft *explicitly identifies* that such implementations will exist (Section 2.2.3 "Classes of Conformance"). Some care was taken so that ABNF-only implementations (which the authors take to include many extant RFC 3066 implementations) would not be broken by any sort of draft-langtags implementations, including future extensions, and to ensure that "junk" tags emitted by these implementations don't cause problems for more capable implementations. Actually, this isn't any different than the case with RFC 3066 today, where implementations must assume that junk tags are just registrations that they don't recognize. By altering the "grandfathered" production in the ABNF we ensure exact parity for everyone, since the general case is that production. Best Regards, Addison Addison P. Phillips Director, Globalization Architecture http://www.webMethods.com Chair, W3C Internationalization Working Group http://www.w3.org/International Internationalization is an architecture. It is not a feature. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf