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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]