Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>

[Harald Alvestrand <[e-mail]>]

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 [e-mail] to
> mustafa.akıncı@example.com (although [e-mail] 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.