Re: Gen-ART LC review of draft-faltstrom-5892bis-04
Paul Hoffman <paul.hoffman@vpnc.org> Wed, 08 June 2011 02:45 UTC
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5721F84FA; Tue, 7 Jun 2011 19:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.413
X-Spam-Level:
X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvrIiajBvDBN; Tue, 7 Jun 2011 19:45:54 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E62C421F84F1; Tue, 7 Jun 2011 19:45:43 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p582jaN4027228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Jun 2011 19:45:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Subject: Re: Gen-ART LC review of draft-faltstrom-5892bis-04
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <01C15A30F3CF4E4F60DCA1E9@PST.JCK.COM>
Date: Tue, 07 Jun 2011 19:45:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3751CF5C-FF3D-4EE0-A96B-BACC0DFC7B1B@vpnc.org>
References: <4de22aaa.8aecd80a.3728.ffffa184@mx.google.com> <E54DF8D5-7299-4E6F-9AF0-78115585E23D@vpnc.org> <4dee03bf.d04ee50a.6936.ffff9483@mx.google.com> <1215FCFF-B566-4E52-88DD-233934F6460F@vpnc.org> <01C15A30F3CF4E4F60DCA1E9@PST.JCK.COM>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1084)
Cc: gen-art@ietf.org, draft-faltstrom-5892bis.all@tools.ietf.org, 'IETF-Discussion list' <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2011 02:45:55 -0000
On Jun 7, 2011, at 6:24 PM, John C Klensin wrote: > I think this is an improvement but there is one issue about > which we have slightly different impressions. I hope the > difference can be resolved without needing yet more tedious > arguments about documentation. Indeed, if such arguments are > required, I'd prefer that we just forget about it. > > Anyway, your comments above about "most current version" imply > to me that IANA should keep derived property tables for the most > current version only. My expectation when 5982 was completed > was that IANA was expected to keep derived property tables, > clearly identified by version, for each and every Unicode > version from 5.2 forward. In other words, the tables for the > [most] current version would be added to, not replace, whatever > previous version tables were around. The reasons for this, in > terms of systems and implementations in various stages of > development, implementation, and deployment, seem obvious... but > maybe it was too obvious to some of us at the time to get the > wording exactly right. While your interpretation could be one thing we might have meant, it is not what is reflected in the RFC or the registry. RFC 5892 says: 5.1. IDNA-Derived Property Value Registry IANA has created a registry with the derived properties for the versions of Unicode released after (and including) version 5.2. The derived property value is to be calculated in cooperation with a designated expert [RFC5226] according to the specifications in Sections 2 and 3 and not by copying the non-normative table found in Appendix B. If non-backward-compatible changes or other problems arise during the creation or designated expert review of the table of derived property values, they should be flagged for the IESG. Changes to the rules (as specified in Sections 2 and 3), including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty) require IETF Review, as described in RFC 5226 [RFC5226]. Note that every reference to the registry is singular. Also, the registry at <http://www.iana.org/assignments/idnabis-tables/idnabis-tables.xml> doesn't mention "5.2" at all. If the registry definition does not talk about keeping versions, and the registry itself doesn't look like it tried, it may be implausible to think that IANA would just start to do so in some future. To me, "a registry" means a single registry. --Paul Hoffman
- Gen-ART LC review of draft-faltstrom-5892bis-04 Roni Even
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Paul Hoffman
- RE: Gen-ART LC review of draft-faltstrom-5892bis-… rontlv
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Paul Hoffman
- RE: Gen-ART LC review of draft-faltstrom-5892bis-… rontlv
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Paul Hoffman
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… John C Klensin
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Paul Hoffman
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Alexey Melnikov
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Alexey Melnikov
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… John C Klensin
- Contents of the IDNA Derived Properties registry … John C Klensin
- Re: Contents of the IDNA Derived Properties regis… Russ Housley
- Re: Gen-ART LC review of draft-faltstrom-5892bis-… Vint Cerf