Sam Roberts wrote:
surely you aren't claiming that people don't actually send zipped
pdfs with a content-type of:
content-type: application/x-zip-compressed
You need to separate the notion of ~"working with zip files" from the
notion of transferring compressed data. If you want to keep doing things
the old way, send application/zip and use CTE of whatever. Trying to store
zip "files" inside of MIME entities is forcing a collision of operational
metaphors which must be resolved.
Do we need a multipart/container object of some kind, where the first
entity is a table of contents to the rest of the entities (thereby making
it act like a traditional zip file, but using MIME as storage), or should
it be a single entity with an embedded TOC (using the current tar or zip
or whatever mechanism)? Do we need a new disposition method for "expand"
to go along with a single entity?
A couple of things we know: (1) the application/zip model makes the actual
content opaque, and (2) sending 100s of files as individual members of a
multipart entity (as would be the case with large tarball packages mapped
directly to MIME-as-storage) won't work very well.
Personally I am wondering if the real solution here isn't another major
media-type family which doesn't have the "application" prohibitions, and
which allows MIME agents to directly decode the data. Sounds like
multipart, except that old systems will treat multipart/unknown as
multipart/mixed, showing you the hundreds of files from that tarball as
discrete attachments. Hard problem.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/