Skip to main content

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


(Lisa Dusseault)
(Ron Bonica)

No Objection

Lars Eggert
(Adrian Farrel)
(Dan Romascanu)
(Pasi Eronen)
(Ralph Droms)
(Robert Sparks)
(Ross Callon)
(Russ Housley)

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

Lars Eggert
No Objection
Lisa Dusseault Former IESG member
Yes ()

Ron Bonica Former IESG member
Yes ()

Adrian Farrel Former IESG member
No Objection
No Objection ()

Alexey Melnikov Former IESG member
No Objection
No Objection (2009-12-27)
[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.  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

              The Unicode Consortium, "Unicode Technical Standard #18:
              Unicode Regular Expressions", May 2005,

              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.
Dan Romascanu Former IESG member
No Objection
No Objection ()

Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2010-01-07)
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.
Pasi Eronen Former IESG member
No Objection
No Objection ()

Ralph Droms Former IESG member
No Objection
No Objection ()

Robert Sparks Former IESG member
No Objection
No Objection ()

Ross Callon Former IESG member
No Objection
No Objection ()

Russ Housley Former IESG member
No Objection
No Objection ()

Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection (2010-01-06)
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?