ISO/IEC 26300-3:2015

INTERNATIONAL ISO/IEC
STANDARD 26300-3
First edition
2015-07-01
Information technology — Open
Document Format for Office Applications
(OpenDocument) v1.2 —
Part 3:
Packages
Technologies de l'information — Format de document ouvert pour
applications de bureau (OpenDocument) v1.2 —
Partie 3: Progiciels
Reference number
©
ISO/IEC 2015
©  ISO/IEC 2015
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any
means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission.
Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of
document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any
patent rights identified during the development of the document will be in the Introduction and/or on the ISO
list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT),
see the following URL: Foreword — Supplementary information.
Document Format for Office Applications (OpenDocument) v1.0 (second edition)] and was adopted, under the
PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its
approval by the national bodies of ISO and IEC. The content of ISO/IEC 26300-3 and OASIS OpenDocument
v1.0 2nd ed. is identical.
ISO/IEC 26300-3 consists of the following parts, under the general title Information technology — Open
Document Format for Office Applications (OpenDocument) v1.2:
— Part 1: OpenDocument Schema
— Part 2: Recalculated Formula (OpenFormula) Format

© ISO/IEC 2015 – All rights reserved iii

Open Document Format for Office
Applications (OpenDocument)
Version 1.2
Part 3: Packages
OASIS Standard
29 September 2011
Specification URIs:
This version:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.odt
(Authoritative)
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.pdf
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html
Previous version:
http://docs.oasis-open.org/office/v1.2/csd06/OpenDocument-v1.2-csd06-part3.odt
(Authoritative)
http://docs.oasis-open.org/office/v1.2/csd06/OpenDocument-v1.2-csd06-part3.pdf
http://docs.oasis-open.org/office/v1.2/csd06/OpenDocument-v1.2-csd06-part3.html
Latest version:
http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.odt (Authoritative)
http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.pdf
http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2-part3.html
Technical Committee:
OASIS Open Document Format for Office Applications (OpenDocument) TC
Chairs:
Rob Weir, IBM
Michael Brauer, Oracle Corporation
Editors:
Patrick Durusau
Dennis Hamilton
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 1 of 35
© ISO/IEC 2015 – All rights reserved

