I tend to agree with Steve on this. I've long thought that compressed
C-T-E might be useful, but I feel like events have undermined this
suspicion. Text is generally too small to be not worth the bother of
compressing (nor the bother of phasing in a new C-T-E), and larger media
generally have built-in compression. So my guess at this point is that
phasing in this new C-T-E would be a huge amount of effort for a very
small efficiency gain.
What do you consider huge effort?
I have tested LZJU90 with media objects that have some built-in compression.
LZJU90 does a better job than a base64 or a uuencoded object -but- again
that is not the major thrust of LZJU90.... Future work is based on the
communities acceptance or rejection of this tranfer encoding....
Having said that, extending mailcap-like mechanisms to advertise
recipient capabilities is more generally useful, and if it were
*already* in place, phasing in the new C-T-E would be a lot less
painful. So I'd suggest focusing on the extension mechanisms first and
then, if still desired, *using* them for the new C-T-E deployment. --
Nathaniel
It would sadden me if mailcap work interfered/delayed introduction of this
transfer encoding or others into MIME.
Accept it / reject it on its own merit not because mailcap functionality is
not where you want it to be -yet-
Only my humle little opinion...
-AL