Re: [Ltru] RFC 3282: should we revise it?

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Sat, 22 August 2009 05:38 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707243A6903 for <ltru@core3.amsl.com>; Fri, 21 Aug 2009 22:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.315
X-Spam-Level: *
X-Spam-Status: No, score=1.315 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5zcN5qVO01K for <ltru@core3.amsl.com>; Fri, 21 Aug 2009 22:38:06 -0700 (PDT)
Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 96F723A67DF for <ltru@ietf.org>; Fri, 21 Aug 2009 22:38:05 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n7M5c0f7028646 for <ltru@ietf.org>; Sat, 22 Aug 2009 14:38:00 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 6c06_f41dd22e_8edd_11de_9292_001d096c566a; Sat, 22 Aug 2009 14:38:00 +0900
Received: from [IPv6:::1] ([133.2.210.1]:58787) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S11CB2CF> for <ltru@ietf.org> from <duerst@it.aoyama.ac.jp>; Sat, 22 Aug 2009 14:34:50 +0900
Message-ID: <4A8F8407.5090302@it.aoyama.ac.jp>
Date: Sat, 22 Aug 2009 14:37:11 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre
MIME-Version: 1.0
To: Doug Ewell <doug@ewellic.org>
References: <mailman.77.1249498812.3028.ltru@ietf.org> <292E8A1E354941089DE14D0A4B506207@DGBP7M81>
In-Reply-To: <292E8A1E354941089DE14D0A4B506207@DGBP7M81>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: LTRU Working Group <ltru@ietf.org>
Subject: Re: [Ltru] RFC 3282: should we revise it?
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 22 Aug 2009 05:38:08 -0000

[Co-chair hat off; mostly written a couple weeks ago]

I'm mostly offline now, so I haven't actually looked at the text, but 
from Doug's list below, it seem to me that an update may be desirable, 
but not really needed. That means that if somebody (like the YAM WG) 
really has the cycles to do, why not, but otherwise, there might be more 
pressing work around. Please note that RFC 4646 obsoletes (or was it 
updates) RFC 3066, so for all intents and purposes, the references in 
RFC 3282 to RFC 3066 are actually to RFC 4646, or soon an even newer one.

Regards,   Martin.

On 2009/08/06 10:37, Doug Ewell wrote:
> "Phillips, Addison" <addison at amazon dot com> wrote:
>
>> Ever the optimist, I would hope that such a revision wouldn't require
>> the level of effort needed for the BCP 47 work.
>
> You never know. In September 2005 on ietf-languages, Peter Constable
> mentioned the upcoming 4646bis effort and said:
>
> "For my part, I hope that *that* revision is completed in a *much*
> shorter time that 3066bis has taken."
>
> As we now know, 4646bis took a year or so longer than 4646.
>
> But a quick look at RFC 3282--which is possible, since it's only 8 pages
> long including boilerplate and page breaks--suggests that the following
> changes might be all that is necessary:
>
> * Update reference to ABNF and remove EBNF in sections 2 and 3.
>
> * Update examples in Section 2.1 using i-languages to use ISO 639-based,
> grandfathered, hypothetical 5-to-8-character registered, or private-
> use tags instead.
>
> * Consider a simple update to Section 4, possibly just a pointer to the
> security section of 4646bis.
>
> * As suggested by CE Whitehead, update reference to Language "Tag"
> Reviewer (which was correct at the time 3282 was written) to refer to
> the Language "Subtag" Reviewer instead. (On the other hand, it's just
> an acknowledgement.)
>
> * Split references into normative and informative.
>
> * Update [TAGS] reference to 3066 to point to 4646bis instead.
>
> * Consider removing references to ISO standards, as the syntax and
> content of tags are fully defined by 4646bis and the Registry.
>
> This in turn suggests that it should be feasible for an individual to
> prepare and submit an update without experiencing the surreal delays of
> the LTRU process, and without being subjected to undue slings and arrows.
>
> --
> Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14
> http://www.ewellic.org
> http://www1.ietf.org/html.charters/ltru-charter.html
> http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp