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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf