[auth48] Re: Final Review: RFC-to-be 10008 <draft-ietf-httpbis-safe-method-w-body> in XML/GitHub

[James M Snell <[e-mail]>]

Approved from my end.

- James M Snell
  he/him
  https://bsky.app/profile/jasnell.me

On Mon, Jun 8, 2026, 14:50 Sandy Ginoza <[e-mail]>
wrote:

> Greetings all,
>
> We have updated the document as discussed in Github <
> https://github.com/rfc-editor-drafts/FinalReview-rfc10008/>.  All of the
> issues and other comments have been resolved.  The resulting XML and
> outputs are available here:
>    https://www.rfc-editor.org/authors/rfc10008.xml
>    https://www.rfc-editor.org/authors/rfc10008.txt
>    https://www.rfc-editor.org/authors/rfc10008.pdf
>    https://www.rfc-editor.org/authors/rfc10008.html
>
> Comprehensive diffs:
>    https://www.rfc-editor.org/authors/rfc10008-diff.html
>    https://www.rfc-editor.org/authors/rfc10008-rfcdiff.html (side by side)
>
> Final Review diffs:
>    https://www.rfc-editor.org/authors/rfc10008-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc10008-auth48rfcdiff.html (side
> by side)
>
> Please review and let us know if any further updates are needed or if you
> approve the RFC for publication.
>
> Thank you,
> Sandy Ginoza
> RFC Production Center
>
>
>
> > On Jun 4, 2026, at 11:29 PM, [e-mail] wrote:
> >
> > Authors,
> >
> > While reviewing this document during Final Review, please resolve (as
> necessary) the following questions, which are also in GitHub as issues <
> https://github.com/rfc-editor-drafts/FinalReview-rfc10008/issues>.
> >
> > 1) <!--[rfced] Abstract: We have added "QUERY requests" to the sentence
> below
> > to clarify what this sentence refers to. Please review.
> >
> > Original:
> > This is similar to POST requests but can be automatically repeated
> > or restarted without concern for partial state changes.
> >
> > Current:
> > This is similar to POST requests, but QUERY requests can be
> automatically repeated
> > or restarted without concern for partial state changes.
> > -->
> >
> >
> > 2) <!--[rfced] May we adjust the sentence below as follows for
> readability
> > and replace "absent" with "without"?
> >
> > Original:
> >
> >   In this variation, however, it is not readily apparent - absent
> >   specific knowledge of the resource and server to which the request is
> >   being sent - that a safe, idempotent query is being performed.
> >
> > Perhaps:
> >
> >   However, in this variation, it is not readily apparent
> >   that a safe, idempotent query is being performed (without
> >   specific knowledge of the resource and server to which the request is
> >   being sent).
> >
> > -->
> >
> >
> > 3) <!-- [rfced] Section 2.1: May we update the first and last items in
> the list below
> > for consistency?
> >
> > Original:
> >
> >   The list below describes various cases of failures and recommends
> >   specific status codes:
> >
> >   *  A request lacking media type information
> >      by definition is incorrect and needs to fail
> >      with a 4xx status code such as 400 (Client Error).
> >
> >   *  If a media type is specified...
> >
> >   *  If a media type is specified...
> >
> >   *  If the media type is specified...
> >
> >   *  Finally, if the client requests a specific response media type
> >      using the Accept field ([HTTP], Section 12.5.1) which is not
> >      supported by the resource, a status code of 406 (Not Acceptable)
> >      is appropriate.
> >
> > Perhaps:
> >
> >   The list below describes various cases of failures and recommends
> >   specific status codes:
> >
> >   *  If a request lacks media type information,
> >      it is incorrect by definition and needs to fail
> >      with a 4xx status code such as 400 (Client Error).
> >
> >      ...
> >
> >   *  If the client requests a specific response media type
> >      using the Accept field ([HTTP], Section 12.5.1) that is not
> >      supported by the resource, a status code of 406 (Not Acceptable)
> >      is appropriate.
> >
> > -->
> >
> >
> > 4) <!-- [rfced] How may we adjust the text below for readability?
> >
> > Original:
> >
> >   The _equivalent resource_ for any given QUERY request is a resource
> >   responding to GET requests, representing that QUERY request and its
> >   target, taking both message content and metadata into account
> >   (Section 6 of [HTTP]).
> >
> > Perhaps:
> >
> >   The _equivalent resource_ for any given QUERY request is a resource
> >   that responds to GET requests, represents that QUERY request and its
> >   target, and takes both message content and metadata into account
> >   (Section 6 of [HTTP]).
> >
> > -->
> >
> >
> > 5) <!-- [rfced] What is being "normalized" in the last two list items
> below?
> > Should these list items be updated accordingly for clarity? (Note that
> we
> > have provided additional text for context.)
> >
> > Original:
> >
> >   To improve cache efficiency, caches MAY remove semantically
> >   insignificant differences first.  For instance, by:
> >
> >   *  removing content encoding(s) (Section 8.4 of [HTTP]).
> >
> >   *  normalizing based upon knowledge of format conventions, as
> >      indicated by any media subtype suffix in the request's Content-
> >      Type field (e.g., "+json", see Section 4.2.8 of [RFC6838]).
> >
> >   *  normalizing based upon knowledge of the semantics of the content
> >      itself, as indicated by the request's Content-Type field.
> >
> > -->
> >
> >
> > 6) <!-- [rfced] Our understanding is that the WHATWG #links are not
> permanent (see
> https://authors.ietf.org/en/reference-style-guidance#web-hypertext-application-technology-working-group-whatwg)
> We do not see a request for the following #links to be made permanent on <
> https://github.com/whatwg/html/issues?q=is%3Aissue%20-state%3A%20permanent%20anchor>.
> For now, we have removed the #links and replaced them with section number
> and title.  Please let us know if you request permanent links.
> >
> > https://fetch.spec.whatwg.org/#methods
> > https://url.spec.whatwg.org/#application/x-www-form-urlencoded
> > -->
> >
> >
> > 7) <!-- [rfced] Would you like the references to be alphabetized
> > or left in their current order? -->
> >
> >
> > 8) <!-- [rfced] FYI - We have added expansions for abbreviations upon
> first use
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> > -->
> >
> > 9) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online
> > Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed.  Updates of this nature
> typically
> > result in more precise language, which is helpful for readers.
> >
> > Note that our script did not flag any words in particular, but this
> should
> > still be reviewed as a best practice.
> > -->
> >
> > Thank you.
> >
> > Kaelin Foody and Sandy Ginoza
> > RFC Production Center
> >
> > On Jun 4, 2026, at 11:14 PM, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > RFC Author(s):
> > --------------
> >
> > Your document has now entered Final Review (formerly AUTH48).
> >
> > Final Review is being handled in GitHub as part of the GitHub pilot test
> > (see
> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test)
>
> >
> > Your document is available for review at:
> > https://github.com/rfc-editor-drafts/FinalReview-rfc10008
> >
> > Please do the following:
> >
> > a) accept your invitations to join the repo as collaborators.
> >
> > b) see the README for details on the Final Review process:
> >
> https://github.com/rfc-editor-drafts/FinalReview-rfc10008/blob/Approved/README.md
> >
> > c) review the edits in the RPC-edits pull request:
> > https://github.com/rfc-editor-drafts/FinalReview-rfc10008/pulls
> >
> > d) address the issues:
> > https://github.com/rfc-editor-drafts/FinalReview-rfc10008/issues
> >
> > Once the content is stable in GitHub, we will provide the updated XML
> file
> > and the output files for review and approval.
> >
> > You and your coauthors are responsible for engaging other parties
> > (e.g., Contributors or Working Group) as necessary before providing
> > your approval.
> >
> > Once the document has been reviewed and approved by all of the authors,
> > it will be published as an RFC.  If an author is no longer available,
> > there are several remedies; see the Unavailable Authors section
> > (https://authors.ietf.org/rfc-publication-process#unavailable-authors)
> >
> > Details on the status of your Final Review are here:
> >  https://queue.rfc-editor.org/final-review/rfc10008/
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation,
> >
> > RFC Production Center
> >
>
>