Media Type Registration for OCF (application/epub+zip) - Review of Informational RFC

[John C Klensin]

Larry and Ned (and others,

Larry's note(s) represent exactly what I was concerned about,
although I don't know how I feel about his answer.   The zip-ish
registrations in the "vnd." tree strike me as interesting but
irrelevant, since registrations in that tree don't have any
implications beyond that particular vendor.  My concern about
application/xxxx+zip is precisely that, given the +xml
precedent, it will be construed as a member of a family of names
(construed now or after someone comes along and defines that
family).  That is ok too, as long as we can be reasonably
assured that the "epub+zip" definition is consistent with the
definition of that family... except that the latter definition
hasn't been written yet, so it is hard to be assured that the
definitions will be consistent.

Certainly, if the community is willing to set up a second
xxx+thing family for files compressed with some well-defined zip
form, it would be a way out of this difficulty and a way that I
could probably support.   Larry has suggested a way to construct
that definition, but I'm not sure I've seen anyone volunteering
to write it and shepherd it through the works yet.

    john


--On Wednesday, 12 September, 2007 10:13 -0700 Larry Masinter
<LMM at acm.org> wrote:

> I should have noted that the document describing the
> +zip convention should also update the (1993) MIME
> type registration for application/zip.
> 
> 
> 
> -----Original Message-----
> From: Larry Masinter [mailto:LMM at acm.org] 
> Sent: Wednesday, September 12, 2007 10:07 AM
> To: 'Ned Freed'; 'John C Klensin'
> Cc: Ric Wright; 'Nick Bogaty'; 'John Rivlin';
> 'gc at ebooktechnologies.com'; 'ietf-types at alvestrand.no'
> Subject: RE: Media Type Registration for OCF
> (application/epub+zip) - Review of Informational RFC
> 
> If the problem with "+zip" is that it isn't sufficiently well
> defined, perhaps an approach would be to define it:
> 
> I'd start with:
> 
>    http://en.wikipedia.org/wiki/ZIP_(file_format) 
> 
> (maybe leaving out the history, but including most of the
> introduction and technical information)
> 
> and note that just as
> 
> " Some software uses the ZIP file format as a wrapper for a
> large number of small items in a specific structure. Generally
> when this is done a different file extension is used."
> 
> In those situations, using a different MIME type seems also
> appropriate, and using "+zip" in the MIME type appropriate
> (but not mandatory).
> 
> 
> -----Original Message-----
> From: ietf-types-bounces at alvestrand.no
> [mailto:ietf-types-bounces at alvestrand.no] On Behalf Of Ned
> Freed Sent: Monday, September 10, 2007 4:50 PM
> To: John C Klensin
> Cc: 'Ric Wright'; Nick Bogaty; 'John Rivlin';
> gc at ebooktechnologies.com; ietf-types at alvestrand.no
> Subject: RE: Media Type Registration for OCF
> (application/epub+zip) - Review of Informational RFC
> 
> 
> 
>> --On Friday, 07 September, 2007 17:27 -0400 Nick Bogaty
>> <nbogaty at 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
>