Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL

From: Shawn Steele <[email-masked]>
Date: Tue, 8 Feb 2011 13:48:58 +0000

> So, your view is that the difference between a specification's containing
> a normative SHOULD NOT versus MAY is merely fine-tuning?

In general, no.

In this case there's little practical difference I think.  Either way the behavior requires pretty much exactly the same logic on the server, and the client isn't forced to look up if it doesn't know.  (But if it does know, then it can (SHOULD or MAY) provide the hint to the server).  Sorry, I can't get excited about what's basically a philosophical difference in a technical standard, where the technical impact is the same behavior.

This is very likely a higher level of detail than most implementations can or will be able to distinguish between.

-Shawn

---

From: John Levine <[email-masked]>
Date: 8 Feb 2011 15:32:50 -0000

>This is very likely a higher level of detail than most
 implementations can or will be able to distinguish between.

Agreed.  I think I'm hearing that everyone but one thinks the current
language is fine, give or take minor tweaks.  So unless someone has
different text for people to consider, we appear to be done.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Shawn Steele <[email-masked]>
Date: Tue, 8 Feb 2011 19:13:01 +0000

I agree

- Shawn

Sent from my Windows Phone 7

-----Original Message-----
From: John Levine
Sent: Tuesday, February 08, 2011 10:34 AM
To: [email-masked]
Cc: Shawn Steele
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 08 Feb 2011 16:05:34 -0800

On 2/8/2011 5:48 AM, Shawn Steele wrote:
>> So, your view is that the difference between a specification's containing a
>> normative SHOULD NOT versus MAY is merely fine-tuning?
>
> In general, no.
>
> In this case there's little practical difference I think.  Either way the
> behavior requires pretty much exactly the same logic on the server, and the
> client isn't forced to look up if it doesn't know.  (But if it does know,
> then it can (SHOULD or MAY) provide the hint to the server).  Sorry, I can't
> get excited about what's basically a philosophical difference in a technical
> standard, where the technical impact is the same behavior.
>

The default that implementations choose for handling ASCII data -- that is, 
casting it as ASCII vs. casting it as UTF-8 -- is going to have a very 
significant effect on interoperability between UTF-8 and legacy systems.  That's 
not a small point.

I'm fascinated by the certitude some folks appear to have about how deployment 
and operation is going to work for EAI.  I had not realized that we could be so 
sure of such specifics, for something like this...

But Shawn's comment essentially reduces down to saying that a normative 
statement, here, does not matter.  I think that Ned's examples from similar 
cases have similar implications.

      If a normative statement is not going to be followed,
      then it should not be a normative statement.

So I suggest that the normative statement instead be a non-normative discussion, 
such as:

Legacy ASCII vs. UTF-8

      Messages containing only characters <= 0x7f can be treated as legacy ASCII 
or can be cast as UTF-8. Different operational environments will prefer one over 
the other. Moving between ASCII-only and UTF-8-only environments requires a 
gateway.

      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.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Jason Nelson <[email-masked]>
Date: Wed, 9 Feb 2011 03:41:05 +0000

Agreed on these points.  While I hope that the idea that this will be deployed like wildfire and the days of legacy MTAs will fade into memory, I am concerned interop during the decade in-between the release of these RFCs and when they reach the furthest corners of the internet.  Full legacy interop is a goal (and in my opinion, a reachable one) but in the mean time, your adjustments to the text look good to me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
Sent: Tuesday, February 08, 2011 4:06 PM
To: [email-masked]
Subject: Re: [EAI] Consensus Result on Issue #1 - Parameter on MAIL

> The default that implementations choose for handling ASCII data -- that is, casting it as ASCII vs. casting it as UTF-8 -- is going to have a very significant effect on interoperability between UTF-8 and legacy systems.  That's not a small point.

> I'm fascinated by the certitude some folks appear to have about how deployment and operation is going to work for EAI.  I had not realized that we could be so sure of such specifics, for something like this...

---

From: John Levine <[email-masked]>
Date: 9 Feb 2011 05:53:51 -0000

>The default that implementations choose for handling ASCII data --
>that is, casting it as ASCII vs. casting it as UTF-8 -- is going to
>have a very significant effect on interoperability between UTF-8 and
>legacy systems.  That's not a small point.

Maybe, maybe not.

Some MTAs may use the EAI flag that the client sends with a message
to decide whether they can relay it to non-EAI destinations.

Other MTAs may find that it's so cheap to scan a message for high bits
(perhaps as it checks for viruses, or just as it shovels the bytes
from the SMTP session into a spool file), and the various combinations
of EAI and non-EAI envelope addresses are hard enough to predict, that
it's easiest to ignore the client's EAI flag and figure out as each
message is about to be relayed whether it needs EAI for the next hop.

> I'm fascinated by the certitude some folks appear to have about how
> deployment and operation is going to work for EAI.

Me, too. At this point, I have no idea how MTAs will implement EAI
relay, and I don't think anyone else does, either.

So while it's perfectly reasonable that clients SHOULD make the flag
match the message if they can, I don't see any basis for adding
paragraphs of threats about all the bad things that might happen if
they don't.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Feb 2011 09:22:32 -0800

On 2/8/2011 9:53 PM, John Levine wrote:
>  I don't see any basis for adding

I don't either, which is why the text has no 'threats'.  (I'm assuming your were 
not merely engaging in dismissive hyperbole to circumvent serious discussion.)

If you think otherwise, please indicate what text you see as having threats and 
how it qualifies as threats.

d/
-- 

   Dave Crocker

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 11 Feb 2011 14:46:12 -0000

On Wed, 09 Feb 2011 00:05:34 -0000, Dave CROCKER <[email-masked]> wrote:

> So I suggest that the normative statement instead be a non-normative  
> discussion, such as:
>
>
> Legacy ASCII vs. UTF-8
>
>       Messages containing only characters <= 0x7f can be treated as  
> legacy ASCII or can be cast as UTF-8. Different operational environments  
> will prefer one over the other. Moving between ASCII-only and UTF-8-only  
> environments requires a gateway.
>
>       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.

+1

-- 
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: [email-masked]
Date: Sun, 13 Feb 2011 13:35:45 -0800 (PST)

> pure-Unicode environments.

I prefer SHOULD NOT language, but this language is also acceptable.

				Ned