comments on drafts
james.mitchell at ausregistry.com.au
Wed Oct 14 01:06:39 CEST 2009
Comments on draft-ietf-idnabis-defs-11
A consequence of the restrictions on valid characters in U-labels
turns out to be that mixed-case 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 always happen to be only lower case, despite matching other
(mixed- or upper-case) potential labels in the DNS.
A-labels do not _always_ happen to be lower case, unless we also want
to update RFC 3942.
punycode_encode_implementation_1(café) = caf-dma
punycode_encode_implementation_2(café) = caf-DMA
punycode_decode(caf-dma) = café
punycode_decode(caf-DMA) = café
A consequence of the punycode algorithm turns out that U-labels containing
the characters a-z produce A-labels matching other FAKE A-labels in the DNS.
o Equivalence between a U-label and an A-label determined by
translating the U-label form into an A-label form and then testing
for an exact match between the A-labels.
Equivalence between a U-label and an A-label determined by translating the
U-label form into an A-label form and then testing using normal DNS matching
One cannot determine the implementation of punycode used to translate the
U-label, for example comparison between caf-DMA and punycode_encode(café) = caf-dma.
It is stated at the beginning of this section that equivalence is defined in
terms of A-labels in a case-independent manner.
Comments on draft-ietf-idnabis-protocol-16
If the input to this procedure appears to be an A-label (i.e., it
starts in "xn--"), the lookup application MAY attempt to convert it
to a U-label, first ensuring that the A-label is entirely in lower
case, and apply the tests of Section 5.4 and the conversion of
Section 5.5 to that form. If the label is converted to Unicode
(i.e., to U-label form) using the Punycode decoding algorithm, then
the processing specified in those two sections MUST be performed, and
the label MUST be rejected if the resulting label is not identical to
the original. See Section 8.1 of [IDNA2008-Rationale] for additional
discussion on this topic.
The label MUST be rejected is the resulting label does not match the
Again, one cannot determine the implementation of punycode used to produce
Comments on draft-ietf-idnabis-bidi-06
The following guarantees can be made based on the above:
In a domain name consisting of only labels that pass the test, the
requirements of Section 3 are satisfied. Note that even LTR
labels and pure ASCII labels have to be tested.
In a domain name consisting of only LDH-labels and labels that
pass the test, the requirements of Section 3 are satisfied as long
as a label that starts with an ASCII digit does not come after a
No guarantee is given for other combinations.
The second guarantee contradicts the test (no label can begin with a digit)
and should be removed. The remaining text adds little value beyond what was
stated at the beginning of the section, with the exception of explicitly
stating that LTR and ASCII labels have to be tested.
I suggest the guarantee text is removed and the following...
2. The BIDI Rule
The following rule, consisting of six conditions, applies to labels
in BIDI domain names. The requirements that this rule satisfies are
described in Section 3. All the conditions must be satisfied for the
rule to be satisfied.
is changed to..
2. The BIDI Rule
The following rule, consisting of six conditions, applies to all labels
in BIDI domain names, including LTR and pure ASCII labels.
The requirements that this rule satisfies are described in Section 3.
All the conditions must be satisfied for the rule to be satisfied.
More information about the Idna-update