Date: Mon, 24 Jun 1991 21:06:25 -0400 (EDT)
From: John C Klensin <KLENSIN(_at_)infoods(_dot_)mit(_dot_)edu>
Subject: Re: Internet Message Bodies DRAFT revisions
To: nsb(_at_)thumper(_dot_)bellcore(_dot_)com
Cc: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
The only time when it might seem strongly desirable to put
an encoding on a non-innermost part (i.e. a message or a multipart) is
if a message has been floating around in a world of 8 bit transport and
is gatewayed back to 7-bit land. In the existing draft, you could do
this by encoding the whole message. WIth Mark's proposal, the gateway
would have to parse the parts and only encode the lowest-level parts.
I'm not a purist, but this does smack somewhat of bad layering.
The choice seems to be complexity in the UA (which is what Mark is up
against now) and complexity in gateways (which someone will be up
against some day). I just wanted to paint the choices clearly.
Personally, I have no problem with pushing the complexity to the
gateway, but it does mean that an 8-bit to 7-bit MTA gateway will have
to parse multipart messages.... -- Nathaniel
As the partial keeper of the "what happens when something floats around
in an 8 bit world and is 'fixed' to 7-bit land" materials, I think there
is a fairly strong case to be made for keeping the "encode the whole
message" option (which I have referred to elsewhere as "encapsulating"
it, following what I understand of the X.400 terminology) available.
The more diddling (e.g., part-parsing) with the message body gateways
have to do, the more likely a few of them are to get it wrong, which
makes finely-tuned delegation of UA responsibilities much more
important.
In other words, please don't change this.
--john
I agree entirely with Mark on this one. In fact, I had already asked for the
same limitation on message format, based on the *difficulty* of doing proper
8-to-7 bit translation in the presense of multiple content-transfer-encodings.
I have long felt that it is unacceptable to do an 8-bit to 7-bit conversion by
applying an overall content-transfer-encoding of a multipart 8-bit message.
If the recipient doesn't have an RFC XXXX capable mail reader, any pure 7-bit
body parts will be munged by such conversion. This includes not only uuencoded
files but also program sources (like .shar files) and the like. Anything that
caused this would certainly be a show stopper.
I consider it very likely that users of newfangled RFC XXXX mail composing
programs will still want to send machine-readable data through e-mail to
recipients without RFC XXXX capability, and such users shouldn't have to be
aware of the intracacies of the e-mail RFCs in order to do so.
Some might argue that the sender can send such data in a pure-7-bit RFC XXXX
message, or in a plain RFC 822 message. But this in effect creates rules like:
"you can't send a uuencoded file in a message that contains multiple body
parts", or "you can't include a .shar archive in a message that also contains
French text". These limitations aren't going to be obvious to casual users of
the e-mail system, and they shouldn't exist at all. A rule that says "if you
want to send machine-readable data, you need to enclose it in its own body
part" is much better.
So unless we are going to give up the ability to send machine-readable data to
those that don't yet have RFC XXXX mail readers, we need to provide a way that
mail composers can send such data without the danger of having it munged by
8-to-7-bit gateways. And yet such usage should not prevent the same message
from containing 8-bit data (e.g. French text) in a separate body part. I
conclude that all 8-bit to 7-bit translation should occur on a per-body-part
basis, and 7-bit only body parts should be left unchanged by this process.
Authors of RFC XXXX mail composers will need to provide some way for the sender
to specify a "compatability mode" body part. This is ugly, but it would be far
worse if there were no way provided to do this at all.
On the other hand, if we do allow 8-to-7 bit whole-body translation, there will
then also be a need for translators that accept arbitrary encoded 7-bit
messages as input and produce as output messages for which all body parts which
were originally 7-bit only, are once again 7-bit only. Such a translator would
be a real mess, since it would have to deal with the possibility of arbitrarily
nested content-transfer-encodings, decoding each body part, checking for 8-bit
characters, and optionally re-encoding each body part. The need for such
translators may be widespread: any site that continues to use pre-RFC XXXX
mailers and that depends on the ability to decode uuencoded files will want to
consider installing such a translator.
Add to this the fact that allowing nested encodings makes the mail reader's
task much more difficult.
Disallowing nested encodings thus has the advantage of simplyfing *both* the
UA's job in decoding the message, and also the process of 8-bit to 7-bit
translation such that a reasonable level of interoperability with existing mail
readers is assured.
Keith