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
- Re: [I18nrp] Conservatism principle doesn't go fa… John Levine
- Re: [I18nrp] Conservatism principle doesn't go fa… John C Klensin
- [I18nrp] Conservatism principle doesn't go far en… Larry Masinter
- Re: [I18nrp] Conservatism principle doesn't go fa… John C Klensin
- Re: [I18nrp] Conservatism principle doesn't go fa… John Levine
- Re: [I18nrp] Conservatism principle doesn't go fa… John R Levine
- Re: [I18nrp] Conservatism principle doesn't go fa… John C Klensin
- Re: [I18nrp] Conservatism principle doesn't go fa… Larry Masinter
- Re: [I18nrp] Conservatism principle doesn't go fa… Adam Roach
- Re: [I18nrp] Conservatism principle doesn't go fa… Asmus Freytag
- Re: [I18nrp] Conservatism principle doesn't go fa… John R Levine
- Re: [I18nrp] Conservatism principle doesn't go fa… John Levine
- Re: [I18nrp] Conservatism principle doesn't go fa… Nico Williams
- Re: [I18nrp] Conservatism principle doesn't go fa… Asmus Freytag (c)
- Re: [I18nrp] Conservatism principle doesn't go fa… Nico Williams
- Re: [I18nrp] Conservatism principle doesn't go fa… Patrik Fältström
- Re: [I18nrp] Conservatism principle doesn't go fa… Nico Williams
- Re: [I18nrp] Conservatism principle doesn't go fa… Anne van Kesteren
- Re: [I18nrp] Conservatism principle doesn't go fa… Larry Masinter
- Re: [I18nrp] Conservatism principle doesn't go fa… Nico Williams
- Re: [I18nrp] Conservatism principle doesn't go fa… Emily Stark