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(_dot_)AKINCI(_at_)EXAMPLE(_dot_)COM to
mustafa.akıncı@example.com (although
mustafa(_dot_)akinci(_at_)example(_dot_)com 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.