Hi Sabrina, The changes look good.
Thanks! Madison Church RFC Production Center > On Sep 5, 2025, at 4:20 PM, Sabrina Tanamal via RT <[email protected]> > wrote: > > 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]
