Internationalized Domain Names in Applications (IDNA): Protocol
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' **)
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' **)
[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. 126.96.36.199. 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
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?