On 16 Nov 2021, at 14:38, Tim Chown via Datatracker wrote: > I have reviewed this document as part of the Operational directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving the operational aspects of > the IETF drafts. Comments that are not addressed in last call may be included > in AD reviews during the IESG review. Document editors and WG chairs should > treat these comments just like any other last call comments. Here are my comments on these. > This document describes changes between Unicode 6.2.0 and 12.0.0 in the context > of IDNA2008. > > The document is generally well-written, and is Ready for publication subject to > a small number of comments and nits, detailed below. being reviewed. > > Note that I am not an expert in Unicode or IDNA2008. > > General comments: > > The draft discusses changes up to Unicode 12.0.0, but I see that Unicode 14.0.0 > was recently published; should the changes made in those past 2 years be > included in this document? Are they major, or minor, to readily allow this? As explained in last sentences of Section 1, review of versions after 12.0.0 is to be made according to RFC 8753, and this document ensures we can do a proper such review of versions after version 12.0.0. 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. > The draft talks about exceptions, but never explicitly says what an exception > is, to what, and what it would look like and where it would be documented. It > would be useful for a non-expert reader to clarify this. Exceptions is defined in section 2.6 of RFC 5892 <https://datatracker.ietf.org/doc/html/rfc5892#section-2.6>. I think to understand this document at all, one must have read RFC 5892, or at least have some information about the algorithm defined in RFV 5892, which I do not think should be repeated in this document. YMMV. > The draft includes several Appendix sections, but these are not mentioned in > the document. I think the context of their inclusion should be given. If not the Table of Contents is enough I think I need some help. Do you mean I should add explicit references from the subsections of section 3 to the various appendices which makes things more explicit than what is in the Table of Contents? > There are several sections which summarise the number of changes to characters > between specific versions. It would be useful to include a reference to these > totals, where they are sourced from. I found some summary numbers at > https://www.babelstone.co.uk/Unicode/HowMany.html, and I checked that the > “Assigned” totals there matched the totals for “PVALID + CONTEXTO/J and > DISALLOWED”, and these were correct against that source. But I don’t know > where to check the CONTEXTO/J numbers; perhaps these 27 (2+25) items should be > listed in an appendix, or a specific reference given. All changes are listed in the Appendices. > Comments: > > In section 1, CONTEXT is explained, but the later use of CONTEXTJ and CONTEXTO > are not. This would be useful to include. See section 1 of RFC 5892. I will add a clarification as follows: As explained in <xref target="RFC5892">RFC 5892</xref> CONTEXT is in turn divided into CONTEXTJ and CONTEXTO. > Section 2, penultimate para, s the first use, unexplained, of CONTEXTO/J. Changed to: The IDNA2008 rules use the Unicode Standard to create a further subset of code points and context that are permitted in DNS labels associated with its PVALID, and CONTEXT (CONTEXTJ or CONTEXTO) derived property values. DNS registries and other organizations that deal with IDNs are supposed to create their own subsets from IDNA2008 for use by those registries and organizations. > In Section 2, last para, maybe point forward to the security section regarding > the reason for conservatism? Added paragraph at the end: See also the Security Considerations section in this document. > In Section 3.1, changes from 6.2.0 to 7.0.0 are summarised, but in the Appendix > the difference listed is 6.3.0 to 7.0.0. Is that intended? That is a problem that I obviously never resolved. In reality, this is a document that deals with Unicode from version 6.0.0 to 12.0.0. I have changed the references to be like that, recalculated all tables and values, and updated accordingly. > Section 5, paragraph 2 it talks of future Unicode versions that might need > action, but given 14.0.0 is published now, can we say more than “might” here? > Or do we publish this as a snapshot against 12.0.0 from two years ago? I guess > this document’s origins were at the time of publication of 12.0.0. This is a snapshot, so that we can when this is done do the proper review of 12.0.0 to 14.0.0. > Section 6 - cite the registry? Reference added. > Nits: > > Abstract: > “consisstent” -> “consistent” Fixed > Section 1: > Third to last para - “and IETF” -> “and the IETF” Fixed > Section 4, line 5, there’s an orphaned “(BackwardCompatible(G))”. Fixed. It was intended to be a more clear reference, but confusing...so I removed it. > Section 5, “after review” -> “after the review” and “tuning. Like” -> “tuning, > like” Fixed > Section 7 - “do not” -> “does not” Fixed > Best wishes, Thanks! Patrik > Tim > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call
Attachment:
signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
