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

Harald Alvestrand <> Mon, 15 February 2016 15:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C48721B3339 for <>; Mon, 15 Feb 2016 07:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yaRHolMNI8bZ for <>; Mon, 15 Feb 2016 07:33:58 -0800 (PST)
Received: from ( [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DE3E1B3334 for <>; Mon, 15 Feb 2016 07:33:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F26E87C76C7 for <>; Mon, 15 Feb 2016 16:33:56 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QVKcp4-o5Raf for <>; Mon, 15 Feb 2016 16:33:56 +0100 (CET)
Received: from (unknown [IPv6:2620:0:1043:1:40bb:4ed6:62f9:825a]) by (Postfix) with ESMTPSA id 3440B7C76A9 for <>; Mon, 15 Feb 2016 16:33:56 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
References: <> <> <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Mon, 15 Feb 2016 16:33:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Feb 2016 15:34:00 -0000

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@EXAMPLE.COM to
> mustafa.akıncı (although 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.