Michael Brauer, Oracle Corporation
Related work:
This document is part of the OASIS Open Document Format for Office Applications
(OpenDocument) Version 1.2 specification.
The OpenDocument v1.2 specification has these parts:
OpenDocument v1.2 part 1: OpenDocument Schema
OpenDocument v1.2 part 2: Recalculated Formula (OpenFormula) Format
OpenDocument v1.2 part 3: Packages (this part)
OpenDocument v1.2 part 3 defines these schemas and ontologies:
OpenDocument v1.2 Manifest Schema
OpenDocument v1.2 Digital Signature Schema
OpenDocument v1.2 Package Metadata Manifest Ontology
Declared XML namespaces:
urn:oasis:names:tc:opendocument:xmlns:manifest:1.0
urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0
http://docs.oasis-open.org/ns/office/1.2/meta/pkg#
Abstract:
This document is part of the Open Document Format for Office Applications
(OpenDocument) Version 1.2 specification.
It defines a package format for OpenDocument documents.
Status:
This document was last revised or approved by the OASIS Open Document Format for
Office Applications (OpenDocument) TC on the above date. The level of approval is also
listed above. Check the "Latest version" location noted above for possible later revisions
of this document.
Technical Committee members should send comments on this specification to the
Technical Committee’s email list. Others should send comments to the Technical
Committee by using the “Send A Comment” button on the Technical Committee’s web
page at http://www.oasis-open.org/committees/office/.
For information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent licensing terms, please refer to
the Intellectual Property Rights section of the Technical Committee web page
(http://www.oasis-open.org/committees/office/ipr.php).
Citation format:
When referencing this specification the following citation format should be used:
OpenDocument-v1.2-part3
Open Document Format for Office Applications (OpenDocument) Version 1.2 Part 3:
Packages. 29 September 2011. OASIS Standard. http://docs.oasis-
open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html.
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 2 of 35
© ISO/IEC 2015 – All rights reserved

Notices
Copyright © OASIS Open 2002–2011. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS
Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the
OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works
that comment on or otherwise explain it or assist in its implementation may be prepared, copied,
published, and distributed, in whole or in part, without restriction of any kind, provided that the
above copyright notice and this section are included on all such copies and derivative works.
However, this document itself may not be modified in any way, including by removing the
copyright notice or references to OASIS, except as needed for the purpose of developing any
document or deliverable produced by an OASIS Technical Committee (in which case the rules
applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its
successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
OASIS requests that any OASIS Party or any other party that believes it has patent claims that
would necessarily be infringed by implementations of this OASIS Committee Specification or
OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the
OASIS Technical Committee that produced this specification.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of
ownership of any patent claims that would necessarily be infringed by implementations of this
specification by a patent holder that is not willing to provide a license to such patent claims in a
manner consistent with the IPR Mode of the OASIS Technical Committee that produced this
specification. OASIS may include such claims on its website, but disclaims any obligation to do
so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such rights. Information on
OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS
Technical Committee can be found on the OASIS website. Copies of claims of rights made
available for publication and any assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of such proprietary rights by
implementers or users of this OASIS Committee Specification or OASIS Standard, can be
obtained from the OASIS TC Administrator. OASIS makes no representation that any information
or list of intellectual property rights will at any time be complete, or that any claims in such list are,
in fact, Essential Claims.
The names "OASIS", “OpenDocument”, “Open Document Format”, and “ODF” are trademarks of
OASIS, the owner and developer of this specification, and should be used only to refer to the
organization and its official outputs. OASIS welcomes reference to, and implementation and use
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 3 of 35
© ISO/IEC 2015 – All rights reserved

of, specifications, while reserving the right to enforce its marks against misleading uses. Please
see http://www.oasis-open.org/who/trademark.php for above guidance.
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 4 of 35
© ISO/IEC 2015 – All rights reserved

Table of Contents
1 Introduction. 8
1.1 Introduction.8
1.2 Terminology.8
1.3 Normative References.8
1.4 Non Normative References.9
1.5 Namespaces.9
2 Packages, Package Consumers and Package Producers.11
2.1 Introduction.11
2.2 Packages.11
2.2.1 OpenDocument Package.11
2.2.2 OpenDocument Extended Package.12
2.3 Producers.12
2.3.1 OpenDocument Package Producer.12
2.3.2 OpenDocument Package Extended Producer.12
2.4 OpenDocument Package Consumer.12
3 Packages.13
3.1 General. 13
3.2 Manifest.13
3.3 MIME Media Type.13
3.4 Encryption.14
3.4.1 General.14
3.4.2 Encryption Process.14
3.5 Digital Signatures.15
3.6 Metadata.15
3.7 Usage of IRIs Within Packages.15
3.8 Preview Image.17
4 Manifest File.18
4.1 Introduction.18
4.2 .18
4.3 .18
4.4 .18
4.5 .19
4.6 .19
4.7 .19
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 5 of 35
© ISO/IEC 2015 – All rights reserved

4.8 Manifest Attributes.20
4.8.1 manifest:algorithm-name.20
4.8.2 manifest:checksum.20
4.8.3 manifest:checksum-type.20
4.8.4 manifest:full-path.21
4.8.5 manifest:initialisation-vector.21
4.8.6 manifest:start-key-generation-name.22
4.8.7 manifest:key-size.22
4.8.8 manifest:iteration-count.22
4.8.9 manifest:key-derivation-name.23
4.8.10 manifest:media-type.23
4.8.11 manifest:preferred-view-mode.23
4.8.12 manifest:salt.24
4.8.13 manifest:size.24
4.8.14 manifest:version.24
5 Digital Signatures File.26
5.1 Introduction.26
5.2 .26
5.3 .26
5.4 Digital Signatures Attributes.28
5.4.1 dsig:version.28
6 Metadata Manifest Files.29
6.1 General. 29
6.2 pkg:Document.29
6.3 pkg:File. 29
6.4 pkg:MetadataFile.29
6.5 pkg:Element.29
6.6 pkg:hasPart.29
6.7 pkg:mimeType.30
7 Datatypes.31
7.1 Introduction.31
7.2 W3C Schema Datatypes.31
7.3 Other Datatypes.31
7.3.1 namespacedToken.31
Appendix A. Schemas.32
A.1. OpenDocument Manifest Schema.32
A.2. OpenDocument Digital Signature Schema.32
Appendix B. OpenDocument Metadata Manifest Ontology.33
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 6 of 35
© ISO/IEC 2015 – All rights reserved

Appendix C. Zip File Structure (Non normative).34
Appendix D. Changes From “Open Document Format for Office Applications (OpenDocument)
v1.1” (Non Normative).35
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 7 of 35
© ISO/IEC 2015 – All rights reserved

© ISO/IEC 2015 – All rights reserved

1 Introduction
1.1 Introduction
This document is part of the Open Document Format for Office Applications (OpenDocument)
Version 1.2 specification. It defines a package format for OpenDocument documents.
1.2 Terminology
All text is normative unless otherwise labeled.
Text with a gray background color which is contained in boxes is informative. It lists the XML
element-element and element-attribute relations for cross reference purposes.
Within the normative text of this specification, the terms “shall”, “shall not”, “should”, “should not”,
“may” and “need not” are to be interpreted as described in Annex H of [ISO/IEC Directives].
XML Element, attribute names, attribute value types, and attribute values appear in monospace
font.
1.3 Normative References
[ISO/IEC Directives] ISO/IEC Directives, Part 2 (Fifth Edition) Rules for the structure and
drafting of International Standards, International Organization for Standardization and International
Electrotechnical Commission, 2004
[OWL] Deborah L. McGuinness, Frank van Harmelen, OWL Web Ontology Language Overview,
http://www.w3.org/TR/2004/REC-owl-features-20040210/, W3C, 2004.
[PNG] David Duce, Portable Network Graphics (PNG) Specification (Second Edition),
http://www.w3.org/TR/2003/REC-PNG-20031110, W3C, 2003.
[RDF-CONCEPTS] Graham Klyne, Jeremy J. Carroll, Brian McBride, Resource Description
Framework (RDF): Concepts and Abstract Syntax, http://www.w3.org/TR/2004/REC-rdf-concepts-
20040210/, W3C, 2004.
[RDF-XML] Dave Beckett, Brian McBride,  RDF/XML Syntax Specification (Revised),
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/, W3C, 2004.
[RFC2898] B. Kaliski, PKCS #5: Password-Based Cryptography Specification Version 2.0,
http://www.ietf.org/rfc/rfc2898.txt, IETF, 2000.
[RFC3174] D. Eastlake, 3rd, P. Jones, US Secure Hash Algorithm 1 (SHA1),
http://www.ietf.org/rfc/rfc3174.txt, IETF, 2001.
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI):
Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt, IETF, 2005.
[RFC3987] M. Duerst, M. Suignard, Internationalized Resource Identifiers (IRIs),
http://www.ietf.org/rfc/rfc3987.txt, IETF, 2005.
[RFC4288] N. Freed, J. Klensin, Media Type Specifications and Registration Procedures,
http://www.ietf.org/rfc/rfc4288.txt, IETF, 2005.
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 8 of 35
© ISO/IEC 2015 – All rights reserved

[RNG] ISO/IEC 19757-2 Document Schema Definition Language (DSDL) -- Part 2: Regular-
grammar-based validation -- RELAX NG, International Organization for Standardization and
International Electrotechnical Commission, 2003
[Schneier] Bruce Schneier, Applied Cryptography (Second Edition), John Wiley & Sons,
ISBN: 0-471-11709-9, 1996
[XAdES] XML Advanced Electronic Signatures (XAdES) (ETSI TS 101 903 v1.4.1 June
2009), ETSI, 650 Route des Lucioles, F-06921 Sophia Antipolis Cedex, FRANCE,
http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=28064, 2009.
[XML-ID] Jonathan Marsh, Daniel Veillard, Norman Walsh, xml:id Version 1.0,
http://www.w3.org/TR/2005/REC-xml-id-20050909/, W3C, 2005.
[xml-names] Tim Bray et al., Namespaces in XML 1.0 (Second Edition),
http://www.w3.org/TR/2006/REC-xml-names-20060816, W3C, 2006.
[XML1.0] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau ,
Extensible Markup Language (XML) 1.0 (Fourth Edition), http://www.w3.org/TR/2006/REC-xml-
20060816/, W3C, 2004.
[xmldsig-core] Donald Eastlake, Joseph Reagle, David Solo, Frederick Hirsch, Thomas
Roessler, XML Signature Syntax and Processing (Second Edition),
http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/, W3C, 2008.
[xmlenc-core] Donald Eastlake, Joseph Reagle, XML Encryption Syntax and Processing,
http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/, W3C, 2002.
[xmlschema-2] Paul V. Biron, Ashok Malhotra, XML Schema Part 2: Datatypes Second Edition,
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, W3C, 2004.
[ZIP] PKWARE Inc. Zip APPNOTE Version 6.2.0, available at
http://www.pkware.com/support/application-note-archives, 2004
1.4 Non Normative References
[Schneier-Errata] Bruce Schneir, Applied Cryptography 2nd. Ed. - Errata,
http://www.schneier.com/book-applied-errata.html, 1998.
1.5 Namespaces
The namespaces used or defined by OpenDocument part 3 are listed in tables 1 and 2.
The prefix column in tables 1 and 2 lists the namespace prefixes this specification uses when
referring to elements and attributes in different namespaces. Conforming OpenDocument
documents may substitute other namespace prefixes, bound to the listed namespace URI's, in
accordance with the Namespaces in XML specification [xml-names].
Note: XML namespaces are employed in accordance with the Namespaces in XML W3C
Recommendation [xml-names].
Table 1 - XML Namespaces defined by the OpenDocument specification part 3
Prefix Description Namespace
manifest Elements and attribute contained in urn:oasis:names:tc:opendocument:xmlns:
the package manifest. manifest:1.0
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 9 of 35
© ISO/IEC 2015 – All rights reserved

Prefix Description Namespace
dsig Elements and attribute contained in urn:oasis:names:tc:opendocument:xmlns:
digital signature files. digitalsignature:1.0
Table 2 - XML Namespaces defined by the OpenDocument metadata manifest ontology
Prefix Description Namespace
pkg OWL classes and properties http://docs.oasis-
contained in metadata manifest files. open.org/ns/office/1.2/meta/pkg#
Table 3 - XML Namespaces used by the OpenDocument digital signature schema
Prefix Description Namespace
ds XML Digital Signature Syntax and http://www.w3.org/2000/09/xmldsig#
Processing namespace (see [xmldsig-
core])
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 10 of 35
© ISO/IEC 2015 – All rights reserved

2 Packages, Package Consumers and Package
Producers
2.1 Introduction
The OpenDocument specification defines conformance for packages, package consumers, and
package producers, with two conformance classes called conforming and extended conforming.
This chapter defines the basic requirements for the individual conformance targets.
2.2 Packages
2.2.1 OpenDocument Package
An OpenDocument Package shall meet the following requirements:
A) It shall be a Zip file, as defined by [ZIP]. All files contained in the Zip file shall be non
compressed (STORED) or compressed using the “deflate” (DEFLATED) algorithm.
B) It shall contain a file “META-INF/manifest.xml”. This file shall meet the following requirements:
B.1) The file shall be a well formed XML document in accordance with the [XML1.0]
specification.
B.2) The XML root element of the file shall be a element 4.2.
B.3) The XML file shall be valid with respect to the manifest schema defined in appendix A.1
OpenDocument Manifest Schema.
C) It should contain a file “mimetype”.
D) It may contain files whose relative paths begin with “META-INF/” and whose names contain the
string “signatures”. These file shall meet the following requirements:
D.1) The files shall be well-formed XML files in accordance with [XML1.0].
D.2) The XML root element of each file shall be a element
5.2.
D.3) The files shall be valid with respect to the digital signature schema defined in appendix
A.2 OpenDocument Digital Signature Schema.
E) It shall not contain other files whose relative path begins with “META-INF/” other than than
those listed in B) and D).
F) The files listed in (B) and (D) meet the following requirements:
F.1) They shall be namespace-well-formed with regard to the XML Namespaces specification
[xml-names].
F.2) They shall conform to the xml-id specification [XML-ID].
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 11 of 35
© ISO/IEC 2015 – All rights reserved

