Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
Note: This ballot was opened for revision 13 and is now closed.
(Jari Arkko) Yes
(Ron Bonica) Yes
(Lisa Dusseault) Yes
(Ross Callon) No Objection
(Ralph Droms) No Objection
Comment (2010-01-02 for -** No value found for 'p.get_dochistory.rev' **)
I think it would improve the clarity of draft-ietf-idnabis-defs to check on the meaning of the phrase "these documents" throughout and replace, as appropriate, "these documents" with "the IDNA2008 documents". For example, in this sentence from the third paragraph of section 2.2: These documents generally use the term "domain name". it wasn't clear to me whether "these documents" refer to RFC 103 or the IDNA2008 documents.
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' **)
1.3. Roadmap of IDNA2008 Documents o A specification [IDNA2008-Tables] of the categories and rules that identify the code points allowed in a label written in native character form (defined more specifically as a "U-label" in Section 126.96.36.199 below), based on Unicode 5.1 [Unicode51] code [IDNA2008-Tables] is using Unicode 5.2 now, so the two documents need to be consistent. point assignments and additional rules unique to IDNA2008. The Unicode-based rules are expected to be stable across Unicode updates and hence independent of Unicode versions. That specification obsoletes RFC 3941 and IDN use of the tables to which it refers. It is referred to informally in other documents in the set as "Tables". 2.3.1. LDH-label A consequence of the restrictions on valid characters in the native Unicode character form (see U-labels turns out to be that mixed-case Missing ")" after "U-labels"? annotation, of the sort outlined in RFC 3492 Appendix A [RFC3492], is never useful. Therefore, since a valid A-label is the result of Punycode encoding of a U-label, A-labels should be produced only in lower case, despite matching other (mixed- or upper-case) potential labels in the DNS. 188.8.131.52. IDNA-valid strings, A-label, and U-label o A "U-label" is an IDNA-valid string of Unicode characters, in normalization form NFC and including at least one non-ASCII character, expressed in a standard Unicode Encoding Form (such as UTF-8). What is "standard" here? Are non-UTF-8 encodings relevant for IDNA documents? A.12. Version -11 o Adjusted Acknowledgments to remove Mark Davis's name, per his request and advice from IETF Trust Counsel. Some clarification of what has happened here would be helpful (and how is this relevant to IETF Trust Counsel).
(Tim Polk) No Objection
Comment (2010-01-06 for -** No value found for 'p.get_dochistory.rev' **)
Section 2.3.1, para 4 s/(see U-labels turns out to be/(see U-labels) turns out to be/