To save people some confusion, I think the reporter is referring to RFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) rather than 7321 (Cryptographic Algorithm Implementation Requirements and Usage Guidance).
On Wed, Mar 25, 2020 at 3:44 PM RFC Errata System <rfc-edi...@rfc-editor.org> wrote: > The following errata report has been submitted for RFC8555, > "Automatic Certificate Management Environment (ACME)". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6030 > > -------------------------------------- > Type: Technical > Reported by: Matt Palmer <mp+i...@hezmatt.org> > > Section: 7.2 > > Original Text > ------------- > To get a fresh nonce, the client sends a HEAD request to the newNonce > resource on the server. The server's response MUST include a Replay- > Nonce header field containing a fresh nonce and SHOULD have status > code 200 (OK). The server MUST also respond to GET requests for this > resource, returning an empty body (while still providing a Replay- > Nonce header) with a status code of 204 (No Content). > > Corrected Text > -------------- > To get a fresh nonce, the client sends a HEAD request to the newNonce > resource on the server. The server's response MUST include a Replay- > Nonce header field containing a fresh nonce and SHOULD have status > code 204 (No Content). The server MUST also respond to GET requests for > this > resource, returning an empty body (while still providing a Replay- > Nonce header) with a status code of 204 (No Content). > > Notes > ----- > RFC7321 s4.3.2, says "The server SHOULD send the same header fields in > response to a HEAD request as it would have sent if the request had been a > GET". I can't see any rationale for violating this SHOULD in the > discussion in the GH issue which introduced the discrepancy in response > code between GET and HEAD (https://github.com/ietf-wg-acme/acme/pull/371), > thus (IMHO) it violates the tenets of a SHOULD, as "the full implications" > do not appear to have "be[en] understood and carefully weighed before > choosing a different course" (RFC2119, of course). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8555 (draft-ietf-acme-acme-18) > -------------------------------------- > Title : Automatic Certificate Management Environment (ACME) > Publication Date : March 2019 > Author(s) : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten > Category : PROPOSED STANDARD > Source : Automated Certificate Management Environment > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
