And, of course, if there really is anything significant to be
gained, there is a case to be made for doing the compression at
the real transport level, rather than as a MIME C-T-E. One
could even imagine a transport level compression procedure
sending binary stream compressed stuff, thereby avoiding
sacrificing some of the efficiency gained from compression to
the need to send ASCII. E.g., one might have something like...
client: EHLO my.dom.ain
server: 250-BDAT-LZmm
s: 250 EXPN
[...]
client: BDAT LZmm NNN
s: 354 expecting NNN octets
c: [...data...]
s: 250 Received ok
John,
I want to make sure I did not misunderstand you....
The Transport Layer? Like the Transport layer of TCP/IP?
Geesh... maybe I'm working too hard but that makes no sense to me.
Correct me if I'm wrong here, but if you do it at the transport layer every
time you mail an object you have re-compress the darn thing....
Now this may make sense if your mailing an object once _BUT_ let me give you
at least one example of why you WANT to do it in the APPLICATION layer as a
transfer encoding.
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?
Doing it in the application layer give you more flexibility in this
regard...
Only my opinion, but it makes a lot more sense to me....
-al