> Comments on draft-ietf-ltru-registry and > draft-ietf-ltru-initial and, secondarily, on > draft-ietf-ltru-matching... I've thought a lot about the excellent analysis and comments in John Klensin's message. My perception is that we have a divergent view of the structure and significance of the LTRU draft(s). Although superficially the drafts are very different than the RFC 3066 that they seek to replace, in fact the structure is very similar. The drafts are attempting to fill certain gaps unaddressed by RFC 3066 for implementers or for tag choice by and the requirements on "content authors" (people who choose tags or ranges). Here are my basic thoughts in response to those comments: 1. All tags valid under the drafts would have been valid or valid to register under RFC 3066. This is a key point. The tag grammar proposed is intended to be highly compatible not just with RFC 3066 but also with existing implementation. It is expressed as greater restriction on what may be registered. This provides more regularity in tags, although tags themselves are not greatly changed. A subtag registry is, in effect, a different way of expressing what is already in place. 2. The fact that it *always* narrows the potential subtags that could be registered *in the future*, but has no effect on any tags or subtags already extant means that (from an RFC 3066 implementation perspective) the range of tags actually seen in the wild will be more limited than it might have been. Commentators on this thread have implied that it is an entirely new protocol, but I think that goes too far: it is the same protocol with greater rigor on what may go where. 3. The various rules and guidelines set down in the draft provide a more rigorous registration process based on the experience of operating ietf-languages for the seven or so years. This could be seen to make it the "best current practice" for registering language tags or their components. The switch to subtags was chosen to spare the community immense numbers of registrations of various subtag variations (examples from the current registry: two German orthographic subtags, eight registrations; two Chinese script subtags, *twelve* registrations). 4. The creation of a registry simplifies the work incumbent on implementers or content authors, since they no longer have to refer to (under RFC 3066) four separate tag-or-subtag repositories and then synthesize the rules in RFC 3066 for choosing between certain overlapping subtags (for example ISO 639-1/-2). The fact that there is a registry doesn't change the fact that "somewhere" there is a list of subtags that may be validly combined into tags. 5. There is a perfectly good matching scheme loosely described in RFC 3066. This scheme is enshrined in numerous places, including RFC 3282 (which, you'll note, also "Obsoletes: 1766", an example with 3066 of two RFCs obsolescing the same BCP on separate days over a year apart). The additional forms of matching described by the matching draft are interesting and may be useful in a variety of applications (draft-matching gives some examples). But they are unnecessary to the specific task of updating RFC 3066. Applications of language tags in the future may wish to choose one or another of the other schemes from draft-matching to produce more interesting results. But such additional schemes are not necessary to the task of updating RFC 3066. If the community feels that matching is so important that draft-registry must deal with it directly, my suggestion would be to take Section 2.5 verbatim from RFC 3066 and include it in draft-registry. This preserves the vital reference to language-ranges. It should be noted that RFC 3066 nowhere provides an explicit treatise on matching. Both it and draft-registry were written for compatibility with known matching schemes. Success or failure of the draft should necessarily be measured by its interoperability with existing matching protocols. My belief is that there is high interoperability, since the matching scheme is quite basic and the rules governing tag choice gave careful consideration to the problem of script subtags. 6. The tag forms used in the draft are, in fact, being registered and adopted. I note that Google this morning returns 41,600 hits for "zh-Hant" as a piece of content. Many of these appear to be valid usages as language tags---script subtags in the wild--rather than just mentions of the registration. Thus the draft merely recognizes the "reality on the ground" with regard to language tags. It does so by reorganizing how tags are registered to make the scheme more manageable. 7. The choice between STD and BCP tracks is really a toss-up. There are very good arguments on both sides. The creation and management of a registry does not lend itself to STD, but the creation and testing of implementations does not lend itself to BCP. My thought here is that one can view the draft entirely through the lens of existing RFC 3066 implementers: these documents represent a set of BCPs related to various aspects of registering, choosing, and implementing language tags. New implementations may be different as a result of the improvements made (certain kinds of assumptions can be made about a 3066bis tag that cannot be made about a 3066 tag). All such implementations will be recognizably implementations of RFC 3066, though, and to the benefit of all concerned (IMHO) they represent the best current thinking on the manner in which to identify languages on the Internet (given our legacy considerations). JCK wrote in part: -- These specifications are a nice piece of work and the model specified is quite elegant. It appears to me to meet the goals of permitting a high degree of specificity when needed while providing a plausible mechanism for preserving stability across changes in underlying documents. Having tried, mostly unsuccessfully, to track the WG's work, I believe that the IETF community owes those who have actively participated and contributed great thanks. -- As a participant in this effort, I have to say that it has been a remarkable and exhausting effort. I certainly hope that LTRU has, in fact, achieved its goals and hope too that, after a lot of work, we can move forward to a recognizable conclusion to these efforts. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf