Re: [Idna-update] IDNA and combining sequences

John C Klensin <john-ietf@jck.com> Sun, 11 March 2018 13:43 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: idna-update@ietfa.amsl.com
Delivered-To: idna-update@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5E9126D05 for <idna-update@ietfa.amsl.com>; Sun, 11 Mar 2018 06:43:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793] autolearn=no 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 UiHu6h91-O8K for <idna-update@ietfa.amsl.com>; Sun, 11 Mar 2018 06:43:33 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712831201FA for <idna-update@ietf.org>; Sun, 11 Mar 2018 06:43:33 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ev1G0-0004Bb-Sv; Sun, 11 Mar 2018 09:43:24 -0400
Date: Sun, 11 Mar 2018 09:43:19 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Asmus Freytag (c)" <asmusf@ix.netcom.com>
cc: =?UTF-8?Q?Mark_Davis_=E2=98=95=EF=B8=8F?= <mark@macchiato.com>, =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@frobbit.se>, idna-update@ietf.org
Message-ID: <AB759B97A4096B41D0D49752@JcK-HP5.jck.com>
In-Reply-To: <b60b8408-5f78-0915-747e-6c3c11bb326b@ix.netcom.com>
References: <C4FBCF12821031786F472AA2@PSB> <02c29140-29f1-cc81-8c4f-8249d0f23b2c@ix.netcom.com> <1E562CDE39B4224F227E765D@PSB> <516E58F3-015D-4AD7-A3FD-0749A6890245@frobbit.se> <CAJ2xs_Gfh+wS3w2AH9rAusCmb+=xS0WsRH18zsUqeXP1kZmb+A@mail.gmail.com> <b60b8408-5f78-0915-747e-6c3c11bb326b@ix.netcom.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/idna-update/fn2ANipCxfECuczn1e-8xJTtAN4>
Subject: Re: [Idna-update] IDNA and combining sequences
X-BeenThere: idna-update@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" <idna-update.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idna-update>, <mailto:idna-update-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idna-update/>
List-Post: <mailto:idna-update@ietf.org>
List-Help: <mailto:idna-update-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idna-update>, <mailto:idna-update-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Mar 2018 13:43:35 -0000


--On Saturday, 10 March, 2018 21:57 -0800 "Asmus Freytag (c)"
<asmusf@ix.netcom.com> wrote:

>...
> However, independent of the details of what may have been
> exchanged a decade ago, I strongly  suspect that going over
> that ground is going to do little in terms of helping to make
> progress forward.
> 
> Instead, the sole question we should be asking is what can we
> do to effectively improve the experience involving IDNs.

I concur.   The history is not, however, completely irrelevant.
It can be important to avoid repeating prior mistakes and,
perhaps, to calibrate some proposals going forward.  

In particular, there is some non-technical history that may
constrain what we can consider today.  In addition to a change
of model, IDNA2008 included a few changes that invalidated some
labels that were possibly in use ("possibly" because I'm talking
about the whole DNS now, not just the root zone or second-level
names) and changed the interpretation of others.  Those changes
were controversial and arguably remain so, but there was broad
consensus in the registry community that they were worth it if
(and perhaps only if) that type of change never occurred again.
If we take that as a constraint today, a guideline that says
"don't do so-and-so unless you have a very good reason" would
still allow registries to "grandfather" existing names or make
other rules about them as needed.  A protocol change, especially
one with lookup-time implications, would not have that property.
That is one of several reasons why the three-level distinction I
tried to make in my earlier note is important.

best,
   john