On Thu, Apr 23, 2015 at 12:37:35AM +0100, Jeremy Harris wrote:
> > That's rather unwise IMHO. The "xn--" prefix is only applicable
> > to domain names (IDNA), and should not be used to encode localparts.
>
> Not proven.
There's not much to prove. You've made up an encoding for localparts
for which there's no expectation that any remote domains will treat
the encoded name as equivalent to the UTF-8 original. Since the
encoding applies to recipients in remote domains, interoperability
demans that such an encoding either be standard, or at least a
de-facto standard.
The new "xn--" encoding for localparts is neither.
> > If you're going to encode, at least use "xl--", which is already
> > in use another MTA.
>
> Why?
> You appear to be saying "do it purely because that other MTA
> does it".
Actually, I am saying "don't do it", or if you do, try to at least
interoperate with some sort of established practice. The IDNA
encoding *is* just for domains.
Note that the normalization rules for domain names prior to UTF-8
encoding are not the same as for localparts. The Microsoft encoding
normalizes localparts differently.
This is a subtle issue, and I don't think it would be helpful for
each MTA to just go off in its ad-hoc direction. We should also
find what Microsoft's future plans are with respect to localpart
encoding.
PLEASE do not create yet another ad-hoc encoding that is unlikely
to be understood by the target system. Write an I-D that proposes
your encoding and see how it is received... Don't impleement it
unless you can get some consensus behind it.
IETF discussion on this topic raised concernts that "xn--" (or
"xl--") is not a reserved prefix in localparts, and introducing
the encoding now might break some existing addresses.
This thread does not appear to resolve the issue:
http://www.ietf.org/mail-archive/web/ima/current/msg05352.html
--
Viktor.
