...
- 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?
Minutes
Background
- 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 aGETorHEADrequest and server will recalculate checksum fixity to compare
Actions
...
- , returning an error response (417) if they do not match
Actions
- Andrew Woods will send a note to the mailing list to summarize the call
- Benjamin Armintor will write a minimal header-driven draft and a "preamble incorporating this stuff from ajs6f and acoburn about external storage and transparency"