Review of draft-ietf-idnabis-protocol-14

[Paul Hoffman]

Section 3.2.1 says:
   IDNA applies only to domain names in the NAME and RDATA fields of DNS
   resource records whose CLASS is IN.
It would be good for the DNS-centric folks in the WG to verify that they think that this restriction is correct. Are there really no other fields where domain labels would appear?

Section 5.4 assumes that an application knows the version of Unicode that is being used in the application. We should state that assumption in 5.4 or maybe further up near the beginning of section 5.

The paragraph in section 5.4 that starts "This test may..." is out of date because the rules in the Bidi document no longer do inter-label checking. The whole paragraph can be removed.

In the light of this, does the WG want to change the requirement level for checking Bidi on lookup from SHOULD to MUST? Given the above, I see no reason why not.


Editorial:
. . .
   Appendix A discusses the relationship between this specification and
   the earlier version of IDNA (referred to here as "IDNA2003") and the
s/) and the/). The/
   rationale for these changes, along with considerable explanatory
   material and advice to zone administrators who support IDNs is
   provided in another document, [IDNA2008-Rationale].

   IDNA works by allowing applications to use certain ASCII string
   labels (beginning with a special prefix) to represent non-ASCII name
   labels.  Lower-layer protocols need not be aware of this; therefore
   IDNA does not changes any infrastructure.  In particular, IDNA does
s/changes/change/
   not depend on any changes to DNS servers, resolvers, or protocol
   elements, because the ASCII name service provided by the existing DNS
   can be used for IDNA.
. . .
   The candidate Unicode string MUST NOT contain characters in the
s/characters in/any character from/
   "DISALLOWED" and "UNASSIGNED" lists specified in [IDNA2008-Tables].
. . .
   In addition to the rules and tests above, there are many reasons why
   a registry could reject a label.  Registries at all levels of the
   DNS, not just the top level, establish policies about label
s/establish/may establish/
   registrations.  Policies are likely to be informed by the local
. . .
   number -- 2.2.3 as of Defs-09]].  Putative labels with any of the
   following characteristics MUST BE rejected prior to DNS lookup:
s/MUST BE/MUST be/