2.2.2 OpenDocument Extended Package
G) An OpenDocument Extended Package shall meet all requirements of a conforming package
except item E) of 2.2.1.
2.3 Producers
2.3.1 OpenDocument Package Producer
An OpenDocument Package Producer is a program that creates conforming OpenDocument
packages, and that meets the additional requirements:
A) It may produce conforming OpenDocument extended packages, but it shall have a mode of
operation where all OpenDocument packages that are created are conforming OpenDocument
packages.
B) It shall be accompanied by a document that defines all implementation-defined values used by
the OpenDocument package producer.
2.3.2 OpenDocument Package Extended Producer
An OpenDocument Package Extended Producer is a program that creates conforming
OpenDocument extended packages. It shall be accompanied by a document that defines all
implementation-defined values used by the OpenDocument package producer.
2.4 OpenDocument Package Consumer
An OpenDocument Package Consumer is a program that can parse and interpret OpenDocument
packages, and that meets the following additional requirements:
A) It shall be able to parse and interpret OpenDocument packages and OpenDocument extended
packages, but it need not interpret the semantics of all elements, attributes and attribute values.
B) The XML parser used to parse the files listed in 2.2.1 (B) and 2.2.1 (D) meets the following
requirements:
B.1) It shall be a nonvalidating XML processor with regard to the XML 1.0 specification
[XML1.0].
B.2) It shall be a conforming processor with regard to the XML Namespaces specification [xml-
names].
B.3) It shall conform to the xml-id specification [XML-ID].
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 12 of 35
© ISO/IEC 2015 – All rights reserved

