Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalize

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

> --On Monday, January 23, 2017 22:50 +0100 Patrik Fältström 
> <paf(_at_)frobbit(_dot_)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

signature.asc
Description: OpenPGP digital signature