Annex H: Conformance Requirements

M1.1

The package implementer shall require a part name.

8.1, 8.1.1

×

M1.2

The package implementer shall require a content type and the format designer shall specify the content type.

8.1

×

×

M1.3

A part name shall not have empty segments.

0

×

M1.4

A part name shall start with a forward slash ("/") character.

0

×

M1.5

A part name shall not have a forward slash as the last character.

0

×

M1.6

A segment shall not hold any characters other than pchar characters. .

0

×

M1.7

A segment shall not contain percent-encoded forward slash ("/"), or backward slash ("\") characters.

0

×

M1.8

A segment shall not contain percent-encoded unreserved characters.

0

×

M1.9

A segment shall not end with a dot (".") character.

0

×

M1.10

A segment shall include at least one non-dot character

0

×

M1.11

A package implementer shall neither create nor recognize a part with a part name derived from another part name by appending segments to it.

8.1.1.1

×

M1.12

Part name equivalence is determined by comparing part names as case-insensitive ASCII strings. Packages shall not contain equivalent part names and package implementers shall neither create nor recognize packages with equivalent part names.

8.1.1.2

×

M1.13

Package implementers shall only create and only recognize parts with a content type; format designers shall specify a content type for each part included in the format. Content types for package parts shall fit the definition and syntax for media types as specified in RFC 2616, §3.7.

8.1.2

×

×

M1.14

Content types shall not use linear white space either between the type and subtype or between an attribute and its value. Content types also shall not have leading or trailing white spaces. Package implementers shall create only such content types and shall require such content types when retrieving a part from a package; format designers shall specify only such content types for inclusion in the format.

8.1.2

×

×

M1.15

The package implementer shall require a content type that does not include comments and the format designer shall specify such a content type.

8.1.2

×

×

M1.16

If the package implementer specifies a growth hint, it is set when a part is created and the package implementer shall not change the growth hint after the part has been created.

8.1.3

×

×

M1.17

XML content shall be encoded using either UTF-8 or UTF-16. If any part includes an encoding declaration, as defined in §4.3.3 of the XML 1.0 specification, that declaration shall not name any encoding other than UTF-8 or UTF-16. Package implementers shall enforce this requirement upon creation and retrieval of the XML content.

8.1.4

×

M1.18

DTD declarations shall not be used in the XML markup defined in this Open Packaging specification. Package implementers shall enforce this requirement upon creation and retrieval of the XML content and shall treat the presence of DTD declarations as an error.

8.1.4

×

M1.19

If the XML content contains the Markup Compatibility namespace, as described in Part 5: "Markup Compatibility and Extensibility", it shall be processed by the package implementer to remove Markup Compatibility elements and attributes, ignorable namespace declarations, and ignored elements and attributes before applying subsequent validation rules.

8.1.4

×

M1.20

XML content shall be valid against the corresponding XSD schema defined in this Open Packaging specification. In particular, the XML content shall not contain elements or attributes drawn from namespaces that are not explicitly defined in the corresponding XSD unless the XSD allows elements or attributes drawn from any namespace to be present in particular locations in the XML markup. Package implementers shall enforce this requirement upon creation and retrieval of the XML content.

8.1.4

×

M1.21

XML content shall not contain elements or attributes drawn from "xml" or "xsi" namespaces unless they are explicitly defined in the XSD schema or by other means described in this Open Packaging specification. Package implementers shall enforce this requirement upon creation and retrieval of the XML content.

8.1.4

×

M1.22

Package implementers and format designers shall not create content types with parameters for the package-specific parts defined in this Open Packaging specification and shall treat the presence of parameters in these content types as an error.

Annex F

×

×

M1.23

XML markup might contain Unicode strings referencing other parts as values of the xsd:anyURI data type. Format consumers shall convert these Unicode strings to URIs, as defined in Annex A, "Resolving Unicode Strings to Part Names," before resolving them relative to the base URI of the part containing the Unicode string.

8.2.1

×

M1.24

Some types of content provide a way to override the default base URI by specifying a different base in the content. In the presence of one of these overrides, format consumers shall use the specified base URI instead of the default.

8.2.1

×

M1.25

The Relationships part shall not have relationships to any other part. Package implementers shall enforce this requirement upon the attempt to create such a relationship and shall treat any such relationship as invalid.

8.3.1

×

M1.26

The package implementer shall require that every Relationship element has an Id attribute, the value of which is unique within the Relationships part, and that the Id type is xsd:ID, the value of which conforms to the naming restrictions for xsd:ID as described in the W3C Recommendation "XML Schema Part 2: Datatypes."

8.3.3

×

M1.27

The package implementer shall require the Type attribute to be a URI that defines the role of the relationship and the format designer shall specify such a Type.

8.3.3.2

×

×

M1.28

The package implementer shall require the Target attribute to be a URI reference pointing to a target resource. The URI reference shall be a URI or a relative reference.

8.3.3.2

×

M1.29

When set to Internal, the Target attribute shall be a relative reference and that reference is interpreted relative to the "parent" part. For package relationships, the package implementer shall resolve relative references in the Target attribute against the pack URI that identifies the entire package resource.

8.3.3.2

×

M1.30

The package implementer shall name relationship parts according to the special relationships part naming convention and require that parts with names that conform to this naming convention have the content type for a Relationships part

8.3.4

×

M1.31

Consumers shall process relationship markup in a manner that conforms to Part 5: "Markup Compatibility and Extensibility". Producers editing relationships based on this version of the relationship markup specification shall not preserve any ignored content, regardless of the presence of any preservation attributes as defined in Part 5: "Markup Compatibility and Extensibility".

8.3.5

×

×

M1.32

If a fragment identifier is allowed in the Target attribute of the Relationship element, a package implementer shall not resolve the URI to a scope less than an entire part.

8.3.3.2

×

M1.33

A Unicode string representing a URI can be passed to the producer or consumer. The producing or consuming application shall convert the Unicode string to a URI. If the URI is a relative reference, the application shall resolve it using the base URI of the part, which is expressed using the pack scheme, to the URI of the referenced part.

Annex A

×

×

M1.34

If a consumer converts the URI back into an IRI, the conversion shall be performed as specified in §3.2 of RFC 3987.

A.2

×

O1.1

The package implementer might allow a growth hint to be provided by a producer.

8.1, 8.1.3

×

O1.2

Format designers might restrict the usage of parameters for content types.

8.1.2

×

O1.3

The package implementer might ignore the growth hint or adhere only loosely to it when specifying the physical mapping.

8.1.3

×

O1.4

If the format designer permits it, parts can contain Unicode strings representing references to other parts. If allowed by the format designer, format producers can create such parts and format consumers shall consume them.

8.2.1

×

×

×

O1.5

The package implementer might allow a TargetMode to be provided by a producer.

8.3.3.2

×

O1.6

A format designer might allow fragment identifiers in the value of the Target attribute of the Relationship element.

8.3.3.2

×

O1.7

Producers might generate relationship markup that uses the versioning and extensibility mechanisms defined in Part 5: "Markup Compatibility and Extensibility" to incorporate elements and attributes drawn from other XML namespaces.

8.3.5

×

M2.1

The Content Types stream shall not be mapped to a part by the package implementer.

9.1.2.1

×^A

M2.2

The package implementer shall define a physical package format with a mapping for the required components package, part name, part content type and part contents.

9.1.1

×

M2.3

The package implementer shall define a format mapping with a mechanism for associating content types with parts.

9.1.2.1

×

M2.4

The package implementer shall require that the Content Types stream contain one of the following for every part in the package:

One matching Default element

One matching Override element

Both a matching Default element and a matching Override element, in which case the Override element takes precedence.

9.1.2.2

×^A

M2.5

The package implementer shall require that there not be more than one Default element for any given extension, and there not be more than one Override element for any given part name.

9.1.2.2

×^A

M2.6

The package implementer shall require a non-empty extension in a Default element. The package implementer shall require a content type in a Default element and the format designer shall specify the content type.

9.1.2.2.2

×^A

×^A

M2.7

The package implementer shall require a content type and the format designer shall specify the content type in an Override element. The package implementer shall require a part name.

9.1.2.2.3

×^A

×^A

M2.8

When adding a new part to a package, the package implementer shall ensure that a content type for that part is specified in the Content Types stream; the package implementer shall perform the steps described in §9.1.2.3.

9.1.2.3

×^A

M2.9

To get the content type of a part, the package implementer shall perform the steps described in §9.1.2.4.

9.1.2.4

×^A

M2.10

The package implementer shall not use the versioning and extensibility mechanisms defined in Part 5: "Markup Compatibility and Extensibility" to incorporate elements and attributes drawn from other XML-namespaces into the Content Types stream markup.

9.1.2.5

×^A

M2.11

The package implementer shall not mix interleaving and non-interleaving for an individual part.

9.1.4

×^B

M2.12

The package implementer shall compare prefix names as case-insensitive ASCII strings.

9.1.3.1

×

M2.13

The package implementer shall compare suffix names as case-insensitive ASCII strings.

9.1.3.1

×^B

M2.14

The package implementer shall not allow packages that contain equivalent logical item names.

9.1.3.1

×

M2.15

The package implementer shall not allow packages that contain logical items with equivalent prefix names and with equal piece numbers, where piece numbers are treated as integer decimal values.

9.1.3.1

×^B

M2.16

The package implementer shall not map logical items to parts if the logical item names violate the part naming rules.

9.1.3.4

×

M2.17

The package implementer shall consider naming collisions within the set of part names mapped from logical item names to be an error.

9.1.3.4

×

M2.18

When interleaved, a package implementer shall represent a part as one or more pieces, using the method described in §9.1.4.

9.2.1

×^B

S2.1

Some physical package formats have a native mechanism for representing content types. For such packages, the package implementer should use the native mechanism to map the content type for a part.

9.1.2.1

×

S2.2

If no native method of mapping a content type to a part exists, the package implementer should include a specially-named XML stream in the package called the Content Types stream

9.1.2.1

×

S2.3

If the package is intended for streaming consumption:

The package implementer should not allow Default elements; as a consequence, there should be one Override element for each part in the package.

The format producer should write the Override elements to the package so they appear before the parts to which they correspond, or in close proximity to the part to which they correspond.

9.1.2.2

×^A

×^A

S2.4

The package implementer should use the mechanism described in this Open Packaging specification to allow interleaving when mapping to the physical package for layout scenarios that support streaming consumption.

9.1.4

×^B

S2.5

The package implementer should store pieces in their natural order for optimal efficiency.

9.1.4

×^B

O2.1

The format designer specifies whether that format might use interleaving.

9.1.4

×

O2.2

Optional. The package implementer might provide a physical mapping for a growth hint that might be specified by a producer.

9.1.1

×

O2.3

Package implementers might use the common mapping solutions defined in this Open Packaging specification.

9.1

×

O2.4

Package producers can use pre-defined Default elements to reduce the number of Override elements on a part, but are not required to do so.

9.1.2.2

×^A

O2.5

The package implementer can define Default content type mappings even though no parts use them.

9.1.2.2

×^A

O2.6

The package implementer might create a physical package containing interleaved parts and non-interleaved parts.

9.1.4

×

O2.7

The package implementer might allow a package that contains logical item names and complete sequences of logical item names that cannot be mapped to a part name because the logical item name does not follow the part naming grammar or the logical item does not have an associated content type.

9.1.3.4

×^B

S3.2

If a growth hint is used for an interleaved part, the package implementer should store the Extra field containing the growth hint padding with the item that represents the first piece of the part.

10.2.7

×

M3.1

A package implementer shall store a non-interleaved part as a single ZIP item.

9.2.1

×

M3.2

ZIP item names are case-sensitive ASCII strings. Package implementers shall create ZIP item names that conform to ZIP archive file name grammar.

9.2.2

×

M3.3

Package implementers shall create item names that are unique within a given archive.

9.2.2

×

M3.4

To map part names to ZIP item names the package implementer shall perform, in order, the steps described in §9.2.3.

9.2.3

×

M3.5

The package implementer shall not map a logical item name or complete sequence of logical item names sharing a common prefix to a part name if the logical item prefix has no corresponding content type.

9.2.3

×

M3.6

To map ZIP item names to part names, the package implementer shall perform, in order, the steps described in §9.2.4.

9.2.4

×

M3.7

The package implementer shall map all ZIP items to parts except MS-DOSZIP items, as defined in the ZIP specification, that are not MS-DOS files.

9.2.5

×

M3.8

The package implementer shall map all ZIP items to parts except MS-DOSZIP items, as defined in the ZIP specification, that are not MS-DOS files. [M3.7]

[Note: The ZIP specification specifies that ZIP items recognized as MS-DOS files are those with a "version made by" field and an "external file attributes" field in the "file header" record in the central directory that have a value of 0. end note]

In ZIP archives, the package implementer shall not exceed 65,535 bytes for the combined length of the item name, Extra field, and Comment fields.

9.2.5

×

M3.9

ZIP-based packages shall not include encryption as described in the ZIP specification. Package implementers shall enforce this restriction.

9.2.5

×

M3.10

Package implementers shall store content type data in an item(s) mapped to the logical item name with the prefix_name equal to "/[Content_Types].xml" or in the interleaved case to the complete sequence of logical item names with that prefix_name.

9.2.6

×

M3.11

Package implementers shall not map logical item name(s) mapped to the Content Types stream in a ZIP archive to a part name.

9.2.6

×

M3.13

Several substantial conditions that represent a package unfit for streaming consumption may be detected mid-processing by a streaming package implementer, described in §9.2.8. When any of these conditions are detected, the streaming package implementer shall generate an error, regardless of any processing that has already taken place. Package implementers shall not generate a package containing any of these conditions when generating a package intended for streaming consumption.

9.2.8

×

M3.14

For a ZIP archive to be a valid physical layer for a package, the package implementer shall ensure that the ZIP archive holds equal values in the appropriate fields of every File Header within the Central Directory and the corresponding Local File Header and Data Descriptor pair.

Annex C

×

M3.15

During consumption of a package, a "Yes" value for a field in a table in Annex C indicates a package implementer shall support reading the ZIP archive containing this record or field, however, support may mean ignoring.

Annex C

×

M3.16

During production of a package, a "Yes" value for a field in a table in Annex C indicates that the package implementer shall write out this record or field.

Annex C

×

M3.17

A "No" value for a field in a table in Annex C indicates the package implementer shall not use this record or field during consumption or production of packages.

Annex C

×

M3.18

A "Partially, details below" value for a record in a table in Annex C indicates that the record contains fields that might not be supported by package implementers during production or consumption. See the details in the corresponding table to determine requirements.

Annex C

×

M3.19

The value "Only used when needed" associated with a record in a table in Annex C indicates that the package implementer shall use the record only when needed to store data in the ZIP archive.

Annex C

×

M3.20

The value "Only used when needed" associated with a record in a table in Annex C indicates that the package implementer shall use the record only when needed to store data in the ZIP archive.

Annex C

×

M3.21

The package implementer shall ensure that all 64-bit stream record sizes and offsets have the high-order bit = 0.

Annex C

×

O3.1

A package implementer might intentionally order the sequence of ZIP items in the archive to enable an efficient organization of the part data in order to achieve correct and optimal interleaving.

9.2.1

×

O3.2

An "Optional" value for a record in a table in Annex C indicates that package implementers might write this record during production.

Annex C

×

M4.1

The format designer shall specify and the format producer shall create at most one core properties relationship for a package. A format consumer shall consider more than one core properties relationship for a package to be an error. If present, the relationship shall target the Core Properties part.

10.2

×

×

×

M4.2

The format designer shall not specify and the format producer shall not create Core Properties that use the Markup Compatibility namespace as defined in Annex F, "Standard Namespaces and Content Types". A format consumer shall consider the use of the Markup Compatibility namespace to be an error.

10.3

×

×

×

M4.3

Producers shall not create a document element that contains refinements to the Dublin Core elements, except for the two specified in the schema: <dcterms:created> and <dcterms:modified> Consumers shall consider a document element that violates this constraint to be an error.

10.4

×

×

M4.4

Producers shall not create a document element that contains the xml:lang attribute. Consumers shall consider a document element that violates this constraint to be an error.

10.4

×

×

M4.5

Producers shall not create a document element that contains the xsi:type attribute, except for a <dcterms:created> or <dcterms:modified> element where the xsi:type attribute shall be present and shall hold the value dcterms:W3CDTF, where dcterms is the namespace prefix of the Dublin Core namespace. Consumers shall consider a document element that violates this constraint to be an error.

10.4

×

×

M5.1

The format designer shall specify thumbnail parts that are identified by either a part relationship or a package relationship. The producer shall build the package accordingly.

11.1

×

×

O5.1

The format designer might allow images, called thumbnails,

11

×

×

M6.1

The package implementer shall include only one Digital Signature Origin part in a package and it shall be targeted from the package root using the well-defined relationship type specified in Annex F, "Standard Namespaces and Content Types".

12.2.1

×

M6.2

When creating the first Digital Signature XML Signature part, the package implementer shall create the Digital Signature Origin part, if it does not exist, in order to specify a relationship to that Digital Signature XML Signature part.

12.2.1

×

M6.3

The producer shall create Digital Signature XML Signature parts that have a relationship from the Digital Signature Origin part and the consumer shall use that relationship to locate signature information within the package.

12.2.1

×

×

M6.4

If the certificate is represented as a separate part within the package, the producer shall target that certificate from the appropriate Digital Signature XML Signature part by a Digital Signature Certificate relationship as specified in Annex F, "Standard Namespaces and Content Types" and the consumer shall use that relationship to locate the certificate.

12.2.3

×

×

M6.5

The producer shall create Reference elements within a SignedInfo element that reference elements within the same Signature element. The consumer shall consider Reference elements within a SignedInfo element that reference any resources outside the same Signature element to be in error.

12.2.4.1

×

×

M6.6

The producer shall not create a reference to a package-specific Object element that contains a transform other than a canonicalization transform. The consumer shall consider a reference to a package-specific Object element that contains a transform other than a canonical transform to be an error.

12.2.4.1

×

×

M6.7

The producer shall create one and only one package-specific Object element in the Signature element. The consumer shall consider zero or more than one package-specific Object element in the Signature element to be an error.

12.2.4.1

×

×

M6.8

The producer shall create package-specific Object elements that contain exactly one Manifest element and exactly one SignatureProperties element. [Note: This SignatureProperties element can contain multiple SignatureProperty elements. end note] The consumer shall consider package-specific Object elements that contain other types of elements to be an error.

12.2.4.1

×

×

M6.9

The producer shall create Reference elements within a Manifest element that reference with their URI attribute only parts within the package. The consumer shall consider Reference elements within a Manifest element that reference resources outside the package to be an error.

12.2.4.1

×

×

M6.10

The producer shall create relative references to the local parts that have query components that specifies the part content type as described in §12.2.4.6. The relative reference excluding the query component shall conform to the part name grammar. The consumer shall consider a relative reference to a local part that has a query component that incorrectly specifies the part content type to be an error.

12.2.4.1

×

×

M6.11

The producer shall create Reference elements with a query component that specifies the content type that matches the content type of the referenced part. The consumer shall consider signature validation to fail if the part content type compared in a case-sensitive manner to the content type specified in the query component of the part reference does not match.

12.2.4.1

×

×

M6.12

The producer shall not create Reference elements within a Manifest element that contain transforms other than the canonicalization transform and relationships transform. The consumer shall consider Reference elements within a Manifest element that contain transforms other than the canonicalization transform and relationships transform to be in error.

12.2.4.1

×

×

M6.13

A producer that uses an optional relationships transform shall follow it by a canonicalization transform. The consumer shall consider any relationships transform that is not followed by a canonicalization transform to be an error.

12.2.4.1

×

×

M6.14

The producer shall create exactly one SignatureProperty element with the Id attribute value set to idSignatureTime. The Target attribute value of this element shall be either empty or contain a fragment reference to the value of the Id attribute of the root Signature element. A SignatureProperty element shall contain exactly one SignatureTime child element. The consumer shall consider a SignatureProperty element that does not contain a SignatureTime element or whose Target attribute value is not empty or does not contain a fragment reference the Id attribute of the ancestor Signature element to be in error.

12.2.4.1

×

×

M6.15

The producer shall create a Signature element that contains exactly one local-data, package-specific Object element and zero or more application-specific Object elements. If a Signature element violates this constraint, a consumer shall consider this to be an error.

12.2.4.2

×

×

M6.16

The producer shall create a SignedInfo element that contains exactly one reference to the package-specific Object element. The consumer shall consider it an error if a SignedInfo element does not contain a reference to the package-specific Object element.

12.2.4.3

×

×

M6.17

Producers shall support DSA and RSA algorithms to produce signatures. Consumers shall support DSA and RSA algorithms to validate signatures.

12.2.4.5

×

×

M6.18

The producer shall create a Reference element within a Manifest element with a URI attribute and that attribute shall contain a part name, without a fragment identifier. The consumer shall consider a Reference element with a URI attribute that does not contain a part name to be an error.

12.2.4.6

×

×

M6.19

The following transforms shall be supported by producers and consumers of packages with digital signatures:

• XML Canonicalization (c14n)
• XML Canonicalization with Comments (c14n with comments)
• Relationships transform (package-specific)

Consumers validating signed packages shall fail the validation if other transforms are encountered. Relationships transforms shall only be supported by producers and consumers when the Transform element is a descendant element of a Manifest element

12.2.4.7

×

×

M6.20

Producers shall create application-specific Object elements that contain XML-compliant data; consumers shall treat data that is not XML-compliant as an error.

12.2.4.14

×

×

M6.21

Producers and consumers shall use the certificate embedded in the Digital Signature XML Signature part when it is specified.

12.2.4.15

×

×

M6.22

The producer shall not create a Manifest element that references any data outside of the package. The consumer shall consider a Manifest element that references data outside of the package to be in error.

12.2.4.18

×

×

M6.23

The producer shall create a data/time format that conforms to the syntax described in the W3C Note "Date and Time Formats". The consumer shall consider a format that does not conform to the syntax described in that WC3 note to be in error.

12.2.4.22

×

×

M6.24

The producer shall create a value that conforms to the format specified in the Format element. The consumer shall consider a value that does not conform to that format to be in error.

12.2.4.23

×

×

M6.25

To sign a subset of relationships, the producer shall use the package-specific relationships transform. The consumer shall use the package-specific relationships transform to validate the signature when a subset of relationships are signed.

12.2.4.25

×

×

M6.26

Producers shall specify a canonicalization transform immediately following a relationships transform and consumers that encounter a relationships transform that is not immediately followed by a canonicalization transform shall generate an error.

12.2.4.25

×

×

M6.27

When applying a relationships transform for digital signatures, the package implementer shall remove all Relationship elements that do not have eitheran Id value that matches any SourceId valueor a Type value that matches any SourceType value, among the SourceId and SourceType values specified in the transform definition. Producers and consumers shall compare values as case-sensitive Unicode strings.

12.2.4.26

×

×

M6.28

When signing Object element data, package implementers shall follow the generic reference creation algorithm described in §3.1 of the W3C Recommendation "XML-Signature Syntax and Processing".

12.4

×

M6.29

When validating digital signatures, consumers shall verify the content type and the digest contained in each Reference descendant element of the SignedInfo element, and validate the signature calculated using the SignedInfo element.

12.5

×

M6.30

The package implementer shall compare the generated digest value against the DigestValue element in the Reference element of the SignedInfo element. Package implementers shall consider references invalid if there is any mismatch.

12.5

×

M6.31

Streaming consumers that maintain signatures shall be able to cache the parts necessary for detecting and processing signatures.

12.5.1

×

M6.32

The package implementer shall not use the Markup Compatibility namespace, as specified in Annex F, "Standard Namespaces and Content Types," within the package-specific Object element. The package implementer shall consider the use of the Markup Compatibility namespace within the package-specific Object element to be an error.

12.6.2

×

M6.33

If an application allows for a single part to contain information that might not be fully understood by all implementations, then the format designer shall carefully design the signing and verification policies to account for the possibility of different implementations being used for each action in the sequence of content creation, content signing, and signature verification. Producers and consumers shall account for this possibility in their signing and verification processing.

12.6.2

×

×

×

M6.34

The following canonicalization methods shall be supported by producers and consumers of packages with digital signatures:

XML Canonicalization (c14n)

XML Canonicalization with Comments (c14n with comments)

Consumers validating signed packages shall fail the validation if other canonicalization methods are encountered.

12.2.4.4

×

×

M6.35

A producer shall not specify more than one relationship transform for a particular relationships part. A consumer shall treat the presence of more than one relationship transform for a particular relationships part as an error.

12.2.4.25

×

×

S6.1

The producer should not create any content in the Digital Signature Origin part itself.

12.2.1

×

S6.2

Producers generating digital signatures should not create Digital Signature Certificate parts that are not the target of at least one Digital Signature Certificate relationship from a Digital Signature XML Signature part. In addition, producers should remove a Digital Signature Certificate part if removing the last Digital Signature XML Signature part that has a Digital Signature Certificate relationship to it.

12.2.3

×

S6.3

For digital signatures, a producer should apply a canonicalization transform to the SignedInfo element when it generates it, and a consumer should apply the canonicalization transform to the SignedInfo element when validating it.

12.2.4.4

×

×

S6.4

Producers and consumers should also use canonicalization transforms for references to parts that hold XML documents.

12.2.4.4

×

×

S6.5

The producer should only create Reference elements within a SignedInfo element that reference an Object element.

12.2.4.1

×

O6.1

Format designers might allow a package to include digital signatures to enable consumers to validate the integrity of the contents. The producer might include the digital signature when allowed by the format designer.

12

×

×

O6.2

If there are no Digital Signature XML Signature parts in the package, the Digital Signature Origin part is optional.

12.2.1

×

O6.4

The producer might create zero or more Digital Signature XML Signature parts in a package.

12.2.2

×

O6.5

Alternatively, the producer might store the certificate as a separate part in the package, might embed it within the Digital Signature XML Signature part itself, or might not include it in the package if certificate data is known or can be obtained from a local or remote certificate store.

12.2.3

×

O6.6

The producer might sign the part holding the certificate.

12.2.3

×

O6.7

Producers might share Digital Signature Certificate parts by using the same certificate to create more than one signature.

12.2.3

×

O6.8

The format designer might permit one or more application-specific Object elements. If allowed by the format designer, format producers can create one or more application-specific Object elements.

12.2.4.14

×

×

O6.9

Format designers and producers might not apply package-specific restrictions regarding URIs and Transform elements to application-specific Object element.

12.2.4.14

×

×

O6.10

Format designers might permit producers to sign individual relationships in a package or the Relationships part as a whole.

12.2.4.25

×

×

O6.11

The package implementer might create relationships XML that contains content from several namespaces, along with versioning instructions as defined in Part 5: "Markup Compatibility and Extensibility".

12.2.4.26

×

O6.12

Format designers might specify an application-specific package part format that allows for the embedding of versioned or extended content that might not be fully understood by all present and future implementations. Producers might create such embedded versioned or extended content and consumers might encounter such content.

12.6.2

×

×

×

M7.1

The authority component contains an embedded URI that points to a package. The package implementer shall create an embedded URI that meets the requirements defined in RFC 3986 for a valid URI.

B.1

×

M7.2

The optional path component identifies a particular part within the package. The package implementer shall only create path components that conform to the part naming rules. When the path component is missing, the resource identified by the pack URI is the package as a whole.

B.1

×

M7.3

The package implementer shall consider pack URIs equivalent if:

The scheme components are octet-by-octet identical after they are both converted to lowercase; and

The URIs, decoded as described in §B.2 from the authority components are equivalent (the equivalency rules by scheme, as per RFC 3986); and

The path components are equivalent when compared as case-insensitive ASCII strings.

B.4

×

M7.4

The package implementer shall not create an authority component with an unescaped colon (:) character.

B.1

×

O7.1

Consumer applications, based on the obsolete URI specification RFC 2396, might tolerate the presence of an unescaped colon character in an authority component.

B.1

×