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

"Debbie Garside" <> Fri, 08 July 2011 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 110D221F8ABC for <>; Fri, 8 Jul 2011 08:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.805
X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[AWL=0.794, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2XMKOhDDZPNf for <>; Fri, 8 Jul 2011 08:13:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9782521F89F0 for <>; Fri, 8 Jul 2011 08:13:43 -0700 (PDT)
Received: from ICTPC ([]) by with MailEnable ESMTP; Fri, 08 Jul 2011 16:13:49 +0100
From: "Debbie Garside" <>
To: "'Doug Ewell'" <>, <>
References: <>
In-Reply-To: <>
Date: Fri, 8 Jul 2011 16:14:24 +0100
Message-ID: <08c601cc3d81$b9370cd0$2ba52670$>
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: Acw9fzNvTmKyUnWJQrOBDmYo6GVsOAAAlH1A
Content-Language: en-gb
Subject: Re: [Ltru] draft-davis-t-langtag-ext
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2011 15:13:45 -0000

Thanks for the explanations Doug

Yes, it all seems terribly fractured which is another reason for keeping it within IETF.

Best wishes


-----Original Message-----
From: [] On Behalf Of Doug Ewell
Sent: 08 July 2011 15:55
Subject: Re: [Ltru] draft-davis-t-langtag-ext

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

> But I still don't see why it needs to be taken out of IETF.  Where is
> the added value?  Where are discussions held?  Why create another list
> when we already have IETF-languages?
> ...
> I really need to be shown the added value of outsourcing this work. I
> am open to being persuaded.

Actually, the responsibility for maintaining extension data has always
been delegated, ever since RFC 4646 introduced the extension mechanism.

A draft that proposes a new extension, such as the one under discussion,
defines the maintaining or registering authority for that extension.  In
theory this could be the ietf-languages list itself, but the membership
of that list, taken as a whole, has historically been less than eager to
embrace the extension concept.  Usually, proposing an extension implies
that one is assuming responsibility for its maintenance, including
setting up a mailing list for discussion.

The CLDR folks were ultimately responsible for proposing both RFC 6067
(the -u- extension) and the present draft, and it is natural that they
assume responsibility for maintaining it.  I'm not worried about that. 
I do have concerns that we neglected, in 4646 and 5646, to require that
the maintaining authority be open or have a transparent process, or that
the "registry" of extension data (paragraph 3) not be spread out across
multiple documents in different formats, including algorithms and prose
descriptions, omissions which are exploited (both IMHO) by 6067 and by
the present draft.

Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14 | | @DougEwell ­

Ltru mailing list