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])
-->
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")
...
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"
-->
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]).
-->
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.
-->
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].
-->
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.
-->
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.
-->
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]).
-->
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.
-->
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]")?
-->
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
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)
-->
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)
-->
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.
-->
Thank you.
Madison Church and Karen Moore
RFC Production Center
On Aug 27, 2025, at 4:45 PM, [email protected] 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
* [email protected] (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).
* [email protected], 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,
[email protected] 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 -- [email protected]
To unsubscribe send an email to [email protected]
