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

Larry Masinter <LMM@acm.org> Sun, 09 December 2018 21:55 UTC

Return-Path: <masinter@gmail.com>
X-Original-To: i18nrp@ietfa.amsl.com
Delivered-To: i18nrp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB291294D0 for <i18nrp@ietfa.amsl.com>; Sun, 9 Dec 2018 13:55:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.638
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 GlqHvMZ_zKoe for <i18nrp@ietfa.amsl.com>; Sun, 9 Dec 2018 13:55:31 -0800 (PST)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7718128CF2 for <i18nrp@ietf.org>; Sun, 9 Dec 2018 13:55:31 -0800 (PST)
Received: by mail-pf1-x435.google.com with SMTP id 64so4385128pfr.9 for <i18nrp@ietf.org>; Sun, 09 Dec 2018 13:55:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=iTBZAvCDEj8khKURf5t1xM97jvWy7cqsH6kquwfexfA=; b=GK+GH4kf5H+E70gFMQ3R9TFaYYtR/syp/hyKP1zjkHOG+TD0aSHpIKxQ2iUebdPnWO 9PSzP+G93Z5bIXr80ie3I0U4GJnkCefOGrW348W2LVux+1xxLFjFLdA667Ledh/L5ci5 aL1mq3gthiZz6/l0Gh2FzdsCdmZGNO2imS9ajceNZrG3yyHJ2pCyfRy5B43Tf69F7UyF vwY7W+QApcIREtp/kfpv8BLCjLJgcDJkXbSEk5omxeZ5XURc+K+RcQe2B2lcB+oSPAte VRLrjX96s8HKDtNzdrGQ3qC0zPF9cwQcJMg48T0t4jeUsN69IdyiaruloxBAw5ZgoBBE 12Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:thread-index:content-language; bh=iTBZAvCDEj8khKURf5t1xM97jvWy7cqsH6kquwfexfA=; b=cB7Z6FPyxZZhnWIjt/orxZCiNxEGhjihdDFe2d9fOT40XYTEjUY3SI/89eW4vjY5MN JI2SGYiULvO9NURO+46HgXqxIVvwmw3ZEis7ands9RQ3ua3jMliz1oXvr4sIMF5JqAZN Ii+CRqF20uNntMy/X0a/lfP3PlavYNodHnjiSDw9jdYa61FmGXse3CTAU1PJakF1+1jz 881b6VQpLhaX5QNLpktjkWkSMsY7qmgl3fOX8lgkDhtBS7roeEOE8+STOz7U4/x0wMrU KR+0FECm2Uq8iqnGhpRWJTr8KQzVfGiKuOsydpB24mzlOrHuSE+6ys3VXxwcR5GYLw36 XYoQ==
X-Gm-Message-State: AA+aEWb6ltmjwInvES2c9Maz2JJwvl/RgNyhPF52oNuYKxif7nWb9FSg V7xkPO0vBkI1WV/meHPaHbqt7xWo
X-Google-Smtp-Source: AFSGD/XKGS9p6kU7KRqxC5Ga+QcDm36VKhqDlTtwOJ2xt6YeW6LDFkaZJWskO2yxaAPL7WZQnLEJDw==
X-Received: by 2002:a63:af18:: with SMTP id w24mr8835656pge.385.1544392530854; Sun, 09 Dec 2018 13:55:30 -0800 (PST)
Received: from TVPC (c-24-6-174-39.hsd1.ca.comcast.net. [24.6.174.39]) by smtp.gmail.com with ESMTPSA id t29sm14285794pfa.158.2018.12.09.13.55.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Dec 2018 13:55:29 -0800 (PST)
Sender: Larry Masinter <masinter@gmail.com>
From: Larry Masinter <LMM@acm.org>
X-Google-Original-From: "Larry Masinter" <lmm@acm.org>
To: "'Asmus Freytag (c)'" <asmusf@ix.netcom.com>, 'John C Klensin' <john-ietf@jck.com>, 'Patrik Fältström' <paf=40frobbit.se@dmarc.ietf.org>
Cc: i18nrp@ietf.org, 'Paul Hoffman' <paul.hoffman@vpnc.org>
References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <FF6F9EB9-C73B-4EC0-AC4F-3E3BFBABA0AB@vpnc.org> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <CC73FC25-92FC-4822-B267-15C41CE450F2@frobbit.se> <D81CDFF3-8CDF-4168-9CEA-E8DC3A133B73@vpnc.org> <217ede0e-ea1f-bb31-a276-f8c618c71278@ix.netcom.com> <8885EE4C-412E-4337-A099-66354A36CEA1@vpnc.org> <EC12FDAE-4ABD-4AD3-A35A-B39D2C8A0AE0@frobbit.se> <f4417f80-fa86-11e6-baf7-2365981e18b1@ix.netcom.com> <48A2A546-4FEA-4060-8706-34D210B2ABAF@frobbit.se> <055301d48dc8$0ea95120$2bfbf360$@acm.org> <07CB0B3B-E48A-40CD-BBC9-E6CAA2FB29F0@frobbit.se> <001d01d48dee$82b415c0$881c4140$@acm.org> <1f879380-f586-cddf-ae4b-62cfc106308a@ix.netcom.com> <00f301d48e63$071e9be0$155bd3a0$@acm.org> <0D2335F6D932D325C3FBA91E@PSB> <6a8c84c4-a7af-9398-e706-199a6ec61d81@ix.netcom.com> <009f01d48ecc$18d853d0$4a88fb70$@acm.org> <932251fc-d620-8d77-aaa5-684d917c9ed6@ix.netcom.com>
In-Reply-To: <932251fc-d620-8d77-aaa5-684d917c9ed6@ix.netcom.com>
Date: Sun, 09 Dec 2018 13:55:28 -0800
Message-ID: <01ab01d49009$e69b4d70$b3d1e850$@acm.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AC_01D48FC6.D878A9B0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLuHH7V14krpZsNZ4Fo+NzUu7802gGsbo1pAc2pzv8Bi4XfCAIpje2WAfWJ+7wBzjyAXAG8g2e4AkfNvv0DFpL47wJLefS0Ak+F4gIB+9VstQH5lg4FAYYc/oUDL4NQrQJXIzW6AliWLnIDAjroL6ILp5Rg
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/FNT6ON_Pp5qX5fVjHlP6ZMytWL0>
Subject: Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC
X-BeenThere: i18nrp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Review Procedures <i18nrp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18nrp/>
List-Post: <mailto:i18nrp@ietf.org>
List-Help: <mailto:i18nrp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18nrp>, <mailto:i18nrp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Dec 2018 21:55:35 -0000

