Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalize

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

signature.asc
Description: OpenPGP digital signature