- Time: 10:00AM Eastern Time US
- Dial-in Number: (712) 775-7035
- Participant Code: 479307#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- 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
- Notes from 2016-12-08 Tech Meeting
- From the draft specification:
For the purposes of the following specification, a fixity result is an extract or summary of some LDPNR made according to some explicit procedure. Fixity results are taken for the purpose of comparing different fixity results for the same resource over time, to ensure a continuity of that resource's identity according to the particular procedure used. Examples might include:
- Checksums like MD5 or SHA1, often used for digital images.
- XML Signatures
- Per-segment results as used for time-based media
Fedora offers management for fixity results in two situations: firstly, as part of content transmission, to guard against faults in transmision, and secondly, by building on its versioning system to support on-demand fixity results, to guard against faults in persistence.
- 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?
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 ingest, if you have a fixity digest header that doesn’t match the calculated value of the binary you’re ingesting, 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
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, but a client can always choose to store it like any other info
- You can provide a fixity again in an
Expectheader on a
HEADrequest and server will recalculate fixity to compare, returning an error response (417) if they do not match