On 1 Dec 2021, at 14:16, Tim Chown wrote: > Hi Patrik, > > First, I agree with what you and John say about getting this doc done. Other responses inline... > >> On 28 Nov 2021, at 13:52, Patrik Fältström <paf@xxxxxxxxxx> wrote: >> >> 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. > > OK, thanks, that wasn’t clear to me (as someone who is not following this work). > > Would it hurt to explicitly say in a final para in section 1? Saying 8753 will “impact future reviews” isn’t as clear as what you said above. > > “Any review of Unicode versions after 12.0.0 should be made according to RFC 8753; an objective of this document is to ensure that a proper review of such versions after version 12.0.0 can be made." Very good suggestion. Fixed! >>> 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. > > Well, it’s not clear to me what an “exception” actually is. > > I was expect to see “exceptions (as defined in section 2.6 of RFC5892)" written for the first use of “exception” in the main body of the draft, i.e. the penultimate paragraph of section 1. Fixed! >>> 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? > > I just find it surprising to see completely unreferenced Appendices in the document. Why are they there if not referenced somewhere? Some of them do not match to the changes discussed in section 3. Hmm....I added this to the section titled "Notable Changes Between Unicode 6.0.0 and 12.0.0": Among the changes between the Unicode versions, most code points that change derived property value change from UNASSIGNED to PVALID or from UNASSIGNED to DISALLOWED. The interesting changes in derived property values include other changes. All changes between the major versions of Unicode can be found in <xref target="Appendix-6.0.0"/>, <xref target="Appendix-7.0.0"/>, <xref target="Appendix-8.0.0"/>, <xref target="Appendix-9.0.0"/>, <xref target="Appendix-10.0.0"/> and <xref target="Appendix-11.0.0"/>. >>> 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. > > I don’t see where the 2+25 figures are taken from. Unicode 6.0.0 already have code points with various derived property values. In the list of "changes from 6.0.0 to 7.0.0" I have written "CONTEXTJ did not change, at 2". To me this is crystal clear the number of code points with the derived property value CONTEXTJ is 2 in Unicode 7.0.0 as it was in Unicode 6.0.0. That it is 2 can be found in earlier RFCs or in the IANA registry. I completely understand you are confused, but I do not know how to make this more clear. If you *now* understand what the number 2 (and because of that 25 and 27) is coming from, can you suggest a change that will make this more clear? >>> 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. > > Thanks. > >>> 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. > > Thanks. > >>> 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. > > Thanks. > >>> 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. > > OK. So 3.1 would now presumably refer to Appendix A, 3.2 to Appendices B,C,D and 3.3 to E and 3.4 to F, but I don’t understand why there is B,C,D instead of an appendix listing the changes covered in 3.2. See above. >>> 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. > > OK. > >>> 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! > > Cheers, > Tim Thanks for your patience! Patrik >> >> 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
