Last Call: draft-ietf-idnabis-protocol (Internationalized Domain Names in Applications (IDNA): Protocol) to Proposed Standard

[SM]

At 09:27 01-10-2009, The IESG wrote:
>The IESG has received a request from the Internationalized Domain Names
>in Applications, Revised WG (idnabis) to consider the following document:
>
>- 'Internationalized Domain Names in Applications (IDNA): Protocol '
>    <draft-ietf-idnabis-protocol-16.txt> as a Proposed Standard

It is easier for me to comment on all six documents in one message as 
they should be read as a collection.  The order in which the 
documents can be read is also relevant if a person is not familiar 
with the IDNABIS work.  The political overtones throughout the 
discussions about some of the technical issues have not been missed. 
:-)  I note that a document published in 1954 was used as a reference 
in an argument about usage of some characters for a particular 
language.  The people speaking it as their native language do not 
know about the characters and would not recognize them as valid 
characters if they see them on printed material.

It is interesting to see how the different languages and language 
specific rules are encompassed in a protocol.  Although the documents 
are not easy to read compared to the usual fare of I-Ds, I found them 
well written.

In Section 3 of draft-ietf-idnabis-rationale-13:

   "For many scripts, the use of variant techniques such as
    those as described in RFC 3843 [RFC3743]"

That should have been RFC 3743.

In Section 8.2:

   "DNS Security (DNSSEC) [RFC2535] is a method for supplying"

RFC 2535 is obsoleted by RFC 4033.

draft-ietf-idnabis-defs-11 obsoletes RFC 
3490.  draft-ietf-idnabis-protocol-16 obsoletes RFC 3490 and 
3491.  That looks like a mistake.

In Section 2.3.2.1 of draft-ietf-idnabis-defs-11:

   "Second, expansion of the A-label form to a U-label may produce strings
    that are much longer than the normal 63 character DNS limit (potentially
    up to 252 characters) due to the compression efficiency of the Punycode
    algorithm."

Shouldn't that be 63 octets?

In Section 2.3.2.4:

   "The IDNA notion of equivalence is an extension of that older
    notion but, because there is no mapping, the only equivalents are"

There's draft-ietf-idnabis-mappings-04.

In Section 4.2 of draft-ietf-idnabis-defs-11:

   "Labels associated with the DNS have traditionally been limited to 63
    characters by the general restrictions in RFC 1035"

That should be 63 octets.

   "A fully-qualified domain name containing several such
    labels can obviously also exceed the nominal 255 character limit for
    such names."

That should be the nominal 255 octet limit.

In Section 5 of draft-ietf-idnabis-bidi-06:

      "Wildcards create the odd situation where a label is "valid" (can
       be looked up successfully) without the zone owner knowing that
       this label exists.  So an owner of a zone whose name starts with a
       digit and contains a wildcard has no way of controlling whether or
       not names with RTL labels in them are looked up in his zone."

I suggest a minor change to keep it in sync with the definitions document:

       Wildcards create the odd situation where a label is "valid" (can
       be looked up successfully) without the zone administrator knowing that
       this label exists.  So the administrator of a zone whose name 
starts with
       a digit and contains a wildcard has no way of controlling whether or
       not names with RTL labels in them are looked up in the zone.

Regards,
-sm