Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Minor typo

...

Requesting checksums for all files in a collection may yeild yield a large set of results. Due to this the protocol supports a method of limiting which files are listed, which can be used for implementing a paging mechanism.  

...

  • The returned checksums should be ordered by their date oldest first.
  • No more than the maximum number of results specified in the request should be delivered. 
  • If the pillar itself only allows for transmitting fewer results than specified in the request the pillar should keep to its own maximum. 
  • If the pillar have has more checksums than could be sent in the response, then the response should be marked as a PartialResult.
  • If limitations by minimum or maximum timestamp is present, the results should be inclusive. 
    • If a minimum timestamp is in place, then first result should matche match the minimum limitation.
    • If a maximum timetamp is in place, then the last result should not be after the limitation. If the number of results is larger than the allowed maximum, the response should be marked as a PartialResult.

...

The Checksum specification is per request and for all files that it pertains (a single file, or all)

A client should expect that checksum pillars will reject a GetChecksums request if the checksum type does not match the one that the pillar has stored