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 <john-ietf@xxxxxxx> wrote:
>
> (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=40frobbit.se@xxxxxxxxxxxxxx> 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.
>>
>> 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"/>.
>
> 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...
>
>>>> 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.
>
> 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.
>>>>
>>>> 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.
>
> 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.
>
>>>>> 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.
>
> 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?
>>>>
>>>> Added paragraph at the end:
>>>>
>>>> See also the Security Considerations section in this
>>>> document.
>>>
>>> Thanks.
>
> 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.
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