3 Packages
3.1 General
OpenDocument defines a package file to store the XML content of a document as separate parts
together with associated binary data as file entries in a single package file. These file entries may
be compressed to further reduce the storage taken by the package. This package is a Zip file
[ZIP], whose structure is described in Appendix C. OpenDocument Packages impose additional
structure on the Zip file to accomplish the representation of OpenDocument Format documents.
A document within a package may consist of a set of files creating a unit, for instance the set of
files specified by OpenDocument part 1. These files may be located in the root of the package, or
within a directory. If they are contained in the root of the package, they are called document. If
they are located within a directory, the document they constitute is called a sub document. A
package may contain multiple sub documents, but only a single document can be contained in the
root of the package. Unless otherwise stated, the term document refers to the document
contained in the root of the package. This may include sub documents.
3.2 Manifest
All OpenDocument packages shall contain a file named “META-INF/manifest.xml”. This file is the
OpenDocument package manifest. The manifest provides :
• A list of all of the files in the package (except those specifically excluded from the manifest).
• The MIME media type of each file in the package.
• If a file is stored in the file data in encrypted form, the manifest provides information required
to decrypt the file correctly when the encryption key is also supplied.
The format of the manifest file is specified in chapter 4.
For all files contained in a package, with exception of the “mimetype” file and files whose relative
path starts with “META-INF/”, the “META-INF/manifest.xml” file shall contain exactly one
element whose manifest:full-path attribute's value references
the file.
The “META-INF/manifest.xml” file need not contain elements 4.3
whose manifest:full-path attribute 4.8.4 references files whose relative path start with
"META-INF/". The file shall not contain elements whose
manifest:full-path attribute value references the “META-INF/manifest.xml” file itself or the
“mimetype” file.
The “META-INF/manifest.xml” file should contain a element whose
manifest:full-path attribute has the value "/". This element specifies information regarding
the document stored in the root of the package. This entry shall exist if the package contains a file
"mimetype"
3.3 MIME Media Type
If a MIME media type for a document exists, then an OpenDocument package should contain a
file with name “mimetype”. The content of this file shall be the ASCII encoded MIME media type
associated with the document. See [RFC4288].
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 13 of 35
© ISO/IEC 2015 – All rights reserved

