On 23 Jan 2017, at 14:40, Alexey Melnikov wrote: > Thank you for your thorough review! My comments/answers below: I have a few comments as well. Basically I agree with what John writes, but let me add some additional spice. >> (3) A MUST NOT requirement on the use of A-labels has often >> been problematic because, as far as a protocol that does not >> support IDNA is concerned, they are ordinary labels conforming >> to the "preferred syntax" of RFC 1034/1035 (commonly known as >> "LDH syntax"). As important, it is easily possible to construct >> strings that look (lexically) like A-labels but are actually not >> A-labels. If the desire is to prevent the use of anything but >> normal (i.e., not IDNA) LDH labels and U-labels, the restriction >> that is probably needed is either "no label starting in 'xn--'" >> or "no label starting in two letters followed by two >> hyphen-minus characters". >> >> Requiring NR-LDH restrictions >> probably solves the problem (although I'm not sure what "solely >> ASCII character labels" means -- see (2) above) but requires >> much more specific knowledge of the IDNA2008 protocol set >> (particularly RFC 5890 in this case) than I predict readers of >> this document will have. See RFC 5890 and 5894 for more >> discussion on this issue and other recent correspondence about >> confusing and contradictory usage of "IDN" and "IDNA" and the >> associated risks for additional details and risk descriptions. > > I think this needs to be discussed a bit more in the LAMPS WG, but you have a good point here. I would extend to 'starting in "XX--" where X can be any ascii character" because who knows whether we need a completely different prefix one day. Or you should explicitly note that ascii-only mailboxes do imply the litteral value and those strings MUST NOT be interpreted as A-Labels. >> (5) It may be worth being explicit that there is no >> normalization or case-folding permitted with the local-part. >> The current text does say that but it may not be obvious to >> someone not thoroughly familiar with other specs. > > Do you have a suggestion where this should be clarified? What about here in section 4 (which I presume is referenced implicitly, or similar places where it is noted some transformation is done (between A-Labels and U-Labels): OLD: In setup for SmtpUtf8Mailbox, the email address local-part MUST be converted to UTF-8 if it is not already. NEW: In setup for SmtpUtf8Mailbox, the email address local-part MUST be converted to UTF-8 if it is not already. The local-part MUST NOT be transformed in any way, for example by doing case folding or normalization of any kind. Patrik
Attachment:
signature.asc
Description: OpenPGP digital signature