Re: [Acme] [Technical Errata Reported] RFC8555 (6030)

That does seem quite likely, thanks for pointing it out, Roland.

With respect to the report itself (noting that the proposed change is from
"200 (OK)" to "204 (No Content)"), I note that the response status code is
not considered to be a "header field" and so the quoted text from RFC 7231
does not seem to directly apply.  Since HEAD is defined to not return any
body content, 204 does not convey any additional information, and 200 in
fact seems to be conventional.

While, I'm happy to ask for more discussion/confirmation on the httpbis WG
list if requested, it seems likely that this report is destined for status
"Rejected".  Does anyone disagree?

Thanks,

Ben

On Wed, Mar 25, 2020 at 09:03:23PM -0700, Roland Shoemaker wrote:
> 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-editor@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+ietf@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
> >