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]
