RE: Media Type Registration for OCF (application/epub+zip) - Review of Informational RFC
To whom it may concern, We apologize for the errors in our previous submissions. Please see the below URL pointing to a Media Type Registration for the Open Container Format (OCF), "application/epub+zip", to be processed as an informational RFC. It has gone through a two week community review period via the iesg@ietf.org and ietf-types@iana.org. The application/template is located at: http://www.idpf.org/draft-conboy-mime-opf-00.txt The published epub specification can be found at: http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm Please send any questions to myself, Nick Bogaty, at nbogaty@idpf.org. Thanks, Nick -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty@idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax
(internet-drafts@ietf.org removed from distribution) --On Thursday, 06 September, 2007 21:23 -0400 Nick Bogaty <nbogaty@idpf.org> wrote:
To whom it may concern,
We apologize for the errors in our previous submissions.
Please see the below URL pointing to a Media Type Registration for the Open Container Format (OCF), "application/epub+zip", to be processed as an informational RFC. It has gone through a two week community review period via the iesg@ietf.org and ietf-types@iana.org.
To be strictly accurate, it has been announced on the ietf-types list, but there have been no substantive comments or review. A few procedural comments (references are to RFC 4288 unless otherwise noted). These comments do not address the substantive content of the proposal. These comments represent my personal observations only; they are not official IETF statements or positions. (1) The proposed name, application/epub+zip, appears to be intended for registration in the standards tree (Section 3 generally and 3.1 in particular). That is acceptable if IDPF is a "recognized standards body" and the definitional document is one of its "formal publications". Whether IDPF is considered to be a "recognized standards body" is up to the IESG, but that designation, in my opinion, usually requires some evidence of an open consensus process (including a review process not restricted to members). Industry consortia are generally not considered "recognized standards bodies". I can find no documented procedures for review and approval of documents, other than a statement about work occurring in working groups, on the IDPF web site. (2) Name forms of a "+suffix" variety are discouraged unless the suffix is well-established (Section 4.2). "+xml" is established as a suffix. "+zip" is not. For reasons that were extensively discussed when the media type system was established, the name of a well-known compression scheme is probably inappropriate for a suffix. So, unless you propose to document the need for that particular suffix independent of specific efforts by IPDF, I would recommend against a standards tree registration containing a "+" in the subtype name. (3) The registration template at http://www.idpf.org/draft-conboy-mime-opf-00.txt is not a registration template for application/epub+zip at all, but one for application/oebps-package+xml. The link originally announced (http://www.idpf.org/draft-idpf-mime-ocf-01.txt) is now dead. Please clarify what you are trying to register and make the registration template consistent with the name and content of your announcements to the ietf-types list. (4) Publication as an Informational RFC requires that the document itself be first posted as an Internet-Draft and not merely placed in the correct format on a private web site (RFC 2223, 4844, 4846). The relevant instructions are referenced from http://www.ietf.org/ID http://www.ietf.org/ietf/1id-guidelines.html and http://www.ietf.org/ID-Checklist.html are particularly relevant. I note, however, that draft-conboy-mime-opf-00.txt, cited as the relevant registration template, has already been published, as RFC 4839. But, as mentioned above, it describes an entirely different media type. So it is, at best, unclear to me what you are trying to do here and where the supporting documentation can be located. regards, John Klensin
The application/template is located at:
http://www.idpf.org/draft-conboy-mime-opf-00.txt
The published epub specification can be found at:
http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm
Please send any questions to myself, Nick Bogaty, at nbogaty@idpf.org. Thanks, Nick -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty@idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax
Dear Mr. Klensin, Thank you for your comments and I apologize for the continuing confusion around this registration. I will follow this email with a re-submission of our registration for OCF. To your points: 1. The IDPF is a recognized standards body which has produced industry standards for the electronic book business since 1999 when it released the Open eBook Publication Structure. Our process includes development of standards within Working Groups, series of public review periods, IP review periods and, finally, membership voting. These processes are documented in the organization's Bylaws, Policies & Procedures, Anti-Trust Policies and Intellectual Property Policies which can all be found at: http://www.idpf.org/doc_library/corpdocs.htm The specific output process for OCF is documented at http://www.idpf.org/ocf/output/index.htm and a full record of public (non-IDPF member) comments and IDPF responses can be found at: http://www.idpf.org/ocf/ocf1.0/download/Container_Comment_Responses_Combined .doc It should also be noted that a previous and recent application for "oebps-package+xml" http://www.ietf.org/rfc/rfc4839.txt was submitted and approved under the standards tree in April 2007. 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. 3. This is my error. The correct registration template is http://www.idpf.org/draft-conboy-mime-ocf-00.txt. I apologize for the confusion. 4. Again, the template was forwarded in error. The correct template is http://www.idpf.org/draft-conboy-mime-ocf-00.txt. With our submission to internet-drafts@ietf.org, we are attempting to have this document posted as an Internet-Draft. One of the options cited on http://www.ietf.org/ietf/1id-guidelines.html is for the Internet-Draft to "be sent as an attachment to the email, or the email may contain a URL which points to a copy of the Internet-Draft stored on a server." We are attempting to post pointing to a copy on our server at http://www.idpf.org/draft-conboy-mime-ocf-00.txt. I apologize for the confusion, I hope this clears things up. Best regards, Nick Bogaty -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty@idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax -----Original Message----- From: John C Klensin [mailto:john-ietf@jck.com] Sent: Friday, September 07, 2007 12:49 AM To: Nick Bogaty Cc: 'Ric Wright'; gc@ebooktechnologies.com; 'John Rivlin'; ietf-types@alvestrand.no Subject: RE: Media Type Registration for OCF (application/epub+zip) - Review of Informational RFC (internet-drafts@ietf.org removed from distribution) --On Thursday, 06 September, 2007 21:23 -0400 Nick Bogaty <nbogaty@idpf.org> wrote:
To whom it may concern,
We apologize for the errors in our previous submissions.
Please see the below URL pointing to a Media Type Registration for the Open Container Format (OCF), "application/epub+zip", to be processed as an informational RFC. It has gone through a two week community review period via the iesg@ietf.org and ietf-types@iana.org.
To be strictly accurate, it has been announced on the ietf-types list, but there have been no substantive comments or review. A few procedural comments (references are to RFC 4288 unless otherwise noted). These comments do not address the substantive content of the proposal. These comments represent my personal observations only; they are not official IETF statements or positions. (1) The proposed name, application/epub+zip, appears to be intended for registration in the standards tree (Section 3 generally and 3.1 in particular). That is acceptable if IDPF is a "recognized standards body" and the definitional document is one of its "formal publications". Whether IDPF is considered to be a "recognized standards body" is up to the IESG, but that designation, in my opinion, usually requires some evidence of an open consensus process (including a review process not restricted to members). Industry consortia are generally not considered "recognized standards bodies". I can find no documented procedures for review and approval of documents, other than a statement about work occurring in working groups, on the IDPF web site. (2) Name forms of a "+suffix" variety are discouraged unless the suffix is well-established (Section 4.2). "+xml" is established as a suffix. "+zip" is not. For reasons that were extensively discussed when the media type system was established, the name of a well-known compression scheme is probably inappropriate for a suffix. So, unless you propose to document the need for that particular suffix independent of specific efforts by IPDF, I would recommend against a standards tree registration containing a "+" in the subtype name. (3) The registration template at http://www.idpf.org/draft-conboy-mime-opf-00.txt is not a registration template for application/epub+zip at all, but one for application/oebps-package+xml. The link originally announced (http://www.idpf.org/draft-idpf-mime-ocf-01.txt) is now dead. Please clarify what you are trying to register and make the registration template consistent with the name and content of your announcements to the ietf-types list. (4) Publication as an Informational RFC requires that the document itself be first posted as an Internet-Draft and not merely placed in the correct format on a private web site (RFC 2223, 4844, 4846). The relevant instructions are referenced from http://www.ietf.org/ID http://www.ietf.org/ietf/1id-guidelines.html and http://www.ietf.org/ID-Checklist.html are particularly relevant. I note, however, that draft-conboy-mime-opf-00.txt, cited as the relevant registration template, has already been published, as RFC 4839. But, as mentioned above, it describes an entirely different media type. So it is, at best, unclear to me what you are trying to do here and where the supporting documentation can be located. regards, John Klensin
The application/template is located at:
http://www.idpf.org/draft-conboy-mime-opf-00.txt
The published epub specification can be found at:
http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm
Please send any questions to myself, Nick Bogaty, at nbogaty@idpf.org. Thanks, Nick -- Nick Bogaty Executive Director International Digital Publishing Forum (IDPF) nbogaty@idpf.org www.idpf.org (212) 924-9081 direct (212) 208-0978 fax
--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. 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. regards, john
--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
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@alvestrand.no [mailto:ietf-types-bounces@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@ebooktechnologies.com; ietf-types@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@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
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@acm.org] Sent: Wednesday, September 12, 2007 10:07 AM To: 'Ned Freed'; 'John C Klensin' Cc: Ric Wright; 'Nick Bogaty'; 'John Rivlin'; 'gc@ebooktechnologies.com'; 'ietf-types@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@alvestrand.no [mailto:ietf-types-bounces@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@ebooktechnologies.com; ietf-types@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@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
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@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@acm.org] Sent: Wednesday, September 12, 2007 10:07 AM To: 'Ned Freed'; 'John C Klensin' Cc: Ric Wright; 'Nick Bogaty'; 'John Rivlin'; 'gc@ebooktechnologies.com'; 'ietf-types@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@alvestrand.no [mailto:ietf-types-bounces@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@ebooktechnologies.com; ietf-types@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@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
participants (4)
-
John C Klensin -
Larry Masinter -
Ned Freed -
Nick Bogaty