Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor-drafts/FinalReview-rfc10025/issues).
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!-- [rfced] We were unable to find the term "the worker's Documents" in [HTML] as indicated in the text below. Does this item need to be updated accordingly? Current: The terms "active browsing context", "active document", "ancestor navigables", "container document", "content navigable", "dedicated worker", "Document", "inclusive ancestor navigables", "navigable", "navigate", "opaque origin", "sandboxed origin browsing context flag", "shared worker", "the worker's Documents", "top-level traversable", and "WorkerGlobalScope" are defined in [HTML]. --> 3) <!--[rfced] May we clarify "choose Section 4" and "choose Section 5" as follows? Original: An implementer should choose Section 4 whenever cookies are created and will be sent to a user agent, such as a web browser. ... An implementer should choose Section 5 whenever cookies are primarily received from another source. Perhaps: An implementer should implement the requirements described in Section 4 whenever cookies are created and will be sent to a user agent, such as a web browser. ... An implementer should implement the requirements described in Section 5 whenever cookies are primarily received from another source. --> 4) <!-- [rfced] Section 5.2.1: Is "(document)" in the text below redundant? If so, may we remove it? Original: Given a Document (document), the following algorithm returns its "site for cookies": Perhaps: Given a Document, the following algorithm returns its "site for cookies": --> 5) <!-- [rfced] How may we make the second sentence below a complete sentence? (Note that we have included the first sentence for context.) Original: Additionally the server is vulnerable to an attacker that purposefully miscapitalizes a cookie in order to impersonate a prefixed cookie. For example, a site already has a cookie __Secure- SID=12345 and by some means an attacker sends the following Set- Cookie header field for the site to a UA which checks prefixes case- sensitively. Perhaps: Additionally, the server is vulnerable to an attacker that purposefully miscapitalizes a cookie in order to impersonate a prefixed cookie. An example of this is if a site already has a cookie __Secure- SID=12345 and by some means an attacker sends the following Set-Cookie header field for the site to a UA that checks prefixes case-sensitively. --> 6) <!--[rfced] It is unclear how "for user agents configured to reject 'public suffixes'" fits into the rest of the sentence. May we update as follows for clarity? Original: - The cookie's domain is not a public suffix, for user agents configured to reject "public suffixes". Perhaps: - The cookie's domain is not a public suffix, as user agents are configured to reject "public suffixes". --> 7) <!-- [rfced] FYI - We have added "are" to the sentences below to make them complete sentences. Please review to confirm this update is accurate. Original: Some partition cookies based upon the first-party context, so that different cookies are sent depending on the site being browsed. Some block cookies based upon user agent cookie policy and/or user controls. Current: Some partition cookies are based upon the first-party context, so that different cookies are sent depending on the site being browsed. Some block cookies are based upon user agent cookie policy and/or user controls. --> 8) <!-- [rfced] FYI - We have added "they are" to the text below. Please review to confirm this update is accurate. Original: This differs from the handling of other reload navigations, which are always same-site if top-level, since the source navigable's active document is precisely the document being reloaded. Current: This differs from the handling of other reload navigations, which are always same-site if they are top level, since the source navigable's active document is precisely the document being reloaded. --> 9) <!--[rfced] FYI - We have updated the "Cookie" and "Set-Cookie" registrations in the IANA Considerations section per RFC 9110. They also now better reflect what appears at <https://www.iana.org/assignments/http-fields/http-fields.xhtml>. Please review these changes and let us know of any concerns. --> 10) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). If this update is desired, these changes will be made upon RFCXML conversion. --> 11) <!-- [rfced] Please review the type/language attribute of each sourcecode block in the file to ensure correctness. We note that "example" is used in a few instances, but it is not on the current list of preferred values: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types. Let us know how these may be updated. Also, it is acceptable to leave the language tag blank. In addition, review each artwork block. Specifically, should any be converted into a sourcecode block or another format? --> 12) <!--[rfced] Abbreviations a) 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. b) We note this document switches between using the expanded ("user agents") and abbreviated ("UAs") forms of this term. For consistency, may we update all instances to use the expanded form "user agents"? --> 13) <!-- [rfced] Terminology: a) We note different uses of quotation marks for the following terms. Please review and let us know how to update for consistency across the document: same-site vs. "same-site" cross-site vs. "cross-site" same-site-flag vs. "same-site-flag" b) We also note the following differences in some terms throughout the document and plan to update as follows. As such, please review and let us know any objections: i) We plan to remove the hyphen from the term below for consistency with the reference [SAMESITE] (and retain the hyphen when used attributively). same-site vs. same site ii) We plan to remove the quotes and fixed-width font from attribute and header field names. iii) We plan to add fixed-width font around all example links. --> 14) <!-- [rfced] Please review the following questions regarding the references in this document: a) [USASCII]: Please review. The series number for the ASCII Standard has changed. It is now known as "INCITS 4-1986". See: https://blog.ansi.org/ansi/ansi-art-ascii-art-iso-standards-x3-64/ "In 1996, the Accredited Standards Committee (ASC) X3 became the ANSI-accredited standards developing organization INCITS, so ANSI X3.4-1986 was redesignated INCITS 4-1986. The current standard for ASCII is INCITS 4-1986 (R2022): Information Systems – Coded Character Sets – 7-Bit Standard Code For Information Interchange (7-Bit ASCII)." We have updated this reference to point to the INCITS version. Original: [USASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. Current: [USASCII] INCITS, "Information Systems - Coded Character Sets - 7-Bit Standard Code for Information Interchange (7-Bit ASCII)", INCITS 4-1986 (R2022), 2022, <https://webstore.ansi.org/standards/incits/ incits1986r2022>. b) [app-isolation]: The original URL for this reference leads to a 404 error. We found an open-access version of this paper in ACM Digital Library. We have updated this reference to use the ACM DL URL. Please let us know if you have any objections. c) [prerendering]: The URL for this reference redirects to a page with a different title and author. It seems similar, but isn't an exact match. Is this still the correct article for this reference? Original URL: https://www.chromium.org/developers/design-documents/prerender Redirected URL: https://developer.chrome.com/docs/web-platform/prerender-pages Note: We found the following URL that appears to match the original title of this reference: https://chromium.googlesource.com/playground/chromium-org-site/+/refs/heads/main/developers/design-documents/prerender/index.md. However, it is missing the author information from the original reference. Possible update: Original: [prerendering] Bentzel, C., "Chrome Prerendering", <https://www.chromium.org/developers/design-documents/prerender>. Redirected URL: [prerendering] Pollard, B., "Prerender pages in Chrome for instant page navigations", 2 December 2022, <https://developer.chrome.com/docs/web-platform/prerender-pages>. URL matching title: [prerendering] "Chrome Prerendering", <https://chromium.googlesource.com/playground/chromium-org-site/+/refs/heads/main/developers/design-documents/prerender/index.md>. --> Thank you. Alanna Paloma and Kaelin Foody RFC Production Center > On Jul 10, 2026, at 10:53 AM, [email protected] wrote: > > *****IMPORTANT***** > > RFC Author(s): > -------------- > > Your document has now entered Final Review (previously AUTH48). > > The document was edited in kramdown-rfc as part of the RPC pilot test (see > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). > > 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-rfc10025 > > Please do the following: > > a) provide your GitHub username so that we can send you an invite to > join the repo as a collaborator. We have already sent invitations to > Mike Bishop (AD), Mark Nottingham (WG Chair and Document Shepherd), > and Tommy Pauly (WG Chair). > > b) see the README for details on the Final Review process: > https://github.com/rfc-editor-drafts/FinalReview-rfc10025/blob/Approved/README.md > > c) review the edits in the RPC-edits pull request: > https://github.com/rfc-editor-drafts/FinalReview-rfc10025/pulls > > d) address the issues: > https://github.com/rfc-editor-drafts/FinalReview-rfc10025/issues > > Once the content of the .md file is stable, we will convert it to .xml > and provide the .html, .pdf, .txt, and .xml files for review. > > 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/rfc10025/ > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Production Center > > -------------------------------------- > RFC 10025 (draft-ietf-httpbis-rfc6265bis) > > Title : Cookies: HTTP State Management Mechanism > Author(s) : S. Bingler, Ed., > M. West, Ed., > J. Wilander, Ed. > WG Chair(s) : Tommy Pauly, Mark Nottingham > Area Director(s) : Mike Bishop, Gorry Fairhurst > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