The “mimetype” file shall be the first file of the zip file. It shall not be compressed, and it shall not
use an 'extra field' in its header.
If the file named “META-INF/manifest.xml” contains a element
whose manifest:full-path attribute has the value "/", then a "mimetype" file shall exist, and
the content of the “mimetype” file shall be equal to the value of the manifest:media-type
attribute 4.8.10 of that element.
Note: The purpose is to allow the type of document represented by the package to be discovered
through 'magic number' mechanisms, such as Unix's file/magic utility. If a Zip file contains a file at
the beginning of the file that is uncompressed, and has no extra data in the header, then its file
name and data can be found at fixed positions from the beginning of the package. More
specifically, one will find:
• the string 'PK' at position 0 of all zip files
• the string 'mimetype' beginning at position 30
• the media type itself beginning at position 38.
3.4 Encryption
3.4.1 General
OpenDocument packages may be encrypted by encrypting some or all files within the package.
The encryption process takes place in the following stages:
• A single start key is generated and used for all of the keys that will be derived.
• The derived key is generated based on the start key.
• The files are encrypted based on the derived key and the encryption algorithm.
The information regarding the algorithms that were used to encrypt a file and required parameters
are contained in the manifest. The manifest shall not be encrypted.
Each file entry that is encrypted shall be compressed with the “deflate” algorithm before being
encrypted. Encrypted file entries shall be flagged as 'STORED' rather than 'DEFLATED' in the Zip
file's central directory. The size of the encrypted file should replace the real size value in the file
entry's central directory records, its local file header and the data descriptor, if any. The original
uncompressed, unencrypted size shall be contained in the manifest:size 4.8.13 attribute of
the 4.3 element for the file entry.
The encrypted form can be of greater size than the DEFLATED file used as the plaintext.
Note: The encrypted form may be of greater because of padding of plaintext, inclusion of
additional information, and other characteristics of the encryption technique).
The encryption method shall be such that the exact size and value of the plaintext DEFLATED file
is recovered by the corresponding decryption process.
3.4.2 Encryption Process
The three stages of the encryption process proceed as follows, using the legacy algorithms to
illustrate each stage:
1.The start key is generated: The byte sequence representing the password in UTF-8 is used to
generate a 20-byte SHA1 digest (see [RFC3174]).
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 14 of 35
© ISO/IEC 2015 – All rights reserved

