Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
draft-ietf-idnabis-defs-13
Yes
(Jari Arkko)
(Lisa Dusseault)
(Ron Bonica)
No Objection
(Adrian Farrel)
(Dan Romascanu)
(Lars Eggert)
(Magnus Westerlund)
(Pasi Eronen)
(Robert Sparks)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 13 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Unknown
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(2009-12-27)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2010-01-02)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2010-01-06)
Unknown
Section 2.3.1, para 4 s/(see U-labels turns out to be/(see U-labels) turns out to be/