> > > > The big danger with variants is using two or more that are > mutually > > exclusive. '1901' and '1996' are mutually exclusive; there is no > > logical way in which both could ever be used in the same tag. To > steer > > people away from this, when a tag with two variants does make > sense, we > > explicitly indicate variant A as part of the Prefix for variant B. > The > > sub-dialects and '1994' sub-sub-dialect of Resian are examples of > this. > > > Unless we say that year digits should only be used to "date" an > existing language or norm - and not itself serve as reference to a > any language or norm - we could claim that 1996 is a modification > of 1901. And thus we could claim that "de-1901-1996" would be > meaningful. (Though redundant.) We could claim all sorts of things, but the current RFC already spells this particular case out and From ltru-bounces at ietf.org Sat Oct 4 09:43:04 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 779A03A690E; Sat, 4 Oct 2008 09:43:04 -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 5F4893A688A for <ltru at core3.amsl.com>; Sat, 4 Oct 2008 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.963 X-Spam-Level: X-Spam-Status: No, score=-106.963 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 InHW8YmWFl8K for <ltru at core3.amsl.com>; Sat, 4 Oct 2008 09:43:02 -0700 (PDT) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) by core3.amsl.com (Postfix) with ESMTP id 19B933A690E for <ltru at ietf.org>; Sat, 4 Oct 2008 09:43:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,361,1220227200"; d="scan'208";a="56440508" Received: from smtp-in-0201.sea3.amazon.com ([172.20.19.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Oct 2008 16:43:32 +0000 Received: from ex-hub-4102.ant.amazon.com (ex-hub-4102.ant.amazon.com [10.248.163.23]) by smtp-in-0201.sea3.amazon.com (8.12.11/8.12.11) with ESMTP id m94GhVjm009489 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Sat, 4 Oct 2008 16:43:31 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-hub-4102.ant.amazon.com ([10.248.163.23]) with mapi; Sat, 4 Oct 2008 09:43:31 -0700 From: "Phillips, Addison" <addison at amazon.com> To: Leif Halvard Silli <lhs at malform.no>, Doug Ewell <doug at ewellic.org>, LTRU Working Group <ltru at ietf.org> Date: Sat, 4 Oct 2008 09:41:42 -0700 Thread-Topic: [Ltru] Prefixes Thread-Index: Ackl9pDqN/sLUhDeRMmsp45Q+EvncQAR0kAg Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA014C7FAFDB at EX-SEA5-D.ant.amazon.com> References: <mailman.1595.1223013734.4981.ltru at ietf.org> <2E5435EE3D0B48C69C76968E47EFABA3 at DGBP7M81> <48E7215E.3060005 at malform.no> In-Reply-To: <48E7215E.3060005 at malform.no> 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] Prefixes 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 > > > > The big danger with variants is using two or more that are > mutually > > exclusive. '1901' and '1996' are mutually exclusive; there is no > > logical way in which both could ever be used in the same tag. To > steer > > people away from this, when a tag with two variants does make > sense, we > > explicitly indicate variant A as part of the Prefix for variant B. > The > > sub-dialects and '1994' sub-sub-dialect of Resian are examples of > this. > > > Unless we say that year digits should only be used to "date" an > existing language or norm - and not itself serve as reference to a > any language or norm - we could claim that 1996 is a modification > of 1901. And thus we could claim that "de-1901-1996" would be > meaningful. (Though redundant.) We could claim all sorts of things, but the current RFC already spells this particular case out and there exthere exists several years of usage--predating RFC4646--that say that 1996 is not a modification of 1901. > > By keeping a strict year meaning to year subtags, we can help that > registrants avoid such things [that I proposed] as 1996groene and > 1996witte. Why? More importantly, isn't that a matter for the registration process to determine/enforce, rather than the RFC? > > This to me suggests to that, in reality, there is consesus that > year subtags are strictly to be understood as years. Or else, as > mentioned above, "de-1901-1996" could be meaningful. No. The two German subtags you cite above are mutually exclusive because they both refer to specific orthographies. That is, language tag variant subtags refer to variations in language, not to years. Let's use a more useful example. 'boont' and 'scottish' are both registered variant subtags that can be applied to English (en). They are mutually exclusive because they refer to specific regional dialects/jargons. One cannot speak Boontling Scottish-wise or vice versa. Replacing 'boont' with '1890' and 'scottish' with (I dunno, let's pick a date) '1707' doesn't make the underlying language variations any different or mutually compatible. > > > This is inherently open to debate for each proposed variant, and > I am > > sure ietf-languages will hold such debates whether we add a rule > or not, > > so I do not support adding a new rule to attempt to regulate this > > behavior, especially not if we are trying to get through a Last > Call. > > > Of course it must be open to debate - we cannot know in advance > what one want to register and how it relatest to "reality". And I > do not think that the current lack of recommended region subtag > prefixes for 1996 is a fundamental error. But I do think that it > would be much more in line with the strict year meaning that you > apply to "-1996" to list the region variants of "de" for which the > 1996 dating is good. Really, when the prefix omits all mention of scripts or regions, we have the positive ability to use whichever ones make sense, even if the registrants overlooked and omitted one. I suspect that remnant populations might use 1901 or 1996, depending, with "de-NA". I think the problem here is that you're suggesting that we should try to register what all of the "correct" potential tags are. But the generative nature of language tags is based on a quite different philosophy: we don't have to do the detailed linguistic research and weigh all manner of data to provide such things (as the old RFC 3066 kind of required). Addison _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru ists several years of usage--predating RFC4646--that say that 1996 is not a modification of 1901. > > By keeping a strict year meaning to year subtags, we can help that > registrants avoid such things [that I proposed] as 1996groene and > 1996witte. Why? More importantly, isn't that a matter for the registration process to determine/enforce, rather than the RFC? > > This to me suggests to that, in reality, there is consesus that > year subtags are strictly to be understood as years. Or else, as > mentioned above, "de-1901-1996" could be meaningful. No. The two German subtags you cite above are mutually exclusive because they both refer to specific orthographies. That is, language tag variant subtags refer to variations in language, not to years. Let's use a more useful example. 'boont' and 'scottish' are both registered variant subtags that can be applied to English (en). They are mutually exclusive because they refer to specific regional dialects/jargons. One cannot speak Boontling Scottish-wise or vice versa. Replacing 'boont' with '1890' and 'scottish' with (I dunno, let's pick a date) '1707' doesn't make the underlying language variations any different or mutually compatible. > > > This is inherently open to debate for each proposed variant, and > I am > > sure ietf-languages will hold such debates whether we add a rule > or not, > > so I do not support adding a new rule to attempt to regulate this > > behavior, especially not if we are trying to get through a Last > Call. > > > Of course it must be open to debate - we cannot know in advance > what one want to register and how it relatest to "reality". And I > do not think that the current lack of recommended region subtag > prefixes for 1996 is a fundamental error. But I do think that it > would be much more in line with the strict year meaning that you > apply to "-1996" to list the region variants of "de" for which the > 1996 dating is good. Really, when the prefix omits all mention of scripts or regions, we have the positive ability to use whichever ones make sense, even if the registrants overlooked and omitted one. I suspect that remnant populations might use 1901 or 1996, depending, with "de-NA". I think the problem here is that you're suggesting that we should try to register what all of the "correct" potential tags are. But the generative nature of language tags is based on a quite different philosophy: we don't have to do the detailed linguistic research and weigh all manner of data to provide such things (as the old RFC 3066 kind of required). Addison _______________________________________________ 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.