Internationalized Domain Names in Applications (IDNA): Protocol
draft-ietf-idnabis-protocol-18

[Ballot comment]
Here's a suggestion from a review by Christian Vogt:

- Section 3.1, third bullet, refers to label requirements in sections 4
  and 5.  Suggest making this more specific and refer to sections 4.2
  and 5.4, respectively.  Sections 4 and 5 specify protocols, and the
  label requirements are only part of this.

[Ballot discuss]
From section 4.2.1:

  If only an A-label was provided and the conversion to a U-label is
  not performed, the registry MUST still verify that the A-label is
  superficially valid, i.e., that it does not violate any of the rules
  of Punycode [RFC3492] encoding such as the prohibition on trailing
  hyphen-minus, appearance of non-basic characters before the
  delimiter, and so on.

From my reading, it appears that the remainder of section 4 (excepting 4.5) does not
apply if the registry chooses not to perform the conversion to a U-label.  Is that
correct?  If so, it should probably be stated explicitly.

[Ballot comment]
[I might have more comments later, sending the first batch now.]

3.1.  Requirements

  2.  Labels MUST be compared using equivalent forms: either both
      A-Label forms or both U-Label forms.  Because A-labels and
      U-labels can be transformed into each other without loss of
      information, these comparisons are equivalent.  A pair of
      A-labels MUST be compared as case-insensitive ASCII (as with all
      comparisons of ASCII DNS labels).  U-labels must be compared

s/must/MUST ?

      as-is, without case-folding or other intermediate steps.

4.2.3.3.  Contextual Rules

  The Unicode string MUST NOT contain any characters whose validity is
  context-dependent, unless the validity is positively confirmed by a
  contextual rule.  To check this, each code-point marked as CONTEXTJ
  and CONTEXTO in [IDNA2008-Tables] MUST have a non-null rule.  If such
  a code-point is missing a rule, it is invalid.  If the rule exists
  but the result of applying the rule is negative or inconclusive, the
  proposed label is invalid.

Can you give an example of inconclusive result of a contextual rule?

5.2.  Conversion to Unicode

  The string is converted from the local character set into Unicode, if
  it is not already in Unicode.  Depending on local needs, this
  conversion may involve mapping some characters into other characters
  as well as coding conversions.

Does mapping only talks about conversion from a character set to Unicode,
or also about Unicode character mapping? If the latter, the section
title is slightly wrong and the description above might not be precise enough.

  Those issues are discussed in
  [IDNA2008-Mapping] and the mapping-related sections (Sections 4.4, 6,
  and 7.3) of [IDNA2008-Rationale].  The result MUST be a Unicode
  string in NFC form.


10.1.  Normative References

  [Unicode-RegEx]
              The Unicode Consortium, "Unicode Technical Standard #18:
              Unicode Regular Expressions", May 2005,
              .

  [Unicode-Scripts]
              The Unicode Consortium, "Unicode Standard Annex #24:
              Unicode Script Property", February 2008,
              .

These references don't seem to be used.


10.2.  Informative References

  [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

This is also not referenced.