[technical hat on] At 04:38 08/05/30, Phillips, Addison wrote: >I would like to submit a "modest proposal" for addressing the impasse: > >1. Restore a *single* extlang to the ABNF. This very, very much looks like a compromize. Of course, if we have at least one language with extlang, we need at least one subtag in the ABNF, so this is more a consequence of the proposals below than a proposal in itself. I personally understand the position of the XML Schema WG, and I also think that we should not change the wellformedness definition in RFC 4646, independent of how many (or how few, even zero) extlangs we use. We have in this WG (though unofficially) produced test data that includes three extlangs to test implementations, and changing this doesn't seem to be a good idea to me (I can very quickly change my implementation, but I have no idea how many or how few downloaded/ deployed there already are). >2. Keep the Macrolanguage field in the registry for all encompassed >languages, which information may be use by implementations however makes >the most sense.From ltru-bounces at ietf.org Mon Jun 2 02:04:55 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 765853A6CCB; Mon, 2 Jun 2008 02:04:55 -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 9ED6A3A6CCA for <ltru at core3.amsl.com>; Mon, 2 Jun 2008 02:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.969 X-Spam-Level: ** X-Spam-Status: No, score=2.969 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, RCVD_IN_NJABL_RELAY=2.696] 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 ZYZcccusvYcN for <ltru at core3.amsl.com>; Mon, 2 Jun 2008 02:04:51 -0700 (PDT) Received: from scmailgw2.scop.aoyama.ac.jp (scmailgw2.scop.aoyama.ac.jp [133.2.251.195]) by core3.amsl.com (Postfix) with ESMTP id 249413A6CC8 for <ltru at ietf.org>; Mon, 2 Jun 2008 02:04:51 -0700 (PDT) Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id m5294lTv021009 for <ltru at ietf.org>; Mon, 2 Jun 2008 18:04:48 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 32ed_f3696434_3082_11dd_9ed7_0014221f2a2d; Mon, 02 Jun 2008 18:04:47 +0900 Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:36199) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S872C9> for <ltru at ietf.org> from <duerst at it.aoyama.ac.jp>; Mon, 2 Jun 2008 17:59:23 +0900 Message-Id: <6.0.0.20.2.20080602173204.0987cc40 at localhost> X-Sender: duerst at localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 02 Jun 2008 17:50:24 +0900 To: "Phillips, Addison" <addison at amazon.com>, LTRU Working Group <ltru at ietf.org> From: Martin Duerst <duerst at it.aoyama.ac.jp> In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA013A84C706 at EX-SEA5-D.ant.a mazon.com> References: <4D25F22093241741BC1D0EEBC2DBB1DA013A84C706 at EX-SEA5-D.ant.amazon.com> Mime-Version: 1.0 Subject: Re: [Ltru] a modest proposal... 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 [technical hat on] At 04:38 08/05/30, Phillips, Addison wrote: >I would like to submit a "modest proposal" for addressing the impasse: > >1. Restore a *single* extlang to the ABNF. This very, very much looks like a compromize. Of course, if we have at least one language with extlang, we need at least one subtag in the ABNF, so this is more a consequence of the proposals below than a proposal in itself. I personally understand the position of the XML Schema WG, and I also think that we should not change the wellformedness definition in RFC 4646, independent of how many (or how few, even zero) extlangs we use. We have in this WG (though unofficially) produced test data that includes three extlangs to test implementations, and changing this doesn't seem to be a good idea to me (I can very quickly change my implementation, but I have no idea how many or how few downloaded/ deployed there already are). >2. Keep the Macrolanguage field in the registry for all encompassed >languages, which information may be use by implementations however makes >the most sense. Fine w Fine with me. >3. Cherry pick *only* the 'zh' (and possibly the 'ar') encompassed >languages for registration as extlangs. This is done in the name of >compatibility alone. I'm personally okay with any kind of selection that would be able to make the "rough consensus" that we currently have a bit less rough. As I know there are some people who, for good reasons, don't like cherry-picking, such a selection, so having a good justification would help. I have stated my preference for also including 'ar' in a separate thread. Personally, I'd prefer including all those languages that have a 'dominant' (or whatever the politically/linguistically correct term) encompassed language. >4. Permit implementations to treat the 'language' >production as atomic (that is, the sequence "zh-yue" MAY be treated as if >it were a single subtag but MAY be treated as separate subtags, notably by >existing implementations). Note that the 'language' production is the one >that includes both the primary and extended language subtags. That definitely seems to be a very good idea. As far as I understand, we already allow virtually any kind of modification for matching provided "you know what you do", but the above definitely adds a lot of clarity. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru ith me. >3. Cherry pick *only* the 'zh' (and possibly the 'ar') encompassed >languages for registration as extlangs. This is done in the name of >compatibility alone. I'm personally okay with any kind of selection that would be able to make the "rough consensus" that we currently have a bit less rough. As I know there are some people who, for good reasons, don't like cherry-picking, such a selection, so having a good justification would help. I have stated my preference for also including 'ar' in a separate thread. Personally, I'd prefer including all those languages that have a 'dominant' (or whatever the politically/linguistically correct term) encompassed language. >4. Permit implementations to treat the 'language' >production as atomic (that is, the sequence "zh-yue" MAY be treated as if >it were a single subtag but MAY be treated as separate subtags, notably by >existing implementations). Note that the 'language' production is the one >that includes both the primary and extended language subtags. That definitely seems to be a very good idea. As far as I understand, we already allow virtually any kind of modification for matching provided "you know what you do", but the above definitely adds a lot of clarity. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp _______________________________________________ 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.