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

["Patrik Fältström " <[e-mail]>]

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

> --On Monday, January 23, 2017 22:50 +0100 Patrik Fältström <[e-mail]> 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