> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of > Martin Duerst > Sent: Friday, June 20, 2008 12:01 AM > Subject: Re: [Ltru] draft updated > >Just letting you and the WG know that I continue to *strongly* favor > >making "zh-cmn" and "zh-yue" (and the rest) the preferred forms, and > >"cmn" and "yue" the pre-deprecated ones. > > [technical hat on] Seconded. Regards, Martin. I haven't commented on this yet, nor has there been much discussion. I'm guessing that there are some differences of opinion here. Indeed, it strikes me that opinions may correlate to a large degree with opinions on whether to keep use of extlang or not. I think we have three approaches that can be taken wrt extlang, only two of which have really been seen so far: for language productions X-Y and Y where X denotes a macrolanguage that encompasses Y 1. only allow one of X-Y or Y to be used 2. allow either X-Y or Y, but deprecate one of them 3. allow either X-Y or Y without deprecation #1, of course, we have spent months on without reaching any consensus. Hence, I think #1 is dead. #2 is currently on the tableFrom ltru-bounces at ietf.org Tue Jul 1 08:35:23 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 4BED83A68D1; Tue, 1 Jul 2008 08:35:23 -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 D3CDD3A6B28 for <ltru at core3.amsl.com>; Tue, 1 Jul 2008 08:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TJKDewNkc+9K for <ltru at core3.amsl.com>; Tue, 1 Jul 2008 08:35:21 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 74D4F3A6BB3 for <ltru at ietf.org>; Tue, 1 Jul 2008 08:33:23 -0700 (PDT) Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.54.46.187) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.251.2; Tue, 1 Jul 2008 08:33:34 -0700 Received: from NA-EXMSG-C117.redmond.corp.microsoft.com ([157.54.62.44]) by tk1-exhub-c103.redmond.corp.microsoft.com ([157.54.46.187]) with mapi; Tue, 1 Jul 2008 08:33:34 -0700 From: Peter Constable <petercon at microsoft.com> To: LTRU Working Group <ltru at ietf.org> Date: Tue, 1 Jul 2008 08:33:31 -0700 Thread-Topic: extlang & deprecation (was draft updated Thread-Index: AcjSvbtyGak94BzbROi83Ty/WYVRDQIwsqJQ Message-ID: <DDB6DE6E9D27DD478AE6D1BBBB8357956338F0C9FF at NA-EXMSG-C117.redmond.corp.microsoft.com> References: <C51F9153327D4470A0DDA6726CBB7A10 at DGBP7M81> <20080619035712.GI32073 at mercury.ccil.org> <6.0.0.20.2.20080620155949.06087920 at localhost> In-Reply-To: <6.0.0.20.2.20080620155949.06087920 at localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [Ltru] extlang & deprecation (was draft updated 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 > From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of > Martin Duerst > Sent: Friday, June 20, 2008 12:01 AM > Subject: Re: [Ltru] draft updated > >Just letting you and the WG know that I continue to *strongly* favor > >making "zh-cmn" and "zh-yue" (and the rest) the preferred forms, and > >"cmn" and "yue" the pre-deprecated ones. > > [technical hat on] Seconded. Regards, Martin. I haven't commented on this yet, nor has there been much discussion. I'm guessing that there are some differences of opinion here. Indeed, it strikes me that opinions may correlate to a large degree with opinions on whether to keep use of extlang or not. I think we have three approaches that can be taken wrt extlang, only two of which have really been seen so far: for language productions X-Y and Y where X denotes a macrolanguage that encompasses Y 1. only allow one of X-Y or Y to be used 2. allow either X-Y or Y, but deprecate one of them 3. allow either X-Y or Y without deprecation #1, of course, we have spent months on without reaching any consensus. Hence, I think #1 is dead. #2 is currently on the table, but I , but I see indicators that we could get stuck on it. (In fact, I'm guessing that one reason there haven't been responses on John's and Martin's comments is that people are afraid of getting into the same rut we were in wrt #1.) I also see another potential concern wrt #2: I think there is an implicit assumption that X-Y and Y be considered semantically equivalent in terms of what they denote (although they may have slightly different behaviours in certain matching scenarios). Yet, with one or the other deprecated, there's some likelihood that some implementations will assume that the deprecated form can be largely disregarded in designing matching behaviour. Btw, it should be noted that both #1 and #2 lead to consideration of cherry picking. Now, let me propose an elaboration of #3 for adoption. This elaboration is captured by three points: (a) that both X-Y and Y are freely allowed, (b) that at the level of the language production X-Y and Y must always be considered a match (regardless of which is part of a tag or of a language range), but (c) that how X and Y compare in matching is a separate consideration (perhaps with some suggestions but ultimately left to implementations). This proposal frees us entirely from having to decide whether "zh-cmn"/"zh-yue" or "cmn"/"yue" is better. It would also mean there's no particular reason to cherry pick: the IETF-Language can discuss when it may or may not be beneficial to use the extlang formulation, but users can ultimately decide for themselves and (because of requirement b) they are assured of some degree of interoperability no matter which they choose. Of course, this would probably need some revision to RFC4647, but I think we have been heading toward that regardless. Thoughts? Peter _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru see indicators that we could get stuck on it. (In fact, I'm guessing that one reason there haven't been responses on John's and Martin's comments is that people are afraid of getting into the same rut we were in wrt #1.) I also see another potential concern wrt #2: I think there is an implicit assumption that X-Y and Y be considered semantically equivalent in terms of what they denote (although they may have slightly different behaviours in certain matching scenarios). Yet, with one or the other deprecated, there's some likelihood that some implementations will assume that the deprecated form can be largely disregarded in designing matching behaviour. Btw, it should be noted that both #1 and #2 lead to consideration of cherry picking. Now, let me propose an elaboration of #3 for adoption. This elaboration is captured by three points: (a) that both X-Y and Y are freely allowed, (b) that at the level of the language production X-Y and Y must always be considered a match (regardless of which is part of a tag or of a language range), but (c) that how X and Y compare in matching is a separate consideration (perhaps with some suggestions but ultimately left to implementations). This proposal frees us entirely from having to decide whether "zh-cmn"/"zh-yue" or "cmn"/"yue" is better. It would also mean there's no particular reason to cherry pick: the IETF-Language can discuss when it may or may not be beneficial to use the extlang formulation, but users can ultimately decide for themselves and (because of requirement b) they are assured of some degree of interoperability no matter which they choose. Of course, this would probably need some revision to RFC4647, but I think we have been heading toward that regardless. Thoughts? Peter _______________________________________________ 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.