Created by: jeremydouglass
Re:
For the type subclass, it should be one of those types:
application/zip, application/octet-stream, application/x-zip-compressed, multipart/x-zip
but which one is more adapted?
Probably use application/zip.
It isn't multipart -- that problem space (html form data submission and part splitting with a size header) isn't relevant to .pdex / .pdez. It isn't application/x-zip-compressed -- that says "this is compressed -- but that isn't necessarily true, if people are allowed to zip and unzip their own .pdex / .pdez directories, as zip can also package with no compression at all ( --compression-method store ) -- so no opinion on whether it is compressed or not. In fact, it is quite common to have containers like this intentionally not compressed so that applications can more easily access their contents directly without unpacking.
octet-stream just means "binary stuff". Most workflows that find this and still want to know how to handle it will then fall back to the type / file extension, .pdex, which they may not recognize if for example there isn't a handler pointing to PDE. So if you want minimal good behavior -- like the ability to inspect or unpack a zip packaged library or sketch with macOS Finder or Windows Explorer -- or Konqueror or Nautilus -- then the MIME type fallback should say "this is a zip!" so that you can interact with it without having to first rename it to .zip.
So: Use application/zip.
It is also possible to submit your own IANA Media Type / MIME type -- some examples of custom zip containers with their own registered MIME type include .cbr, .cbz, and .epub. A submission looks like this:
https://www.iana.org/assignments/media-types/application/vnd.comicbook+zip
However, the ones I'm familiar with in "archival container formats" using zip with a custom extension tend to have large ecosystems of software that all use the same format -- and in this case we would be starting out with just PDE, I believe...?