Page tree

Versions Compared


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


  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?




  • 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? 


  • 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, returning an error response (417) if they do not match


  • 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"