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

John C Klensin <john-ietf@jck.com> Wed, 05 December 2018 21:46 UTC

Return-Path: <john-ietf@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 5EC89130DFF; Wed, 5 Dec 2018 13:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOPPetMGYXh9; Wed, 5 Dec 2018 13:46:56 -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 7FFB6130E95; Wed, 5 Dec 2018 13:46:56 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1gUf0O-0004GM-Nd; Wed, 05 Dec 2018 16:46:52 -0500
Date: Wed, 05 Dec 2018 16:46:45 -0500
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf=40frobbit.se@dmarc.ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
cc: i18nrp@ietf.org, Asmus Freytag <asmusf@ix.netcom.com>, idna-update@ietf.org
Message-ID: <FCBA1A6A9774AC3E69C8EC66@PSB>
In-Reply-To: <EC12FDAE-4ABD-4AD3-A35A-B39D2C8A0AE0@frobbit.se>
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>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/r2AOrPxw1RLSdfJzGjbG0it0r-Q>
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: Wed, 05 Dec 2018 21:46:57 -0000


--On Wednesday, December 5, 2018 08:56 +0100 Patrik Fältström
<paf=40frobbit.se@dmarc.ietf.org> wrote:

> 3. Registries should not "just" allow all PVALID (etc) code
> points, but also include a conservative registration policy
> 
> I do though not see (3) is in violation with other documents.
> It just emphasizes the same thing already said elsewhere. For
> example in the "troublesome characters" draft there is a
> suggestion on a method to use when developing one such policy.

It is also an existing requirement.  See discussion and
references in draft-klensin-idna-rfc5891bis but that I-D doesn't
actually change anything other than clarifying the existing
rules.   So, whether (3) should be said here may be
controversial unless it is clearly stated as restating rules
established elsewhere (a reference to
draft-klensin-idna-rfc5891bis would help with that, but
certainly is not essential).  On the other hand, if you were to
say anything about registry policies that changed that rule or
encouraged a belief that anything authorized by the 5892 rules
was ok, that would not only clearly update several other
documents but be very controversial.

     john

p.s. addressing another issue, I don't believe we've ever made a
document Historic that is part of the record of evolution of a
Standards Track specification that is not itself considered
Historic.   Even if we had, I think it would be really
unfortunate in this case.