diff --git a/draft/spec/index.html b/draft/spec/index.html index c37a11a2..578dd67c 100644 --- a/draft/spec/index.html +++ b/draft/spec/index.html @@ -410,78 +410,85 @@

Object Structure

└── ... content files ...

- The OCFL Object Root MUST NOT contain files or directories other than those specified in the - following sections. + The OCFL Object Root MUST NOT contain files or directories other than those + specified in the following sections.

Object Conformance Declaration

- The version declaration MUST be formatted according to the [[!NAMASTE]] specification. It MUST be a - file in the base directory of the OCFL Object Root giving the OCFL version in the filename. The filename - MUST conform to the pattern T=dvalue, where T MUST be 0, and dvalue - MUST be ocfl_object_, followed by the OCFL specification version number. The text contents of - the file MUST be the same as dvalue, followed by a newline (\n). + The version declaration MUST be formatted according to the [[!NAMASTE]] + specification. + It MUST be a file in the base directory of the OCFL Object Root giving the OCFL + version in the filename. The filename MUST conform to the pattern + T=dvalue, where T MUST be 0, and dvalue + MUST be ocfl_object_, followed by the OCFL specification version + number. The text contents of the file MUST be the same as dvalue, + followed by a newline (\n).

Version Directories

- OCFL Object content MUST be stored as a sequence of one or more versions. Each object version is stored in a - version directory under the object root. The sequence of version numbers is the sequence of positive, - base-ten integers: 1, 2, 3, etc., and the version directory name is constructed by adding the prefix - v. The version number sequence MUST start at 1 and MUST be continuous without missing integers. + OCFL Object content MUST be stored as a sequence of one or more versions. Each + object version is stored in a version directory under the object root. The sequence of version numbers + is the sequence of positive, base-ten integers: 1, 2, 3, etc., and the version directory name is + constructed by adding the prefix v. The version number sequence MUST + start at 1 and MUST be continuous without missing integers.

- Implementations SHOULD use version directory names constructed without zero-padding the - version number, ie. v1, v2, v3, etc.. + Implementations SHOULD use version directory names constructed without zero-padding + the version number, ie. v1, v2, v3, etc..

For compatibility with existing filesystem conventions, implementations MAY use zero-padded version directory numbers, with the following restriction: If zero-padded version directory numbers are used then - they MUST start with the prefix v and then a zero. For example, in an implementation that uses - five digits for version directory names then v00001 to v09999 are allowed, - v10000 is not allowed. + they MUST start with the prefix v and then a zero. For example, in an + implementation that uses five digits for version directory names then v00001 to + v09999 are allowed, v10000 is not allowed.

The first version of an object defines the naming convention for all version directories for the object. - All version directories of an object MUST use the same naming convention: either a non-padded version - directory number, or a zero-padded version directory number of consistent length. Operations that add a new - version to an object MUST follow the version directory naming convention established by earlier versions. - In all cases, references to files inside version directories from inventory files MUST use the actual - version directory names. + All version directories of an object MUST use the same naming convention: either a + non-padded version directory number, or a zero-padded version directory number of consistent length. + Operations that add a new version to an object MUST follow the version directory + naming convention established by earlier versions. In all cases, references to files inside version + directories from inventory files MUST use the actual version directory names.

- There MUST be no other files as children of a version directory, other than an MUST be no other files as children of a version directory, other than an inventory file and a inventory digest. - The version directory SHOULD NOT contain any directories other than the designated content - sub-directory. Once created, the contents of a version directory are expected to be immutable. + The version directory SHOULD NOT contain any directories other than the designated + content sub-directory. Once created, the contents of a version directory are expected to be immutable.

Content Directory

