Re: [I18ndir] Review of Unicode-07: Finishing

"Marc Blanchet" <marc.blanchet@viagenie.ca> Thu, 21 March 2019 16:19 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887C91313B8 for <i18ndir@ietfa.amsl.com>; Thu, 21 Mar 2019 09:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.20150623.gappssmtp.com
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 VbESf7y_apdU for <i18ndir@ietfa.amsl.com>; Thu, 21 Mar 2019 09:19:05 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08CF13141D for <i18ndir@ietf.org>; Thu, 21 Mar 2019 09:19:04 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id k2so7286580qtm.1 for <i18ndir@ietf.org>; Thu, 21 Mar 2019 09:19:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=UQbqnmbv2i+XkJAu8m+4Xfyn3Lqq2FXsTV5Daoc9M1c=; b=CRXNJf4D4jmk3driUyV18X/yCSvcTEd7TXeNITROk/Bcy0ZIjkZDQ/Hxf5/WI/ovmG 1RSZBt0v6mgZl2g3q9k73ypxVIbsbjoTBYd2DCIJVd0Sv7H8RdVLTDziwa5w95RBsWuP JVjUyBrjXlCGySUOuvazJIXTSzJu0BIxPqjWndEko6KFNWgfpGonUwko3aN2C1XdKIaK AmoKfcHEGW1OVsr5PInrgJpJjIBVxhWV5ssiX8wrTYAbmSca8rkEtiQajBwBXSyRFcE4 DKiVvTOzlcRoYmjH2jA835nC+pNJG3q6fu4LkWRnaSq6bCZbkawyCrUSur+F/vfieacT ot2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=UQbqnmbv2i+XkJAu8m+4Xfyn3Lqq2FXsTV5Daoc9M1c=; b=Y53NfS2crLKu2HTMkUlhlmElMIic3jmeAw3QlZpA8AxV6SRzvk8Xa6i42I8+3dbqUR XCVDz11eOj2tXpODo6fTB2MGX4ctRRHvLy4MV5j6/gExzlsPAZAbYKoQwRTUErrrp7QT FTAQ2W5gOOqfUL4Ilr+Kl5NwRvrMKwz/2MkgibSCTeTrVhE5oltQnM0lr0WypSPp3sNX jR2pyoxHbZXvfHB2VIDwfZQEvXdHr1mJbmBf5SgNyWTLQeL0jvi59H+2wsnpv5dPmtTu oqbukHj4WR74sA7C9oHUdBAV45UT+yBYeT8aT0esSUu6LimzY75sZiCN1vZlrTY7lgm9 hNKA==
X-Gm-Message-State: APjAAAXTNZriJOR0M4IxE95dMJgRPxINUn7t4SdZlhBCIL1jVRJuXDUw M6CiGK0cA2PT2a1yiaZHsBVOVDEeVySTLg==
X-Google-Smtp-Source: APXvYqxfJkaoVzCKJyF92tOhUBTf2moxG0L/vO9fu3UDSURamFOPoHdYdgiKSWIzItd/zLVNBH1ZrQ==
X-Received: by 2002:a0c:e706:: with SMTP id d6mr3793130qvn.141.1553185143966; Thu, 21 Mar 2019 09:19:03 -0700 (PDT)
Received: from [206.123.31.196] (modemcable040.161-162-184.mc.videotron.ca. [184.162.161.40]) by smtp.gmail.com with ESMTPSA id g5sm2987141qke.71.2019.03.21.09.19.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Mar 2019 09:19:03 -0700 (PDT)
From: "Marc Blanchet" <marc.blanchet@viagenie.ca>
To: "Harald Alvestrand" <harald@alvestrand.no>
Cc: i18ndir@ietf.org
Date: Thu, 21 Mar 2019 12:19:01 -0400
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <550BAF17-3CF2-46D6-B131-FA56DA3FF294@viagenie.ca>
In-Reply-To: <2cd9f904-d1b7-d715-289f-1535db754883@alvestrand.no>
References: <2cd9f904-d1b7-d715-289f-1535db754883@alvestrand.no>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_8D3ED83F-1730-4607-A096-619C578BB309_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"HTML":[2591, 12791], "plain":[499, 4221], "uuid":"7CD83657-9134-4FE4-9F20-D4DC38C850D1"}]
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/W7QskjvAp6fRaUAD8P2hRxxNCl4>
Subject: Re: [I18ndir] Review of Unicode-07: Finishing
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2019 16:19:10 -0000

