Review of draft-phillips-langtags-03
ned.freed at mrochek.com
ned.freed at mrochek.com
Sun Jun 27 22:21:27 CEST 2004
> 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
> 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
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.
> - 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