- Version directories MUST contain a designated content sub-directory if the version contains files to be - preserved, and SHOULD NOT contain this sub-directory otherwise. The name of this designated sub-directory - MAY be defined in the inventory file using the key contentDirectory - with the value being the chosen sub-directory name as a string, relative to the version directory. - The contentDirectory value MUST NOT contain the forward slash (/) path - separator and MUST NOT be either one or two periods (. or ..). If the key - contentDirectory is set, it MUST be set in the first version of the object and MUST NOT - change between versions of the same object. + Version directories MUST contain a designated content sub-directory if the version + contains files to be preserved, and SHOULD NOT contain this sub-directory + otherwise. The name of this designated sub-directory MAY be defined in the + inventory file using the key contentDirectory with the value being + the chosen sub-directory name as a string, relative to the version directory. The + contentDirectory value MUST NOT contain the forward slash + (/) path separator and MUST NOT be either one or two periods + (. or ..). If the key contentDirectory is set, it + MUST be set in the first version of the object and + MUST NOT change between versions of the same object.

If the key contentDirectory is not present in the inventory file - then the name of the designated content sub-directory MUST be content. OCFL-compliant tools - (including any validators) MUST ignore all directories in the object version directory except for the - designated content directory. + then the name of the designated content sub-directory MUST be + content. OCFL-compliant tools (including any validators) MUST + ignore all directories in the object version directory except for the designated content directory.

- Every file within a version's content directory MUST be referenced in the manifest - section of the inventory. There MUST NOT be empty directories within a version's content directory. A - directory that would otherwise be empty MAY be maintained by creating a file within it named according to - local conventions, for example by making an empty .keep file. + Every file within a version's content directory MUST be referenced in the + manifest section of the inventory. There MUST NOT be empty + directories within a version's content directory. A directory that would otherwise be empty MAY be + maintained by creating a file within it named according to local conventions, for example by making an + empty .keep file.

@@ -498,16 +505,18 @@

Digests

whether a file has become corrupt, through hardware degradation or accident for example.

- For content-addressing, OCFL Objects MUST use either sha512 or sha256, and SHOULD - use sha512. The choice of the sha512 digest algorithm as default recognizes - that it has no known collision vulnerabilities and multiple implementations are available. + For content-addressing, OCFL Objects MUST use either sha512 or + sha256, and SHOULD use sha512. The choice of the + sha512 digest algorithm as default recognizes that it has no known collision vulnerabilities + and multiple implementations are available.

For storage of additional fixity values, or to support legacy content migration, implementers - MUST choose from the following controlled vocabulary of digest algorithms, or from a list of additional - algorithms given in the [[Digest-Algorithms-Extension]]. OCFL clients MUST support all fixity algorithms - given in the table below, and MAY support additional algorithms from the extensions. Optional fixity - algorithms that are not supported by a client MUST be ignored by that client. + MUST choose from the following controlled vocabulary of digest algorithms, or from a + list of additional algorithms given in the [[Digest-Algorithms-Extension]]. OCFL clients + MUST support all fixity algorithms given in the table below, and MAY support + additional algorithms from the extensions. Optional fixity algorithms that are not supported by a client + MUST be ignored by that client.

@@ -526,30 +535,30 @@

Digests

- +
sha1 Insecure. Use only for legacy fixity values. SHA-1 algorithm defined by [[!FIPS-180-4]] - and MUST be encoded using hex (base16) encoding [[!RFC4648]]. + and MUST be encoded using hex (base16) encoding [[!RFC4648]]. For example, the sha1 digest of a zero-length bitstream is da39a3ee5e6b4b0d3255bfef95601890afd80709.
sha256 Non-truncated form only; note performance implications. SHA-256 algorithm defined by - [[!FIPS-180-4]] and MUST be encoded using hex (base16) encoding [[!RFC4648]]. + [[!FIPS-180-4]] and MUST be encoded using hex (base16) encoding [[!RFC4648]]. For example, the sha256 digest of a zero-length bitstream starts e3b0c44298fc1c149afbf4c8996fb92427ae41e4... (64 hex digits long).
sha512 Default choice. Non-truncated form only. SHA-512 algorithm defined by [[!FIPS-180-4]] and - MUST be encoded using hex (base16) encoding [[!RFC4648]]. + MUST be encoded using hex (base16) encoding [[!RFC4648]]. For example, the sha512 digest of a zero-length bitstream starts cf83e1357eefb8bdf1542850d66d8007d620e405... (128 hex digits long).
blake2b-512Full-length form only, using the 2B variant (64 bit) as defined by [[!RFC7693]]. MUST be encoded - using hex (base16) encoding [[!RFC4648]]. For example, the blake2b-512 digest of a - zero-length bitstream starts 786a02f742015903c6c6fd852552d272912f4740... (128 hex - digits long).Full-length form only, using the 2B variant (64 bit) as defined by [[!RFC7693]]. + MUST be encoded using hex (base16) encoding [[!RFC4648]]. For example, the + blake2b-512 digest of a zero-length bitstream starts + 786a02f742015903c6c6fd852552d272912f4740... (128 hex digits long).
@@ -576,14 +585,14 @@

Digests

Inventory

- An OCFL Object Inventory MUST follow the [[!JSON]] structure described in this section and MUST be named - inventory.json. The order of entries in both the [[JSON]] objects and arrays used in inventory - files has no significance. + An OCFL Object Inventory MUST follow the [[!JSON]] structure described in this + section and MUST be named inventory.json. The order of entries in both + the [[JSON]] objects and arrays used in inventory files has no significance.

- The forward slash (/) path separator MUST be used in content paths in the manifest - and fixity blocks within the inventory. Implementations that target systems using - other separators will need to translate paths appropriately. + The forward slash (/) path separator MUST be used in content paths in the + manifest and fixity blocks within the inventory. + Implementations that target systems using other separators will need to translate paths appropriately.

@@ -594,31 +603,32 @@

Inventory

Basic Structure

- An OCFL Object Inventory MUST include the following keys: + An OCFL Object Inventory MUST include the following keys:

id
- A unique identifier for the OCFL Object. This MUST be unique in the local context, and SHOULD be - a URI [[!RFC3986]]. There is no expectation that a URI used is resolvable. For example, URNs - [[RFC8141]] MAY be used. + A unique identifier for the OCFL Object. This MUST be unique in the local + context, and SHOULD be a URI [[!RFC3986]]. There is no expectation that a + URI used is resolvable. For example, URNs [[RFC8141]] MAY be used.
type
A type for the inventory JSON object that also serves to document the OCFL specification version - that the inventory complies with. This MUST be the URI of the inventory section of the - specification, https://ocfl.io/1.0/spec/#inventory. + that the inventory complies with. This MUST be the URI of the inventory + section of the specification, https://ocfl.io/1.0/spec/#inventory.
digestAlgorithm
- The digest algorithm used for calculating digests within the OCFL Object. This MUST be - either sha512 or sha256, and SHOULD be sha512. See the + The digest algorithm used for calculating digests within the OCFL Object. This + MUST be either sha512 or sha256, and + SHOULD be sha512. See thead section on Digests for more information.
head
- The version directory name of the most recent version of the object. This MUST be the version - directory name with the highest version number. + The version directory name of the most recent version of the object. This + MUST be the version directory name with the highest version number.

@@ -632,8 +642,8 @@

Basic Structure

- In addition to these keys, there MUST be two other blocks present, manifest and - versions, which are discussed in the next two sections. + In addition to these keys, there MUST be two other blocks present, + manifest and versions, which are discussed in the next two sections.

@@ -643,7 +653,8 @@

Manifest

The value of the manifest key is a JSON object, with keys corresponding to the digests of every content file in all versions of the OCFL Object. The value for each key is an array containing the content paths of files in the OCFL Object that have content with the - given digest. Content paths within a manifest block MUST be relative to the OCFL Object Root. + given digest. Content paths within a manifest block MUST be relative to the + OCFL Object Root.

