http://www.idpf.org/idpf_groups/content.htm

 This document was submitted to the IDPF Board of Directors as an Informational Document as defined by the IDPF’s Policies and Procedures, section 4.6.1.  While Informational Documents do not have an official specification status in the organization, the Working Group felt it important that IDPF members and the public have the opportunity to review the requirements which will form the basis of the specification.  This document was approved by the IDPF Board of Directors as an Informational Document on Monday, February 20^th and approved for submission by the Working Group on Thursday, February 23^rd.  The document was posted for public review on the IDPF website at www.idpf.org.

The Unified OeBPS Container Format Working Group continues to meet on a biweekly basis and is required by these approved requirements to submit a specification via the official output process, as defined by the IDPF Policies & Procedures 4.6.2, by May 1^st, 2006.

The following requirements are required to be met by functional specifications for products that comply with the Unified OeBPS Container Format Working Group version 1.0.

1. The container will support publisher archival of publications, interchange of publications between publishers and the channel and delivery to reading systems and user agents.
2. The container format should be light-weight – easy to create, assemble, interpret, extract components, preferably with widely available tools
3. The container must support OEBPS encapsulation.
4. The container should support encapsulation of other formats.
5. The OEBPS application of the container must contain at least an OEBPS version of the publication.
6. The OEBPS application of the container eventually would enable publishers to produce only the unified content container format for entry into the distribution/sales channels.
7. The container format should be DRM agnostic but should facilitate the optional application of DRM to contained components.
8. Production of reading-system-targeted (e.g. DRM wrapped or ready to be wrapped) publications should be a “lights out” process.
9. The container should provide a method for identifying the encapsulated DRM system, if any.
10. The container format should support optional compression of contained components; such compression should employ royalty-free compression algorithms.
11. The container format should facilitate random access to contained components.
12. The container format should support the exposure of an optional integral "facade book" in cases where the viewer doesn't have rights or software to access the contained publication.
13. The container format should support detection of post-creation content tampering.
14. The container format need not accommodate "streaming" of individual components.
15. The container itself must be able to be validated.
16. Creation of tools to support validation of both the container and encapsulated OEBPS publications is a goal and should be encouraged or done within the working group.
17. The container format should be extensible such that storable content and any descriptions thereof can evolve over time without necessitating changes to the container itself.
18. A container should include all resources needed to completely render the contained publication.  External documents or Web resources explicitly linked to need not be considered part of the publication.
19. Publication definition files (e.g. OEBPS Package files) stored within the container must be stored unencrypted.
20. A container will contain a single publication.  Bundling multiple unique publications for sale should initially be external to each of the publication's containers.
21. Future versions of the container should support encapsulating multiple publications and containers and may communicate bundling/shrink-wrapping information.
22. The container should support the optional inclusion of alternate or derived versions of the contained publication beyond OEBPS (e.g. PDF, ".lit") to support the addition and removal of various formats along the distribution value chain.
23. The target completion date for version 1.0 of Container specification is May 1^st.
24. The container format must provide bootstrapping information to enable unambiguous identification of the root file of the publication and any alternate or derived versions within a container.

Note: Any comments, questions or suggestions on any of the informational documents can be directed to the IDPF.  They will be forwarded to the appropriate contacts in IDPF Working Groups or SIGs.