- Is Fixity Checking a core repository service?
- If yes to #1, what is the interaction model?
- If yes to #1, should the result of executing the Fixity Checking service be specified as being persisted in the repository?
- If yes to #1, should repository messages be emitted upon the completion of executing the Fixity Checking service?
- What is the interaction model for invoking a fixity request?
- Assumption that the result of this invocation would be persisted in the repository
- Do we actually need to persist this result?
- Further, is fixity really a core service?
- On ingest, Fedora will calculate a checksum
- You will get an error response if you try to ingest something with a user provided value that does not match the calculated value
- No guarantee that this will be stored, but a client can always choose to store it like any other info
- You can provide a digest fixity again in head an
Expectheader on a
HEADrequest and server will recalculate checksum fixity to compare, returning an error response (417) if they do not match