[Ltru] Frank's comments (was: Re: proto-draft-10)

"Doug Ewell" <dewell@roadrunner.com> Tue, 04 December 2007 05:57 UTC

Return-path: <ltru-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQmI-0007Fm-In; Tue, 04 Dec 2007 00:57:06 -0500
Received: from ltru by megatron.ietf.org with local (Exim 4.43) id 1IzQmG-00076k-Q3 for ltru-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 00:57:04 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzQmG-00075h-FT for ltru@ietf.org; Tue, 04 Dec 2007 00:57:04 -0500
Received: from mta13.adelphia.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzQmF-0006V4-OE for ltru@ietf.org; Tue, 04 Dec 2007 00:57:04 -0500
Received: from DGBP7M81 ([]) by mta13.adelphia.net (InterMail vM. 201-2131-123-102-20050715) with SMTP id <20071204055703.VNFK24109.mta13.adelphia.net@DGBP7M81> for <ltru@ietf.org>; Tue, 4 Dec 2007 00:57:03 -0500
Message-ID: <002201c8363a$7e17ef40$6601a8c0@DGBP7M81>
From: "Doug Ewell" <dewell@roadrunner.com>
To: "LTRU Working Group" <ltru@ietf.org>
References: <E1IzNhV-0004B6-6Y@megatron.ietf.org>
Date: Mon, 3 Dec 2007 21:57:02 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Subject: [Ltru] Frank's comments (was: Re: proto-draft-10)
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> I also note that it still contains the fantasy island codes,
> Chairs, please produce the consensus for this modification
> in -09.

I'd really like the chairs to declare consensus on a number of topics, 
because otherwise this happens: old decisions and non-decisions are 
revisited over and over again.

Chairs: *do* we have consensus for adding the exceptionally reserved 
3166 codes?  I'm not even asking any more for my position to be heard; I 
just want to know what the decision is.

> It still contains "Latin transliterations of descriptions",
> without saying what Latin is,

Do we need to provide a definition of the Latin script?

> or why the subtag review list
> should create "transliterations" when the source standard
> didn't bother for whatever reasons.

The source (ISO) standards will always provide Latin-script 
descriptions.  It's the independently registered subtags that need to 
have this specified.  We simply need to make sure we don't register 
"Description: Тарашкевіца" without providing a suitable Latin-script 

Personally I'm satisfied with the existing wording, because it does not 
go any farther than 4646 in recommending ASCII-only transcriptions. 
That was a popular thing to request a year or so ago.  Hopefully the 
advent of the UTF-8 Registry will put that to an end.

> It still contains the unused 5*8ALPHA "registered languages"
> instead of reviving the good tradition of i-whatever tags
> for this in the times of 639-3 likely unnecessary loophole.

I don't believe there is any popular sympathy, let alone consensus, to 
change this.  I wonder why you would call out Addison for not changing 

> As a consequence of not removing the extlang syntax it still
> contains the answer 42 instead of a much more MIME friendly
> limit 30 (or 31 for a 639-6 language).

You guys can beat the maximum-theoretical-tag-length issue into the 
ground if you wish.  I'll just be happy if implementers would stop 
getting confused in the presence of a script subtag.

> Allegedly it's unclear that a subtag can be "undrepecated"
> if say (in theory) ISO 3166-1 revives FX.  Or rather Doug
> said that it's clearly not allowed, IMO that would be a bug.

I think it's extremely clear in 4646.  Whether that's a bug is another 
question, one I think deserves serious discussion.  But we should be 
careful about breaking our own stability promises, and refusing to 
un-deprecate a subtag was a stability promise.

> It still allows "generic" variants without prefix, they're
> known to be cumbersome (fonipa + fonupa).

I don't see how they're "cumbersome."  They serve the purpose they were 
meant to serve: too many languages can be, and are, written in IPA to 
make it worthwhile to enumerate them all.

In any case, like removing the registered languages, I haven't seen no 
popular support for changing this.  (Another case where a declaration of 
consensus would be useful.)


> There are no registered languages, so what's the point of
> allowing the full set of BCP 47 features for them ?  For
> cases like i-default I don't miss any default-Hant-fonupa
> opportunity.

You're probably more likely to see a 5- to 8-letter registered language 
subtag before you see an extension.  The barriers to creating an 
extension are just too high.

> As explained earlier  5*8( ALPHA )  limits implementation
> freedom if there would be ever a variant and a language
> using the same subtag.

John Cowan replied to this:

> Rules for the first subtag don't apply to later subtags, period.
> The fact that you'd like them all to be unique doesn't make it so.

Exactly; they belong to different namespaces.

Or, to provide a wholly unnecessary analogy:  I work in an open office 
environment (no petitions, please; I'm talking physical offices), and as 
it turns out, I'm the only Doug in my building.  This makes certain 
petty operations a bit simpler: my co-workers can talk unambiguously 
about "Doug" without using, or even knowing, my surname, and when 
someone calls out "Doug" I can look up right away, confident in the 
knowledge that they mean me.  But this is no justification for my 
company to refuse to hire other, well-qualified Dougs.

Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

Ltru mailing list