good. I especially content with that paragraph:

> In addition, it’s become clear that IDNA2008 does not specify the
> mechanisms and expectations of the review of new versions of Unicode in
> enough detail; with the review of a number of versions of Unicode behind
> us, we should be able to describe those procedures and expectations
> better than IDNA2008 does. However, this may need to happen in another
> document than this one.

Marc.

On 21 Mar 2019, at 12:10, Harald Alvestrand wrote:

> With the petering out of discussion, I think it's time to file our
> review of unicode-07 and call it "done". We were asked for a review, we
> have written a review. The review should be part of the public record,
> but I don't think we need to call attention to it by posting it all over
> the place, given that we have new versions of the document to work from.
>
> Current proposed text:
>
>
>
> **
>
> *Directorate review of draft-faltstrom-unicode11-07*
>
> *
>
> Overall conclusion: Not ready yet, needs some updates. New I-D recommended.
>
>
> [Note: As part of the discussion that resulted in this text, a new I-D
> has been issued.]
>
>
>     Context issues
>
>
> The discussion of draft-faltstrom-unicode11 in the directorate has shown
> that the directorate members share a number of concerns about the
> current state of IDNA, only some of which are directly relevant to this
> memo.
>
>
> IDNA2008 considered limits to what was reasonable to register and use in
> the DNS at a number of levels:
>
>
>   *
>
>     A level of “don’t register stuff that causes confusion”. This
>     requires human judgment, and reasonable people may disagree about
>     what causes confusion.
>
>   *
>
>     A level of “don’t register stuff that is structurally invalid under
>     the relevant writing system”. Aspects of this can be captured in
>     rulesets (ICANN’s RZ-LGR efforts fall not this category), but
>     requires deep expertise; this is captured in IDNA2008 as the “don’t
>     register what you don’t understand” rule.
>
>   *
>
>     A level of “this is stuff that you should never register, and
>     applications can reasonably choose to treat it as an error or an
>     attack if it ever shows up”. This is the distinction that is
>     captured in the classification of codepoints as DISALLOWED, and
>     where IDNA2008 (with updates) gives precise rules.
>
>
> The current document focuses on the last level only - the maintenance of
> the distinction between PVALID and DISALLOWED. (It also considers
> whether new CONTEXTO and CONTEXTJ rules are needed).
>
>
> It is clear from directorate discussion that work needs to be done at
> the other levels outlined above too, but it is not clear from the
> discussion what form that work should take or what fora that work is
> reasonably performed in; the work may or may not involve a revision of
> the basic IDNA2008 specifications.
>
>
> We suggest to insert a paragraph in the document describing the context
> of the state of IDNA2008, and explain what issues this document does not
> attempt to address. Specifically that the conclusion of the document is
> what to do regarding Unicode versions up to and including 11, and that
> this is not to be used as expectations of future versions of Unicode.
>
>
> In addition, it’s become clear that IDNA2008 does not specify the
> mechanisms and expectations of the review of new versions of Unicode in
> enough detail; with the review of a number of versions of Unicode behind
> us, we should be able to describe those procedures and expectations
> better than IDNA2008 does. However, this may need to happen in another
> document than this one.
>
>
>     Content issues
>
>
> Section 4.1 does not specify where to find the conclusion of the IETF
> discussion on U+08A1.
>
> It is not easy to see from the text whether the algorithms and
> procedures will render U+0628 U+0654 an illegal sequence or a legal
> sequence. No matter what the resolution is, the document should make it
> obvious what the conclusion is (and why).
>
>
> RFC 5892 states that SPHERICAL ANGLE OPENING UP is DISALLOWED not PVALID:
>
> 27D0..2B4C  ; DISALLOWED
>
>
> Section 4.1 ought to include numbers for how many characters ended up in
> DISALLOWED vs PVALID - ideally, for each Unicode version since IDNA2008
> was issued. This may also be something that is recommended for the IANA
> tables rather than this document.Given the time that has passed since
> this work started, we should consider whether or not to include Unicode 12.
>
>
>     Nits
>
>
> These have been submitted separately to the author, and are not
> enumerated here.
>
>
> *
>
>
> -- 
> Surveillance is pervasive. Go Dark.


> -- 
> I18ndir mailing list
> I18ndir@ietf.org
> https://www.ietf.org/mailman/listinfo/i18ndir