Subject: Re: [EAI] Parameter(s) on MAIL options

From: John Levine <[email-masked]>
Date: 1 Feb 2011 00:39:12 -0000

It seems to me there are three separate features here:

A) Messages with UTF-8 headers
B) Envelopes with UTF-8 addresses
C) SMTP responses with UTF-8 text

The current proposal is to have one flag that enables (ABC).  Dave, as
I understand it, wants one flag for (AB) and a separate flag for (C).
I suppose one could separate them out further.

For reasons I think I've explained about as well as I can, I don't see
much utility in more than one flag, and a lot of opportunity for
confusion and broken implementations.

I also agree with Ned that it's a quality of implementation issue
whether a client only sets the flag for messages and/or envelopes that
need it, or for everything.  And it's debatably a quality of
implementation issue for a server whether it passes along the flag
that came with a message on a subsequent hop, or inspects it to see
whether it needs the flag.  So perhaps we can say something about it
as a MAY or SHOULD, but don't mandate finicky rules that implementors
are likely to ignore.

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: [email-masked]
Date: Mon, 31 Jan 2011 16:44:29 -0800 (PST)

> confusion and broken implementations.

I agree.

> as a MAY or SHOULD, but don't mandate finicky rules that implementors

I think, as a practical matter, that this is the most reasonable approach.

				Ned

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 31 Jan 2011 18:29:01 -0800

> I suppose one could separate them out further.

I cited distinctions, along the lines of your list above.  That recitation was 
not to indicate my own preference but to clarify the possibilities.

After thinking it through, my observation was (and remains) that having a single 
MAIL command flag that declares a message to be in UTF-8 is all that it is needed:

    It specifies the type of the message AND implies the capabilities of the client.

    There does not seem to be any need for handling the differential scenarios 
that would be enabled by having additional flags.

>   And it's debatably a quality of
> whether it needs the flag.

This would move the protocol specification into the realm of heuristics. 
Protocols should not involve guessing.

If a message is changed from UTF-8 to ASCII or vice-versa, then it has gone 
through a gateway, not a relay.  That sort of cleverness is the distinction 
between MTA relaying and translation gatewaying.

The current specification seeks to provide details for MTA relaying of a UTF-8 
message.  Don't confuse that task with the details for gatewaying.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 31 Jan 2011 22:08:54 -0500

>> And it's debatably a quality of implementation issue for a server 
>> whether it passes along the flag that came with a message on a 
>> subsequent hop, or inspects it to see whether it needs the flag.

> Protocols should not involve guessing.

The specific scenario I have in mind is one where a client sends a message 
with the EAI flag set, then the server relays it, and it turns out that 
the next hop doesn't need the flag.  There are a variety of sub-scenarios 
here, e.g., client was lazy and set the flag on an ASCII message, client 
sent to a mix of EAI and ASCII addresses, client sent to EAI address which 
server relays to an ASCII address.  The behavior is entirely algorithmic, 
but it's not clear what the ideal algorithm would be.

I am specifically NOT suggesting that we try to solve this problem here, 
nor that we mandate what the client do beyond requiring that it set the 
EAI flag if the message or envelope is non-ASCII.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 31 Jan 2011 19:55:15 -0800

On 1/31/2011 7:08 PM, John R Levine wrote:
...
 >          There are a variety of sub-scenarios here, e.g., client
> was lazy and set the flag on an ASCII message, client sent to a mix of EAI and
> ASCII addresses, client sent to EAI address which server relays to an ASCII
> address. The behavior is entirely algorithmic, but it's not clear what the ideal
> algorithm would be.

Having a system along the handling sequence impose a change on a message might 
be algorithmic in a software sense, but it is a heuristic in terms of 
justification, absent a formal standards specification dictating the change.

> I am specifically NOT suggesting that we try to solve this problem here, nor
> that we mandate what the client do beyond requiring that it set the EAI flag if
> the message or envelope is non-ASCII.

Then I do not understand how this foray into the topic has aided deciding on the 
details of the parameter.

d/

-- 

   Dave Crocker

---

From: "John R Levine" <[email-masked]>
Date: 31 Jan 2011 23:05:24 -0500

> Having a system along the handling sequence impose a change on a message 
> might be algorithmic in a software sense, but it is a heuristic in terms of 

Well, gee, this is hardly a new problem.  You had a somewhat analogous 
situation with 8BITMIME, where some relay MTAs were (and, I suppose, still 
are) better than others at recoding messages or noticing that a message 
didn't really need it.

>> I am specifically NOT suggesting that we try to solve this problem 
>> here, nor that we mandate what the client do beyond requiring that it 
>> set the EAI flag if the message or envelope is non-ASCII.

> Then I do not understand how this foray into the topic has aided deciding on 
> the details of the parameter.

Pick the simplest possible version, since extra complication won't help.

Regards,