Skip to main content

Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
draft-ietf-idnabis-defs-13

Yes

(Jari Arkko)
(Lisa Dusseault)
(Ron Bonica)

No Objection

Lars Eggert
(Adrian Farrel)
(Dan Romascanu)
(Magnus Westerlund)
(Pasi Eronen)
(Robert Sparks)
(Ross Callon)
(Russ Housley)

Note: This ballot was opened for revision 13 and is now closed.

Lars Eggert No Objection

(Jari Arkko; former steering group member) Yes

Yes ()

                            

(Lisa Dusseault; former steering group member) Yes

Yes ()

                            

(Ron Bonica; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2009-12-27)
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

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) No Objection

No Objection ()

                            

(Ralph Droms; former steering group member) No Objection

No Objection (2010-01-02)
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

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) No Objection

No Objection (2010-01-06)
Section 2.3.1, para 4
s/(see U-labels turns out to be/(see U-labels) turns out to be/