On Apr 9, 11:51pm, ned+ietf-822(_at_)mrochek(_dot_)com wrote:
}
} > following CTEs:
}
} > binary
} > 7bit
} > 8bit
} > quoted-printable
} > base64
}
} > gzip (binary)
} > gzip+base64
}
} [...] I agree this is the right idea.
}
} > I do think that we probably at least need to consider the need for two
} > types of compression.
}
} Humpf. I see the rationale, but I'm really uncomfortable with more than
} one compression.
I seem to recall that this all came up long ago, before MIME was even a
proposed standard, and was rejected precisely because of the combinatoric
problem: Every time there's a new encoding or new compression scheme, you
end up having to support every combination of compression and encoding.
Sun tried to solve this years ago in Mailtool with the X-Sun-Encoding-Info
header, which was an unordered list of transformations that had been applied
to the body part, e.g., "tar, compress, btoa" (anybody else remember btoa?).
The receiving software had to know which keywords meant transport encoding,
compression, archiving, etc. and undo them in the "right" order no matter
what the order in the header field. This was an interoperability disaster.
As far as I can tell, none of the reasons why compression was excluded
from MIME in the first place have become any less valid over the years.
--
Bart Schaefer Zanshin
http://www.well.com/user/barts http://www.zanshin.com