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

Harald Alvestrand <harald@alvestrand.no> Mon, 15 February 2016 15:34 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48721B3339 for <ietf@ietfa.amsl.com>; Mon, 15 Feb 2016 07:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaRHolMNI8bZ for <ietf@ietfa.amsl.com>; Mon, 15 Feb 2016 07:33:58 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE3E1B3334 for <ietf@ietf.org>; Mon, 15 Feb 2016 07:33:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id F26E87C76C7 for <ietf@ietf.org>; Mon, 15 Feb 2016 16:33:56 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVKcp4-o5Raf for <ietf@ietf.org>; Mon, 15 Feb 2016 16:33:56 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:40bb:4ed6:62f9:825a]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3440B7C76A9 for <ietf@ietf.org>; Mon, 15 Feb 2016 16:33:56 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
To: ietf@ietf.org
References: <56C09764.1020700@hagfish.name> <3E8BDD1E0C94F17DFD06C92C@JcK-HP5.jck.com> <56C18E14.8060608@hagfish.name>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <56C1EFE3.4020405@alvestrand.no>
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: <56C18E14.8060608@hagfish.name>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/RnKaVx2C7hpygbf5PtYqXXKgyxU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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ı@example.com (although mustafa.akinci@example.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.