...

1. Retaining HTTP layer of existing Fedora codebase
2. Replacing ModeShape persistence with OCFL storage
3. Support for three interaction models: 
   1. atomistic (implicit) - every LDP resource maps to an individual OCFL Object
   2. archive group - hierarchy of LDP resources map into a compound OCFL Object
   3. archival-part (implicit) - an LDP resource that is a constituent part of a compound OCFL Object
4. Eliminate "single-subject-restriction", i.e. support arbitrary RDF
5. Fedora-specific information to be stored in the OCFL Object in a ".fcrepo/" directory
   1. i.e. Which file is the description of another file
   2. i.e. While Which file is an ACL
6. Optimizing reads/lookups with an internal database
   1. proposed database model: https://docs.google.com/document/d/1MsMfhae3thmNdoFtnTUnII3mr_-OkllRs9PvgnY1fDY/edit
7. Support for both OCFL storage hierarchies:
   1. created by Fedora
   2. created by another application (pre-existing)

...

1. Fedora resources may be created with an optional "archive group" interaction model provided via headers

2. New resources created via POST or PUT to the archive group will be LDP contained by the archive group and will be stored within the OCFL object representing that archive

3. If a resource is created without the "archive" model, new resources created via POST or PUT will be LDP contained by the parent resource, but will be stored as separate OCFL objects

4. Note: user establishes interaction model at creation time. Changing the model would require additional migration tooling.

...

1. Expose JHU OCFL client functionality with minimal HTTP endpoints
   1. Such an endpoint should implement minimal LDP interactions
2. Use HTTP over OCFL to test:
   1. Performance bottlenecks
   2. Scale viability (e.g. NLM migration)
   3. User expectations, ergonomics

Versioning

1. Support for both two versioning models:
   1. version an object on-demand (manual versioning)
   2. version an object on-change (auto-versioning)
2. Support for toggling auto-versioning on/off
3. One-to-one correspondence between OCFL versions and mementos
4. For archival-archive groups, any new version of the OCFL Object captures current state of the entire archival-archive group

Versioning on-demand

1. Same as Fedora 4 and 5 version creation: POST to a resource's "/fcr:versions" endpoint to create a Momento Memento (i.e. a new OCFL version directory)
2. Actively edited objects captured in a "cache/" directory at the sibling-level with OCFL version directories

...

1. Same code logic used for creation of OCFL versions / Mementos in both on-demand and on-change models
2. LDP resources within a compound object should respond with a "Link" header pointing the the TimeMap of the Fedora "archival-archive group" resource

3. POST on /fcr:versions of part resources returns a 400 response

4. GET on /fcr:versions returns a version of the "constituent part"

...