Excerpts from transarc.system.ietf-822: 21-Jan-93 Re: MIME to Draft
Standard Erik M. van der Poel(_at_)poe (5591)
However, the header that identifies a Base64 message as such
(Content-Transfer-Encoding) is *not* designed to be "transmissible"
anywhere. Apparently, there is an enclave in the UK that only
transmits certain RFC 822 headers, and other headers are dropped. I
would guess this enclave is JANET, but I'm not sure.
While I agree that the idea behind base64 was to be transmissible
everywhere, that's not mentioned explicitly in the MIME draft, so I
don't think you can draw a contradiction here. MIME is designed for
systems that can express additional RFC-822-style headers, not for
systems ``everywhere.'' (RFC 1123 discourages (``SHOULD NOT'')
alteration of existing header fields except in the ``gateway'' case.
The intent of that section seems to be directed at discouraging
rewriting of addresses, but covers the existence of optional header
fields.)
Even though users of limited enclaves, or broken mail redistributors,
cannot generate additional RFC-822-style headers required for RFC 1341,
it is a non-sequitur that MIME should be changed to allow them to move
their ``headers'' into the message body.
Excerpts from transarc.system.ietf-822: 21-Jan-93 Re: MIME to Draft
Standard Erik M. van der Poel(_at_)poe (5591)
There are several solutions that I think we should consider:
1. The way the "Andrew" implementation used to do it. (Nathaniel, would
you care to describe this?)
I believe that I can speak to this, and thanks, but ``Andrew'' is still
doing it today.
There were two versions of the mechanism, which both used additional
header fields. The first one was a header like:
X-Andrew-ScribeFormat: <format>
where <format> was ``Yes'' or ``2'' or ``10'' or ``12'' for the various
versions of ATK encoding that was in use.
The second one, still in use, uses the Content-Type: header (from RFC
1049) like:
Content-Type: X-BE2; <format>
where <format> takes, in general, one of those documented values.
Generally, the only value in use today is ``12''.
In both cases, with <format> values of 10 or larger, the formatted
message body was expected to begin with the text ``\begindata{'', and
leading extra whitespace (such as gratuitously-added newlines) was
removed.
I will echo part of Erik's sentiments, though, since transmitting either
of these headers was not always possible. In particular, we couldn't
get them into netnews. But we always viewed this limitation as one of
mail software that could in principle be fixed, once the header names
and usages became more standard.
Back in the early days of ietf-822, we shared knowledge of all kinds of
transport limitations, such as conversions between EBCDIC and ASCII,
deletion of trailing whitespace on lines, addition of whitespace to ends
of lines, gratuitous line folding, and the like. What we perhaps didn't
share, because it was so obvious, was knowledge about which headers were
dropped by some gateways--not because of any intention, but because that
didn't seem like it was part of the problem: those gateways were clearly
bogus (even in the RFC 1123 sense), and there would be no way to work
around such a gratuitous limitation.
Well, maybe back then we indeed could have worked around their
limitations, by defining an additional ``header'' portion of the message
body with some signature. I don't remember it's having arisen as a
recommendation before now, and there are lots of reasons not to do it
(just one: gateways that needed to translate for some reason would now
have to look at the message body, not just the message header). But
it's a pretty big monkey wrench to throw in at this late date, and I
guess I don't see the limitations of a set of restrictive enclaves as
big enough to derail MIME. Perhaps MIME's rather broad support will be
adequate to flush out these MTAs that don't propagate the RFC 1341
header fields.
Craig