Re: [Ltru] RFC 4646 production "grandfathered" considered harmful
Martin Duerst <duerst@it.aoyama.ac.jp> Mon, 18 September 2006 01:26 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uJ-0001Ti-9a; Sun, 17 Sep 2006 21:26:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GP7uH-0001Sz-KU for ltru@ietf.org; Sun, 17 Sep 2006 21:26:45 -0400
Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GP7uE-0004J5-Uy for ltru@ietf.org; Sun, 17 Sep 2006 21:26:45 -0400
Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k8I1QfOh007629 for <ltru@ietf.org>; Mon, 18 Sep 2006 10:26:41 +0900 (JST)
Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 365b_bd0b0758_46b4_11db_9068_0014221fa3c9; Mon, 18 Sep 2006 10:26:41 +0900
Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:49525) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S247EF> for <ltru@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 18 Sep 2006 10:26:46 +0900
Message-Id: <6.0.0.20.2.20060917163157.08a0e030@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Version 6J
Date: Sun, 17 Sep 2006 16:32:12 +0900
To: John Cowan <cowan@ccil.org>, ltru@ietf.org
From: Martin Duerst <duerst@it.aoyama.ac.jp>
Subject: Re: [Ltru] RFC 4646 production "grandfathered" considered harmful
In-Reply-To: <20060917061912.GB26073@ccil.org>
References: <20060917061912.GB26073@ccil.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc:
X-BeenThere: ltru@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Language Tag Registry Update working group discussion list <ltru.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Errors-To: ltru-bounces@ietf.org
Like John, I favor choice 2. Regards, Martin. At 15:19 06/09/17, John Cowan wrote: >Section 2.2.9 of RFC 4646 says: > > An implementation that claims to check for well-formed language tags > MUST: > > o Check that the tag and all of its subtags, including extension and > private use subtags, conform to the ABNF OR that the tag is on the > list of grandfathered tags. > > o Check that singleton subtags that identify extensions do not > repeat. For example, the tag "en-a-xx-b-yy-a-zz" is not well- > formed. > >(I have emphasized the word OR in the first bullet point.) > >Unfortunately, this wording allows too much. For example, the invalid tag >"ra-bb-it" matches the "grandfathered" rule in the ABNF. Therefore it >winds up being well-formed even though it cannot be analyzed as a sequence >of subtags and is not on the grandfathered list either. > >To avoid this, we can take one of two actions: > >1) Remove the "grandfathered" production in the ABNF altogether, and use >the "OR" in the conformance clause to allow the irregular grandfathered >tags (that is, those which don't match the "langtag" or "privateuse" >productions) to be well-formed. The danger here is that people will >implement the ABNF only, and the grandfathered tags will become outright >unusable rather than merely discouraged. > >2) Add an explicit "irregular" production in place of the "grandfathered" >production which explicitly enumerates the 17 irregular grandfathered >tags, thus: > >irregular = "en-GB-oed" / "i-ami" / "i-bnn" / "i-default" > / "i-enochian" / "i-hak" / "i-klingon" / "i-lux" / "i-mingo" > / "i-navajo" / "i-pwn" / "i-tao" / "i-tay" / "i-tsu" > / "sgn-BE-fr" / "sgn-BE-nl" / "sgn-CH-de" > >It is safe to enumerate this list explicitly, as it can neither grow >nor shrink. It's true that all the tags except "i-default" can become >deprecated, but that makes no difference to well-formed processors. >The other grandfathered tags in the registry are all well-formed already >and do not need to be in this list. > >In this case the conformance clause can be simplified by omitting the >second part of the "OR". > >I favor choice 2. > >-- >John Cowan cowan@ccil.org > "You need a change: try Canada" "You need a change: try China" > --fortune cookies opened by a couple that I know > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru
- [Ltru] RFC 4646 production "grandfathered" consid… John Cowan
- [Ltru] Re: RFC 4646 production "grandfathered" co… Frank Ellermann
- [Ltru] Re: RFC 4646 production "grandfathered" co… Stephane Bortzmeyer
- Re: [Ltru] RFC 4646 production "grandfathered" co… Addison Phillips
- Re: [Ltru] RFC 4646 production "grandfathered" co… Mark Davis
- Re: [Ltru] RFC 4646 production "grandfathered" co… John Cowan
- Re: [Ltru] RFC 4646 production "grandfathered" co… Martin Duerst
- Re: [Ltru] RFC 4646 production "grandfathered" co… Martin Duerst
- [Ltru] Re: RFC 4646 production "grandfathered" co… Frank Ellermann
- Re: [Ltru] RFC 4646 production "grandfathered" co… Mark Davis
- Re: [Ltru] Re: RFC 4646 production "grandfathered… John Cowan
- Re: [Ltru] RFC 4646 production "grandfathered" co… Addison Phillips
- [Ltru] Re: RFC 4646 production "grandfathered" co… Frank Ellermann
- Re: [Ltru] RFC 4646 production "grandfathered" co… John Cowan
- Re: [Ltru] RFC 4646 production "grandfathered" co… Addison Phillips
- [Ltru] Re: RFC 4646 production "grandfathered" co… Frank Ellermann
- Re: [Ltru] Re: RFC 4646 production "grandfathered… John Cowan
- Re: [Ltru] Re: RFC 4646 production "grandfathered… Mark Davis
- [Ltru] Re: RFC 4646 production "grandfathered" co… Doug Ewell
- [Ltru] Re: zh-hakka Doug Ewell
- Re: [Ltru] Re: zh-hakka Martin Duerst
- Re: [Ltru] Re: zh-hakka Doug Ewell
- [Ltru] Re: zh-hakka Frank Ellermann
- [Ltru] Re: RFC 4646 production "grandfathered" co… Doug Ewell
- Re: [Ltru] Re: zh-hakka Addison Phillips
- Re: [Ltru] Re: RFC 4646 production "grandfathered… Addison Phillips
- [Ltru] Re: RFC 4646 production "grandfathered" co… Doug Ewell