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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf