...
- Andrew Woods
- Nick Ruest
- David Wilcox
- John Rees
- Doron Shalvi
- A. Soroka
- Benjamin Armintor
- Unknown User (acoburn)
- Aaron Birkland
- Anna Headley
- Bethany Seeger
- Jim Tuttle
- Jack Hill
- Jim Coble
- ...Daniel Lamb
Objective
- Define proposal, if one is required, to Fedora community for specification of Fixity Checking Service
...
- 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?
...
- 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 createingest, if you have a fixity digest header that doesn’t match the calculated value of the binary you’re creatingingesting, you should get a conflict response
- 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
...