Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

John C Klensin <john-ietf@jck.com> Mon, 23 January 2017 23:10 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3181293F5; Mon, 23 Jan 2017 15:10:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 Q9yiBoPhGQ6U; Mon, 23 Jan 2017 15:10:39 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3371293F3; Mon, 23 Jan 2017 15:10:38 -0800 (PST)
Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1cVnkx-000CVY-3e; Mon, 23 Jan 2017 18:10:35 -0500
Date: Mon, 23 Jan 2017 18:10:28 -0500
From: John C Klensin <john-ietf@jck.com>
To: Patrik Fältström <paf@frobbit.se>, Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Message-ID: <03F1CB475309958D48B54060@PSB>
In-Reply-To: <14A8995E-D7BF-4994-98F8-875CCED02085@frobbit.se>
References: <148460673104.22580.543094070599448665.idtracker@ietfa.amsl.com> <E61E7383DDD7A81671C398EC@JcK-HP5.jck.com> <61a0a970-cab2-3f21-7f05-691b6d6ab53f@isode.com> <14A8995E-D7BF-4994-98F8-875CCED02085@frobbit.se>
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
X-SA-Exim-Connect-IP: 198.252.137.70
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/VNe5WyuQjB_MAIx3R_D3ui9xuPY>
Cc: spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-eai-addresses@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Jan 2017 23:10:40 -0000


--On Monday, January 23, 2017 22:50 +0100 Patrik Fältström
<paf@frobbit.se> wrote:

>...
> OLD:
> 
> In setup for SmtpUtf8Mailbox, the email address local-part
> MUST be converted to UTF-8 if it is not already.
> 
> NEW:
> 
> In setup for SmtpUtf8Mailbox, the email address local-part
> MUST be converted to UTF-8 if it is not already. The
> local-part MUST NOT be transformed in any way, for example by
> doing case folding or normalization of any kind.

That reinvents the same apparent contradiction I was concerned
about.  RFC 6530 and 6531 require (there is a MUST) in Section
1.1 of 6531 and maybe elsewhere) that all relevant strings,
including Mailboxes, be in UTF-8 (noting that an all-ASCII
string with ASCII encoded in the usual octet form with a leading
zero bit followed by (seven-bit) ASCII is a string encoded in
UTF-8.     So there is no such thing as a SMTPUTF8-valid
local-part that is not in UTF-8 and no conversion can possibly
be needed.   If it is needed, then this I-D is allowing
local-part strings that do not conform to 6530/6531 (or 5321 for
that matter).  If that were the intent, a _lot_ more discussion
is needed, if only because I believe there are CCSs floating
around that do not have obvious and unique transformations to
Unicode (which would be a necessary step to get them to [Unicode
in] UTF-8).

Then you say "MUST NOT be transformed in any way", which is
correct, but "conversion to UTF-8", required by the previous
sentence, is "transformed in [some] way".

One way out of this would be to say 

NEW2:

	In setup for SmtpUtf8Mailbox, the email address
	local-part MUST conform to the requirements of RFC 6530
	and 6531, including already being a string in UTF-8
	form.  In particular, the local-part MUST NOT be
	transformed in any way, such as by doing case folding or
	normalization of any kind.

That accomplishes two things:

(i) It avoids the apparent contradiction.

(ii) It puts the responsibility for the restriction on the
SMTPUTF8 specs and makes it clear that this I-D is just carrying
those restrictions over.  IMO, the less this spec appears to be
imposing its own restrictions, the better off we will all be.
That is especially important if there is even the vaguest of
chances that we might eventually decide that unnormalized
strings, or strings with no restrictions on the code points
(other than those ASCII-repertoire characters prohibited by RFC
5321), are a terrible idea and either deprecate or recommend
against their use.    If this part of this document is strictly
dependent on 6531 and its successors, we avoid the need to
untangle it to reflect that change and the risk of having it be
contradictory to the mail spec.

best,
    john