[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