>
(B> On the contrary, what the authors of a standard intend is not normative.
(B> As much as possible, every standard must say what it means, because
(B> what a standard says *is* its technical content. For example, I'm
(B> unhappy about an apparent sentiment that would put ABNF on a lower
(B> footing that the English text. I think I'm like most implementors and
(B> perhaps unlike non-engineers in reversing that precedence. Whenever
(B> I read an RFC, I rely first and foremost on the ABNF. I use the English
(B> only for hints, and follow the ABNF instead of the English whenever
(B> there is a conflict.
(B
(BThe ABNF is not on a lower footing than the English text. But it is
(Bdependent on the English text in exactly the same way that the ABNF in RFC
(B3066 was.
(B
(BI think the suggestion to change the "grandfathered" production is a good
(Bone and will help implementers who start with the ABNF.
(B
(BI also think, though, that the establishment of a comprehensive (as opposed
(Bto fractional) registry is the real salient point for implementers here. An
(Bimplementation of RFC 3066 that follows *only* the ABNF would happily
(Bproliferate garbage tags like "c57-x", not just valid ones. The existence of
(Ba registry in draft-langtags should focus implementer's attention on two
(Bthings: the ABNF and the subtags that fit into them. In that regard
(Bdraft-langtags will simplify the lives of implementers who do not read the
(Btext (in the same way that having a registry for character encoding
(Bnames--"charsets"--does).
(B>
(B>
(B> There are a couple other issues that ought to be addressed.
(B>
(B> I think Bruce Lilly started by charging that a potentially disruptive
(B> document had reached last-call without any review by those concerned
(B> with related, affected IETF standards. That sounds like a process
(B> problem that needs at least 1% as many words as have been spent in
(B> this mailing list in lawyerly talk such as whether "accounts" is more
(B> appropriate than "account."
(B
(BThe IETF process is not really my concern. I will note that many IETF and
(Bnon-IETF standards folks have participated in the process of developing and
(Breviewing draft-langtags, though. I don't know if a wider audience should
(Bhave been invoked earlier in the process. Mark and I welcome comments and
(Bquestions on the technical suitability of our draft. I think that we have
(Bfully and carefully considered the potential impact and, in fact, have
(Bhelped to stabilize language tags, not just now but for the future as well.
(B
(BPeter made the argument that future I-D authors could write a draft that
(Bdoes whatever they please with regard to language tags. Which is true.
(BHowever, draft-langtags lays down a framework that should guide the
(Bactivities of these authors and constrain the changes they make in a manner
(Bthat is completely compatible with implementations of draft-langtags (not to
(Bmention RFC 3066 and RFC 1766). I think that a guarantee of future
(Bstability---in implementations (including current ones), extensions, and the
(Btags (data) themselves---is of great benefit to related and/or affected IETF
(Bstandards.
(B
(BBest Regards,
(B
(BAddison
(B
(BAddison P. Phillips
(BDirector, Globalization Architecture
(Bhttp://www.webMethods.com
(B
(BChair, W3C Internationalization Working Group
(Bhttp://www.w3.org/International
(B
(BInternationalization is an architecture.
(BIt is not a feature.
(B
(B
(B
(B_______________________________________________
(BIetf mailing list
([EMAIL PROTECTED]
(Bhttps://www1.ietf.org/mailman/listinfo/ietf