@@ -668,26 +679,28 @@

Manifest

Versions

- An OCFL Object Inventory MUST include a block for storing versions. This block MUST have the - key of versions within the inventory, and it MUST be a JSON object. The keys of this object - MUST correspond to the names of the version directories used. Each - value MUST be another JSON object that characterizes the version, as described in the - section. + An OCFL Object Inventory MUST include a block for storing versions. This block + MUST have the key of versions within the inventory, and it + MUST be a JSON object. The keys of this object MUST + correspond to the names of the version directories used. Each + value MUST be another JSON object that characterizes the version, as described + in the section.

Version

- A JSON object to describe one OCFL Version, which MUST include the following keys: + A JSON object to describe one OCFL Version, which MUST include the + following keys:

created
- The value of this key is the datetime of creation of this version. It MUST be expressed in the - Internet Date/Time Format defined by [[!RFC3339]]. This format requires the inclusion of a - timezone value or Z for UTC, and that the time component be granular to the - second level (with optional fractional seconds). + The value of this key is the datetime of creation of this version. It + MUST be expressed in the Internet Date/Time Format defined by + [[!RFC3339]]. This format requires the inclusion of a timezone value or Z for UTC, + and that the time component be granular to the second level (with optional fractional seconds).
state @@ -696,7 +709,7 @@

Version

The value of this key is a JSON object, containing a list of keys and values corresponding to the logical state of the object at that version. The keys of this JSON object - are digest values, each of which MUST correspond to an entry in the + are digest values, each of which MUST correspond to an entry in the manifest of the inventory. The value for each key is an array containing logical path names of files in the OCFL Object state that have content with the given digest. @@ -705,10 +718,11 @@

Version

