[I18ndir] Review of Unicode-07: Finishing

[Harald Alvestrand <[e-mail]>]

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.