---
Need to reduce the front page authors to five.
Those names should appear in the "Authors' Addresses" section.
The other names should be moved into a new "Contributors" section.
---
Loads of little nits ...
Abstract
s/specifies/describes/
s/should be/is/
---
When you cite LC-CONFORMANCE-SUITE you are using [[ not [
---
You cite RFC 2234, but that was obsoleted by RFC 4234. Any reason not to
use the more recent reference?
---
Could you please split the References section into two subsections
called "Normative References" and "Informative References" and divide
the references accordingly. Roughly speaking, the Normative References
are those that you absolutely must read to understand this document,
the other are background.
---
Section 1.2
OLD
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 [RFC2119].
NEW
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
END
...and add a normative reference to RFC 8174
---
A little pedantically, I would like to reduce the emphasis on this
being a "specification" since that has connotations in the RFC series.
We can do that relatively easily as follows.
s/specification/document/
1.3 seven times
2. once
2.1.2 once
2.2.4 once
2.3 once
Abstract
s/specifies/describes/
2.1.1
OLD
The number for this version of the specification is "1.0".
NEW
The number for this version of BagIt is "1.0".
END
3.
OLD
4. For BagIt 1.0, every payload file MUST be listed in every payload
manifest. Note that older versions of this specification allowed
payload files to be listed in just one of the manifests.
5. Every element present MUST comply with this specification.
NEW
4. For BagIt 1.0, every payload file MUST be listed in every payload
manifest. Note that older versions of BagIt allowed payload
files to be listed in just one of the manifests.
5. Every element present MUST conform to BagIt 1.0.
END
---
1.3
I wonder whether you should add "manifest" as a term in this section:
you use it quite a lot without specific explanation.
---
Error handling. I see a lot of description of what must be in a bag and
how it must be formatted, but couldn't find anything about what to do if
a bag is found to be deficient or, for example, if a checksum fails.
I don't think this needs much text. Just a statement about not
processing a bag if it is in error, and possibly something about logging
or reporting the problem.