Re: [Idna-update] [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

John C Klensin <> Fri, 07 December 2018 06:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FAD2124BF6; Thu, 6 Dec 2018 22:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wgdp02TkITVD; Thu, 6 Dec 2018 22:12:55 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFFB712008A; Thu, 6 Dec 2018 22:12:55 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1gV9Nc-00091i-FI; Fri, 07 Dec 2018 01:12:52 -0500
Date: Fri, 07 Dec 2018 01:12:47 -0500
From: John C Klensin <>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <>, Larry Masinter <>
cc:,, Asmus Freytag <>, Paul Hoffman <>
Message-ID: <50A496896DE57696A5184DC2@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <055301d48dc8$0ea95120$2bfbf360$> <>
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
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [Idna-update] [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Internationalized Domain Names in Applications \(IDNA\) implementation and update discussions" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Dec 2018 06:12:58 -0000

--On Friday, December 7, 2018 05:43 +0100 Patrik Fältström
<>; wrote:

>> As I've noted before, usability includes "re-enterable"
>> (including "retypable") .
> I might not agree with this, as for example very few
> characters in arabic script are "retypable" for me. So this is
> at least a separate issue. But what the registry chooses, I
> feel is up to them, as long as they do come up with a good
> repertoire.


I think your second point ("up to them" as long as it is "good"
--including sufficiently conservative) is the important one and
the one on which we can all agree.  But I still believe that,
with appropriate qualification, Larry is still correct.   The
very decision to move in the direction of IDNs meant that there
would be labels that would be much easier to read (and enter)
for some populations and other labels that would be easier for a
different population.  It seems to me that we just have to
accept that.  One think it implies is that, if a label is
written in a script one doesn't use frequently, "typing" may
require a character-picker.  Character-pickers are better than
nothing but no fun at all, especially if one does not easily
recognize the characters involved and differences between then
(and, to save Asmus pointing it out, complex scripts may
complicate both the recognition problem and the picking one).
We also need to remember, as Ted Hardie and others have reminded
us multiple times, that there are increasing moves toward voice
input, a trend that will de-emphasize typing and, most likely,
make the lives of those of us who can speak a given language
only with horrible accents much more "interesting".

However, to the extent to which one can sensibly use (including
simple reading of the characters) a label at all at all, I think
ability to re-enter it, to be assured that, insofar as possible,
there are no other labels in the zone that can easily be
mistaken for it, strings that are likely to be entered where it
is is intended, etc., are as important to a conservative
approach as things we've talked about more such as ensuring that
strings are well-formed for the script and that interactions
between RtoL characters and characters with neutral or LtoR
directionality don't cause, e.g., labels to appear in orders
that others might not predict.

I hope Larry has a better (and shorter) way to formulate that
than I do, which is why I'm hoping for text.