Logical paths present the structure of an OCFL Object at a given version. This is given as an array of values, with the following restrictions to provide for path safety in the common case of the logical path value representing a file - path. The logical path MUST be interpreted as a set of one or more path elements joined by - a / path separator. Path elements MUST NOT be ., .., - or empty (//). Additionally, a logical path MUST NOT begin or end with a - forward slash (/). + path. The logical path MUST be interpreted as a set of one or more + path elements joined by a / path separator. Path elements + MUST NOT be ., .., or empty + (//). Additionally, a logical path MUST NOT begin or + end with a forward slash (/).

@@ -743,7 +757,8 @@

Version

- The JSON object describing an OCFL Version, SHOULD include the following keys: + The JSON object describing an OCFL Version, SHOULD include the + following keys:

@@ -758,12 +773,12 @@

Version

The value of this key is a JSON object intended to identify the user or agent that created the current OCFL Version. - The value of the user key MUST contain a user name key, name and - SHOULD contain an address key, address. - The name value is any readable name of the user, e.g., a proper name, user ID, - agent ID. - The address value SHOULD be a URI: either a mailto URI [[RFC6068]] with the e-mail - address of the user or a URL to a personal identifier, e.g., an ORCID iD. + The value of the user key MUST contain a user name key, + name and SHOULD contain an address key, + address. The name value is any readable name of the user, e.g., a + proper name, user ID, agent ID. The address value SHOULD be + a URI: either a mailto URI [[RFC6068]] with the e-mail address of the user or a URL to a + personal identifier, e.g., an ORCID iD.
@@ -774,17 +789,19 @@

Fixity

An OCFL Object inventory MAY include a block for storing additional fixity information to supplement the complete set of digests in the Manifest, for example to support legacy digests - from a content migration. This block MUST have the key of fixity within the inventory. + from a content migration. This block MUST have the key of fixity + within the inventory.

- The fixity block MUST contain keys corresponding to the controlled vocabulary given in - the digest algorithms listed in the Digests - section, or in a table given in an Extension. The value of the fixity block for a particular - digest algorithm MUST follow the structure of the manifest block; - that is, a key corresponding to the digest value, and an array of content paths that match that - digest. The fixity block for any digest algorithm MAY include digest values for any subset of - content paths in the object. There is no requirement that all content files have a value in the fixity - block, or that fixity values provided in one version are carried forward to later versions. + The fixity block MUST contain keys corresponding to the controlled + vocabulary given in the digest algorithms listed in the + Digests section, or in a table given in an Extension. The value of the + fixity block for a particular digest algorithm MUST follow the structure of the + manifest block; that is, a key corresponding to the digest value, + and an array of content paths that match that digest. The fixity block for any digest algorithm + MAY include digest values for any subset of content paths in the object. There is no requirement that + all content files have a value in the fixity block, or that fixity values provided in one version are + carried forward to later versions.

@@ -813,14 +830,15 @@

Fixity

Inventory Digest

- Every occurrence of an inventory file MUST have an accompanying sidecar file stating its digest. This - sidecar file must be of the form inventory.json.ALGORITHM, where ALGORITHM is - the chosen digest algorithm for the object. This value MUST match the value given for the - digestAlgorithm key in the inventory. An example might be - inventory.json.sha512. + Every occurrence of an inventory file MUST have an accompanying sidecar file stating + its digest. This sidecar file must be of the form inventory.json.ALGORITHM, where + ALGORITHM is the chosen digest algorithm for the object. This value + MUST match the value given for the digestAlgorithm key in the + inventory. An example might be inventory.json.sha512.

- The digest sidecar file MUST contain the digest of the inventory file. This MUST follow the format: + The digest sidecar file MUST contain the digest of the inventory file. This + MUST follow the format: 

 DIGEST inventory.json
@@ -830,29 +848,30 @@ 
Inventory Digest

             inventory.json; that is, the name of the inventory file in the same directory.
         

         

-            The digest of the inventory MUST be computed only after all changes to the inventory have been made, and
-            thus writing the digest sidecar file is the last step in the versioning process.
+            The digest of the inventory MUST be computed only after all changes to the inventory
+            have been made, and thus writing the digest sidecar file is the last step in the versioning process.

Version Inventory and Inventory Digest

- Every OCFL Object MUST have an inventory file within the OCFL Object Root, + Every OCFL Object MUST have an inventory file within the OCFL Object Root, corresponding to the state of the OCFL Object at the current version. Additionally, every version directory - SHOULD include an inventory file that is an Inventory of all content for versions - up to and including that particular version. Where an OCFL Object contains inventory.json - in version directories, the inventory file in the OCFL Object Root MUST be the same as the file in the - most recent version. Every inventory file MUST have a corresponding Inventory - Digest. + SHOULD include an inventory file that is an Inventory of + all content for versions up to and including that particular version. Where an OCFL Object contains + inventory.json in version directories, the inventory file in the OCFL Object Root + MUST be the same as the file in the most recent version. Every inventory file + MUST have a corresponding Inventory Digest.

In the case that prior version directories include an inventory file there will be multiple inventory files describing prior versions within the OCFL Object. Each version block in each prior inventory file - MUST represent the same object state as the corresponding version block in the current inventory file. - Additionally, the values of the created, message and user keys in - each version block in each prior inventory file SHOULD have the same values as the corresponding keys in - the corresponding version block in the current inventory file. + MUST represent the same object state as the corresponding version block in the + current inventory file. Additionally, the values of the created, message and + user keys in each version block in each prior inventory file SHOULD + have the same values as the corresponding keys in the corresponding version block in the current inventory + file.

Non-normative note: Storing an inventory for every version provides redundancy for this critical @@ -864,10 +883,10 @@

Version Inventory and Inventory Digest

Logs Directory

The base directory of an OCFL Object MAY contain a directory named logs, which MAY be empty. - Implementers SHOULD use this for storing files that contain a record of actions taken on the object. Since - these logs may be subject to local standards requirements, the format of these logs is considered - out-of-scope for the OCFL Object. Clients operating on the object MAY log actions here that are not - otherwise captured. + Implementers SHOULD use this for storing files that contain a record of actions + taken on the object. Since these logs may be subject to local standards requirements, the format of these + logs is considered out-of-scope for the OCFL Object. Clients operating on the object MAY log actions here + that are not otherwise captured.

@@ -887,10 +906,11 @@

Logs Directory

Object Extensions

The base directory of an OCFL Object MAY contain a directory named extensions for the purposes - of extending the functionality of an OCFL Object. The extensions directory MUST NOT contain - any files, and no sub-directories other than extension sub-directories. Extension sub-directories SHOULD be - named according to a registered extension name. The specific structure and function of the extension, as - well as a declaration of the registered extension name MUST be defined in one of the following locations: + of extending the functionality of an OCFL Object. The extensions directory + MUST NOT contain any files, and no sub-directories other than extension + sub-directories. Extension sub-directories SHOULD be named according to a registered + extension name. The specific structure and function of the extension, as well as a declaration of the + registered extension name MUST be defined in one of the following locations:

  • @@ -919,7 +939,7 @@

    OCFL Storage Root

    Root Structure

    - An OCFL Storage Root MUST contain a + An OCFL Storage Root MUST contain a Root Conformance Declaration identifying it as such.

    @@ -929,14 +949,15 @@

    Root Structure

    An OCFL Storage Root MAY contain a JSON file named ocfl_layout.json to describe the arrangement - of directories and OCFL objects under the storage root. - If present, this JSON document MUST include the following two keys in the root JSON object: + of directories and OCFL objects under the storage root. If present, this JSON document + MUST include the following two keys in the root JSON object:

    • key - A key identifying the precise arrangement of directories and OCFL objects under the storage root, i.e. how OCFL object identifiers are mapped to directory hierarchies. The value of this key - is not defined in the OCFL specification, but MUST correspond to a value given in an Extension. + is not defined in the OCFL specification, but MUST correspond to a value given in an + Extension.
    • description - A human readable description of the arrangement of directories and OCFL @@ -944,12 +965,13 @@

      Root Structure

    - Sub-directories within an OCFL Storage Root MUST NOT contain files that are not part of an OCFL Object. - Empty directories MUST NOT appear within a storage root. + Sub-directories within an OCFL Storage Root MUST NOT contain files that are not part + of an OCFL Object. Empty directories MUST NOT appear within a storage root.

    Although implementations may require multiple OCFL Storage Roots—that is, several logical or - physical volumes, or multiple "buckets" in an object store—each OCFL Storage Root MUST be independent. + physical volumes, or multiple "buckets" in an object store—each OCFL Storage Root + MUST be independent.

    The following example OCFL Storage Root represents the minimal set of files and folders: @@ -965,24 +987,27 @@

    Root Structure

    Root Conformance Declaration

    - The OCFL version declaration MUST be formatted according to the [[!NAMASTE]] specification. It MUST be a - file in the base directory of the OCFL Storage Root giving the OCFL version in the filename. - The filename MUST conform to the pattern T=dvalue, where T MUST be 0, and - dvalue MUST be ocfl_, followed by the OCFL specification version number. The - text contents of the file MUST be the same as dvalue, followed by a newline (\n). + The OCFL version declaration MUST be formatted according to the [[!NAMASTE]] + specification. It MUST be a file in the base directory of the OCFL Storage Root + giving the OCFL version in the filename. The filename MUST conform to the pattern + T=dvalue, where T MUST be 0, and dvalue + MUST be ocfl_, followed by the OCFL specification version number. The + text contents of the file MUST be the same as dvalue, followed by a + newline (\n).

    Root conformance indicates that the OCFL Storage Root conforms to this section (i.e. the OCFL Storage Root section) of the specification. OCFL Objects within the OCFL Storage Root also include a conformance - declaration which MUST indicate OCFL Object conformance to the same or earlier version of the specification. + declaration which MUST indicate OCFL Object conformance to the same or earlier version + of the specification.

    Storage Hierarchies

    - OCFL Object Roots MUST be stored either as the terminal resource at the end of a directory storage - hierarchy or as direct children of a containing OCFL Storage Root. + OCFL Object Roots MUST be stored either as the terminal resource at the end of + a directory storage hierarchy or as direct children of a containing OCFL Storage Root.

    A common practice is to use a unique identifier scheme to compose this storage hierarchy, typically arranged @@ -990,12 +1015,14 @@

    Storage Hierarchies

    hierarchies, the following restrictions apply:

      -
    1. There MUST be a deterministic mapping from an object identifier to a unique storage path
      2. -
    2. Storage hierarchies MUST NOT include files within intermediate directories
      3. -
    3. Storage hierarchies MUST be terminated by OCFL Object Roots
      4. -
    4. Storage hierarchies within the same OCFL Storage Root SHOULD use just one layout pattern
      5. -
    5. Storage hierarchies within the same OCFL Storage Root SHOULD consistently use either a directory - hierarchy of OCFL Objects or top-level OCFL Objects
      6. +
    6. There MUST be a deterministic mapping from an object identifier to a unique + storage path
      7. +
    7. Storage hierarchies MUST NOT include files within intermediate directories
      8. +
    8. Storage hierarchies MUST be terminated by OCFL Object Roots
      9. +
    9. Storage hierarchies within the same OCFL Storage Root SHOULD use just one layout + pattern
      10. +
    10. Storage hierarchies within the same OCFL Storage Root SHOULD consistently use + either a directory hierarchy of OCFL Objects or top-level OCFL Objects
    @@ -1007,12 +1034,12 @@

    Storage Root Extensions

    The base directory of an OCFL Storage Root MAY contain a directory named extensions for the purposes of extending the functionality of an OCFL Storage Root. The storage root extensions - directory MUST conform to the same guidelines and limitations as those defined for + directory MUST conform to the same guidelines and limitations as those defined for object extensions.

    - An OCFL validator MUST ignore any files in the storage root it does not understand. Additional - files MUST NOT appear in other directories under the storage root. + An OCFL validator MUST ignore any files in the storage root it does not understand. + Additional files MUST NOT appear in other directories under the storage root.

    @@ -1029,19 +1056,19 @@

    Filesystem features

    In order to maximize the compatibility of the OCFL with different filesystems, and thus improve the portability of OCFL Objects between different systems, some restrictions on the use of certain filesystem features are necessary. If the preservation of non-OCFL-compliant features is required then - the content MUST be wrapped in a suitable disk or filesystem image format which OCFL can treat as a regular - file. + the content MUST be wrapped in a suitable disk or filesystem image format which OCFL + can treat as a regular file.

    1. Filesystem metadata (e.g. permissions, access, and creation times) are not considered portable between filesystems or preservable through file transfer operations. These attributes also cannot be validated in terms of fixity in a consistent manner. As such, the OCFL does not support the portability of these attributes.
      2. -
    2. Hard and soft (symbolic) links are not portable and MUST NOT be used within OCFL Storage hierachies. - A common use case for links is storage deduplication. OCFL inventories provide a portable method - of achieving the same effect by using digests to address content.
      3. -
    3. File paths and filenames in the OCFL are case sensitive. Filesystems MUST preserve the case of OCFL - filepaths and filenames.
      4. +
    4. Hard and soft (symbolic) links are not portable and MUST NOT be used within OCFL + Storage hierachies. A common use case for links is storage deduplication. OCFL inventories provide a + portable method of achieving the same effect by using digests to address content.
      5. +
    5. File paths and filenames in the OCFL are case sensitive. Filesystems MUST preserve + the case of OCFL filepaths and filenames.
    6. Transparent filesystem features such as compression and encryption should be effectively invisible to OCFL operations. Consequently, they should not be expected to be portable.