Re: [I18nrp] Conservatism principle doesn't go far enough

John C Klensin <john@jck.com> Fri, 01 February 2019 01:01 UTC

Return-Path: <john@jck.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 33BDE131196 for <i18nrp@ietfa.amsl.com>; Thu, 31 Jan 2019 17:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 vVC9XE-VrWpL for <i18nrp@ietfa.amsl.com>; Thu, 31 Jan 2019 17:01:31 -0800 (PST)
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 35342131195 for <i18nrp@ietf.org>; Thu, 31 Jan 2019 17:01:31 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1gpNCy-000ICs-O3; Thu, 31 Jan 2019 20:01:28 -0500
Date: Thu, 31 Jan 2019 20:01:21 -0500
From: John C Klensin <john@jck.com>
To: Larry Masinter <LMM@acm.org>, i18nrp@ietf.org
Message-ID: <A0F4590C3A54B244C34226F8@PSB>
In-Reply-To: <031f01d4b9c3$88468030$98d38090$@acm.org>
References: <031f01d4b9c3$88468030$98d38090$@acm.org>
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@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/kKStM-2sjQJafF11BXVVUk2Nus4>
Subject: Re: [I18nrp] Conservatism principle doesn't go far enough
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: Fri, 01 Feb 2019 01:01:34 -0000


--On Thursday, January 31, 2019 16:17 -0800 Larry Masinter
<LMM@acm.org> wrote:

> https://chromium.googlesource.com/chromium/src/+/master/docs/s
> ecurity/url_di splay_guidelines/url_display_guidelines.md

> is interesting; one wouldn't want to register a domain which a
> popular browser / OS won't display.

Larry,

I can't speak for those who would want to do that or why.
However, I note that any application that conforms to IDNA2008
is required to reject and not look up any string that contains
code points that are DISALLOWED by that spec.  The standard is
silent on how "reject" is expressed through the UI (IIR,
deliberately), but the specification is quite clear.  And yet,
surveys in ICANN-land have have shown SLD registrations for many
such labels.

The interesting question is what should be done about it.  As
far as I know, the division of the protocol police that was to
be responsible for name syntax enforcement was never established
and chartered, the IETF does not have a role in determining what
is registered in practice, ICANN has been completely ineffective
in enforcing even its own guidelines and contractual rules for
behavior outside the root, etc. Judging from the numbers and
some advertising, a good number of registrants are convinced
that domain names can be treated as trophies or art objects that
can be obtained and held and either admired or eventually sold
speculatively without any need to consider actual usability.
Others seem to believe it is appropriate (and potentially
profitable) to obtain names that may not be handled consistently
by different applications and whose sole purpose is to confuse
people and take advantage of the confusion.  Again, I don't know
what, if anything, can or should be done about that, but I'm
fairly confident that effective fixes do not lie within the
IETF's authority.

    best,
     john