2.For each file to be encrypted, a separate derived key is generated from the start key: The
PBKDF2 algorithm based on the HMAC-SHA-1 function (see [RFC2898]) is used for the key
derivation. For each file, a 16-byte salt is generated by a random generator. The salt is used
together with the start key to derive a unique 128-bit key for each file. The default iteration count
for the algorithm is 1024.
3.The files are encrypted: The random number generator is used to generate the 8-byte
initialization vector for the algorithm. The derived key is used together with the initialization vector
to encrypt the file using the Blowfish algorithm in 8-bit cipher feedback (8-bit CFB) mode (see
[Schneier]).
3.5 Digital Signatures
Files within a package may have a digital signature applied. Digital signatures are stored in one or
more files whose relative paths begin with “META-INF/”. The names of these files shall contain
the term “signatures”.
The format of digital signature files is specified in chapter 5.
3.6 Metadata
Metadata for documents contained in an OpenDocument package may be expressed using the
model of the W3C Resource Description Framework [RDF-CONCEPTS].
A document or sub document that is stored in a package may contain any number of metadata
files. The content of a metadata files shall conform to the [RDF-XML] specification.
Implementations that are consumers as well as producers should preserve all metadata files.
All metadata files of a document or sub document shall be listed in a separate metadata manifest
file, which has the file name “manifest.rdf”. This file enumerates metadata files and their
relationships to other files in an OpenDocument package. See chapter 6.
In addition to metadata files, the "manifest.rdf" file may list other files which are contained in the
document or sub document that contain RDF metadata, like files that contain RDFa metadata.
The "manifest.rdf" file need not exist if a document or sub document does not contain any files
that contain RDF metadata.
All references to a resource within the same package that occur within metadata file shall be
represented by relative IRIs to the resource. This includes values of rdf:about attributes
occurring within metadata files or metadata manifest files.
3.7 Usage of IRIs Within Packages
Within the files contained in a package, relative IRIs as defined by [RFC3987] may be used to
reference other files within the same package.
OpenDocument Package Consumers shall resolve relative IRIs that occur within a file of a
package as follows:
1. The file entry path is the file name of the file within the Zip file which contains the relative IRI,
including its relative path.
2. The package base IRI is the base IRI which would be established for the package itself as
defined in §5.1 of [RFC3986].
3. If the relative IRI does not match the rule for "relative-ref" defined in §4.2 of [RFC3986] or if the
relative IRI does start with a "/" character (U+002F, SOLIDUS) then it is resolved as defined in
§5.2 of [RFC3986] with the package base IRI as base URI.
OpenDocument-v1.2-os-part3 29 September 2011
Copyright © OASIS Open 2002 - 2011. All Rights Reserved.  Standards Track Work Product Page 15 of 35
© ISO/IEC 2015 – All rights reserved

