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

"Patrik Fältström " <paf@frobbit.se> Mon, 23 January 2017 23:16 UTC

Return-Path: <paf@frobbit.se>
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 C00C5129406; Mon, 23 Jan 2017 15:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level:
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] 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 ns2JI4tWrAI6; Mon, 23 Jan 2017 15:16:46 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DC012940C; Mon, 23 Jan 2017 15:16:45 -0800 (PST)
Received: from [192.168.220.238] (unknown [31.15.50.66]) by mail.frobbit.se (Postfix) with ESMTPSA id D0F6920105; Tue, 24 Jan 2017 00:16:40 +0100 (CET)
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" <paf@frobbit.se>
To: "John C Klensin" <john-ietf@jck.com>
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
Date: Tue, 24 Jan 2017 00:16:40 +0100
Message-ID: <C0BF2DD2-B173-48D7-873C-A69245B020F9@frobbit.se>
In-Reply-To: <03F1CB475309958D48B54060@PSB>
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> <03F1CB475309958D48B54060@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_C4B64475-C138-4454-8B8C-DBDB8F35C77A_="; micalg=pgp-sha1; protocol="application/pgp-signature"
X-Mailer: MailMate (2.0BETAr6072)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/HQEcvjatNkCPnnZWP_kmsJ1CRik>
Cc: spasm@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>, draft-ietf-lamps-eai-addresses@ietf.org, ietf@ietf.org, lamps-chairs@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:16:49 -0000

On 24 Jan 2017, at 0:10, John C Klensin wrote:

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

True, thanks.

   paf

> 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