Subject: Re: [EAI] Consensus Issue #1: parameter on MAIL FROM?

From: Shawn Steele <[email-masked]>
Date: Wed, 19 Jan 2011 17:30:25 +0000

IMO that's way more complex than is necessary.  Either the client understands EAI or it doesn't.

-Shawn
------------------------------

Message: 2
Date: Tue, 18 Jan 2011 01:29:03 -0800
From: Bill McQuillan <[email-masked]>
Subject: Re: [EAI] Consensus Issue #1:  parameter on MAIL FROM?
To: IMA Discussion <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

If there is to be a parameter on the MAIL FROM: command, it seems that it
may have overloaded meanings:

  1 - The message immediately following has non-ASCII

  2 - The client is able to accept non-ASCII in responses to any commands
      related to the immediately following message

This might entail a syntax like:

  UTF8=WITHIN  or  UTF8=ACCEPTED

Where WITHIN implies ACCEPTED.

--
Bill McQuillan <[email-masked]>

---

From: Shawn Steele <[email-masked]>
Date: Wed, 19 Jan 2011 17:47:57 +0000

> * No EAI facilities used or required: no parameter associated
> with the extensions on MAIL.  That corresponds to your cases 0
> and 1 and is the same whether the server advertises UTF8SMTPbis
> or not.

This information should be irrelevent.  If your system supports EAI (which is "just" parsing the mail with UTF-8 instead of ASCII), then it shouldn't matter if a particular message is specifically EAI or not.  Sure, if the receiving end wants to do something smart it may have to figure out what to do with it, but that's the same thing that happens if it sends mail from an EHLO environment to HELO, or 8BITMIME to a 7 bit environment, etc.  

But, assuming that the system supports EAI because it actually intends to use it, then it shouldn't have any missing pieces...  At the very least, anything that needed this information should be "temporary"...

-Shawn

 
http://blogs.msdn.com/shawnste

---

From: Shawn Steele <[email-masked]>
Date: Fri, 21 Jan 2011 18:37:06 +0000

The reason why I prefer #1 is because it is only required if the server has a need to figure it out.  Option #2 ALWAYS requires that the client figure out the right thing to do, so it shifts the burden to the client.  Since the client won't know when the "transition" is complete, #2 always has to happen "forever".  At some point #1 can always stop the work.

-Shawn

Message: 7
Date: Fri, 21 Jan 2011 07:50:35 -0500
From: John C Klensin <[email-masked]>
Subject: Re: [EAI] Consensus Issue #1:  parameter on MAIL FROM?
To: [email-masked], Charles Lindsey <[email-masked]>
Cc: IMA <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

--On Thursday, January 20, 2011 09:12 -0800 [email-masked]
wrote:

>> However, it needs a NOTE to the efect that including this
>> parameter in a message where it is not strictly necessary
>> (that message is pure ASCII) MAY result in a more circuitous
>> propagation path, or even in falure to deliver the message at
>> all (e.g if the ultimate recipient does not advertise
>> UTF8SMTPbis).
>
> Yes, it would be a very good idea to include a statement like
> this.

Sorry, folks, but I'm seeing a contradiction here, not just
notes, and, if I were Jiankang, I'd have trouble knowing what to
write.

Option 1: Any EAI-capable client that is talking with a server
that supports EAI extensions SHOULD send the parameter with
MAIL, indicating that it is modern and that message envelope or
headers might contain UTF-8 (restricted however we might
restrict it, but not necessarily restricted to ASCII).  That
SHOULD might be accompanied by a note about exceptions. but the
intent is "almost always".   As I understand it, this is what
Shawn is proposing.

Option 2: In order to avoid requiring a subsequent analysis of
headers before dealing with a server that cannot handle EAI
extensions, an EAI-capable client talking with an EAI-capable
server SHOULD send the parameter only if it has reason to
believe that the message requires EAI support.  "Reason to
believe" allows exceptions and might be further noted, but the
intent is that the parameter not be sent with ASCII-only (aka
strictly 5321/5322-conforming) messages.  As I understand it,
this is what Charles and Ned are proposing.

In practice, option 2 probably gradually becomes equivalent to
option 1 as the EAI extensions are broadly deployed (just as
support for 8BITMIME (without requiring downgrading) is now
pretty general.  But, in the reasonably short term, it does make
a difference.

So which is it?
     john