[I18ndir] draft-faltstrom-unicode and "outdated versions of Unicode" ... and the "review model" document
John C Klensin <john-ietf@jck.com> Sat, 16 March 2019 20:58 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F0F1279A1 for <i18ndir@ietfa.amsl.com>; Sat, 16 Mar 2019 13:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2gp_SgCt_Jd for <i18ndir@ietfa.amsl.com>; Sat, 16 Mar 2019 13:58:44 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47ECB1279A3 for <i18ndir@ietf.org>; Sat, 16 Mar 2019 13:58:44 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1h5GOA-0001bg-Gn for i18ndir@ietf.org; Sat, 16 Mar 2019 16:58:42 -0400
Date: Sat, 16 Mar 2019 16:58:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: i18ndir@ietf.org
Message-ID: <0DA0CBAEF3730D672CD7ADC7@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/4t77OLrbFQDSal4PkvylQG1IUbU>
Subject: [I18ndir] draft-faltstrom-unicode and "outdated versions of Unicode" ... and the "review model" document
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2019 20:58:46 -0000
Hi. In the confusion of the last week, I apparently wrote one note that I never sent. As we think about what needs to be said or clarified going forward, some of that note may be useful even though I think all of us are now in synch about it and hence, for the purposes of the directorate of draft-faltstrom-unicodeXX, I'm probably kicking the proverbial dead horse. --On Sunday, March 10, 2019 13:35 -0700 Asmus Freytag <asmusf@ix.netcom.com> wrote: >... > "The Unicode Standard is being updated at least yearly and > implementors and vendors of OS, libraries and other tools are > aggressively updating their systems/libraries to the new > versions of > Unicode. Therefore, IETF recognizes the burden on implementers > to support IDNA2008 corresponding to an outdated version of > Unicode. It is probably worth having tables as part of an IANA registry. It is probably worth keeping them up to date (see below about both of those statements). But those tables are not normative and do not define a particular version of Unicode for use with IDNA2008. The requirement on implementers is that they choose a version of Unicode and then work either directly with the [current] rules of IDNA2008 or derive or find a table that corresponds to that version of Unicode. There is absolutely nothing about IDNA2008 that would require an implementer to work with an outdated version of Unicode of to "support IDNA2008 corresponding with it" (whatever that means). I say "probably" above because, if the existence of the IANA tables going forward is to create confusion about this -- especially if we don't get IANA to keep versions of each table corresponding to every version of Unicode from 5.2 forward -- I think it may be critical to either add more notes to the top of that IANA table or to get rid of the IANA tables entirely. That is something we should think about when we are working on the "review model" document because that would be a logical place to adjust the instructions to IANA going forward. Now, should some body with a claim to regulatory or contractual authority over some collection of zones say "you are allowed to only use Unicode version X" or "you must use the version of Unicode corresponding to the IANA tables at the time of registration of a label", IDNA2008 does not prohibit such a restriction and the decision to impose it is Not An IETF Problem. I would, personally, consider such a restriction rather dumb unless it turned out to be a requirement of some more elaborate system for advising registries, but, even if people agreed with me, that evaluation doesn't belong in draft-falstrom or any of the core IDNA2008 documents. I believe and hope that anything in the above that needs to be said in draft-faltstrom-unicode11 (or 12) has already been said. However, for work going forward, are we all in agreement about the above? best, john john
- [I18ndir] draft-faltstrom-unicode and "outdated v… John C Klensin
- Re: [I18ndir] draft-faltstrom-unicode and "outdat… Asmus Freytag
- Re: [I18ndir] draft-faltstrom-unicode and "outdat… Patrik Fältström
- Re: [I18ndir] draft-faltstrom-unicode and "outdat… Patrik Fältström
- Re: [I18ndir] draft-faltstrom-unicode and "outdat… Asmus Freytag (c)