> I'm not saying year numbers don't ever have their place, but it > worries > me when we expect them to be so common that we are thinking about > compromising an important property of the Registry, uniqueness of > subtag > values within type, in anticipation that there will be tons of them. I don't think the problem will be common. The problem is that the potential for conflicts is relatively large if years end up being used commonly, since mostly we'll be registering either (a) new events that happen typically in the current or a recent year or (b) standards published in the relatively recent past fifty years or so (1694acad notwithstanding). I don't think it is a huge problem, but I think we should foreclose the possibility of a particular year being given two meanings. Although I think subtags like "1958hpin" (or is it "hpin1958"???) are particularly ugly, they do From ltru-bounces at ietf.org Wed Oct 1 08:48:02 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 B0BF028C1C3; Wed, 1 Oct 2008 08:48:02 -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 EA9893A67B3 for <ltru at core3.amsl.com>; Wed, 1 Oct 2008 08:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.999 X-Spam-Level: X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 tGdmPbXXlnKg for <ltru at core3.amsl.com>; Wed, 1 Oct 2008 08:48:01 -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 F0D393A6768 for <ltru at ietf.org>; Wed, 1 Oct 2008 08:48:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,344,1220227200"; d="scan'208";a="54610668" Received: from smtp-in-1105.vdc.amazon.com ([10.140.9.24]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2008 15:48:20 +0000 Received: from ex-hub-4104.ant.amazon.com (ex-hub-4104.sea5.amazon.com [10.248.163.25]) by smtp-in-1105.vdc.amazon.com (8.12.11/8.12.11) with ESMTP id m91FmJpQ018876 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 1 Oct 2008 15:48:20 GMT Received: from EX-SEA5-D.ant.amazon.com ([10.248.163.28]) by ex-hub-4104.ant.amazon.com ([10.248.163.25]) with mapi; Wed, 1 Oct 2008 08:48:19 -0700 From: "Phillips, Addison" <addison at amazon.com> To: Doug Ewell <doug at ewellic.org>, LTRU Working Group <ltru at ietf.org> Date: Wed, 1 Oct 2008 08:47:52 -0700 Thread-Topic: [Ltru] Uniqueness of variant subtags Thread-Index: Ackjyubgj1Lk1JQXRjetmLMQcX3S6wAEEB5g Message-ID: <4D25F22093241741BC1D0EEBC2DBB1DA014C598ACC at EX-SEA5-D.ant.amazon.com> References: <mailman.1037.1222842292.4981.ltru at ietf.org> <907B23283D8A4A63989E9BBE9D5FBFE8 at DGBP7M81> In-Reply-To: <907B23283D8A4A63989E9BBE9D5FBFE8 at DGBP7M81> 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] Uniqueness of variant subtags 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 > I'm not saying year numbers don't ever have their place, but it > worries > me when we expect them to be so common that we are thinking about > compromising an important property of the Registry, uniqueness of > subtag > values within type, in anticipation that there will be tons of them. I don't think the problem will be common. The problem is that the potential for conflicts is relatively large if years end up being used commonly, since mostly we'll be registering either (a) new events that happen typically in the current or a recent year or (b) standards published in the relatively recent past fifty years or so (1694acad notwithstanding). I don't think it is a huge problem, but I think we should foreclose the possibility of a particular year being given two meanings. Although I think subtags like "1958hpin" (or is it "hpin1958"???) are particularly ugly, they do solve thsolve the uniqueness problem pretty well. So I think that formally banning subtag 'repurposing' should be done. > > And no, I don't consider this inconsistent with my position that > 'coruc' > and 'corur' and so forth are acceptable subtags. These may be > cryptic, but they are not arbitrary. It's not inconsistent and your position on those subtags is not incoherent. My concern with them was merely that a tranche of extremely similar subtags might prove confusing and difficult for users to approach, not that they were not "unique enough". Addison _______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru e uniqueness problem pretty well. So I think that formally banning subtag 'repurposing' should be done. > > And no, I don't consider this inconsistent with my position that > 'coruc' > and 'corur' and so forth are acceptable subtags. These may be > cryptic, but they are not arbitrary. It's not inconsistent and your position on those subtags is not incoherent. My concern with them was merely that a tranche of extremely similar subtags might prove confusing and difficult for users to approach, not that they were not "unique enough". 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.