Re: [Ltru] Last open item

"Randy Presuhn" <randy_presuhn@mindspring.com> Tue, 15 April 2008 18:22 UTC

Return-Path: <ltru-bounces@ietf.org>
X-Original-To: ltru-archive@megatron.ietf.org
Delivered-To: ietfarch-ltru-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021A03A68DD; Tue, 15 Apr 2008 11:22:36 -0700 (PDT)
X-Original-To: ltru@core3.amsl.com
Delivered-To: ltru@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99C213A6C97 for <ltru@core3.amsl.com>; Tue, 15 Apr 2008 11:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.324
X-Spam-Level:
X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599]
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 dEXCGcR6kiCv for <ltru@core3.amsl.com>; Tue, 15 Apr 2008 11:22:33 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 9871D3A6818 for <ltru@ietf.org>; Tue, 15 Apr 2008 11:22:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BSd/WSPD2BzyZtacCuCmVkvUinYSAVP9pZKGEfSpsfBYtzuR9a64rf7z9D/tWFZ+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [68.166.188.83] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1JlpoA-00019y-VM for ltru@ietf.org; Tue, 15 Apr 2008 14:23:07 -0400
Message-ID: <000b01c89f1d$7abf8960$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: LTRU Working Group <ltru@ietf.org>
References: <30b660a20804101252p37e22884g6dfbec6dd17e5ea1@mail.gmail.com> <006101c89daa$323fc3e0$6801a8c0@oemcomputer> <30b660a20804140815w5d56933auefbdccdcbdfe034b@mail.gmail.com> <001e01c89e4b$897c0000$6801a8c0@oemcomputer> <20080414193212.GI28132@mercury.ccil.org> <002601c89e94$80c98ce0$6801a8c0@oemcomputer> <20080415021154.GK19045@mercury.ccil.org> <001001c89ea2$29a61560$6801a8c0@oemcomputer> <20080415170448.GJ28132@mercury.ccil.org> <002601c89f17$aff089a0$6801a8c0@oemcomputer> <30b660a20804151059m2e82e773y5a9b0c4f2aab883a@mail.gmail.com>
Date: Tue, 15 Apr 2008 11:23:53 -0600
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117dc2597d8421f453b070e67b74a5356d5350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 68.166.188.83
Subject: Re: [Ltru] Last open item
X-BeenThere: ltru@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@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ltru>
List-Post: <mailto:ltru@ietf.org>
List-Help: <mailto:ltru-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltru>, <mailto:ltru-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ltru-bounces@ietf.org
Errors-To: ltru-bounces@ietf.org

Hi -

As a technical contributor...

> From: "Mark Davis" <mark.davis@icu-project.org>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "LTRU Working Group" <ltru@ietf.org>
> Sent: Tuesday, April 15, 2008 11:59 AM
> Subject: Re: [Ltru] Last open item
>
> > we will find ourselves in the situation that a tag found to be OK
> > be a validating processor will suddenly become not OK
> 
> That is a red herring. There appears to be a fundamental misperception here.
> The key issue is that canonical form is NOT the same as is valid, and never
> has been. Moreover:

RFC 4646 is quite clear: "Although valid in language tags, subtags and tags
with a 'Deprecated' field are deprecated and validating processors SHOULD
NOT generate these subtags."  Thus my statement that something that would have
once been fine will suddenly become "not OK".

> 1. The canonical form is not, and never has been "stable" in the sense you
> mean. Any time a subtag is deprecated in favor of another, we make the
> change, which will change the canonical form. True of our process before,
> and still true in the latest draft.

I could understand this as part of the process of constructing RFC 4646 to
deal with historical mistakes.  I think continuing down that path would be
a really bad idea.

> 2. However, the key notion of stability that we have striven for is that
> once a tag is valid, it will always stay valid. *That is true even if the
> canonical form changes.*

Somehow the notion that the canonical form for an entity would change
over time seems contrary to the very notion of "canonical."

> 3. This drives the main stabilizing principle in BCP 47, which is that once
> in the registry, we never change the meaning of a subtag in a way that would
> narrow the denotation of a tag (or change it completely, like CS was handled
> by ISO). THAT is the area where we stabilize the ISO codes, and where we do
> not accept changes from ISO.
> 
> If you have a math bent, think of it this way. The domain of valid tags is
> partitioned into equivalence classes. Each equivalence class has one
> distinguished member, the canonical form. Over time, only certain changes
> are allowed:
> 
>    - Tags never disappear (each of the tags, once valid, will always
>    remain valid).
>    - New tags and equivalence classes may be added.
>    - The canonical form for a given class may change, but the old
>    canonical form remains valid and remains the same in meaning as the new one.
>    - Equivalence classes may grow, and may merge (unlikly but possible),
>    but will never split.

All fine, except for permitting the canonical form to change.
 
However, since I seem to be the only person bothered by this kind
of instability, and since I'd love to see this work finished so we
can close down this WG, I'll give up.

Randy

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www.ietf.org/mailman/listinfo/ltru