On 02/15/2016 09:36 AM, E Taylor wrote: > Hello, > > Thank you, John, for your detailed comments on the i18n aspect of this > draft, which I admit I hadn't fully considered. I think you're right > that, whatever approach is taken, it would make sense to add a short > "Internationalization Considerations" section to state what the expected > interaction is between this specification and non-ASCII addresses. > > More comments inline below: > >> Temporarily and for purposes of discussion, assume I agree with >> the above as far as it goes (see below). Given that, what do >> you, and the systems you have tested, propose to do about >> addresses that contain non-ASCII characters in the local-part >> (explicitly allowed by the present spec)? Note that lowercasing >> [1] and case folding are different and produce different results >> and that both are language-sensitive in a number of cases, what >> specifically do you think the spec should recommend? > I have not seen any specific examples of software which unintentionally > converts characters to uppercase (although I can readily imagine such > bugs/features), so I'm prepared to assume that the lowercasing logic can > be safely limited to just the input strings which include only ASCII > characters. My idea was for the client to make a reasonable effort to > correct for a plausible (but rare) problem, so for the purposes of an > experiment I think it is acceptable if this correction does not try > anything more clever, like converting MUSTAFA.AKINCI@xxxxxxxxxxx to > mustafa.akıncı@example.com (although mustafa.akinci@xxxxxxxxxxx should > be tried). Note that the user understandability of "only lowercase if it's all ASCII" is zero. If ARNE matches arne, but BLÅBÆR doesn't match blåbær, any user from an extended-ASCII country (which is *all* Latin script using countries, even though the non-ASCII variants in English are rarely used) will be mighty confused.