Changes requested from ISE review

[justinlittman]

---

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.

[justinlittman]

The only change I didn't make was the suggestion about providing some guidance on error handling. Basically, I think this should be completely unspecified as an implementer can take any of a range of actions, e.g., erroring out, fixing the error, asking a person to approve.

[acdha]

@justinlittman Agreed