Review of draft-phillips-langtags-03

Doug Ewell dewell at
Wed Jun 30 06:40:02 CEST 2004

Harald Tveit Alvestrand <harald at alvestrand dot no> wrote:

> Let me make one thing perfectly clear: I do not like this proposal. To
> me, it smacks of overengineering and overambitious frameworks that
> allow an extremely large number of variations that recipients must be
> able to handle in order to deal with a problem with guidelines for
> registration and responsiveness of the registration authority.

I'm a bit concerned about the "overengineering" problem too,
particularly things like a specification for canonicalizing a sequence
of extensions that don't even exist and aren't even defined yet.

Fortunately, the way I see it, I can implement the parts of RFC 3066bis
that relate to things that currently exist -- the standard codes, the
registered subtags, and the grandfathered tags -- and ignore the rest.
If and when an extension mechanism is ever created, I can update my
implementation to handle it.  It's certainly easier than revising the
RFC.  I do understand, to a certain extent, the desire to build the RFC
so it won't have to be revised again right away.

> I think subtag registration is an approach that is harder to manage
> and less useful to the wide communtiy than a whole-tag registration
> scheme, and I think that generative grammars that permit "all well-
> formed tags" is less useful than a scheme that permits only tags that
> someone has bothered to argue are useful.

Count me among those who prefer to be able to compose an arbitrary tag
as the need arises, rather than waiting for it to be proposed, debated,
and registered.

I don't think this is necessarily a problem with "responsiveness of the
registration authority," either.  If the tag combinations are to be
limited to those that have been registered, it's natural that the
candidates have to go through a period of careful and deliberate review.
If all proposed combinations are to be quickly and automatically
accepted, why bother going through the motions?

> Interchanging private-use subtags is not something that should be
> absolutely outlawed, in my opinion. But if it is to be mentioned at
> all, it needs to have a LARGE caveat that such use MUST be "only
> between consenting adults".
> Private-use subtags are simply useless for information exchange
> without prior arrangement.

Has this really been a problem, that people throw private-use tags
around without any prior agreement as to what they mean?

> - Extension single-letter tags: Section 3.3 specifies rules for
> subtags that are specific enough and onerous enough that it's likely
> that any proposal for use of subtags would be fair game for a
> procedural denial-of-service attack. Just the "specification..... must
> be available over the Internet and at no cost" possibly invalidates
> this very document.

The experience with ISO 4217 -- where BSI only offers an outdated list
for free, and charges an exorbitant fee for the current version -- shows
exactly why such a specification is necessary.  Personally, I'm
delighted to see it.

> - Allowing/encouraging private-use "q" tags, private-use "x" tags and
> the "x-" singleton. Allowing ALL of these seem excessive.

I agree here.  I still don't understand why all three mechanisms are

> - Allowing registration of *any* language tag longer than 3 characters
> as the first subtag of a tag. This opens the door for IANA to become
> "fallback when you are rejected by ISO 639 RA" wider than the I- tag
> ever did.

How does this make the problem worse?  It's still up to the reviewer to
determine what does and does not get registered.

> The document is 35 pages long. RFC 3066 was 13 pages. Cutting out this
> sort of overspecification would help reduce the growth.

Part of the increased length, to be sure, comes from the fact that there
are many more examples and a longer list of references.  Also, if page
count is an issue, I'm sure sections 4 and 5 could fit on one page as
they were in RFC 3066, and the examples could be single-spaced instead
of double-spaced.

> The grammar given is incompatible with RFC 3066; RFC 3066 allows
> subtags to be up to 8 characters; the proposal lengthens this to 15
> characters without any justification for the change. Subtags in
> extensions can hit 31 characters; the reason to make 2 different
> length is not obvious.

I agree that there should be some justification here.  A 31-character
extension subtag is really, really long.

> The registration of the necessary UN codes in IANA should not be
> optional. The interesting codes should be given in this memo.

I see in the latest draft (-04) that not only the registered subtags,
but the standard codes as well, are to be included in a freely available
registry as well.  This is an excellent idea, and I plan to write about
it separately.

> Section 2.3 bullet 6: The NOTE is not specific to bullet 6. If
> specific to any bullet, it should be specific to bullet 4.

I think it belongs with bullet 3.  Also, the NOTE that goes with bullet
4 ("the displeasure of developers") should be placed in its own
paragraph and indented, just like the one we are discussing ("avoid
versioning difficulties").

-Doug Ewell
 Fullerton, California

More information about the Ietf-languages mailing list