Time/Place

Attendees 

Objective

  1. Define proposal, if one is required, to Fedora community for specification of Fixity Checking Service

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:

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.

Agenda

  1. Is Fixity Checking a core repository service?
  2. If yes to #1, what is the interaction model?
  3. If yes to #1, should the result of executing the Fixity Checking service be specified as being persisted in the repository?
  4. 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 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 Expect header on a GET or HEAD request and server will recalculate fixity to compare, 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"
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.