Internationalized Domain Names in Applications (IDNA): Protocol
RFC 5891

Note: This ballot was opened for revision 18 and is now closed.

(Ron Bonica) Yes

(Lisa Dusseault) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2010-01-07 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Alexey Melnikov No Objection

Comment (2009-12-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
[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,
              <http://www.unicode.org/reports/tr18/>.

   [Unicode-Scripts]
              The Unicode Consortium, "Unicode Standard Annex #24:
              Unicode Script Property", February 2008,
              <http://www.unicode.org/reports/tr24/>.

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.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2010-01-06)
No email
send info
Section 4.2.1 makes no statement regarding the input format U-label only.  Perhaps all
appropriate actions are described in 4.2.2 through 4.5?

(Dan Romascanu) No Objection

(Robert Sparks) No Objection