Re: [Ltru] draft-davis-t-langtag-ext

"Debbie Garside" <debbie@ictmarketing.co.uk> Fri, 08 July 2011 18:51 UTC

Return-Path: <debbie@ictmarketing.co.uk>
X-Original-To: ltru@ietfa.amsl.com
Delivered-To: ltru@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8221F8A43 for <ltru@ietfa.amsl.com>; Fri, 8 Jul 2011 11:51:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn+BW5E0FpgF for <ltru@ietfa.amsl.com>; Fri, 8 Jul 2011 11:51:26 -0700 (PDT)
Received: from 145.nexbyte.net (145.nexbyte.net [62.197.41.145]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8021F8A7E for <ltru@ietf.org>; Fri, 8 Jul 2011 11:51:22 -0700 (PDT)
Received: from ICTPC ([92.28.116.69]) by 145.nexbyte.net with MailEnable ESMTP; Fri, 08 Jul 2011 19:51:30 +0100
From: Debbie Garside <debbie@ictmarketing.co.uk>
To: 'Doug Ewell' <doug@ewellic.org>
References: <20110708093849.665a7a7059d7ee80bb4d670165c8327d.f7747e9524.wbe@email03.secureserver.net>
In-Reply-To: <20110708093849.665a7a7059d7ee80bb4d670165c8327d.f7747e9524.wbe@email03.secureserver.net>
Date: Fri, 08 Jul 2011 19:52:37 +0100
Message-ID: <090501cc3da0$354aad90$9fe008b0$@co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
thread-index: Acw9jZXP2nGraEblQRKbIuDvzwNSNgAEd2yQ
Content-Language: en-gb
Cc: ltru@ietf.org
Subject: Re: [Ltru] draft-davis-t-langtag-ext
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2011 18:51:29 -0000

Thanks Doug

Yes that's what I was thinking of.

(Being lazy here) Does BCP47 reference the -u extension RFC?

If not things seem to be getting very messy with subtag rules potentially in a number of RFCs.

Just as an aside, ISO are actually merging all of the ISO 639 standards into one workable document.  It will be known as ISO 639 and will replace all the other standards.  I am the new Editor (appointed in Korea in June).

I must say I am more for merging procedures rather than splitting.  Quite funny as when it comes to languages I am for splitting rather than clumping :-)

Best

Debbie

-----Original Message-----
From: Doug Ewell [mailto:doug@ewellic.org] 
Sent: 08 July 2011 17:39
To: Debbie Garside
Cc: ltru@ietf.org
Subject: RE: [Ltru] draft-davis-t-langtag-ext

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

> Also, if my memory serves me correct, the responsibility for
> maintaining extension data was designed for private extensions not
> this type of extension where there is a more public use.

If you mean the 'x' singleton, as in "en-x-whatever", there are no
procedures.  You just make up the subtags and use them, and if you want
anyone else to understand them, you distribute a private agreement. 
These subtags don't have to be stabled, versioned, or freely available. 
They do have to be syntactically valid (e.g. 2*8alphanum), but that's
about it.

I just noticed that RFC 5646, Section 2.2.6 ("Extension Subtags"), item
3 says, "Note that there might not be a registry of these subtags."  I
missed this until now and wonder how it fits with Section 3.7, which
requires the extension RFC to specify the "URL location of the
registry."  Obviously that doesn't mean the IANA Language Tag Extensions
Registry; there would be no point in repeating that in every extension
RFC.

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