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

"Doug Ewell" <> Fri, 08 July 2011 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DACCC21F86C5 for <>; Fri, 8 Jul 2011 07:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z8kKgxBqdB6C for <>; Fri, 8 Jul 2011 07:55:29 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 3392821F869E for <>; Fri, 8 Jul 2011 07:55:29 -0700 (PDT)
Received: (qmail 20352 invoked from network); 8 Jul 2011 14:55:26 -0000
Received: from unknown (HELO localhost) ( by with SMTP; 8 Jul 2011 14:55:26 -0000
Received: (qmail 12031 invoked by uid 99); 8 Jul 2011 14:55:26 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
User-Agent: Web-Based Email 5.5.08
Message-Id: <>
From: "Doug Ewell" <>
Date: Fri, 08 Jul 2011 07:55:25 -0700
Mime-Version: 1.0
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 14:55:30 -0000

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 ­