Review of draft-phillips-langtags-03

ned.freed at ned.freed at
Sun Jun 27 22:21:27 CEST 2004

> Introduction
> ------------

> 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 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.

> But I have been convinced by the debate on the ietf-languages list that a)
> I'm in a minority on this, and b) there are reasonable arguments for
> switching to a generative scheme.

FWIW, I an in complete agreement with Harald on this. I think this is an
overengineered proposal whose costs if implemented will almost certainly far
outweigh the benefits.

> Use of non-registered codepoints
> --------------------------------
> RFC 3066 says (section 2.2):

> > All 2-letter subtags are interpreted according to assignments
> > found in ISO standard 639, "Code for the representation of names
> > of languages" [ISO 639], or assignments subsequently made by the
> > ISO 639 part 1 maintenance agency or governing standardization
> > bodies.

> And similar text for the 3-letter subtags.

> This means that "private use" tags have NO interpretation. That was
> intentional.

> This proposal says (section 2.2, 3rd bullet of 3rd bulleted list):

> > o  ISO639-2 reserves for private use codes the range 'qaa'
> > through 'qtz'. These codes should be used for non-registered
> > language subtags.

> Similar for script codes.

> 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".

I agree. Every time we do this sort of thing and people take advantage
of the feature we end up with interop problems.

> Private-use subtags are simply useless for information exchange without
> prior arrangement.

> Excessive extensibility
> -----------------------
> Not only does this proposal make "legal" a huge number of hitherto
> undreamed-of tags, it provides several means of extensibility.

> Namely:

> - Extended language tags: 3-letter tags following the first subtag get a
> long section on how they might be used if ISO ever creates something that
> fits into this space.

> - 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.
> And their ordering is specified, including speculation about the ordering
> requirements they may impose.

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

> - 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.

> In my opinion, the 3-letter speculation is simply not reasonable to
> include. It should be restricted to a simple statement that "codes that
> consist of a language subtag followed by a 3-letter subtag are not defined
> by this memo, and are reserved for future extension". Period.

I agree with this as well. This opens the door to abuse.

> Allowing single-character subtags in the first tag positon would allow
> grandfathering of the "i-" subtags without special tag magic.
> And trying to encode the fact that "x" has a defined meaning in the ABNF
> looks gross. It is better to define the special meaning of "x" in text only.

This has been my experience as well - trying to do this sort of thing
in ABNF leads to overly complex syntax specifications. Semantics
attached to specific prefixes and such need to be spelled out in the text

> 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.

Its marginally OK to make something longer, as this does. But absent
a good reason I see no reason to do it.


More information about the Ietf-languages mailing list