Subject: Re: [EAI] The scenario favoring "uMailbox"?

From: Shawn Steele <[email-masked]>
Date: Tue, 26 Apr 2011 15:23:43 +0000

I think Dave's point is valid:

> The basic problem with your approach is that you are still trying to define a
> hybrid ASCII + UTF-8 system.  However that is no longer the model, for the
> current, core specifications.

An ASCII@ASCII address *IS* an EAI address because it is also UTF8@UTF8

> rfc5336bis said
>  "
> If the UTF8SMTPbis SMTP extension is not offered by the SMTP server,
>    the EAI-aware SMTP client MUST NOT transmit an internationalized
>    email address and MUST NOT transmit a mail message containing
>    internationalized mail headers as described in [RFC5335bis]
> "

But that's OK.  ASCII@ASCII is ALSO a legacy email address, so it may be transmitted as a legacy message.  Eg: it won't be transmitted by EAI.

The attempt to overspecify this protocol gets to smaller and smaller edge cases.  If we just try to define EAI and let applications worry about what happens if they can't send EAI, then the document is much less confusing.

> I am not trying to define a hybrid ASCII + UTF-8 system.
> but I think that the implementor will be likely to choose to recognize both rfc5321 address
> and UTF-8 address.

Probably.  So we need to define EAI.  rfc5321 is already clearly defined, and the implementor probably already implements it.

> If they choose to recognize both addresses, we should give them more convenient way to do it.

Overspecificity isn't convenient.  If they can look to the EAI docs and figure out UTF-8 mail, great.  They can also look to 5321 to figure out legacy email, great.  If we try to say how do this, then that, then it becomes less convenient because they have to keep going back & forth and build test cases for the edge cases we think about, etc.  It's easy for them to conform to both.  If we try to define exactly how they should do that, then the doc takes longer to write and is harder to adopt.

I'd go so far as to say that this language:

>    the EAI-aware SMTP client MUST NOT transmit an internationalized
>    email address and MUST NOT transmit a mail message containing
>    internationalized mail headers as described in [RFC5335bis]

Is redundant and not necessary.  RFC5321 clearly describes what's permitted in RFC5321.  That is clearly not permitted.  There are many other RFCs that an implementation will use (TCP/IP, DNS, IDNA, etc). We don't have to say "Make sure you follow RFCs xxx, yyy, & zzz" when building your EAI app.

> If it is not an internationalized message, then it has nothing to do with the
> EAI working group.  Or, at least, it has nothing to do with these two, core
> specifications.

Very much agreed.  If we really wanted to, a "how to build an app using bout EAI and 5321 best practices" doc could be written, but I dont' think it's necessary.

> it  means that Alice with an [email-masked] address from rfc5321 system
> can send the message to BOB with an  [email-masked] or abc@a-labeladdress
> from the Pure EAI-aware system;
> but BOB with the [email-masked] or abc@a-label address in the  Pure
> EAI-aware system can not reply it to Alice with the [email-masked] since
> Alice's system does not support UTF8SMTP extension.

That kind of thing's OK.  If you email (with either EAI or 5321) to [email-masked] that turns your email into a fax and hand-delivers it to me, then I may not be able to easily reply.  The apps and gateways will have to figure that out.  We can write a doc on "best practices" or "suggestions" or something, but that doesn't have to be part of the core spec.

- Shawn

---

From: Shawn Steele <[email-masked]>
Date: Tue, 26 Apr 2011 22:31:25 +0000

> Because the WG told him to
> include a requirement that U-labels be used in internationalized
> domain parts when possible, it is perfectly reasonable for him
> to say what should occur when it is not possible 

So an EAI conforming mail should use U-labels.  Bob's email could do that, but it won't get to Alice.  So his system will quickly discover that it can't use EAI.  His mail system is left with only the 5321/5322 option, which is clear that U-labels cannot be sent. 

I don't think that requires muddying the waters in EAI about ascii/utf-8 if/and/else/then/but stuff.

It's might be fair to note, perhaps in the introduction or an informational note, that if a conforming EAI message cannot be sent, mail clients mail consider using 5321/5322 if that service is available to them and they have the information needed to use 5321/5322.

I agree with Dave's simplified ABNF suggestion.  EAI is all about UTF-8 mail.  If it's not EAI mail, then it's some other protocol (like 5321/5322).

If EAI fails, users have numerous ways to attempt communication:  Send an IM.  Send a Fax.  Find their corporate office on the web and complain to their boss.  Send a letter (snail mail).  Pick up the phone and call them.  5321/5322 is just one of those alternates.  Given that we're already in mail, it seems particularly likely that 5321/5322 might be useful, but we aren't going to create language around all the other mechanisms.  Any catering to 5321/5322 fallback (as opposed to downgrade) should be informational or something.

-Shawn