On 24 Jan 2017, at 0:10, John C Klensin wrote: > --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 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
Attachment:
signature.asc
Description: OpenPGP digital signature