[UA-EAI] FW: comments on uasg019b

[John Levine]

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 at 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 at .

> 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 at standcore.com
Standcore LLC