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

John C Klensin <john-ietf@jck.com> Mon, 15 February 2016 16:47 UTC

Return-Path: <john-ietf@jck.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 4A0721A1B96 for <ietf@ietfa.amsl.com>; Mon, 15 Feb 2016 08:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] autolearn=no
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 63IldJIFcf94 for <ietf@ietfa.amsl.com>; Mon, 15 Feb 2016 08:47:01 -0800 (PST)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8000C1A044E for <ietf@ietf.org>; Mon, 15 Feb 2016 08:47:01 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aVMIb-0002y3-Hv; Mon, 15 Feb 2016 11:46:57 -0500
Date: Mon, 15 Feb 2016 11:46:52 -0500
From: John C Klensin <john-ietf@jck.com>
To: Harald Alvestrand <harald@alvestrand.no>, ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt>
Message-ID: <28459DA6030B0DF750F2CD57@JcK-HP5.jck.com>
In-Reply-To: <56C1EFE3.4020405@alvestrand.no>
References: <56C09764.1020700@hagfish.name> <3E8BDD1E0C94F17DFD06C92C@JcK-HP5.jck.com> <56C18E14.8060608@hagfish.name> <56C1EFE3.4020405@alvestrand.no>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/5t2xJ8qZs7Nl6KXA_kWiycvCTZY>
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 16:47:03 -0000


--On Monday, February 15, 2016 4:33 PM +0100 Harald Alvestrand
<harald@alvestrand.no> wrote:

> 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.

Indeed.

However, that is exactly the decision we made with IDNA (both
the "2003" and "2008" versions and, as there, may be
justification for really strong advice for treating email
addresses (both local and domain parts) as lower-case only.   

Harald, I am confident you know all of this, but others may
not...  The idea of requiring that mailbox names be treated as
all lower case was discussed during the work leading up to RFC
1123 and again in DRUMS (pre-2821).  The community reached what
appeared to me as fairly strong consensus that we just couldn't
do it.  Part of the problem was that, at the time 821 was
written (and maybe as late as the time of DRUMS) there were
still systems around that operated upper-case-only and had only
the vaguest idea what lower case was.  Another part was that
Unix (and Multics) and some of their successors were very
case-sensitive in general: "foo" and "Foo" and "foO" were
unambiguously three different names.

Because of that history and consensus, the strong suggestions in
5321 are about as far as one is going to get as far as
restrictions/ recommendations on the mailbox names themselves
and the "don't try to guess" rule probably isn't going anywhere.

In retrospect, we dodged a bullet because, for mailbox local
parts, ARNE does not, in terms of anything a sender is allowed
to predict, match arne.  That BLÅBÆR doesn't match blåbær
may still be a surprise to some, but it is not more or a
surprise.

>From that perspective, the problem facing DANE is that either
the basic "if they are not identical, they don't match" rules is
applied or there is a need to invent rules different from the
email rules and that de facto modify the email rules by
restricting the syntax of a mailbox if there is any possibility
a DANE DNS record will be used with it.  Nothing I'm aware of
(other than probably the WG Charter) prohibits DANE from
proposing an update to 5321 and 6530ff, but the history (and
probable side-effects that no one has tried to analyze) predicts
that the idea won't easily get community consensus.

     john