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

Larry Masinter <> Fri, 07 December 2018 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9F8DC130F93; Fri, 7 Dec 2018 10:24:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.638
X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lxPQ9O4XJXCP; Fri, 7 Dec 2018 10:23:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 050A0130F99; Fri, 7 Dec 2018 10:23:56 -0800 (PST)
Received: by with SMTP id y4so2052641pgc.12; Fri, 07 Dec 2018 10:23:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=JBpEv0D44kqBUsCRDOVu0DlXBXJGG7Y0u7QtiGI18Bk=; b=apsILcQED1EqZ5+TrmMcKJd4vP1b1Lby1mC5TDcWb4lZEmLWQvESQFJqSqzvRnung4 Zojd+LevZBiolWUn6qoZwuNTyABMk+Ptl9MKEwO0ShXz1/e2A4G/n0JoCJLXp5oM0osr kVygUX+04hHHyuPlLNdZakQTshYcL9Y5Z6G0VLsi1rJb9INj19pehhOX9/ILWE7PRyiK F8OyedxDp3cmVjBa+Bu6y23x9gd1uwKlkABLebCyucfzhbNUUrFuKMRiqOiJhuRu6xvL JYv50o8bDvQvw+cdt/E5+GaXITMeABorkVDUj5aNrVRWrTsoO+qIHHwwGKljf8wk0RNq paAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-language:thread-index; bh=JBpEv0D44kqBUsCRDOVu0DlXBXJGG7Y0u7QtiGI18Bk=; b=B3JbuA6grgPhDfuEeFWAlXf0vQ1jSA7z9nANFOiNVTYK1DS+yX4zQE1sR8PCTiEDc7 gfqrHCU9DGYVCjFRWqfnAjsbKUL9+PqW3cQUH0bMUASHb1MXjJnS6JGIdhHX36PuyBoh TWRZQb+bIzj/8Q19gi0/XD/6YrRa4G3GfDoQGls/IiTTFDWzAckw1HG4eLF6iw/HmVHP nD/Sb5q/zJlaUXGsNFX13PDeHK1RhK/0t9ixmyXcBneKYIfC2uB0dNnila7oY+S0JAlX dCWpMsiA3Cwcvwu3gZWsAGClzvQP/OwXNXYUmD0/KYe/DHXIc+ZjXI0/e6/ZOv1v0k/l mzUQ==
X-Gm-Message-State: AA+aEWb6ufFY4aPYjQr/+NteDL5wRjO8Q5yr/4F/ri7/FHOvQSSTEeZT F5RhCDTHcJBQ7sHryHbCo2M=
X-Google-Smtp-Source: AFSGD/VvLkYr94cIZWFaltBZ/YjUKDy0iNaCcpSYQaWPAWRtyzvYXv2REDGSpX0jHZHZLKGXyCeZrg==
X-Received: by 2002:a63:5455:: with SMTP id e21mr2924800pgm.316.1544207035173; Fri, 07 Dec 2018 10:23:55 -0800 (PST)
Received: from TVPC ( []) by with ESMTPSA id v14sm10358664pgf.3.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 10:23:53 -0800 (PST)
Sender: Larry Masinter <>
From: Larry Masinter <>
X-Google-Original-From: "Larry Masinter" <>
To: "'Asmus Freytag \(c\)'" <>, =?utf-8?Q?'Patrik_F=C3=A4ltstr=C3=B6m'?= <>, "'John C Klensin'" <>
Cc: <>, <>, "'Paul Hoffman'" <>
References: <> <> <> <> <> <> <> <> <> <> <055301d48dc8$0ea95120$2bfbf360$> <> <50A496896DE57696A5184DC2@PSB> <> <>
In-Reply-To: <>
Date: Fri, 7 Dec 2018 10:23:53 -0800
Message-ID: <005401d48e5a$02d08d90$0871a8b0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01D48E16.F4ADE9D0"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
thread-index: AQLuHH7V14krpZsNZ4Fo+NzUu7802gGsbo1pAc2pzv8Bi4XfCAIpje2WAfWJ+7wBzjyAXAG8g2e4AkfNvv0DFpL47wJLefS0Ak+F4gICCo1moQC5ku1oAf4uqzSiZSE4EA==
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 18:24:02 -0000

Look at RFC1736 , Functional Recommendations for Internet Resource Locators”, section 4.6: Locators are human transcribable

   Users can copy Internet locators from one medium to another (such as

   voice to paper, or paper to keyboard) without loss or corruption of

   information.  This process is not required to be comfortable.

Changing Internet locators to allow for Internationalization need not necessarily eliminate this valuable property.



From: Asmus Freytag (c) <>; 
Sent: Friday, December 7, 2018 12:49 AM
To: Patrik Fältström <>;; John C Klensin <>;
Cc: Larry Masinter <>;;;; Paul Hoffman <>;
Subject: Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC


On 12/6/2018 10:16 PM, Patrik Fältström wrote:

On 7 Dec 2018, at 7:12, John C Klensin wrote:

But I still believe that, with appropriate qualification, Larry is still correct.

I think we dive into the details here.
1. I think the ability (for example) copy and paste, respond to, click on, save in bookmarks etc is the most important global requirement
2. The ability to type, to enter via a keyboard, read on a bus, etc is secondary and have localization issues so very much different than (1)

A longer reply to this in my prev. note, but I emphatically disagree.

If you are dealing with a foreign language / script to you, then you will be reduced to selecting or perhaps copying; but for your own language and script (and for too many of the modern scripts) there are many possible sequences that so deeply violate the reader's expectation (or the systems' expectations) that they can effectively not be understood (read and remembered) by the users or displayed or processed by the system (or not reliably so across systems).

For many scripts, allowing too much will make labels every bit as unusable as allowing too little.

My point was that because of this, I think retypable is very very very much different than other, global, requirements, and the latter should not (I think) muddy the waters of the first requirement I list above.

Your item (1) addresses much more the level of implementation of the user presentation of IDNs, and less what should be allowed in IDN labels. Apples and oranges, it seems to me.

Item 1 is what the UASG should be concerned with, Item 2 is what IDNA should be concerned with (at the guidance level).