Which is what 3066 does. So the questions remain as to what
real problems we have in internetworking that 3066 does not
solve and, if there are such problems, whether they can be fixed
by a less radical and complex change to the 3066 framework.
There are real problems with the identification of languages outlined in a
number of places in draft-langtags, the announcement, and elsewhere. These
problems are not solved by RFC 3066 due to the design of the registration
mechanism in particular. I'll come back to those in a separate message.
First I want to address your rhetoric! :-)
The description of draft-langtags as a "radical" and "complex" change to the
RFC 3066 framework I think is unwarranted. Although there is a lot of
additional content in the draft, most of this content focuses on
establishing greater stability in the language tag framework, now and for
the future. Your claim that the language tags defined by the draft are
incompatible with RFC 3066 is false.
Let me explain.
First, all draft-langtags tags are *fully* backwards compatible with RFC
3066, both in terms of the ABNF and the possibility of those tags for
registration. Every single such tag could be registered. Creating
draft-langtags obviates the need to register every one of a potentially very
large class of tags.
Second, all RFC 3066 language tags are *fully* forward compatible with
draft-langtags. The few tags that do not meet one or another requirement of
the draft for subtag registration are grandfathered in.
Third, registry conversion is a poor characterization of the process. RFC
3066's registry will continue to exist, but will no longer be maintained (it
will be dead, since items cannot be added to it or, by RFC 3066's own rules,
removed). draft-langtags will comprise a new registry that happens to
contain everything previously defined by the RFC 3066 registry.
Fourth and finally, references to RFC 3066 in extant RFCs and I-Ds need not
be changed immediately. Certainly a transition period is warranted. In any
case, implementations of RFC 3066 in Internet-Drafts and RFCs generally
incorporate language tags or language ranges as holistic entities (as in:
"this field identifies the language of the content using identifiers defined
by RFC 3066") and do not refer to the specific content of the subtags. They
may refer to the structure of a language tag, but as noted, the RFC 3066
syntax is compatible with that in draft-langtags. RFC 3066 processors (if
they adhere to RFC 3066) will work correctly with draft-langtags tags.
The handwringing about "breaking things" is incorrect, I believe. Yes, the
document is different and the rules about what subtags can be registered are
more strict, but these changes are internal to the framework of the registry
and do not represent actual incompatibility as experienced by protocols,
implementers, or end users.
I should note: generally it is accepted practice to refer to "RFC 3066 or
its successors" in many standards organizations (such as W3C) that reference
language tags (since RFC 3066 itself obsoletes RFC 1766).
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