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
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> E Taylor
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> E Taylor
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Harald Alvestrand
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Harald Alvestrand
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> ned+ietf
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Harald Alvestrand
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Keith Moore
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John R Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Stephen Farrell
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Stephen Farrell
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John Levine
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Paul Wouters
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> Viktor Dukhovni
- Re: Last Call: <draft-ietf-dane-openpgpkey-07.txt> John C Klensin