...
- 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?
Is Fixity Checking a core repository service?
- Underlying assumption that users expect Fedora to provide infrastructure to ensure that repository resources have not changed
- Fixity vs. validity
- A service for checking bitwise stability or resource validation?
- Validity is a broader concept we should not introduce into the spec, which currently only talks about fixity proper
- A fixity calculation may generate something very complex (e.g. not just a number) which could be difficult to validate
- While the current implementation stores the checksum as a property, this is not necessarily part of the specification (i.e. it is not necessarily a requirement on other Fedora implementations)
- Nick Ruest: Repository should be able to receive, compare, and store a user-provided fixity value
- Should not be a core service because other things do this better
- Jim Coble: On-demand fixity is an important feature as well
- If Fedora doesn’t do this, it will need to be supported in some other way
- Benjamin Armintor: Ideal workflow
- On create, if you have a fixity digest header that doesn’t match the calculated value of the binary you’re creating, you should get a conflict
- Client should be able to provide an expected value (which may be stored in the repository) to check against the calculated value at any time (as opposed to the current implementation where the stored value is compared to a calculated value)
- Doron Shalvi: NLM advocates for a more turn-key system
- Already have filesystem level checks
- Looking for system level checks
- Ideally, repository would calculate checksum and validate on ingest, followed by regular automatic checks
- Desire for on-demand checks
- Should be able to configure automated checks on a schedule and optionally store the results and notify if there has been a change
- This kind of functionality already exists in fcrepo-camel
What is the desired interaction model?
- 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
- You can provide a digest again in head request and server will recalculate checksum to compare
Actions
- A. Soroka will revise fixity spec based on this discussion
- 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