I think we’re looking at the problem from different ends of the telescope.

 

I’m concerned with giving guidance to the use of Unicode in other naming contexts, including URLs.

I think we should extend the advice to anyone assigning a “Unicode name” e.g., email addresses social media handles. 

 

In particular, the  IRI document RFC3987 needs update to align its recommendations with IDNA and the WHATWG URL “living standard” (which mainly neglects giving any advice at all the those choosing URLs.)    

 

Larry

--

https://LarryMasinter.net

 

 

 

From: i18nRP <i18nrp-bounces@ietf.org> On Behalf Of Asmus Freytag (c)
Sent: Saturday, December 8, 2018 1:13 PM
To: Larry Masinter <LMM@acm.org>; 'John C Klensin' <john-ietf@jck.com>; 'Patrik Fältström' <paf=40frobbit.se@dmarc.ietf.org>
Cc: i18nrp@ietf.org; 'Paul Hoffman' <paul.hoffman@vpnc.org>
Subject: Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

 

On 12/8/2018 12:00 AM, Larry Masinter wrote:

We were discussing Patrik’s document and what advice or rules to give to Registrars about being conservative,

And some questions about the motivation or intelligence of Registrars and their Clients.

 

It would help if the Registrars could pass off responsibility to their Clients; the only reason not to do so would be that the clients shouldn’t be expected to know the complex rules.

 

The transcription problem is relatively easy to explain and understand, and covers most other ways in which a name could be “bad”. 

These names don’t fall from the sky. Someone chooses them. Give them a clear motivation.

 

The rules are complex even if the basic requirements can be stated simply.

The process of teasing them out for the 28 scripts that make up all but a miniscule fraction of modern use is progressing nicely, but including preparatory phases will probably have taken most of a decade before completion. (I'm referring to the Root Zone LGR program).

The good news is that the result of this effort will be well documented (linking the final design to the underlying details of the scripts and language use) and that it will also be available in a machine-readable format.

That means that for the first time, there would be a well-researched (and well-documented) starting point for anyone trying to create and enforce registry policies for pretty much any writing system used in daily transactions.

Policies for the second level would have to extend this template to allow digits and hyphen - and perhaps relax some other restrictions that are seen as relevant only to the root. This is a much smaller task than starting from scratch, but for some scripts, even that task is not entirely trivial.

Common to the rules for most of the scripts is that they define variant labels and the restrictions applicable to them (never allocatable to unrelated entities and most commonly the first allocated blocks all subsequent registrations of variants). Carefully designed to make indistinguishable or semantically equivalent labels mutually exclusive or reserved for a single applicant, these policies require access to a registry to implement. Only when you know what is allocated already can you evaluate whether a new label is a blocked variant.

Being machine readable should make it easy to integrate these rules into registry operations. Therefore, I'm a bit confused as to what would be gained by somehow distributing this responsibility down the chain - other than surfacing restrictions built into the registry to applicants.

A./