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 06:59 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 6E624130DF7 for <i18nrp@ietfa.amsl.com>; Mon, 3 Dec 2018 22:59:09 -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 shBUUq-Xz5Su for <i18nrp@ietfa.amsl.com>; Mon, 3 Dec 2018 22:59:05 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81815129C6A for <i18nrp@ietf.org>; Mon, 3 Dec 2018 22:59:04 -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 F3D2226C2F; Tue, 4 Dec 2018 07:59:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1543906741; bh=ZSS6Rkmbc+kLKHIlCYvvkRZNpvHnc2U+IS2+cm9tf7Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mZzoW0jhW8kUryDQmshqT6+YoCnv1JSLcUUnqM0caJD0/m0gXV7Y1d0sQaH3utx3I D7su6izEP0taJdd+D/VW7/azMiOAOpJqEQTYtCwlDGVoXYleKqB21HckQkcnh9UyTI gP0y8yxe7kQsq/jYePl3uGyS6TSfjBE+fEjIXJjM=
From: Patrik Fältström <paf@frobbit.se>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: i18nrp@ietf.org
Date: Tue, 04 Dec 2018 07:59:00 +0100
X-Mailer: MailMate (1.12.2r5568)
Message-ID: <CC73FC25-92FC-4822-B267-15C41CE450F2@frobbit.se>
In-Reply-To: <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org>
References: <154385119878.18333.5085298134102919486.idtracker@ietfa.amsl.com> <FF6F9EB9-C73B-4EC0-AC4F-3E3BFBABA0AB@vpnc.org> <8E20D432-01B0-4B52-80BB-3348C5FE73AF@vpnc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_F64D786F-27A0-47D2-A306-A3731E2D350F_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18nrp/_XH_HLMHU_BOSSjrenGDq4Hnhr8>
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 06:59:10 -0000

Good morning!

I see there are a few comments on this draft, I will try to respond to each one of them.

On 4 Dec 2018, at 1:02, Paul Hoffman wrote:

> Before I go to the ietf@ietf.org mailing list with my concerns about this draft, I hope it is OK to bounce them off people here in case I'm wildly off track.
>
> =====
>
> In Section 1:
>    Specifically, the Internet Architecture Board did issue a statement
>    [IAB] which requested IETF to resolve the issues related to the code
>    point ARABIC LETTER BEH WITH HAMZA ABOVE (U+08A1), introduced in
>    Unicode 7.0.0 [Unicode-7.0.0].  This document resolves this issue and
>    suggests IDNA2008 standard is to follow the Unicode Standard and not
>    update RFC 5892 [RFC5892] or any other IDNA2008 RFCs.
>
> In Section 4.1:
>    The discussion in the IETF concluded that although it is possible to
>    create "the same" character in multiple ways, the issue with U+08A1
>    is not unique.  In the case of U+08A1, it can be represented with the
>    sequence ARABIC LETTER BEH (U+0628) and ARABIC HAMZA ABOVE (U+0654).
>    Just like LATIN SMALL LETTER A WITH DIAERESIS (U+00E4) can be
>    represented via the sequence LATIN SMALL LETTER A (U+0061), and
>    COMBINING DIAERESIS (U+0308).  One difference between these sequences
>    is how they are treated in the normalization forms specified by the
>    Unicode Consortium.
>
> This sounds like the IETF is saying that if the Unicode Consortium changes how a character appears in a normalization form other than for case folding (Section 2.2 of RFC 5892), that change does not affect the tables for IDNA2008. Is that correct?

First of all, this document evaluates the individual changes made up until and including Unicode 11. Sure, one could say this has implications on the IETF view of existence of normalization rules (or not) but that is not the intention here. The result of this review should neither be extrapolated to future versions of Unicode nor to future evolutions of normalizations.

> =====
>
> In Section 4.1:
>    As U+08A1 is discussed in draft-freytag-troublesome-characters
>    [I-D.freytag-troublesome-characters] and elsewhere.  Regardless of
>    whether those discussions ends in recommending including the code
>    point in the repertoire of characters permissable for registration or
>    not, it is acceptable to allow the code point to have a derived
>    property value of PVALID.
>
> This sounds like it is saying that even though draft-freytag-troublesome-characters is meant for standards track, because it is not yet finished, this document (which is informational) can ignore the other document and make changes to the IANA registry. If that's correct, it concerns me because it could make the IANA registry unstable for characters that we know about and are actively discussing. If I'm not correct, I'd like to hear why so that maybe this document can be reworded.

First of all, this document is (as it seems to me now) to be Standards Track. So that issue is taken care of.

Regarding the reference to the troublesome characters, I also have referenced a document by Klensin. I do not mind referencing other documents as well regarding U+08A1, but I do NOT want to explain everything in this document (again), i.e. no repeat please.

The klensin document unfortunately have expired but look at diff between -04 and -05 and you see the reference. This is also why I in this version wrote "and elsewhere".

If you have better more references, send them in my direction.

   paf