comments on drafts

[James Mitchell]

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
rules.

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
original.

Again, one cannot determine the implementation of punycode used to produce
the A-label.



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
   right-to-left label.
   
   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.


Regards,

James