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

"Patrik Fältström " <paf@frobbit.se> Tue, 04 December 2018 07:17 UTC

Return-Path: <paf@frobbit.se>
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 D9177130DFB for <i18nrp@ietfa.amsl.com>; Mon, 3 Dec 2018 23:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
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 1kbUnyzKIVTB for <i18nrp@ietfa.amsl.com>; Mon, 3 Dec 2018 23:17:01 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FAC129C6A for <i18nrp@ietf.org>; Mon, 3 Dec 2018 23:16:59 -0800 (PST)
Received: from [169.254.186.213] (unknown [IPv6:2a01:3f0:1:0:29da:870d:c8f1:83f4]) by mail.frobbit.se (Postfix) with ESMTPSA id F106D2300D; Tue, 4 Dec 2018 08:16:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1543907813; bh=L4z9rEW6n20AokM9qUwxmJWtDtTsRjCFjzuOx8Xp+dM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UFkw4kYUUkvvF8/eGLmetT7QJzMxKO0R0pscnX6sYU6oZKB2jdD8WDkmwpwko4UXR BBWXM0j+9f8B3Uww7eqeB/45JKVyzwRv5lNhQ88cNuwWVj6B93RZClXCupbDpEyEDQ i9sFdU9CHpJZabezVoixpocyaR497/Z/aH/v8JkY=
From: Patrik Fältström <paf@frobbit.se>
To: John C Klensin <john-ietf@jck.com>
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, i18nrp@ietf.org
Date: Tue, 04 Dec 2018 08:16:52 +0100
X-Mailer: MailMate (1.12.2r5568)
Message-ID: <E5A7B829-FE59-4649-AE36-2918E910A667@frobbit.se>
In-Reply-To: <A5B69D318689A6515CCB4883@PSB>
References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <FF6F9EB9-C73B-4EC0-AC4F-3E3BFBABA0AB@vpnc.org> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org> <A5B69D318689A6515CCB4883@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_7AB7C54B-6F2A-46DA-87E0-F5C6DFE9E954_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/jAW3CIVbjFrmFZHQSQrk_LA6AZE>
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: Tue, 04 Dec 2018 07:17:04 -0000

On 4 Dec 2018, at 2:21, John C Klensin wrote:

> In addition, I personally read "suggests IDNA2008 standard is to follow the Unicode Standard and not update RFC 5892 [RFC5892] or any other IDNA2008 RFCs" as effectively eliminating the
> version-by-version review process called for in Section 5.1 of RFC 5892 (and followed by Patrik and yourself to produce RFC 6452) if favor of uncritically accepting changes in The Unicode Standard.  Insofar as that reading is correct, this is
> necessarily a Standards Track document that updates RFC 5892 and makes what I believe is a very substantive change to it.

The goal is to say in this document that it is suggested for changes up until and including Unicode 11.0.0 IETF accept the changes in Unicode Standard.

What to do with future versions is something IETF have to evaluate for every version that is released.

The process I have used for each version of Unicode is the following:

1. Unicode releases beta versions of Unicode

2. I calculate the derived property values and do a diff

3. I report the result to IAB and whatever I feel is the most recent IDNA-related mailing list in the IETF

3.1. If there are no incompatible changes, I say so and simply suggest I will report to IANA "to move on" -- and if I do not hear anything within say two weeks, I simply do so

3.2. If there are incompatible changes, I say so to and suggest an I-D that include my and others review of the situation


Step 3.2. have so far resulted in two things:

- RFC 6452
- This document, where I basically suggest same action as in RFC 6452

> I am told, although I wasn't able to find it quickly, that there is now a notation from the AD in the file that this document must be reviewed by the
> directorate that BOF decided should be created (and with which the AD(s) agreed).

See <https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/history/>

2018-12-03 05 Alexey Melnikov This document needs to be reviewed by the to-be-created-soon Internationalization Directorate.

   Patrik