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