[auth48] Re: Final Review: RFC-to-be 10025 (draft-ietf-httpbis-rfc6265bis) in markdown/GitHub

[Steven Bingler <[e-mail]>]

Hello Kaelin,

Thank you for the reminder, I'll get to these in the coming weeks.

Take care,
- Steven

On Tue, Jul 28, 2026 at 3:57 PM Kaelin Foody
<[e-mail]> wrote:
>
> Authors,
>
> This is another friendly reminder that this document awaits your attention.
>
> Please review and resolve (as necessary) the questions in this email thread, which can also be found in the GitHub
> repository for this document as issues (see https://github.com/rfc-editor-drafts/FinalReview-rfc10025/issues)
>
> Please let us know if you have any questions.
>
> All the best,
>
> Kaelin Foody
> RFC Production Center
>
> > On Jul 20, 2026, at 6:31 PM, Kaelin Foody <[e-mail]> wrote:
> >
> > Authors,
> >
> > This is a friendly reminder that this document awaits your attention.
> >
> > Please review and resolve (as necessary) the questions in this email thread, which can also be found in the GitHub
> > repository for this document as issues (see https://github.com/rfc-editor-drafts/FinalReview-rfc10025/issues)
> >
> > Please let us know if you have any questions.
> >
> > All the best,
> >
> > Kaelin Foody
> > RFC Production Center
> >
> >> On Jul 10, 2026, at 1:56 PM, Alanna Paloma <[e-mail]> wrote:
> >>
> >> 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, [e-mail] 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
> >>>
> >>
> >
>