Re: [Last-Call] [Gen-art] Genart last call review of draft-faltstrom-unicode12-03
Lars Eggert <lars@eggert.org> Thu, 03 February 2022 11:22 UTC
Return-Path: <lars@eggert.org>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280093A11D6; Thu, 3 Feb 2022 03:22:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=eggert.org
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 AMO3TSC6g11o; Thu, 3 Feb 2022 03:22:09 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 7BC2B3A11D5; Thu, 3 Feb 2022 03:22:06 -0800 (PST)
Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:3483:e6e7:fbe7:7efc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 623B11D389F; Thu, 3 Feb 2022 13:21:56 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1643887316; bh=Th8eSV73Zy6hJKUieOoYJHimRnWyfeHQtg74X8+pelA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=G/U8b4Qhzsi6U89ayMAbnTaisM2eeh61wvIJllLN1HQABCyqQ9cZdmjE0F6pahcMq PejsllqNgNBhMuIy+EHIIP7WCe5ocDMFTrZJFM3ZEwwLDqX4X7MJ+/8G8tSN++wD8l IAcZpfn6xfYFsaBzR7hv3GSB6OO3LGV+z9r/Yhsc=
Content-Type: multipart/signed; boundary="Apple-Mail=_B7B2A08E-235D-4CAF-9BF5-CD388EE445D2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <163424380422.30664.6295894825173486352@ietfa.amsl.com>
Date: Thu, 03 Feb 2022 13:21:55 +0200
Cc: gen-art@ietf.org, last-call@ietf.org, draft-faltstrom-unicode12.all@ietf.org
Message-Id: <D40A3331-F752-40ED-8F92-697C2831100B@eggert.org>
References: <163424380422.30664.6295894825173486352@ietfa.amsl.com>
To: Russ Housley <housley@vigilsec.com>
X-MailScanner-ID: 623B11D389F.A5941
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/9InfiyZiiM1IbLRaoVxAjuehdUs>
Subject: Re: [Last-Call] [Gen-art] Genart last call review of draft-faltstrom-unicode12-03
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2022 11:22:15 -0000
Russ, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-10-14, at 23:36, Russ Housley via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Russ Housley > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-faltstrom-unicode12-03 > Reviewer: Russ Housley > Review Date: 2021-10-14 > IETF LC End Date: 2021-11-16 > IESG Telechat date: unknown > > Summary: Almost Ready > > > Major Concerns: > > Section 4 says: > > ... As including an exception would require > implementation changes in deployed implementations of IDNA20008, the > editor proposes that such a BackwardCompatible rule NOT to be added > to IDNA2008. This also ensures all sandhi marks being treated in an > equal way. > > The IETF has decided to NOT add a BackwardCompatible rule to IDNA2008 > (i.e. Section 2.7 of RFC 5892 [RFC5892]) for this code point. > > This document is implementing the recommendations (assuming that the > IETF Last Call confirms there is consensus). So, this sentence should > reflect that as a way forward, not a recommendation. I suggest: > > ... As including an exception would require > implementation changes in deployed implementations of IDNA20008, the > IETF has decided to not add a BackwardCompatible rule to IDNA2008 > (i.e. Section 2.7 of RFC 5892 [RFC5892]) for this code point. This > also ensures all sandhi marks being treated in an equal way. > > Section 5: > > s/conclusion of this document is to not add/conclusion is to not add/ > > It is not the conclusion of the document, it is the consensus of the > IETF (assuming that the IETF Last Call confirms that position). > > > Minor Concerns: > > Section 2.1: s/4892/5892/ > > Section 2.3 says: "... CONTEXTJ, and CONTEXTO ..." CONTEXT is explained > earlier in the document, but please provide a brief explanation of these > derived property values. They are used later in the document too. > > > Nits: > > Section 1, last 3 paragraphs, says: > > There were three incompatible changes in the Unicode standard after > Unicode 5.2.0 [Unicode-5.2.0] up to including Unicode 6.0.0 > [Unicode-6.0.0], as described in RFC 6452 [RFC6452]. The code points > U+0CF1 and U+0CF2 had a derived property value change from DISALLOWED > to PVALID while U+19DA had a change in derived property value from > PVALID to DISALLOWED. They were examined in great detail and IETF > concluded that the consensus is that no update was needed to RFC 5892 > [RFC5892] based on the changes made to the Unicode standard. > > As described in Section 3, more changes have been made to code points > between Unicode version 6.0.0 and Unicode version 12.0.0 > [Unicode-12.0.0] so that the derived property values have been > changed in an incompatible way. This document concludes that no > exceptions are to be added to RFC 5892 [RFC5892] even though there > are changes in the derived property value as a result of the changes > made in Unicode between version 6.2.0 and 12.0.0. > > Further, in 2015, the Internet Architecture Board (IAB) issued a > statement [IAB] which requested the IETF to resolve the issues > related to the code point ARABIC LETTER BEH WITH HAMZA ABOVE (U+08A1) > that was introduced in Unicode 7.0.0 [Unicode-7.0.0]. This document > concludes that this code point is not to be added to the exception > list either. It should be noted that the review on U+08A1 indicated > that it is not an isolated case and that a number of PVALID code > points of long standing may have similar issues. The problem > resulted in a clarification of the review process of new Unicode > versions RFC 8753 [RFC8753]. This clarification of the review > process will impact review of Unicode versions after version 12.0.0. > > I propose a shorter summary that I think says the same thing: > > There were three incompatible changes between Unicode 5.2.0 > [Unicode-5.2.0] and Unicode 6.0.0 [Unicode-6.0.0]; they are > described in RFC 6452 [RFC6452]. The code points U+0CF1 and U+0CF2 > had a derived property value change from DISALLOWED to PVALID, and > the code point U+19DA had a change in derived property value from > PVALID to DISALLOWED. These changes were examined in great detail, > but the IETF concluded that these changes to the Unicode standard > did not warrant an update to RFC 5892 [RFC5892]. > > As described in Section 3, more incompatible changes have been made > to code points between Unicode 6.0.0 and Unicode 12.0.0 > [Unicode-12.0.0]; however, the changes in the derived property values > do not result in exceptions being added to RFC 5892 [RFC5892]. > > Further, in 2015, the Internet Architecture Board (IAB) issued a > statement [IAB] that asked the IETF to resolve the issues around > the code point ARABIC LETTER BEH WITH HAMZA ABOVE (U+08A1) that was > introduced in Unicode 7.0.0 [Unicode-7.0.0]. Again, no exception is > being added to RFC 5892 [RFC5892]; however, it should be noted that > the review of the issues around U+08A1 indicated that this code point > is not an isolated case and that a number of PVALID code points of > long standing may have similar issues. The problem resulted in a > clarification of the review process of new Unicode versions, which > are published in RFC 8753 [RFC8753]. This clarification of the > review process will impact the future review of Unicode versions > beyond 12.0.0. > > Section 2.3: s/version 3.2 of The Unicode Standard/Unicode 3.2/ > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- [Last-Call] Genart last call review of draft-falt… Russ Housley via Datatracker
- Re: [Last-Call] Genart last call review of draft-… Patrik Fältström
- Re: [Last-Call] [Gen-art] Genart last call review… Lars Eggert