Hi Madison, This is done:
https://www.iana.org/assignments/link-relations Thanks, Sabrina On Wed Sep 03 21:31:44 2025, [email protected] wrote: > IANA, > > Under the "Link Relation Types” registry at > "https://www.iana.org/assignments/link-relations/";, please make the > following update under the “Reference” column: > > OLD: > Relation Name: compression-dictionary > Reference: [RFC-ietf-httpbis-compression-dictionary-19] > > NEW: > Relation Name: compression-dictionary > Reference: [RFC-ietf-httpbis-compression-dictionary-19, Section 3] > > Thank you, > Madison Church > RFC Production Center > > > On Sep 3, 2025, at 4:25 PM, Patrick Meenan <[email protected]> > > wrote: > > > > Section pointers look good, thanks. No other updates needed that I > > can see. > > > > On Wed, Sep 3, 2025 at 5:21 PM Madison Church <[email protected] > > editor.org> wrote: > > Hi Patrick and Yoav, > > > > Thank you both for your quick replies! We have updated the files as > > requested and noted your approvals on the AUTH48 status page (see > > https://www.rfc-editor.org/auth48/rfc9842). > > > > Before we send our updates to IANA, please verify that the section > > pointers appear as desired in the output files below (or let us know > > if any changes are needed). > > > > 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) > > > > Thank you! > > > > Madison Church > > RFC Production Center > > > > > On Sep 3, 2025, at 1:18 PM, Yoav Weiss <[email protected]> > > > wrote: > > > > > > Thanks all! I approve this RFC for publication! :) > > > > > > On Wed, Sep 3, 2025 at 5:51 PM Patrick Meenan <[email protected]> > > > wrote: > > > 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 <[email protected] > > > 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 > > > > <[email protected]> wrote: > > > > > > > > On Wed, Aug 27, 2025 at 7:48 PM <[email protected]> > > > > 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, [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]
