On Fri, 11 Sep 1998 00:23:42 -0400 Al Costanzo <al(_at_)akc(_dot_)com>
wrote:
I want to make sure I did not misunderstand you....
The Transport Layer? Like the Transport layer of TCP/IP?
No. Mail transport, as in SMTP.
I'm a software distributor, I distribute updates of my software via email.
All the software is LZJU90 compressed and stored on a disk. when someone
orders an update it I email them a precompressed LZJU90 object.
The objects were compressed once and may be mailed many times, why waste cpu
cycles re-compressing the thing?
You have just described, IMO, a distribution data format, not a
C-T-E. Certainly, one could use a C-T-E to make unpacking a
little more convenient but, if you were _storing_ the software
in compressed form, you would need a rather tricky MUA and/or a
rather fancy file system, to notice that the material was in
that form and should be sent with this rather specialized
content-type disguised as a C-T-E, rather than just treating it
as binary data and using base64.
That was, of course, part of the perceived problem with
RFC1505. MIME separates the concept of the data type of an
object ("content-type") from the concept of an encoding used to
move it safely across the mail transport system. If one
believes that distinction is useful, 1505 hopelessly muddled it.
So, while there may be value in a compressed C-T-E, it is
something I'd expect to be applied when two communicating MTAs
decide it is appropriate for us with any data that met some
observable criteria (probably having more to do with the
patterns of the bits than the semantics of the file). As soon
as you start talking about transferring precompressed objects of
particular sorts, I think you are back to an application/
subtype, not a C-T-E.
Note also that, absent a "mailcap"-like capability that can work
successfully down the length of an unknown relay chain (I think
Turing might be impressed with that, but that is another
problem), use of a new C-T-E for this purpose probably involves
the risk that some gateway would need to downgrade to Base64
--exactly the conversion/deconversion situation you are trying
to avoid. Use of a content-type with base64 of course avoids
that problem.
Reading some of your other notes, my guess --perhaps completely
wrong-- is that your more general model/plan wants to see a
hierarchy of the form of
C-T-E / content-type / content-subtype / parameters
That is probably unfortunate, at least from the standpoint of
those of us who see C-T-E and content-type as orthogonal, not
hierarchical. But, to intelligently go down that path very far,
I suspect we will need to see more of the picture, not just one
or two terminal leaves of the tree with promises of grand
concept to come.
john