I'm OK with using section pointers for the [FETCH] and [URLPATTERN] references given the commit snapshots (sorry, missed that those had been added).
The "create a URL pattern" changes in section 2.2.2 look good to me. Once the section pointers are added, I approve this RFC for publication. On Wed, Sep 3, 2025 at 11:24 AM Madison Church <mchu...@staff.rfc-editor.org> wrote: > Hi Patrick, > > Thank you for your reply! We have updated the document as requested. > Please see below for followup questions/comments and updated files. > > > On Aug 28, 2025, at 10:13 AM, Patrick Meenan <pmeenan= > 40google....@dmarc.ietf.org> wrote: > > > > 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. > > Thank you for your explanation. We note that the [FETCH] and [URLPATTERN] > reference entries contain commit snapshots, which readers can use to access > the versions of these specifications as they appear at the time of > publication (despite being living standards). Thus, the proposed section > pointers would be correct according to the commit snapshots. With this in > mind, would you still like to avoid using section pointers in these > citations? > > See https://whatwg.org/faq#change-at-any-time for more information. > > > 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. > > > > 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]). > > FYI - For the text in Section 2.2.2, we added quotes around "create a URL > pattern" to match Section 2.1.1. Please let us know if this is correct. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9842.txt > https://www.rfc-editor.org/authors/rfc9842.pdf > https://www.rfc-editor.org/authors/rfc9842.html > https://www.rfc-editor.org/authors/rfc9842.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9842-diff.html > https://www.rfc-editor.org/authors/rfc9842-rfcdiff.html (side by side) > https://www.rfc-editor.org/authors/rfc9842-auth48diff.html > https://www.rfc-editor.org/authors/rfc9842-auth48rfcdiff.html (side by > side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9842 > > Once we receive approvals from all parties listed on the AUTH48 status > page, we will move this document forward in the publication process. > > Thank you, > Madison Church > RFC Production Center > > > 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
