Subject: [EAI] consensus text and parameter of MAIL FROM

From: Joseph Yee <[email-masked]>
Date: Wed, 16 Feb 2011 01:32:34 -0500

All,

Below are consensus text and parameter regarding MAIL FROM after discussion on:
  (1) determining the meaning the parameter
  (2) the text to use to explain the usage
  (3) the parameter syntax

--------
(1) the meaning the parameter

Through out the discussion, the WG agreed that the parameter intends to tell MTA that the following message needs to run under EAI-mode.

---------
(2) consensus text

If the envelope or message being sent requires the capabilities of these EAI extensions, the client MUST supply the UTF8SMTPbis parameter with the MAIL command.

If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command.  Because there is no guarantee that a next-hop SMTP server will support the UTF8SMTPbis extension, use of the extension always carries a risk of transmission failure. In fact during the early stages of deployment for the extension, the risk will be quite high.  Hence there is a distinct near-term advantage for ASCII-only messages to be sent without using this extension. The long-term advantage of casting 0x7f and below as UTF-8 is that it permits pure-Unicode environments.  This specification does not require that the client inspect the message or otherwise go to extraordinary lengths to assure itself that EAI capabilities are not required for the particular message.  

--
Note:
- 'SHOULD NOT' was kept, with text explaining the reason behind and the long term desire
- Interop is important, however making gateway as necessity deployment in order for ASCII mail exchange between 2 different platforms makes adoption more complicate.  This also requires more text to explain gateway.  Gateway is optional in current standard and will remain the same in EAI.  Gateway text is not acceptable in this regard.
- The detail explaining of EAI extensions is less likely needed once the text integrates with the rest of RFC5336bis content.  Editors can determine to expand it if necessary.

----------
(3) parameter syntax

The consensus agreed that that parameter will not make distinction of which part of message (envelop, header, etc) contains UTF-8 characters, nor will it make distinction whether the message is UTF-8 or below 0x7f.  The presence of the parameter itself is the only indication needed to notify MTA to process the message under EAI-mode.

There is only keyword, and no value(s) assigned.  The keyword is 'UTF8SMTPbis', same as SMTP EHLO keyword and the parameter of VRFY/EXPN.  It is subject to change when the new keyword named.

----------

With this and rest of issues closed (EAI Trac issue#1 - issue#7), editors should have the clarity needed for draft revision.

Regards,
Joseph, co-chair EAI

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 16 Feb 2011 11:03:57 -0000

On Wed, 16 Feb 2011 06:32:34 -0000, Joseph Yee <[email-masked]>  
wrote:

> If the client is aware that the envelope or message being sent does not  
> require any of the EAI extension capabilities, it SHOULD NOT supply the  
> UTF8SMTPbis parameter with the MAIL command.  Because there is no  
> guarantee that a next-hop SMTP server will support the UTF8SMTPbis  
> extension, use of the extension always carries a risk of transmission  
> failure. In fact during the early stages of deployment for the  
> extension, the risk will be quite high.  Hence there is a distinct  
> near-term advantage for ASCII-only messages to be sent without using  
> this extension. The long-term advantage of casting 0x7f and below as  
> UTF-8 is that it permits pure-Unicode environments.  This specification  
> does not require that the client inspect the message or otherwise go to  
> extraordinary lengths to assure itself that EAI capabilities are not  
> required for the particular message.

s/use of the extension always carries/unnecessary use of the extension  
always carries/

Not my preference, but if that is the consensus then OK.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Feb 2011 06:12:39 -0500

Joseph,

Thanks for getting these posted.

WG participants,

In order to make progress, I believe we should consider these
matters closed, with no further discussion of them unless 

(1) Clarification of Joseph's statements or intent is required

(2) Really new information appears or difficulties that have not
been raised previously are discovered.

thanks,
    john

---

From: [email-masked]
Date: Sat, 19 Feb 2011 18:16:17 -0800 (PST)

>   (2) the text to use to explain the usage

+1 on everything except the actual parameter name - it's ugly. However, since I
have nothing better to propose, I suggest retaining it unless someone else has
an alternate, clearly superior name to suggest.

				Ned

> Regards,
> Joseph, co-chair EAI
> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 20 Feb 2011 19:06:45 +0100 (CET)

> an alternate, clearly superior name to suggest.

+1 as well.

the parameter name is indeed ugly... but it will be seen only by machines, 
who still do not have a senso ob beauty. Thus I do not care about its 
name.

>> If the client is aware that the envelope or message being sent does not require any of the EAI extension capabilities, it SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command.  Becaus…

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: John C Klensin <[email-masked]>
Date: Mon, 28 Feb 2011 14:09:51 -0500

--On Sunday, February 20, 2011 19:06 +0100 Claudio Allocchio
<[email-masked]> wrote:

>...
>> +1 on everything except the actual parameter name - it's
>> ugly. However, since I have nothing better to propose, I
>> suggest retaining it unless someone else has an alternate,
>> clearly superior name to suggest.
> 
> +1 as well.
> 
> the parameter name is indeed ugly... but it will be seen only
> by machines, who still do not have a senso ob beauty. Thus I
> do not care about its name.

Folks, please remember that "UTF8SMTPbis" isn't a proposed
parameter name and never has been.  It is just a placeholder
that reflects an explicit WG decision to avoid assigning a final
name until after all (other) protocol issues were resolved.
The intention of deferring it was to prevent any implementer
from getting ahead of the WG and deploying something that would
use the same parameter for a slightly different collection of
features... a sure guarantee of interoperability problems.

     john