David,
We had a somewhat similar discussion awhile back. I, in
particular, was pushing the view you suggest that in order to
create a mailable object there is often a sequence of transformations
which happens to the original object. This resulted in two
changes & features:
-- New header Content-Transfer-Encoding: which is to be used
to specify the encoding used for a particular hop.
-- In Content-Type: binary, an attribute of "conversions" which
takes a list of encodings.
As I noted a couple weeks ago the text in section 7.5 does not make it
clear which order the conversions are applied in. By their nature, the
conversions must be applied in a particular order. Try running
uudecode before uncompress some day ;-).
Your suggestion is somewhat radical, though interesting. If you'd
brought it up 6 months ago ...
The Content-Transfer-Encoding mechanism suffers by being only one
encoding. It doesn't take much ingenuity to invent circumstances where
it is insufficient. After all, all the Officially Blessed encodings
operate on byte streams and there's a number of widely available
systems which don't even *have* byte stream sort of files. I am
uncertain, but believe that the EOL-marker capability in BASE64
is insufficient for some sorts of record oriented files.
An example I cooked up before is a user wishing to send an RMS file off
a VAX/VMS system. My sequence of transformations to create the
mailable object were:
x-RMS-to-stream | compress | base64
I'm sure something similar would be true with those `segment' files on
PR1MOS ... ;-). For both (and others), the set of attributes is very
complex.
SUGGESTION: Change Content-Transfer-Encoding to have the same syntax as
"conversions=" in the binary Content-Type. Also use the same list of
encodings as in conversions=, you can continue poo-pooing on uuencode
if you like ;-).
I do not view this as a SHOW STOPPER. Instead it is as the next level
of concern down from SHOW STOPPER. I cannot be at Santa Fe to defend
myself.
David