(editor hat now OFF) > BNF: In the current state of things, why are we allowing two > extlangs > rather than one or three? Allowing two makes "zh-min-nan" regular > rather > than irregular, but surely that is a trivial point. One is all > that will > be allowed in non-grandfathered cases. Three is what 4646 > permitted. > I'd go for three, even though the capacity won't be used, just to > avoid a gratuitous change to the production. I follow the latter part of your comment, but not the first part. The ABNF allows 0, 1, 2, or 3 extlangs. It is functionally equivalent to the older version. I did anticipate the question about changing the actual BNF notation to permanently reserve the second and third positions, but thought I'd include it initially (for much the same reason that we put the 'regular' production in, etc.). It even turned out to be useful to me in my implementation (I can look at that From ltru-bounces at ietf.org Fri Jun 20 14:04:09 2008 Return-Path: <ltru-bounces at ietf.org> X-Original-To: ltru-archive at megatron.ietf.org Delivered-To: ietfarch-ltru-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A433A6805; Fri, 20 Jun 2008 14:04:09 -0700 (PDT) X-Original-To: ltru at core3.amsl.com Delivered-To: ltru at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5CAE3A683E for <ltru at core3.amsl.com>; Fri, 20 Jun 2008 14:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.3 X-Spam-Level: X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 EvAhob9byuJU for <ltru at core3.amsl.com>; Fri, 20 Jun 2008 14:04:07 -0700 (PDT) Received: from smtp-fw-2101.amazon.com (smtp-fw-2101.amazon.com [72.21.196.25]) by core3.amsl.com (Postfix) with ESMTP id C3C233A6805 for <ltru at ietf.org>; Fri, 20 Jun 2008 14:04:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,681,1204502400"; d="scan'208";a="71582436" Received: from smtp-in-5102.iad5.amazon.com ([10.218.9.29]) by smtp-border-fw-out-2101.iad2.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jun 2008 21:04:08 +0000 Received: from ex-hub-4103.ant.amazon.com (ex-hub-4103.sea5.amazon.com [10.248.163.24]) by smtp-in-5102.iad5.amazon.com (8.12.11/8.12.11) with ESMTP id m5KL45Lm018641 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 20 Jun 2008 21:04:05 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-hub-4103.ant.amazon.com ([10.248.163.24]) with mapi; Fri, 20 Jun 2008 14:04:05 -0700 From: "Phillips, Addison" <addison at amazon.com> To: John Cowan <cowan at ccil.org>, "ltru at ietf.org" <ltru at ietf.org> Date: Fri, 20 Jun 2008 14:04:00 -0700 Thread-Topic: [Ltru] A few points about the 4646 vs. -16 diff Thread-Index: AcjTEW9o8y2pjANoTDmOecaUqqRI8QABUPNQ Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA013B37F7C9 at EX-SEA5-D.ant.amazon.com> References: <20080620200834.GP25157 at mercury.ccil.org> In-Reply-To: <20080620200834.GP25157 at mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Ltru] A few points about the 4646 vs. -16 diff X-BeenThere: ltru at 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 at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/ltru> List-Post: <mailto:ltru at ietf.org> List-Help: <mailto:ltru-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request at ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ltru-bounces at ietf.org Errors-To: ltru-bounces at ietf.org (editor hat now OFF) > BNF: In the current state of things, why are we allowing two > extlangs > rather than one or three? Allowing two makes "zh-min-nan" regular > rather > than irregular, but surely that is a trivial point. One is all > that will > be allowed in non-grandfathered cases. Three is what 4646 > permitted. > I'd go for three, even though the capacity won't be used, just to > avoid a gratuitous change to the production. I follow the latter part of your comment, but not the first part. The ABNF allows 0, 1, 2, or 3 extlangs. It is functionally equivalent to the older version. I did anticipate the question about changing the actual BNF notation to permanently reserve the second and third positions, but thought I'd include it initially (for much the same reason that we put the 'regular' production in, etc.). It even turned out to be useful to me in my implementation (I can look at that groupinggrouping in the regular expression and 'invalidate' tags without bothering to look at the subtags). (editor hat now ON) > > In 2.2.4 and and 2.2.5, point 1 says "language" instead of > "language, > extended language" for the tags which must precede the tag > currently > under discussion. In 2.2.6 it's point 9, in 2.2.7 point 3. Done. > > In the first of the three examples at the end of 2.2.4, why was > Switzerland replaced with Austria? I don't quite recall, but I think it has to do with the discussion of "gsw" vs "de-CH". Austria doesn't have this problem. > > 2.2.8: Probably no need to enumerate the regular grandfathered tags > in prose, since they are now enumerated in the BNF. Done. Text now reads: <t>Grandfathered tags that (appear to) match the 'langtag' production in <xref target="ABNF"></xref> are considered 'regular' grandfathered tags. These tags either contain subtags that do not individually appear in the registry, or their subtags appear but with a different semantic meaning: each tag, in its entirety, represents a language or collection of languages.</t> > > 2.2.8 near the end: s/superseded/superseded by/. Done. > > 3.1.2: in bullet point 'Type', add comma after "redundant". Done. > > 3.1.2: s/MUST only appear/MUST appear only/. Done 6x. > > 3.1.2: s/will always follow/will always conform to/. Done. > > 4.4.1: bring back extlangs here > Will study this and bring back the text. Haven't done it yet: I'm teaching a class in a few minutes. _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru in the regular expression and 'invalidate' tags without bothering to look at the subtags). (editor hat now ON) > > In 2.2.4 and and 2.2.5, point 1 says "language" instead of > "language, > extended language" for the tags which must precede the tag > currently > under discussion. In 2.2.6 it's point 9, in 2.2.7 point 3. Done. > > In the first of the three examples at the end of 2.2.4, why was > Switzerland replaced with Austria? I don't quite recall, but I think it has to do with the discussion of "gsw" vs "de-CH". Austria doesn't have this problem. > > 2.2.8: Probably no need to enumerate the regular grandfathered tags > in prose, since they are now enumerated in the BNF. Done. Text now reads: <t>Grandfathered tags that (appear to) match the 'langtag' production in <xref target="ABNF"></xref> are considered 'regular' grandfathered tags. These tags either contain subtags that do not individually appear in the registry, or their subtags appear but with a different semantic meaning: each tag, in its entirety, represents a language or collection of languages.</t> > > 2.2.8 near the end: s/superseded/superseded by/. Done. > > 3.1.2: in bullet point 'Type', add comma after "redundant". Done. > > 3.1.2: s/MUST only appear/MUST appear only/. Done 6x. > > 3.1.2: s/will always follow/will always conform to/. Done. > > 4.4.1: bring back extlangs here > Will study this and bring back the text. Haven't done it yet: I'm teaching a class in a few minutes. _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.