Thanks for the comments. As an overall comment, I expect these slides to be used in a presentation by someone who is reasonably familiar with the technology and doesn't just read the slides aloud (aka Death by Powerpoint). The acronyms should all be in the notes if need be.
slide 12 MSA should be defined on previous slide. And I know it is ridiculously picky but it should be sending/receiving or sender/recipient MTAs.
Fixed to sender to match previous slide.
slide 14 the info about single and multiple scripts seems irrelevant.
It's come up, people ask why you can't just restrict identifiers to a single script.
The process of relating characters to values a computer can use is not mapping but character encoding.
Fixed.
slide 15 is correct that mapping relates characters to numbers. That is a different statement than the previous slide. (Those numbers are in turn encoded.)
Right, tightened up the text while I was there.
slide 17 should explain the U+hhhh nomenclature as a way of indicating the number assigned to a unicode character consisting of 4 to 6 hex digits appended to U+.
In the notes, but added it to the slide since people will doubtless see it.
slide 21. remove the comment that bidi text is often confusing to users. Seems pejorative.
It sure can when people deliberately mix scripts in addresses to confuse recipients.
slide 22- i dont understand the intent of saying domain can contain any TLD. Any part of the domain can be unicode. Maybe you mean any IDN.
Fixed to refer to IDNs.
23 - Is there a recommended practice for validating user parts?
Other than sending mail and seeing if anyone responds, no.
What should MUA do with a failed message? Anything different from other failures?
Nope.
24- fuzzy matching seems like a bad idea. Even case mapping is a bad idea when multiple languages are introduced, as the case rules can change, even for ascii characters.
An MTA that didn't do fuzzy matching would be unusuable. Remember these are not IDNs, local parts are interpereted only by the recipient MTA and each MTA uses whatever fuzz rules make sense.
If fuzzy matching is to be recommended, the rules should be specific.
No. They can't be.
what is the scenario where mail is sent from an mta to an mta that doesn't support EAI?
If this is going to an intermediate MTA wouldnt it be better to attempt to route to a different intermediate mta?
It fails. In the SMTP world there's no such thing as an intermediate MTA.
If the mta is the destination mta, then why wouldnt it accept the email for the domain that it represents?
An MTA that supports EAI can accept EAI mail for all or some of its mailboxes depending on whether they expect the recipients to handle EAI. An MTA that doesn't support EAI accepts no EAI mail.
Perhaps, the scenario is I send an email to 2 people one uses an EAI, the other not. The non-EAI recipient rejects the mail because of the EAI address in the to-field, and the SMTPUTF8 commands, even if it isn't the local destination address?
Yes, that is one scenario.
27- avoiding easily confused characters seems too vague. We want to prevent "One" vs "0ne" (the letter vs the digit) but we don't want to eliminate the use of zeroes.
It has to be vague -- easily confused is ill defined. We've been living with addresses like operat0r@hotmail.com (try it) for decades but we can try not to make the situation worse.
Also, names that differ only in accents is too limiting. And by restricting accents, it implicitly makes the names ascii equivalents. If this is the recommendation then it undermines the benefit of EAI.
This also seems like a latin based viewpoint. What does this mean for languages that heavily use modifiers?
That's not what it says or what it means. The idea is that if you make bób and bøb different mailboxes, you will be sorry. Updated slightly.
It would be better to insist on exact matches.
Trust me, that is a recipe for eternal hatred from your users and their correspondents. I am reasonably sure your MTA accept TEXTEXIN@ as equivalent to textexin@.
Slide 29 Should discuss mailbox or address downgrading not message downgrading
Sorry, can you provide a reference for mailbox or address downgrading? They are not terms that are used anywhere in the EAI standards. Message downgrading is discussed in RFCs 6857 and 6858.
32 the summary talks about non-latin support, but EAI is about supporting languages that are latin-based too.
Perhaps refer to languages that require characters outside of ascii.
Fixed. Regards, John Levine, john.levine@standcore.com Standcore LLC