Subject: Re: [Last-Call] Opsdir last call review of draft-faltstrom-unicode12-03

From: Tim Chown <[email-masked]>
Date: Wed, 1 Dec 2021 13:16:41 +0000

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 <[email-masked]> 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."

>> 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.

>> 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.

>> 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.

>> 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.

>> 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

> 
>   Patrik
> 
>> Tim
>> 
>> 
>> -- 
>> last-call mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/last-call

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 01 Dec 2021 16:30:26 +0100

Thanks for the feedback. Now I understand. I will do yet another version based on this. Will be back when I have had time to do one. Hopefully tomorrow.

   Patrik

On 1 Dec 2021, at 14:16, Tim Chown wrote:

>> 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.
>

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 03 Dec 2021 13:13:12 +0100

> “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!

>> 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.
>

Fixed!

> 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…

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"/>.

> 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?

> 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…

See above.

>>> Section 7 - “do not” -> “does not”

Thanks for your patience!

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Fri, 03 Dec 2021 11:21:59 -0500

(Most of the comments in this note are likely to be of specific
interest to Patrik, Tim, and those deeply involved with IDNA.
Other busy people, probably including the IESG, might want to
just skip to the two paragraphs at the end and then treat the
rest of the text as examples they may or may not want to study.

--On Friday, December 3, 2021 13:13 +0100 Patrik Fältström
<paf=[email-masked]> wrote:

>...
>> 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.
> 
>         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

Patrik,

Since this fine-tuning effort (which I appreciate) to make
things crystal-clear, I suggest replacing "interesting" with
"significant" or "important".  "Interesting" in your sentence
just has too many possible implications.    For the same
purpose, what might be even better would be to rephrase, so

NEW (from your note):
	The interesting changes in derived property values
	include other changes. 

NEWER (suggested):
	Changes in derived property values other than those
	transitions are normally the only ones of significance
	to IDNA users and applications.

That is a quick thought.  I think it can be improved further,
but hope we can all trust the RPC to work it out.

Also...

>> 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. 

Does this refer to the text of Unicode 6.0.0 or is it actually
about RFC 6452?  If the latter, perhaps "RFC 6452 has already
identified code points with various derived property values".
If it is really about Unicode 6.0.0, I don't quite understand
the point because _every_ version of Unicode has "Derived
Properties" [1].  If it does not affect the text of the
document, maybe we don't care other that for the edification of
Tim and others as we move forward (see comment at end).

> 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.

You might be able to make that a bit more clear by saying
something like "There were no changes to the number of code
points assigned to CONTEXTJ; the number remains at 2" or words
to that general effect (again see comment at end).

>...
>>>> Comments:
>>>> 
>>>> In section 1, CONTEXT is explained, but the later use of
>>>> CONTEXTJ and CONTEXTO are not.  This would be useful to
>>>> include.
>>> 

If there is still any remaining confusion (and maybe even if
there is not), perhaps a reference to Section 3.1 of RFC 5894
would be helpful.  It seems to me that part of Tim's confusion
(and likely confusion by readers who, like him, are not
thoroughly familiar with IDNA2008) is that RFC 5892 talks about
those contextual rules and how and why they are assigned to code
points but not about what they are for, why there are two types
and how they differ in practice, and so on.  Some of that
material is in RFC 5891 ("the Protocol Document") to which the
category definitions of RFC 5892 explicitly points, but the more
or less plain English, quasi-tutorial, explanation is in RFC
5894.   And see comment at end.

>>>  by those registries and organizations.

While these are improvements, I am concerned about the path this
is going down, especially because I expect this document to set
precedents for its successors.  A paragraph like the above,
while helpful, is basically a reprise of text that already
appear in RFCs 5890, 5894, 8753, and 5892 itself.  That strikes
me as unwise: it turns this document into more of a tutorial
than it should be, creates risks of having to update it (or
having it further confuse readers) if IDNA2008 definitions are
ever upgraded, and makes it harder for someone who is thoroughly
familiar with IDNA2008 and its applications, and why this type
of document is needed at all, to find information that is
relevant to them and their needs.  

Similar comments apply to the explanation of why conservatism is
important even though a one-sentence cross-reference is, at
worst, harmless. 

See comment at end.

>>>> In Section 2, last para, maybe point forward to the
>>>> security section regarding the reason for conservatism?
>>> 

See above.

>...

While each of these changes makes the I-D better when it is
viewed as an isolated document, I fear that we may be going down
the wrong path.  As I think the Introduction makes fairly clear,
this document is part of the IDNA2008 collection and is only
marginally comprehensible without an understanding of the base
documents (RFCs 5890-5894).  Every bit of tutorial explanation
that is added here is a step toward encouraging people to
believe that they can read this document and understand what it,
and the tables and their application, are about without
understanding IDNA2008.   Many of the issues Tim has caught in
his obviously careful reading are very real.  The fixes are
significant and important --  Patrik has already thanked him and
so do I, but the community owes him thanks more generally.   But
others, and Patrik's response to them, seem to be straying in
the direction of tutorial information that already appears in
the base IDNA2008 documents or in RFC 8753.  I think we should
be very cautious about that both because of the "belief" issue
above and because I (and I think everyone else who has commented
recently) would prefer to get this document out than to have to
carefully check these tutorial explanations for complete
consistency with the IDNA2008 base, down to reviewing the impact
of even slight differences in terminology and picking the last
nit.  

So, again in the interest of being done with this and letting
those involved move on to other work (including thinking about
how to get the Unicode 13.x and 14.x reviews moving forward), I
suggest that we do not try to un-do any of the changes that have
been made already, fixing them when needed.  If the fixes to
tutorial explanations involve significant work and/or thought,
removing those paragraphs should be considered as an
alternative, but I haven't seen any cases of that (my
suggestions about the changes above notwithstanding).  In
retrospect, I wonder whether Section 3.2 (or most of it) even
belongs here -- that material mostly is a repetition and
clarification of material already in the base documents.  Where
it is not, we might have been better off with a separate
document that explicitly updates part of the core.  However, I
don't think that is worth changing the I-D, or even debating the
point, now.   I make one suggestion to clarify the situation:
Add a sentence in the Introduction that clearly conveys the
principle that this document is a supplement to the core
IDNA2008 specs and that anyone who tries to read it without a
solid understanding of those specs is going to be in Big Trouble
and might be led into error (I trust Patrik can come up with a
less inappropriate phrasing while making the point).   But let's
not try to add more tutorial materials or keep trying to
fine-tune: let's get the document out and move on.  

Thanks,
   john

[1] See TUS version 13.0, Section 3.5, definition D46.

---

From: Tim Chown <[email-masked]>
Date: Tue, 7 Dec 2021 11:23:07 +0000

Hi Patrik,

In-line… with some snipping...

> On 3 Dec 2021, at 12:13, Patrik Fältström <[email-masked]> wrote:
> 

<snip>

>        target="Appendix-11.0.0"/>.

Thanks.  Sorry if it seems pedantic to point out!

> 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?

OK, that’s fine, let’s leave it as is.

<snip>

> Thanks for your patience!

Likewise - I’m happy for it to proceed now and my review switches to Ready.

Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 7 Dec 2021 11:28:07 +0000

Thanks John,

Your observations are also in my view very good and I would not object to any of what you propose for added clarity.

But the emphasis should indeed be on shipping this.

Tim

> On 3 Dec 2021, at 16:21, John C Klensin <[email-masked]> wrote:
>