I refer to ASCII@xn--something
Here’s an example:
1.
I send an email to a pair of recipients: A-label@U-label
and ASCII@ASCII.
a.
(The former is EAI and the latter is non-EAI).
2.
Let’s assume that ASCII@ASCII is using the default email client on an iPhone.
3.
Both recipients Reply All.
4.
The iPhone email app does not reply to A-label@U-label – it replies to A-label@xn--something. That just happens to be how that app is currently designed.
a.
Now my mailbox contains 2 replies. The reply from the EAI user is to the same addresses that I originally used. The reply from the iPhone user contains a different address than I used.
5.
These addresses may be searched and sorted in my mailbox differently. That depends on how my mailbox app is coded.
a.
AFAIK there is no requirement that these addresses be treated as equivalent. Email is not DNS.
6.
In fact, one of these formats does not even have a name, which means that discussing this scenario requires the use of new terminology. I’ve been calling this format “IDN email”.
Does that make sense.
-----Original Message-----
From: Andrew Sullivan [mailto:ajs@anvilwalrusden.com]
Sent: Wednesday, February 17, 2016 6:46 PM
To: Mark Svancarek
Cc: ua-discuss@icann.org
Subject: Re: [UA-discuss] Review of UASG Charter
On Wed, Feb 17, 2016 at 11:32:19PM +0000, Mark Svancarek wrote:
> I still think it's important to distinguish between EAI and addresses in "local@punycode" formats, since many email clients treat those different in various scenarios. What would you call that format?
>
"Email address"?
I'm not quite sure what you mean by "local@" above, so two possible
interpretations:
An address of the form [utf-8]@xn--something is just user-hostile. In order for the local-part to be in utf-8, the EAI extensions need to be in place anyway; otherwise it won't work. So refusing to handle the IDNA server-part portion
is really just poor implementation (a polite way of saying "broken" ;-)).
If you mean the case where you have a non-EAI localpart with a server-part that has at least one A-label, well, that's just old-fashioned email. It's certainly true that the target server name is mystifying. That is frustrating, but
basically it's just an IDNA-unaware client. We designed IDNA the way we did precisely because there are so many clients out there that couldn't accept anything but LDH in a domain name slot (thats what the server-part is
-- see RFC 5890).
There are also clients -- the version of mutt I'm sending this mail with, IIRC -- that have IDNA-awareness compiled in, and they can display the server part as IDNA U-labels as opposed to A-labels. So if I registered crânkycanuck.ca
(which under CIRA's rules I think I could), you could send me mail at
ajs@xn--crnkycanuck-x7a.ca and (assuming I configured my MTA to take it) I'd see
ajs@crânkycanuck.ca.
_This_ use case is definitely different to EAI, because the SMTP extensions aren't needed. But it's just ordinary IDNA, I think -- all the transformations have to happen in the client at display time. I suppose there's an issue in
that such a client might try EAI when it attempts to send mail, and get a failure.
Best regards,
A
> -----Original Message-----
> From: ua-discuss-bounces@icann.org
> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan
> Sent: Monday, February 15, 2016 8:01 PM
> To: ua-discuss@icann.org
> Subject: Re: [UA-discuss] Review of UASG Charter
>
> I agree with the comment in the doc that "IDN email" isn't a thing.
> "Email using EAI" or "Email using address internationalization" or just "EAI" are correct.
>
> Otherwise, no comment.
>
> A
>
> On Tue, Feb 16, 2016 at 03:43:21AM +0000, Don Hollander wrote:
> > Further to the face-to-face meeting of the UASG Coordination group in January, the charter has been reviewed some fundamental changes are proposed.
> >
> > Instead of having a community of volunteers supported by a professional body, we’re proposing shifting to a professional body supported by volunteers. The UASG Coordination group will shift more toward governance than operation,
though volunteers are still very highly encouraged.
> >
> > Please find attached a red-lined revision to the Charter.
> >
> > Your comments would be welcome through the 22nd of February.
> >
> >
> > Don
> >
> >
>
>
>
> --
> Andrew Sullivan
--
Andrew Sullivan