ietf-822
[Top] [All Lists]

Re: Nested Encodings

1991-08-25 21:27:07
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
case...

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
true).

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 
quoted-printable,
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>.  
That is,
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 
obviously,
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
"8-bit-required".

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:

Originator:
        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 
most
                                        RFC-XXXX UA's will do this anyway.  But 
in
                                        any case, the (new) UA can be 
configurable.
        7-bit-UA -> 7-bit-MTA:          Unchanged

Recipient:
        7-bit-MTA -> 7-bit-UA:          Unchanged.  Messages originated by 
8-bit UAs
                                        will be minimally modified by the 
transport
                                        encoding, so should be as readable as 
could
                                        be hoped for.
        8-bit-MTA -> 8-bit-UA:          No problem.  The UA need not handle the
                                        transport encoding since the MTA 
already did.
        8-bit-MTA -> 7-bit-UA:          This is mildly problematical.  I 
believe the
                                        (new) 8-bit MTA must be conditioned to 
operate
                                        as though it were a 7-bit MTA, at least 
for
                                        those UA's that are not 8-bit.
        7-bit-MTA -> 8-bit-UA:          Here we have a bit more of a problem: 
the
                                        UA wants to have the transport encoding
                                        undone, but the MTA won't do it.  This 
is
                                        the reason for leaving the 
Transport-encoding:
                                        header, so that a simple filter can be 
interposed
                                        that can undo the encoding just in this 
case,
                                        which we can hope will be a transient 
one.

Thanks for your perseverence --
Jim Hamilton

<Prev in Thread] Current Thread [Next in Thread>