Forgive me if I am naive. I have been reading this list for a only few months.
I have read the draft rfcs and followed the discussion on this topic. I
believe I sympathize with most if not all of the stated positions. And yet
I see no fundamental conflict. How can this be? (I feel confident I'll be
corrected in due course.) What follows is an alternative that I think
must surely have been rejected already in the distant past, but just in
I was tempted to retitle this as "Parsimony considered harmful". The problem
seems to be that RFC-XXXX is trying to do too many jobs. My preference is
to view RFC-XXXX as defining a message representation suitable for composition
and interpretation by UA's, and specifically nothing else. Under this
interpretation nested encoding (for example) is clearly unnecessary, and,
if it is problematical, it may as well be banned.
The problem arises, as everyone has incessantly observed, because a separate
constituency wishes to extend the transport to handle 8-bit text and/or
binary data streams. This constituency has a well-stated and defensible
position, and there is no need to deny them their extensions.
What seems to have happened is that the SMTP extension proposal, in an
attempt at parsimony, referenced RFC-XXXX as the mechanism for "conversion"
at 8->7 transitions. This is as clear a layering violation as any I've
ever seen. It seems hopeless to pursue this path. More importantly, it
does not seem to be necessary.
Instead, the SMTP extension *must* specify *independently* what is to be
done with 8-bit text at 8->7 boundaries. This is a transport issue and
not a UA issue at all (but see later for why this may not *appear* to be
Some people have proposed that 8-bit-required messages be bounced
unconditionally at such transitions, and this would indeed solve the
problem, but it is understandably unsatisfying. A more palatable solution
requires additional transport extension. Ideally this extension would
go in the envelope and not in the headers, but later I'll touch on a
possible reason for having a header instead (or in addition). For the
sake of discussion, suppose we define a new header, "Transport-encoding:".
Here's how it would work:
"Simple" 7-bit text messages would either omit the header or code it as
the equivalent "7-bit". Messages containing 8-bit text that was not
already sanitized (e.g. using RFC-XXXX methods) by the UA would specify
"8-bit-required". At an 8->7 boundary, the 8-bit MTA MUST (or SHOULD -- I
don't care really, but it must bounce if it does not) change "8-bit-required"
to "8-bit-encoded-as-7-bit" and encode the entire message, including headers,
using a single designated encoding method. This method could be
or it could be mnemonic (in its encoding interpretation rather than its
content-type interpretation). One critical property it must have is
that it preserve intact (at least) all printable ascii as well as <cr-lf>.
it must disallow any "quoting" of these characters. Obviously it must quote
all characters with the high bit set, and it must be reversible. Also
base-64 is not a candidate.
At 7->8 boundaries, when the header state is "8-bit-encoded-as-7-bit"
the 8-bit mta MUST reverse the encoding and replace the header with
You will no doubt have observed that I am assuming the transport extension
is limited to 8-bit *text*, not arbitrary binary. I am aware of the desire
to include binary as well, but I am convinced that that is far more involved
and in any case should be treated as a separate extension. I cannot see any
reason why such an extension, if justified by performance requirements, cannot
stand on its own.
At this point, although I have not addressed issues like ebcdic gateways,
broken gateways, and so on, I hope the transport implications are clear.
So let me itemize the UA implications:
8-bit-UA -> 8-bit-MTA: Bliss
7-bit-UA -> 8-bit-MTA: MTA is upward compatible with 7-bit UA
8-bit-UA -> 7-bit-MTA: If the UA is RFC-XXXX compliant it can
emit only 7-bit messages. I believe
RFC-XXXX UA's will do this anyway. But
any case, the (new) UA can be
7-bit-UA -> 7-bit-MTA: Unchanged
7-bit-MTA -> 7-bit-UA: Unchanged. Messages originated by
will be minimally modified by the
encoding, so should be as readable as
be hoped for.
8-bit-MTA -> 8-bit-UA: No problem. The UA need not handle the
transport encoding since the MTA
8-bit-MTA -> 7-bit-UA: This is mildly problematical. I
(new) 8-bit MTA must be conditioned to
as though it were a 7-bit MTA, at least
those UA's that are not 8-bit.
7-bit-MTA -> 8-bit-UA: Here we have a bit more of a problem:
UA wants to have the transport encoding
undone, but the MTA won't do it. This
the reason for leaving the
header, so that a simple filter can be
that can undo the encoding just in this
which we can hope will be a transient
Thanks for your perseverence --