[Ltru] Extensions in general (was: Re: Fwd: draft-davis-t-langtag-ext )

"Doug Ewell" <doug@ewellic.org> Sun, 10 July 2011 15:58 UTC

Message-ID: <CBE4658941304E35995DFAB0D2556E5E@DougEwell>
From: Doug Ewell <doug@ewellic.org>
To: ltru@ietf.org
References: <mailman.3012.1310309232.3031.ltru@ietf.org>
In-Reply-To: <mailman.3012.1310309232.3031.ltru@ietf.org>
Date: Sun, 10 Jul 2011 09:31:55 -0600
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: [Ltru] Extensions in general (was: Re: Fwd: draft-davis-t-langtag-ext )
Precedence: list

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> I'm not sure that I see where the "overhead" is.  Can you elaborate?

The overhead would be in revising BCP 47 to change the extension 
mechanism or add a new one.

> Keeping everything in one place/list has got to be easier for the end 
> user.  I still cannot see any real reason for taking this out of IETF 
> other than BCP47 allows for it.

Having everything in one place is easier for the user (which is why I 
don't like scattering the values for either -t- or -u- across multiple 
files), but there is a reason.  It's not just that "BCP47 allows for 
it."  We who worked on BCP 47 *wanted* it to allow for this, so that 
"well-regulated" individuals and organizations that came up with new 
needs for BCP 47 could implement them in a systematic way, and not force 
the LTRU group to go back and rewrite the RFC again, at an expense of 
several years and much political and bureaucratic strife, and probable 
scope creep like last time.

By creating an extension, nothing is being "taken out of" ietf-languages 
that was already there, except to the extent that transliterations etc. 
have heretofore been handled by registering variants (through 
ietf-languages) and would now be handled via the -t- extension.  That is 
an issue that needs to be addressed—for example, should ietf-languages 
deprecate existing variants like 'pinyin' if they become available 
via -t-?  Users are supposed to be able to ignore extensions if they 
don't understand them or choose not to, but they are not supposed to 
ignore variants.

I agree with Addison that the question of whether the extension 
mechanism is a good one (including delegating the administration of the 
data to a third-party organization) is separate from the question of 
whether transliterations etc. should be an extension or not, or whether 
draft-davis-t-langtag-ext has any particular issues.  I suggest that 
everyone read RFC 5646, Section 3.7 and decide whether they feel this 
draft satisfies it.

--
Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell

[Ltru] Extensions in general (was: Re: Fwd: draft… Doug Ewell