4. If the relative IRI references matches the rule for "relative-ref" defined in §4.2 of [RFC3986]
and its "relative-part" component matches the "path-empty" rule it shall be resolved as a
"Same-Document" references defined in §4.4 of [RFC3986].
5. Otherwise the "relative-part" component of the relative IRI is copied into a relative IRI buffer
and an empty file entry path buffer is created
6. If the file entry path does contain a "/" character (U+002F, SOLIDUS) then the file path up to
and including the last "/" character is copied into the file entry buffer.
7. If the relative IRI buffer starts with the character sequence "./" (U+002E, FULL STOP, followed
by U+002F, SOLIDUS) then that character sequence it removed from the buffer. Continue with
step 7.
8. If the content of the relative IRI buffer is the character sequence "." (U+002E, FULL STOP),
the content of the relative IRI buffer is removed. Continue with step 11.
9. If the content of the relative IRI buffer is the character sequence "." (U+002E, FULL STOP,
followed by U+002E, FULL STOP) and
• if the file entry path buffer is empty, then the content of the relative IRI buffer is replaced
with "." (U+002E, FULL STOP). The query and fragment components of the relative IRI, if
present, are appended to the relative IRI buffer, including the "?" (U+003F, QUESTION
MARK) and "#" (U+0023, NUMBER SIGN) delimiter characters. The content of the relative
IRI buffer then is resolved as defined in §5.2 of [RFC3986] with the package base IRI as
base URI.
• if the file entry path buffer contains at least one relative path component, the last relative
path component up to and including the last "/" character (U+002F, SOLIDUS) is removed.
The "." character sequence is removed from the IRI buffer. Continue with step 11.
10.If a fragment buffer has been created and is not empty, its c
...