Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
draft-ietf-idnabis-defs-13
Yes
No Objection
Note: This ballot was opened for revision 13 and is now closed.
Lars Eggert No Objection
(Jari Arkko; former steering group member) Yes
(Lisa Dusseault; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
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 2.3.2.1 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.
2.3.2.1. 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).
(Dan Romascanu; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
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[45] or the IDNA2008 documents.
(Robert Sparks; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
Section 2.3.1, para 4 s/(see U-labels turns out to be/(see U-labels) turns out to be/