> > On the contrary, what the authors of a standard intend is not normative. > As much as possible, every standard must say what it means, because > what a standard says *is* its technical content. For example, I'm > unhappy about an apparent sentiment that would put ABNF on a lower > footing that the English text. I think I'm like most implementors and > perhaps unlike non-engineers in reversing that precedence. Whenever > I read an RFC, I rely first and foremost on the ABNF. I use the English > only for hints, and follow the ABNF instead of the English whenever > there is a conflict. The ABNF is not on a lower footing than the English text. But it is dependent on the English text in exactly the same way that the ABNF in RFC 3066 was. I think the suggestion to change the "grandfathered" production is a good one and will help implementers who start with the ABNF. I also think, though, that the establishment of a comprehensive (as opposed to fractional) registry is the real salient point for implementers here. An implementation of RFC 3066 that follows *only* the ABNF would happily proliferate garbage tags like "c57-x", not just valid ones. The existence of a registry in draft-langtags should focus implementer's attention on two things: the ABNF and the subtags that fit into them. In that regard draft-langtags will simplify the lives of implementers who do not read the text (in the same way that having a registry for character encoding names--"charsets"--does). > > > There are a couple other issues that ought to be addressed. > > I think Bruce Lilly started by charging that a potentially disruptive > document had reached last-call without any review by those concerned > with related, affected IETF standards. That sounds like a process > problem that needs at least 1% as many words as have been spent in > this mailing list in lawyerly talk such as whether "accounts" is more > appropriate than "account." The IETF process is not really my concern. I will note that many IETF and non-IETF standards folks have participated in the process of developing and reviewing draft-langtags, though. I don't know if a wider audience should have been invoked earlier in the process. Mark and I welcome comments and questions on the technical suitability of our draft. I think that we have fully and carefully considered the potential impact and, in fact, have helped to stabilize language tags, not just now but for the future as well. Peter made the argument that future I-D authors could write a draft that does whatever they please with regard to language tags. Which is true. However, draft-langtags lays down a framework that should guide the activities of these authors and constrain the changes they make in a manner that is completely compatible with implementations of draft-langtags (not to mention RFC 3066 and RFC 1766). I think that a guarantee of future stability---in implementations (including current ones), extensions, and the tags (data) themselves---is of great benefit to related and/or affected IETF standards. 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