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, [email protected] 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, [email protected] 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 > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
