> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf