On Thu June 30 2005 20:33, Laird Breyer wrote:
I generally agree with you that double compression is useless, where
we differ is where the single compression step should be applied. You
propose that it should occur in the MIME format, while I still believe
it should be a transparent service at a level much closer to the OS.
Although it's a perhaps subtle distinction, my position is that an
end-to-end solution is preferable to multiple hop-by-hop partial
solutions, and that MIME is the most appropriate mechanism for
supporting a general end-to-end solution.
Since XML data seems to be the main beneficiary mentioned thus far of
the CTE (37% base64 overhead aside), let me ask what the proponents
aim to achieve in this instance?
I'm not particularly a compression proponent and I'm certainly not
an XML proponent. The gains would be the usual ones for compression;
shorter transmission time, etc. For email, it probably doesn't
matter much, but for highly interactive protocols (HTTP, IM, etc.)
it may be a significant factor. As a non-proponent of XML, I'd
personally say pick a more efficient representation, but that's
just me.
Other media types such as audio/video/images are already compressed so
won't benefit substantially from a CTE.
A few points:
1. some specific image (etc.) formats can benefit from compression
2. CTE for binary-to-8bit (unrelated to compression) can reduce the
37% expansion to ~2%
If space is such a serious concern, I ask: why shouldn't XML applications
simply read and write XML directly in compressed form when needed
(you already gave the example of OpenOffice) ?
While OpenOffice uses XML to represent documents, it's not amenable
to use OpenOffice to edit arbitrary XML. For example, you might think
that a document processor that uses XML might be useful for editing
XML versions of Internet-Drafts. Not without a major effort. So while
compression may be useful for OpenOffice file formats, it doesn't
necessarily follow that the same compression is necessarily useful for
all XML applications.
There would be no need for MIME readers and writers to be adapted at
all, and the physical benefits would be comparable.
RFC 1925:
(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.
(6a) (corollary). It is always possible to add another level of
indirection.
Moving the problem to all applications and/or their respective protocols
doesn't solve the problem, it just shifts the burden.
Now if the arguments against this are that this requirement would
complicate XML applications needlessly, obscure data against the
purpose of XML, and could be handled at a lower system level such that
other programs can also benefit, then this also summarizes my current
position on MIME/email (as opposed to MIME alone - but substantial
changes to MIME cannot be ignored by email).
Trying to shift the problem to media specifically for text would obscure
the text. Probably not a problem for application/*+xml, though it seems
wasteful (to this non-XML proponent anyway) to have to repeat the solution
N times over in N formats rather than once in MIME.