--On Monday, January 23, 2017 22:50 +0100 Patrik Fältström
<paf@xxxxxxxxxx> 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