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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
