Subject: Re: [Ltru] Fw: I-D Action: draft-falk-transliteration-tags-01.txt

From: "Doug Ewell" <[email-masked]>
Date: Wed, 15 Jun 2011 12:30:41 -0700

Mark Davis 🍣 <mark at macchiato dot com> wrote:

> There are major problems with that approach. Where should comments
> be directed?

One of the major problems with this draft, which hasn't been mentioned
yet, is that RFC 5646, Section 3.7 sets out specific requirements for
extensions.  It's not enough just to have an RFC that proposes
singletons: the singletons must be formally communicated to IANA and
added to the extensions registry, there must be a registry of valid
subtags, there must be a registering authority and discussion mailing
list, etc.  The present draft does not meet any of these requirements.

The draft states that the 's' singleton would be followed by "the ISO
15924 for the source script" (part of the draft's underlying
misconception that ISO code elements, not subtags from the LSR, are
directly used in language tags) and that the 't' singleton would be
followed by "a 2-8 character alphanumeric string abbreviation of the
transliteration system,"  There is no list, or pointer to a list, of 't'
subtags, nor any indication or assurance of their stability as required
by Section 3.7.  The draft says there are no IANA considerations, which
is far from true for a BCP 47 extension.

A comparison with RFC 6067 (the 'u' extension) would be helpful in
understanding how the BCP 47 requirements should be fulfilled.  While I
was surprised by the RFC 6067 implementation of "registry" as a set of
CLDR XML files, there is definitely a well-defined, freely accessible
list of subtags, a mailing list where users can ask questions about
then, and a process for proposing new ones.

I am a believer in the concept of BCP 47 extensions and would welcome a
better-conceived proposal that follows the BCP 47 rules and takes
existing BCP 47 mechanisms into better account (e.g. variant subtags
already exist for several transliteration systems).  The present
proposal is not suitable.

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