On Fri June 24 2005 17:36, Ned Freed wrote:
FWIW, I would be happy to revive the draft if there is any interest.
The last time I tried this the silence was fairly deafening, however.
It probably makes sense, though as noted last time, there may be some
benefit to decoupling compression and encoding binary->8-bit:
o some binary content, e.g. http://users.erols.com/blilly/mparse/tm35
body content, won't compress well and may in fact be expanded by gzip
"compression".
o combining compression and encoding can yield benefits even for 8-bit
content encoded to a 7-bit transport. E.g. given a 1 MB 8-bit text
source, compression will typically yield approx. 500 kB binary
compressed data. Base64 encoding will expand that by about 26:19
(4/3 * 78/76) yielding about 684 kB which is obviously smaller than
what encoding alone would yield.
o similarly, binary content could be compressed and encoded for 7bit
transport, yielding a size reduction compared to encoding alone.
o Continuing along the same lines, large 7-bit content could be
compressed and encoded for 7-bit transport to yield an overall size
reduction, e.g. if one part of the transport path is known to be a
low-bandwidth or size-constrained bottleneck (typically 1 MB -> 684 kB
as detailed above).
o compression could be used even where binary transport is available
(though it's a stretch to call that an "encoding") without the need
to hide the nature of the original media type by wrapping the compressed
data in a label identifying the data as "application/x-gzip" or
"application/octet-stream".
I found out yesterday that 8BITMIME works much more widely than expected,
so this probably should be handled separately from the USEFOR WG (which
is already behind schedule with its work items). Accordingly, I've
copied the ietf-822 list and set Reply-To to point there.
I should also mention that Dan and I saw no problem, and indeed some benefit,
from combining the two drafts.
If you think I can be of assistance, feel free to contact me off-list(s).