All, We have now received all approvals and consider AUTH48 complete (see https://www.rfc-editor.org/auth48/rfc9842).
Once RFC-to-be-9481 completes AUTH48, we will move this document forward in the publication process. Best, Madison Church RFC Production Center > On Sep 8, 2025, at 8:25 AM, Madison Church <[email protected]> > wrote: > > 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]
