Versions Compared

Old Version 18

changes.mady.by.user David Wilcox

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Woods

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Objective

  1. Define proposal, if one is required, to Fedora community for specification of Fixity Checking 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

...

  • 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 Expect header on a GET or HEAD request 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"