IDN Guidelines 3.0 comments

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Dear ICANN,

While I am not the target audience for this document, I read the
document to understand if it would have any impact on my IDNA2008
implementation called Libidn2.

I have no opinion on the policy aspects of the document, but I noticed a
set of technical issues below.

None of the issues are showstoppers.  Issue 2) suggests there is a
misunderstanding about how IDNA2008 works on a technical level, which
could have unintended consequences.  The consequences could be that
different people read the guidelines in different incompatible ways.  Or
that the rest of the document needs to be re-thought in light of the
issue.

1)

Guideline 1 in the document says:

   The initial version of this protocol was defined in RFCs 3454, 3490,
   3491, and 3492.  A revised version is defined in RFCs 5890, 5891,
   5892, 5893, and 5894. They are referred to here as IDNA2003 and
   IDNA2008, respectively.

According to RFC 5890, however, the IDNA2008-Mapping document (RFC 5895)
is also part of IDNA2008.

2)

Guideline 2 in the document says:

    No code point permitted in IDNA2003 but disallowed in IDNA2008 will
    be accepted for registration regardless of the extent to which such
    code points appear in names registered prior to the protocol
    revision.

This requirement is under-specified.  One code point may be permitted in
IDNA2008 with one Unicode version and disallowed with another.  For
example, IDNA2008 with Unicode 5.2 permits the code point U+19DA while
IDNA2008 with Unicode 6.0 disallows the code point.

One possible solution: Qualify "disallowed in IDNA2008" as "disallowed
in IDNA2008 with some Unicode version later than or equal to 5.2.0".

3)

Guideline 4 refers to "all code point listings".  It wasn't immediately
clear to me what this refered to, but I guess it refers exclusively to
the code point lists in bullet 3?  It may help to clarify this.

4)

Guideline 6 uses the expression "code points that are prohibited by
IDNA2008" which is under-specified for the reason explained in 1).

Thanks,
Simon