Re: [I18ndir] Review of Unicode-07: Finishing

["Marc Blanchet" <[e-mail]>]

good. I especially content with that paragraph:

> In addition, it’s become clear that IDNA2008 does not specify the
> mechanisms and expectations of the review of new versions of Unicode in
> enough detail; with the review of a number of versions of Unicode behind
> us, we should be able to describe those procedures and expectations
> better than IDNA2008 does. However, this may need to happen in another
> document than this one.

Marc.

On 21 Mar 2019, at 12:10, Harald Alvestrand wrote:

> With the petering out of discussion, I think it's time to file our
> review of unicode-07 and call it "done". We were asked for a review, we
> have written a review. The review should be part of the public record,
> but I don't think we need to call attention to it by posting it all over
> the place, given that we have new versions of the document to work from.
>
> Current proposed text:
>
>
>
> **
>
> *Directorate review of draft-faltstrom-unicode11-07*
>
> *
>
> Overall conclusion: Not ready yet, needs some updates. New I-D recommended.
>
>
> [Note: As part of the discussion that resulted in this text, a new I-D
> has been issued.]
>
>
>     Context issues
>
>
> The discussion of draft-faltstrom-unicode11 in the directorate has shown
> that the directorate members share a number of concerns about the
> current state of IDNA, only some of which are directly relevant to this
> memo.
>
>
> IDNA2008 considered limits to what was reasonable to register and use in
> the DNS at a number of levels:
>
>
>   *
>
>     A level of “don’t register stuff that causes confusion”. This
>     requires human judgment, and reasonable people may disagree about
>     what causes confusion.
>
>   *
>
>     A level of “don’t register stuff that is structurally invalid under
>     the relevant writing system”. Aspects of this can be captured in
>     rulesets (ICANN’s RZ-LGR efforts fall not this category), but
>     requires deep expertise; this is captured in IDNA2008 as the “don’t
>     register what you don’t understand” rule.
>
>   *
>
>     A level of “this is stuff that you should never register, and
>     applications can reasonably choose to treat it as an error or an
>     attack if it ever shows up”. This is the distinction that is
>     captured in the classification of codepoints as DISALLOWED, and
>     where IDNA2008 (with updates) gives precise rules.
>
>
> The current document focuses on the last level only - the maintenance of
> the distinction between PVALID and DISALLOWED. (It also considers
> whether new CONTEXTO and CONTEXTJ rules are needed).
>
>
> It is clear from directorate discussion that work needs to be done at
> the other levels outlined above too, but it is not clear from the
> discussion what form that work should take or what fora that work is
> reasonably performed in; the work may or may not involve a revision of
> the basic IDNA2008 specifications.
>
>
> We suggest to insert a paragraph in the document describing the context
> of the state of IDNA2008, and explain what issues this document does not
> attempt to address. Specifically that the conclusion of the document is
> what to do regarding Unicode versions up to and including 11, and that
> this is not to be used as expectations of future versions of Unicode.
>
>
> In addition, it’s become clear that IDNA2008 does not specify the
> mechanisms and expectations of the review of new versions of Unicode in
> enough detail; with the review of a number of versions of Unicode behind
> us, we should be able to describe those procedures and expectations
> better than IDNA2008 does. However, this may need to happen in another
> document than this one.
>
>
>     Content issues
>
>
> Section 4.1 does not specify where to find the conclusion of the IETF
> discussion on U+08A1.
>
> It is not easy to see from the text whether the algorithms and
> procedures will render U+0628 U+0654 an illegal sequence or a legal
> sequence. No matter what the resolution is, the document should make it
> obvious what the conclusion is (and why).
>
>
> RFC 5892 states that SPHERICAL ANGLE OPENING UP is DISALLOWED not PVALID:
>
> 27D0..2B4C  ; DISALLOWED
>
>
> Section 4.1 ought to include numbers for how many characters ended up in
> DISALLOWED vs PVALID - ideally, for each Unicode version since IDNA2008
> was issued. This may also be something that is recommended for the IANA
> tables rather than this document.Given the time that has passed since
> this work started, we should consider whether or not to include Unicode 12.
>
>
>     Nits
>
>
> These have been submitted separately to the author, and are not
> enumerated here.
>
>
> *
>
>
> -- 
> Surveillance is pervasive. Go Dark.


> -- 
> I18ndir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18ndir