Review of draft-phillips-langtags-03
mark.davis at jtcsv.com
Tue Jul 13 22:33:35 CEST 2004
What we do is provide a structure for private use codes; we don't provide an
interpretation of those codes. That is, in fact, very similar to the way
that 10646 works; it provides a structure for private use, and a structure
for how private use codes can be intermixed with 'public' use codes.
----- Original Message -----
From: "Mike Ksar" <mikeksar at microsoft.com>
To: <ned.freed at mrochek.com>; "Harald Tveit Alvestrand"
<harald at alvestrand.no>
Cc: <ietf-languages at iana.org>; <iesg at ietf.org>
Sent: Monday, June 28, 2004 11:22
Subject: RE: Review of draft-phillips-langtags-03
I share the concerns expressed by Harald and others on RFC 3066bis.
Any future extensions, such as allowing/encouraging private-use "q"
tags, private-use "x" tags and the "x-" singleton, should not be part of
the conformance clause for this RFC. This would follow the example how
"Private Use" is treated in ISO 10646/Unicode, and is not part of the
Here is a quote from clause 2, Conformance, and 2.1 General, in ISO/IEC
"Whenever private use characters are used as specified in
ISO/IEC 10646, the characters themselves shall not be covered by these
[following] conformance requirements."
It certainly will cause interoperability problems if specified in RFC
3066bis. For meaningful interchange of such information an agreement,
independent of RFC 3066bis, is necessary between sender and recipient.
From: ietf-languages-bounces at alvestrand.no
[mailto:ietf-languages-bounces at alvestrand.no] On Behalf Of
ned.freed at mrochek.com
Sent: Sunday, June 27, 2004 1:21 PM
To: Harald Tveit Alvestrand
Cc: ietf-languages at iana.org; iesg at ietf.org
Subject: Re: Review of draft-phillips-langtags-03
> Let me make one thing perfectly clear: I do not like this proposal. To
> it smacks of overengineering and overambitious frameworks that allow
> extremely large number of variations that recipients must be able to
> 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
> less useful to the wide communtiy than a whole-tag registration
> I think that generative grammars that permit "all well-formed tags" is
> useful than a scheme that permits only tags that someone has bothered
> argue are useful.
> But I have been convinced by the debate on the ietf-languages list
> 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
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
> needs to have a LARGE caveat that such use MUST be "only between
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
> 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
> long section on how they might be used if ISO ever creates something
> fits into this space.
> - Extension single-letter tags: Section 3.3 specifies rules for
> 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
> over the Internet and at no cost" possibly invalidates this very
> And their ordering is specified, including speculation about the
> requirements they may impose.
> - Allowing/encouraging private-use "q" tags, private-use "x" tags and
> "x-" singleton. Allowing ALL of these seem excessive.
> - Allowing registration of *any* language tag longer than 3 characters
> the first subtag of a tag. This opens the door for IANA to become
> 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
> consist of a language subtag followed by a 3-letter subtag are not
> 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
> looks gross. It is better to define the special meaning of "x" in text
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
> The grammar given is incompatible with RFC 3066; RFC 3066 allows
> be up to 8 characters; the proposal lengthens this to 15 characters
> 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.
Ietf-languages mailing list
Ietf-languages at alvestrand.no
Ietf-languages mailing list
Ietf-languages at alvestrand.no
More information about the Ietf-languages