On Wed, Aug 27, 2025 at 7:48 PM <rfc-edi...@rfc-editor.org> wrote:
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] In an effort to make the text file reader-friendly and to
> keep
> links to non-RFC references from degrading over time, we would like to
> update six reference links that use the "relative" attribute to some more
> meaningful text.
>
> Please review the following instances and let us know if these changes are
> acceptable.
>
> a)
> Current:
> (see Part RequestDestination of [FETCH])
>
> Perhaps:
> (see "RequestDestination" in Section 5.4 of [FETCH])
>
> b)
> Current:
> (see Part has regexp groups of [URLPATTERN])
>
> Perhaps:
> (see the last list in Section 1.4 of [URLPATTERN])
>
> c)
> Current:
> (see Part create of [URLPATTERN])
>
> Perhaps:
> (see Section 1.4 of [URLPATTERN])
>
> d)
> Current:
> (see Part match of [URLPATTERN])
>
> Perhaps:
> (see "Match" in Section 1.4 of [URLPATTERN])
>
> e)
> Current:
> (see Part CORS check of [FETCH])
>
> Perhaps:
> (see Section 4.9 of [FETCH])
> -->
>
>
The FETCH and URLPATTERN are living standards and the section numbers are
likely to change. The named "parts" are durable references to the W3C
standards. I'd recommend not adding the section numbers as they will become
incorrect over time.
>
> 2) <!-- [rfced] May we restructure and rephrase Sections 2.1.5.1 and
> 2.1.5.2 as
> follows for readability?
>
> Original (Section 2.1.5.1):
> A response that contained a response header:
>
> NOTE: '\' line wrapping per RFC 8792
>
> Use-As-Dictionary: \
> match="/product/*", match-dest=("document")
>
> Would specify matching any document request for a URL with a path
> prefix of /product/ on the same Origin (Section 4.3.1 of [HTTP]) as
> the original request.
>
> Perhaps (Section 2.5.1.1):
> A response that contained a response header (as shown below) would
> specify matching any document request for a URL with a path prefix of
> /product/ on the same Origin (Section 4.3.1 of [HTTP]) as the original
> request:
>
> NOTE: '\' line wrapping per RFC 8792
>
> Use-As-Dictionary: \
> match="/product/*", match-dest=("document")
>
Proposed edit looks good to me.
>
> ...
> Original (Section 2.5.1.2):
> A response that contained a response header:
>
> Use-As-Dictionary: match="/app/*/main.js"
>
> Would match any path that starts with "/app/" and ends with
> "/main.js".
>
> Perhaps (Section 2.5.1.2):
> A response that contained a response header (shown
> below) would match any path that starts with "/app/" and
> ends with "/main.js":
>
> Use-As-Dictionary: match="/app/*/main.js"
> -->
>
>
Proposed edit looks good to me.
>
> 3) <!--[rfced] Is "by running the steps to create a URL pattern" needed
> in this sentence or may it be rephrased as follows for conciseness?
>
> Original:
> 6. Let PATTERN be a URL pattern created by running the steps to
> create a URL pattern by setting input=MATCH, and baseURL=URL
> (see Part create of [URLPATTERN]).
>
> Perhaps:
> 6. Let PATTERN be a URL pattern; the URL pattern is created by
> setting input=MATCH and baseURL=URL (see Part create of
> [URLPATTERN]).
> -->
>
>
Proposed edit looks good to me.
>
> 4) <!--[rfced] May we update this sentence for clarity? Should "caching
> response header" be singular (option A) or plural (option B)?
> Should "caching" contain quote marks for consistency or is it
> correct as is?
>
> Current:
> The response to the fetch for the compression dictionary needs to
> include a "Use-As-Dictionary" and caching response headers for it to
> be usable as a compression dictionary.
>
> Perhaps A:
> The response to the fetch for the compression dictionary needs to
> include a "Use-As-Dictionary" response header and a caching response
> header for it to be usable as a compression dictionary.
>
> Perhaps B:
> The response to the fetch for the compression dictionary needs to
> include a "Use-As-Dictionary" response header and caching response
> headers for it to be usable as a compression dictionary.
> -->
>
Edit A looks good to me. It doesn't need multiple caching headers but it
does need at least one. caching is correct as it is without quotes because
there are different headers ("cache-control" and "Expires") that can be
used for caching. If future caching headers are added to HTTP in the future
then those would work as well so we don't want to call out specific headers.
>
> 5) <!-- [rfced] The following sentence points to a section (Section 9.2)
> that
> doesn't exist. The term "prefix dictionary" is used in Section 8.2. May
> we update as follows?
>
> Original:
> The dictionary used for the "dcb" content encoding is a "raw"
> dictionary type as defined in Section 2.1.4 and is treated as a
> prefix dictionary as defined in Section 9.2 of [SHARED-BROTLI].
>
> Perhaps:
> The dictionary used for the "dcb" content encoding is a "raw"
> dictionary type as defined in Section 2.1.4 and is treated as a
> prefix dictionary as defined in Section 8.2 of [SHARED-BROTLI].
> -->
>
>
Yes, thank you. The shared brotli draft was updated on the path to
publication after this was approved for publication. Now that shared brotli
is also in edit stage it should be stable.
>
> 6) <!-- [rfced] The phrase "available for use compressing the response..."
> is
> difficult to parse. Please let us know if option A or B is preferred.
>
> Original:
> When a compression dictionary is available for use compressing the
> response to a given request, the encoding to be used is negotiated
> through the regular mechanism for negotiating content encoding in
> HTTP through the "Accept-Encoding" request header and "Content-
> Encoding" response header.
>
> Perhaps A (removing "for use"):
> When a compression dictionary is available to compress the
> response to a given request, the encoding to be used is negotiated
> through the regular mechanism for negotiating content encoding in
> HTTP through the "Accept-Encoding" request header and "Content-
> Encoding" response header.
>
> Or
>
> Perhaps B (adding "to" for readability):
> When a compression dictionary is available for use to compress the
> response to a given request, the encoding to be used is negotiated
> through the regular mechanism for negotiating content encoding in
> HTTP through the "Accept-Encoding" request header and "Content-
> Encoding" response header.
> -->
>
>
Edit A looks good to me and is easier to read than B (while still being
accurate).
>
> 7) <!-- [rfced] FYI: We rephrased the following sentence for clarity.
>
> Original:
> Not only can the dictionary reveal information about the compressed
> data, but vice versa, data compressed with the dictionary can reveal
> the contents of the dictionary when an adversary can control parts of
> data to compress and see the compressed size.
>
> Current:
> The dictionary can reveal information about the compressed data and
> vice versa. That is, data compressed with the dictionary can reveal
> contents of the dictionary when an adversary can control parts of
> the data to compress and see the compressed size.
> -->
>
>
Looks good to me, thanks.
>
> 8) <!--[rfced] Please clarify the phrasing in this "either" sentence. Is
> the intended meaning that the dictionary and compressed response
> are same-origin or the response is cross-origin?
>
> Original:
> In browser terms, that means that both are either same-origin to the
> context
> they are being fetched from or that the response is cross-origin and
> passes
> the CORS check (see Part CORS check of [FETCH]).
>
> Perhaps:
> In browser terms, that means either the dictionary and compressed
> response are same-origin to the context they are being fetched from or
> the response is cross-origin and passes the Cross-Origin Resource
> Sharing (CORS) check (see Part CORS check of [FETCH]).
> -->
>
>
The proposed edit looks good to me.
>
> 9) <!-- [rfced] May we rephrase the following sentence to improve
> readability?
>
> Original:
> This includes partitioning the storage as cookies are partitioned as
> well
> as clearing the dictionaries whenever cookies are cleared.
>
> Perhaps:
> This includes partitioning the storage (just as cookies are
> partitioned), as well as clearing the dictionaries whenever cookies are
> cleared.
> -->
>
>
This is a bit more subtle because we want to partitioning to be at least as
strict as the partitioning used for cookies (not just that it should be
partitioned).
Maybe something like:
This includes partitioning the storage using partitioning similar to or
stricter than the partitioning used for cookies, as well as clearing the
dictionaries whenever cookies are cleared.
>
> 10) <!-- [rfced] We note that both symbolic citation tags and numeric
> citation tags are used for normative RFCs throughout the
> document. May we make this convention consistent by including a
> symbolic tag for RFC 8878 (perhaps "[ZSTD]")?
> -->
>
>
[ZSTD] instead of [RFC 8878[ for the references looks good to me.
>
> 11) <!-- [rfced] Terminology
>
> a) Throughout the text, the following term appears to be used
> inconsistently. Please review these occurrences and let us
> know if/how they may be made consistent.
>
> URL Pattern vs. URL pattern
>
This is a bit complicated because the standard is the "URL Pattern"
standard but a "URL pattern" is specifically a struct documented as part of
the standard <https://urlpattern.spec.whatwg.org/#url-pattern-struct>.
My recommendation would be to change the Url pattern references to be "URL
pattern struct" and leave "URL Pattern" as it is.
2.1.1. match:
OLD:
3. Let PATTERN be a URL pattern created by running the steps to
create a URL pattern by setting input=MATCH, and baseURL=URL (see
Part create of [URLPATTERN]).
NEW:
3. Let PATTERN be a "URL pattern struct" created by running the steps to
"create a URL pattern" by setting input=MATCH, and baseURL=URL (see
Part create of [URLPATTERN]).
2.2.2. Dictionary URL matching
OLD:
6. Let PATTERN be a URL pattern created by running the steps to
create a URL pattern by setting input=MATCH, and baseURL=URL (see
Part create of [URLPATTERN]).
NEW:
6. Let PATTERN be a "URL pattern struct" created by running the steps to
create a URL pattern by setting input=MATCH, and baseURL=URL (see
Part create of [URLPATTERN]).
> b) We note the following forms. Are these terms different or are any
> updates needed for consistency (i.e., should any of these forms be
> updated as '"Use-As-Dictionary" response header')?
>
> "Use-As-Dictionary" response header (3 instances)
> Use-As-Dictionary header (4 instances)
> Use-As-Dictionary response (1 instance)
> -->
>
>
All of the references should be changed to "Use-As-Dictionary" response
header for consistency.
>
> 12) <!-- [rfced] FYI - We have added an expansion for the following
> abbreviation upon first use per Section 3.6 of RFC 7322 ("RFC
> Style Guide"). Please review each expansion in the document to
> ensure correctness.
>
> Cross-Origin Resource Sharing (CORS)
> -->
>
>
The expansion in the document is correct, thank you.
>
> 13) <!-- [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.
> -->
>
>
I double-checked the document and it all appeared to use the correct
language.
>
> Thank you.
>
> Madison Church and Karen Moore
> RFC Production Center
>
>
> On Aug 27, 2025, at 4:45 PM, rfc-edi...@rfc-editor.org wrote:
>
> *****IMPORTANT*****
>
> Updated 2025/08/27
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48. Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> * RFC Editor questions
>
> Please review and resolve any questions raised by the RFC Editor
> that have been included in the XML file as comments marked as
> follows:
>
> <!-- [rfced] ... -->
>
> These questions will also be sent in a subsequent email.
>
> * Changes submitted by coauthors
>
> Please ensure that you review any changes submitted by your
> coauthors. We assume that if you do not speak up that you
> agree to changes submitted by your coauthors.
>
> * Content
>
> Please review the full content of the document, as this cannot
> change once the RFC is published. Please pay particular attention to:
> - IANA considerations updates (if applicable)
> - contact information
> - references
>
> * Copyright notices and legends
>
> Please review the copyright notice and legends as defined in
> RFC 5378 and the Trust Legal Provisions
> (TLP – https://trustee.ietf.org/license-info).
>
> * Semantic markup
>
> Please review the markup in the XML file to ensure that elements of
> content are correctly tagged. For example, ensure that <sourcecode>
> and <artwork> are set correctly. See details at
> <https://authors.ietf.org/rfcxml-vocabulary>.
>
> * Formatted output
>
> Please review the PDF, HTML, and TXT files to ensure that the
> formatted output, as generated from the markup in the XML file, is
> reasonable. Please note that the TXT will have formatting
> limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
> * your coauthors
>
> * rfc-edi...@rfc-editor.org (the RPC team)
>
> * other document participants, depending on the stream (e.g.,
> IETF Stream participants are your working group chairs, the
> responsible ADs, and the document shepherd).
>
> * auth48archive@rfc-editor.org, which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion
> list:
>
> * More info:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
> * The archive itself:
> https://mailarchive.ietf.org/arch/browse/auth48archive/
>
> * Note: If only absolutely necessary, you may temporarily opt out
> of the archiving of messages (e.g., to discuss a sensitive matter).
> If needed, please add a note at the top of the message that you
> have dropped the address. When the discussion is concluded,
> auth48archive@rfc-editor.org will be re-added to the CC list and
> its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes. Information about stream managers can be found in
> the FAQ. Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication. Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
> https://www.rfc-editor.org/authors/rfc9842.xml
> https://www.rfc-editor.org/authors/rfc9842.html
> https://www.rfc-editor.org/authors/rfc9842.pdf
> https://www.rfc-editor.org/authors/rfc9842.txt
>
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9842-diff.html
> https://www.rfc-editor.org/authors/rfc9842-rfcdiff.html (side by side)
>
> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9842-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9842
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9842 (draft-ietf-httpbis-compression-dictionary-19)
>
> Title : Compression Dictionary Transport
> Author(s) : P. Meenan, Y. Weiss
> WG Chair(s) : Mark Nottingham, Tommy Pauly
> Area Director(s) : Gorry Fairhurst, Mike Bishop
>
>
>
>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
