Summary: This draft is almost ready for publication as Proposed Standard but I have a few comments. Minor ===== * Section 2.3.1 Page 8 ==> "XN-labels are further divided in those whose remaining characters (after the "xn--") are valid output of the Punycode algorithm." ... and what else? ==> U-labels are used before their definition ==> Since -- is already implied for R-LDH labels shouldn't this text "Labels within the class of R-LDH labels that are not prefixed with "xn--" are also not valid IDNA-labels." be replaced with "Labels within the class of R-LDH labels that are not prefixed with "xn" are also not valid IDNA-labels." * Section 2.3.2.4 "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." Given that the transformation in the other direction (A-label to U-label and then compare) is going to give the same result, is there a specific reason for picking this direction for the transformation? i.e. is Punycode encoding more efficient than decoding? * 4.4 Security considerations Should this section mention issues with visually similar domain names causing issues with non-matching certificates. If this happens the user is probably going to get very confused.