Crocker suggestions #15
Conversation
This appears to have been commented out since at least 2008.
This follows the guidelines in RFC-3629
* Note the existence of namespaces in the security considerations section * Update previously un-displayed list of reserved DOS/Windows filenames
Clarify that this section is part of the specification but is not considered a hard requirement for an implementation.
Update the section describing md5sum’s output format and clarify that it is strictly optional to accept bags which are produced using md5sum and will not pass a strict validation.
This adds background information for problems related to case-sensitivity and Unicode normalization and adds a list of recommendations for implementors.
This adds the note that, unlike other metadata tags, this element must not be repeated and clarifies that the Payload-Oxum value is not sufficient for validation.
This triggers the standard formatting in HTML, etc. outputs
* Use <organization> for relevant <author> entries * Omit empty <date> attributes
* Remove reference to GRABIT since the spec is now returning HTTP 404 and there are no known public implementations. * Add METALINK (RFC 5854) as an alternative which supports mirrors and protocols such as BitTorrent.
| BagIt does not require the processing of the entire structure to understand to | ||
| involve understanding the payload. The name, BagIt, is inspired by the "enclose | ||
| and deposit" method <xref target="ENCDEP" />, sometimes referred to as "bag it and tag it". | ||
| This differs from other specifications (like ZIP) that only ensure the integrity |
There was a problem hiding this comment.
This isn't really true for ZIP files – by now that format includes integrity checks on the entire archive as well. The differences I would emphasize are the use of stronger checks than CRC-32s, ability to upgrade to stronger hash algorithms without breaking backwards compatibility, etc. and the tradeoffs for large archives of having each file be individually accessible, transferred, etc. without having to read through a potentially large archive (e.g. people still report interoperability issues with archives which are large enough to require using ZIP64.
| The tag file required to be in all bags conforming to this | ||
| specification. Contains tags necessary for bootstrapping the | ||
| The file required to be in all bags conforming to this | ||
| specification. Contains values necessary for bootstrapping the |
There was a problem hiding this comment.
“Contains values necessary for bootstrapping the reading and processing of the rest of a bag” could be simplified to something like “Contains values necessary to read the bag”.
| found in the Interoperability section of this document. | ||
| </t> | ||
| </section> <!-- /Purpose --> | ||
|
|
||
| <section title="Requirements"> | ||
| <t> | ||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
| document are to be interpreted as described in <xref target="RFC2119"/>. | ||
| </t> |
There was a problem hiding this comment.
Why “filesystem folder” instead of the more common “directory”?
| <t> | ||
| An implementation is not compliant if it fails to satisfy one or | ||
| more of the MUST or REQUIRED level requirements for the protocols | ||
| it implements. An implementation that satisfies all the MUST or |
There was a problem hiding this comment.
“filesystem” feels redundant here as well
|
ugh I hate how it defaults to a pull request here instead of to our repo. Sorry |
Avoid confusing MAY clause
my attempt at going through the email listing suggestions for changes in the 07 draft version by Dave Crocker