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

ned+ietf@mauve.mrochek.com Mon, 15 February 2016 19:58 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
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 DD8521ACD82 for <ietf@ietfa.amsl.com>; Mon, 15 Feb 2016 11:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 DaGfO9j29kZl for <ietf@ietfa.amsl.com>; Mon, 15 Feb 2016 11:58:17 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF43D1AC443 for <ietf@ietf.org>; Mon, 15 Feb 2016 11:58:17 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PWPNY7XTI8004FO1@mauve.mrochek.com> for ietf@ietf.org; Mon, 15 Feb 2016 11:53:14 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="US-ASCII"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PWLL3KZ0CW00008P@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Mon, 15 Feb 2016 11:53:09 -0800 (PST)
From: ned+ietf@mauve.mrochek.com
Message-id: <01PWPNY62N1I00008P@mauve.mrochek.com>
Date: Mon, 15 Feb 2016 11:45:00 -0800
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
In-reply-to: "Your message dated Mon, 15 Feb 2016 18:46:13 +0100" <56C20EE5.4060009@alvestrand.no>
References: <56C09764.1020700@hagfish.name> <3E8BDD1E0C94F17DFD06C92C@JcK-HP5.jck.com> <56C18E14.8060608@hagfish.name> <56C1EFE3.4020405@alvestrand.no> <28459DA6030B0DF750F2CD57@JcK-HP5.jck.com> <56C20EE5.4060009@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/CihNrMDpeIW6-PVKKFQ2UGR6P7o>
Cc: ietf@ietf.org
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 19:58:19 -0000

> A possible way out (strawman!!!!) would be to say:

> - All recipient participants in the experiment MUST agree to ignore case
> differences in mailbox names. This has no effect on non-participants, so
> we can possibly get consensus for that.

> - All code in the experiment MUST use a particular algorithm to generate
> the LHS lookup key
> (I would suggest toLowerCase(NFC(string) in the C locale) off the top of
> my head - but one could also argue for caseFold(NFC(string)) or
> NFC(caseFold(string)) - and the people choosing had better know the
> difference)

I would strongly recommend that if you're going to do this, you do it using the
same case-folding and normalization algoritms that are used for IDNs. (You can
skip the prep stuff and punycode.)

My reasoning here is that if you have support for EAI you're likely 
to have IDN support libraries lying around. Libraries which may or may not
support other normalization and case-folding algorithms.

> The case operations referenced are in Unicode 8.0.0 section 5.18 - I
> *strongly* recommend actually reading that chapter, and not making the
> (invalid) assumption that calling toLower() in some random library will
> actually do something compatible with this.

Whereas an IDN library will have something you should be able to trust.

> I don't think anything less precise has a chance of being interoperable.

Agreed.

				Ned