Bagit specification version conformance should be configurable. #27
Assignees
Labels
Comments
|
We could also comment on the draft perhaps talk to John
Carl
…Sent from my iPhone
On Jul 12, 2018, at 3:08 AM, mikedarcy <notifications@github.com<mailto:notifications@github.com>> wrote:
Bagit spec 1.0 introduces some significant changes from 0.97, most notably the restriction that if multiple checksum types are used, every payload file must be listed in every checksum manifest. This makes creating bags that contain references to remote files with mixed checksum types impossible if bdbag was to only support bagit spec 1.0 moving forward.
For example, when creating bags using a remote-file-manifest, for legacy reasons only an MD5 might be available for a subset of files, whereas others may have newer SHA256 or SHA512 hashes. Creating bags with this type of mixed checksum content is actually a pretty common use case, and one that was supported prior to bdbag release 1.3.0. This issue is described in further detail in #26<#26>.
The change proposed here is to create a bdbag.json configuration (and API object) parameter which allows the user to specify the bagit specification conformance level. Specifying 0.97 will allow for the less restrictive payload manifest declarations and specifying 1.0 will enforce strict payload manifest homogeneity. The system will default to 0.97 for backward compatibility. This mechanism will also provide a way to address additional compatibility issues in the future, should they arise.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#27>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADbjXr69hcZoCpqfM9YDyokwhizRjyyBks5uFqGigaJpZM4VMD6D>.
|
mikedarcy
added a commit
that referenced
this issue
Aug 28, 2018
Factor out configuration structure and logic into separate file. Added a configuration option for specifying the Bagit spec compatibility level, per #27. Defaults to 0.97. This allows for creating bags where payload files must have at least one checksum in one payload manifest, but not necessarily a checksum in every payload manifest. The Bagit 1.0 spec currently states that every payload file MUST have a checksum in every payload manifest, and essentially prohibits creating backward-compatible bags. Added and additional auth mechanism for HTTP that scans for Mozilla/Netscape/CURL compatible cookie files, merges them, and uses them in outbound HTTP fetch requests. Made fetch handler functions a bit more extensible via use of **kwargs. A more extensive refactor is likely at some point.
Merged
|
Fixed in 1.5.0 release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bagit spec
1.0introduces some significant changes from0.97, most notably the restriction that if multiple checksum types are used, every payload file must be listed in every checksum manifest. This makes creating bags that contain references to remote files with mixed checksum types impossible ifbdbagwas to only supportbagitspec1.0moving forward.For example, when creating bags using a
remote-file-manifest, for legacy reasons only an MD5 might be available for a subset of files, whereas others may have newer SHA256 or SHA512 hashes. Creating bags with this type of mixed checksum content is actually a pretty common use case, and one that was supported prior tobdbagrelease 1.3.0. This issue is described in further detail in #26.The change proposed here is to create a
bdbag.jsonconfiguration (and API object) parameter which allows the user to specify thebagitspecification conformance level. Specifying0.97will allow for the less restrictive payload manifest declarations and specifying1.0will enforce strict payload manifest homogeneity. The system will default to0.97for backward compatibility. This mechanism will also provide a way to address additional compatibility issues in the future, should they arise.The text was updated successfully, but these errors were encountered: