Approved from my end. - James M Snell he/him https://bsky.app/profile/jasnell.me
On Mon, Jun 8, 2026, 14:50 Sandy Ginoza <[email protected]> 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, [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]
