
--On Friday, 07 September, 2007 17:27 -0400 Nick Bogaty <nbogaty@idpf.org> wrote:
... 2. The currently adopted OCF standard uses a MIME type of "application/epub+zip". It would be difficult to change that as it has already gone through a standard adoption process and is used in commercially released products. ...
It is up to the IESG as to what to do about this. While I personally generally prefer registration of something that has already been deployed to non-registration and the risk of confusion, many of us would consider establishing a precedent for either arbitrary "+foo" form, and "+zip" in particular, to be a very bad idea. I comments from others on this list would be welcome.
First, a data point you may be unaware of: A fair number vnd. types have been registered that use zip as a container for a bunch of other stuff. But until now none of them used +zip as a type name suffix. I have to say I don't see this as significantly different from the +xml case. Knowing the format of the container can be useful information since it lets you process the type in a generic way. My main concern with the +zip case is whether or not "zip" is sufficiently well defined. I admit to not knowing much about the vagarities of zip.
For future reference for IDPF and others, it would have been much better to have consulted this list about choices of names, etc., before this name was deployed. The "+xml" form, including that used in "oebps-package+xml", is well-established and has fairly specific semantics (to which oebps-package+xml appears to conform). There is no such arrangement for "+zip" or, for some very specific reasons, any other compression scheme.
There's a big difference between registering application/zip as a generic compression/container media type versus adopting a convention of using +zip as a suffix for types which use zip as a containiner for an appplication-specific set of subobjects that need to be carried around as a package. I am strongly opposed to the former, modulo the definition of zip I think the latter may be a good idea. Speaking as an individual contributor, not as media type reviewer. Ned