Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
RFC 5890

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' **)
No email
send info
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.

(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' **)
No email
send info
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).

(Tim Polk) No Objection

Comment (2010-01-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Section 2.3.1, para 4
s/(see U-labels turns out to be/(see U-labels) turns out to be/

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Magnus Westerlund No Objection