Subject: Re: [I18ndir] Request for review: draft-faltstrom-unicode11-07

From: "Patrik Fältström" <[email-masked]>
Date: Mon, 11 Mar 2019 00:50:47 +0900

Many of these comments from Martin Düerst are taken care of.

  Patrik

> Hello everybody,
>
> I'm responding to this mail because it's the last in the thread that arrived here, and because it's reasonably short.
>
> I'm also including my detailed review.
>
> On 2019/02/24 11:41, John C Klensin wrote:
>> Scott,
>>
>> Two questions that may affect, not the utility of your report
>> but how it is interpreted in context:
>>
>> (1) I see no trace in the report of any of a recent discussions
>> of whether draft-faltstrom-unicode11-07 can be construed as
>> accepting problems that the IETF has been aware of for years,
>> either treating those problems as of no particular interest or
>> as issues on which registries should be warned and aware but, in
>> either event, as things for which there is no justification for
>> adjusting IDNA2008 and its lists or rules now or in the future.
>> Was it your intent to indicate that the document is ok at is and
>> that those issues are either of no significance or at least do
>> not need to be reflected in the document?
>
> As to what our draft should do, I am very much of the opinion that it should say that it does not warrant any adjustments to the rules of IDNA2008 at this moment.
>
> But I think it should not say (or give the impression) that such changes (or even more wide-ranging changes) are ruled out in the future.
>
>
>> (2) You use the term "domain name registry operator" below.  To
>> be sure we are talking about the same thing, I tend to use that
>> term in the context used in RFC 1591, i.e., applying to every
>> entity that places names into the DNS at any level with the
>> possible exception of the root.   Is that your intent as well,
>> or were you referring to such subsets as "TLD registry
>> operator", "gTLD registry operator", what ICANN calls a
>> "contracted party", or some combination of them or others?
>>
>> I'll let Pete, Peter, and Harald address the question of whether
>> the directorate is expected to submit one report based on a
>> discussion to which I think this is your first contribution or
>> whether Harald is preparing a summary and we are each expected
>> to write our own report or additions.
>>
>> best,
>>      john
>>
>>
>>
>>
>>
>>
>> --On Thursday, February 21, 2019 19:50 +0000 "Hollenbeck, Scott"
>> <shollenbeck=[email-masked]> wrote:
>>
>>> I've completed my review of draft-faltstrom-unicode11 from the
>>> perspective of a domain name registry operator. In that
>>> context, I believe the document is "Ready with Nits". The nits
>>> I noted were minor issues with grammar and/or phrasing that'll
>>> be sorted out by the RFC Editor, so I don't see a lot of value
>>> in calling them out individually.
>
> I agree with the "Nits", but I think it's better to sort out most of them as soon as we are aware of them to avoid confusion later. And some may be a bit more than just nits, depending on how you look at them. So here we go:
>
> Abstract, second para:
>
> "Some changes have been made in the Unicode Standard related to the    algorithm IDNA2008 specifies."
> ->
> "Some additions and changes have been made in the Unicode Standard that affect the algorithm IDNA2008 specifies."
> [it's mostly additions, very few changes]
>
> "IDNA2008 allows adding exceptions to
>     the algorithm for backward compatibility; however, this document
> makes no such changes"
> ->
> "IDNA2008 allows adding exceptions to
>     the algorithm for backward compatibility; hovever, this document not
> add any such exceptions"
> [in 'such changes', the referent may be unclear]
>
> "Thus this document requests that IANA update
>     the tables to Unicode 11."
> ->
> "This document provides the necessary tables to IANA for the update to Unicode 11."
> [This document would request that IANA update the tables even if we decided we needed some exceptions.]
>
> "The document also recomments that all DNS registries continue the    practice of calculating a repertoire using conservatism and inclusion
>     principles."
> ->
> "The document also recommen*d*s that all DNS registries continue the    practice of defining their repertoires using conservatism and inclusion
>     principles."
> [Align to plural for 'registries' and 'repertoires'; avoid
> 'calculating', because it suggests this can mostly be done
> algorithmically, without judgement, which isn't the impression I think we should give.]
>
> 1. Introduction, first para:
>
> 'was largely completed in 2008, and is thus known within as "IDNA2008"'
> ->
> 'was started in 2008, and is thus known as "IDNA2008"'
> [within what?; "largely completed" already noted, more correct wordings appreciated]
>
> "It is specified in a series of documents
>     listed in Section 3.1."
> ->
> "It is specified in the series of documents
>     listed in Section 3.1."
>
> 1. Introduction, first 'o' bullet:
>
>       "Assigning code points can create problems if the newly-assigned
>        code points are compositions of code points changes (or would have
>        changed) the normalization functions.  These problems can arise if
>        the new code points change the matching algorithms used and this
>        in turn creates problems looking up already stored strings."
> [I think I know what this paragraph wants to get at, but I have problems parsing the text. For example, should it be "compositions of code point changes" or "compositions of code points that change" or what else?
> Also, what matching algorithm? As far as I'm aware, matching of labels is done by comparing A-Labels in the DNS.]
>
> 1. Introduction, second 'o' bullet:
>
> "a code point that
>        was not allowed (and thus is blocked in some situations) to
>        suddenly end up being allowed."
> ->
> "a code point that
>        was not allowed (and thus is blocked in some situations) can
>        suddenly end up being allowed."
>
> 1. Introduction, para following bullet list:
>
>    "Historically, the IETF has accepted all implications of changes in
>     the Unicode Standard even though the changes have resulted in
>     problematic changes in the derived property value."
> ->
>    "Historically, the IETF has accepted all implications of changes in
>     the Unicode Standard even though the changes have resulted in
>     minor changes in the derived property values."
> [Let's not call these 'problematic' if we actually accepted them. If we really have to, "potentially problematic" might be the furthest I'd be willing to support.]
>
> 1. Introduction, second-to-last para:
>
> "there is not a problem" -> "there is no problem"
>
> "This document concludes that no
>     exceptions are to be added to IDNA2008 even if changes in the derived
>     property value is a result of the changes made in Unicode between
>     version 6.3.0 and 11.0.0."
> ->
> "This document concludes that no
>     exceptions are to be added to IDNA2008 even though there are changes
> in the derived
>     property values as a result of the changes made in Unicode between
>     version 6.3.0 and 11.0.0."
> [We know whether there are changes in the derived property values or not, so "if" isn't appropriate.
>
> 1. Introduction, last para:
>
> "The current document
>     resolves this issue and suggests that the IDNA2008 standard followsO
>     the Unicode Standard and not update RFC 5892 [RFC5892] or any other
>     IDNA2008 RFCs."
> ->
> "The current document
>     resolves this issue and suggests that the IDNA2008 standard follows
>     the Unicode Standard and does not update RFC 5892 [RFC5892] or any other
>     IDNA2008 RFCs."
> [Actually, we could also address the "ARABIC LETTER BEH WITH HAMZA ABOVE" by adding an exception for this letter, rather than changing RFC 5892, but we are not doing that, either. Maybe we should say so.]
>
> Section 3.1, RFC 5892:
>
> "an is based originally on Unicode 5.2.0"
> ->
> "and is based on Unicode 5.2.0"
> [It's still based on Unicode 5.2.0, and that will never change, so 'originally' seems superfluous.]
>
> "The Unicode-based rules in RFC 4892"
> ->
> "The Unicode-based rules in RFC 5892"
> [RFC 4892 happens to be about the DNS, but not what we want.]
>
> "RFC 5892
>        obsoletes RFC 3491 [RFC3491], and in particular the use of the
>        tables to which it refers."
> ->
> "RFC 5892
>        obsoletes RFC 3491 [RFC3491], and in particular the use of the
>        tables to which RFC 3491 refers."
> [Avoid unclear referent.]
>
> Section 3.1, RFC 5895:
>      " RFC 5895 [RFC5895], informally called "Mapping", discusses the
>        issue of mapping characters into other characters and that
>        provides guidance for doing so when that is appropriate.  RFC 5895
>        provides advice and is not a required part of IDNA."
> ->
>       "RFC 5895 [RFC5895], informally called "Mapping", discusses the
>        issue of mapping characters to other characters and
>        provides guidance for doing so when that is appropriate.  RFC 5895
>        provides advice only and is not a required part of IDNA."
>
> Section 3.1, RFC 6452:
> "that resulted in the derived property value change
>        for the code points U+0CF1, U+0CF2 and U+19DA"
> ->
> "that resulted in derived property value changes
>        for the code points U+0CF1, U+0CF2 and U+19DA"
>
> "The IETF concluded that no update to RFC
>        5892 [RFC5892] was needed based on the changes made in Unicode
>        6.0.0 [Unicode-6.0.0]."
> [There was also no additional exception, and this should probably be mentioned here.]
>
> "As a result, the derived property value
>        remained aligned with the Unicode Standard."
> ->
> "As a result, the derived property values
>        remained aligned with the Unicode Standard."
>
> Section 3.2, first 'o' bullet:
> "IDNA2003 as specified in RFC 3490 [RFC3490] and RFC 3491 [RFC3491]
>        which implies using a table within which it is said whether code
>        points are allowed to be used or not, after doing the
>        normalization specified in IDNA2003."
> ->
> "IDNA2003 as specified in RFC 3490 [RFC3490] and RFC 3491 [RFC3491].
>        This implies using a table that indicates whether code
>        points are allowed to be used or not, after doing the
>        mapping specified in IDNA2003."
> [ToASCII as specified in RFC 3490 can be seen as a kind of normalization in the wider sense, but when Unicode is involved, I'd try to avoid this term unless it refers to things like NFC, NFD, NFKC,...]
>
> Section 3.2, first para after bullet list:
>
> "create a subset of these
>     by assigning the PVALID derived property value to them."
> ->
> "create a subset consisting of the codepoints
>     that are assigned the PVALID derived property value."
> [Should we talk about contextual rules here?]
>
> Section 4.1, third paragraph:
>
> "The character U+08A1 (ARABIC LETTER BEH WITH HAMZA ABOVE) can be represented with the
>     sequence ARABIC LETTER BEH (U+0628) and ARABIC HAMZA ABOVE (U+0654)."
> ->
> "The character U+08A1 can be represented with the
>     sequence ARABIC LETTER BEH (U+0628) and ARABIC HAMZA ABOVE (U+0654)."
> [Better give the name again, makes it easier to understand for outsiders (unless we explicitly want this to be under the radar, but I guess it's way too late for that).]
>
> "This identical to LATIN SMALL LETTER A WITH DIAERESIS (U+00E4), that    can be represented"
> ->
> "This identical to LATIN SMALL LETTER A WITH DIAERESIS (U+00E4), which    can be represented"
>
> "One difference between
>     these two sequences is how they are treated in the normalization
>     forms specified by the Unicode Consortium."
> ->
> "The important difference between
>     these two sequences is how they are treated in the normalization
>     forms specified by the Unicode Consortium."
>
> 4.1, last para:
>
> "U+08A1 is discussed in draft-freytag-troublesome-characters    [I-D.freytag-troublesome-characters] and other Internet-Drafts."
> ["and other Internet-Drafts" does not give any information whatsoever.
> Either remove it or provide actual references.]
>
> "Regardless of whether the discussion of those drafts ends in    recommendations to include the code point in the repertoire of
>     characters permissable for registration or not, it is still
>     acceptable to allow the code point to have a derived property value
>     of PVALID."
> ->
> "Regardless of whether the code point U+08A1 should be permitted for registration in any specific case, it is still
>     acceptable to allow the code point to have a derived property value
>     of PVALID."
> [I think this is a bit more open. In practice, I'd expect most serious registries to disallow this codepoint, but would expect registries supporting the Adamawa Fulfulde language in Cameroon to allow it, making sure there's no confusion with the decomposed version.]
>
> Section 4.2:
>
> "There are no changes made to Unicode between version 7.0.0 and 10.0.0    that impact IDNA2008 calculation of the derived property value."
> ->
> "There are no changes made to Unicode between version 7.0.0 and 10.0.0    that impact the IDNA2008 calculation of derived property values."
>
> Section 4.3, first para:
> "The Unicode Standard Version 11.0.0 [Unicode-11.0.0] has included a    number of changes [Changes-11.0.0] from version 10.0.0."
> ->
> "The Unicode Standard Version 11.0.0 [Unicode-11.0.0] includes a    number of changes [Changes-11.0.0] from version 10.0.0.
>     Those relevant for IDNA2008 are listed below."
>
> Section 4.2, first 'o' bullet of second bullet list:
>
> "o  The newly assigned 684 characters are to have a derived property       value as of a result of applying the IDNA2008 algorithm."
> ->
> "o  The newly assigned 684 characters are assigned a derived property       value as a result of applying the IDNA2008 algorithm."
>
> Section 4.2, second 'o' bullet of second bullet list:
>
> Add something like "The newly encoded Mtavruli letters have general category "Lu" and are therefore DISALLOWED."
>
> Section 5, last para:
>
> "All DNS registries (and other organizatios) SHOULD calculate a    repertoire using the conservatism and inclusion principles, as
>     described in SAC-084 [SAC-084] and similar documents."
> [Again, I think "and similar documents" is not helpful. I'd point to UTR 36 (Unicode Security Considerations) and UTR 39 (Unicode Security Mechanisms). These references might also go into the Security Considerations section.]
>
> Section 7:
>
> "This document makes recommendations regarding the use of the IDNA2008    algorithm for calculation of derived property values, based on the
>     current Unicode version."
> ->
> "This document makes recommendations regarding the use of the IDNA2008    algorithm for calculation of derived property values, based on
> Unicode version 11.0.0."
> [Be specific about version. Makes it easier for people to read this document years later.]
>
> "It also recommends that DNS registries (and
>     others dealing with Internationalized Domain Names) explicitly select
>     appropriate subsets of characters with the derived value of PVALID."
> ->
> "It also recommends that DNS registries (and
>     others dealing with Internationalized Domain Names) explicitly select
>     appropriate subsets of the characters with the derived value of PVALID."
>
> Again, I didn't check the tables. I might be able to do so (by writing my own program) in a week or two, but I understand this will be too late.
>
> I seem to remember that Patrik wrote the program for generating the tables in Ruby. If that's so, I'd be glad to review it if I get a pointer.
>
> Hope this helps.   Regards,   Martin.
>
>>> The Conclusion and Security Considerations sections contain
>>> useful information that domain registries and registrars will
>>> need to fully understand to guide implementation and
>>> deployment decisions. I also appreciated the last sentence of
>>> the Introduction ("The current document resolves this issue
>>> and suggests that the IDNA2008 standard followsO  (SAH:
>>> there's a nit) the Unicode Standard and not update RFC 5892
>>> [RFC5892] or any other IDNA2008 RFCs") because it provides an
>>> up-front executive summary of what an implementer needs to
>>> know at a high level.
>>>
>>> Scott
>>

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 11 Mar 2019 00:27:05 +0000

Hello Patrik,

> Many of these comments from Martin Düerst are taken care of.

Many thanks!

Regards,   Martin.

P.S.: Please note that my name is preferably "Dürst", with a fallback of 
"Duerst". "Düerst" is not an option.