Jyrki, Thai, Evgenii, This is a friendly reminder that we have yet to hear back from you regarding this document’s readiness for publication.
Please review the AUTH48 status page (http://www.rfc-editor.org/auth48/rfc9841) for further information and the previous messages in this thread. Thank you! Madison Church RFC Production Center > On Sep 11, 2025, at 8:45 AM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > Hi Lode, > > Thank you for your reply! We have marked your approval on the AUTH48 status > page (see https://www.rfc-editor.org/auth48/rfc9841). > > Once we receive approvals from Jyrki, Thai, and Evgenii, we will move this > document forward in the publication process. > > Thank you! > > Madison Church > RFC Production Center > >> On Sep 11, 2025, at 3:38 AM, Lode Vandevenne <l...@google.com> wrote: >> >> Hello Madison, >> >> I also approve the RFC for publication >> >> Thank you and kind regards, >> Lode Vandevenne >> >> Am Di., 9. Sept. 2025 um 23:52 Uhr schrieb Madison Church >> <mchu...@staff.rfc-editor.org>: >> Hi All, >> >> Mike - Thank you for your reply! We have marked your approval as AD on the >> AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9841). >> >> Authors - We now await approvals from Jyrki, Thai, Evgenii, and Lode. Once >> we receive all author approvals, we will move this document forward in the >> publication process. >> >> Thank you! >> >> Madison Church >> RFC Production Center >> >>> On Sep 9, 2025, at 2:37 PM, Mike Bishop <mbis...@evequefou.be> wrote: >>> >>> It's related to work in the HTTP WG, so I'll take it. I've reviewed the >>> Auth48 changes, including that sentence in the abstract, and I >>> approve.From: Madison Church <mchu...@staff.rfc-editor.org> >>> Sent: Monday, September 8, 2025 4:26 PM >>> To: Gorry Fairhurst <go...@erg.abdn.ac.uk>; Mike Bishop >>> <mbis...@evequefou.be> >>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; auth48archive@rfc-editor.org >>> <auth48archive@rfc-editor.org>; pmee...@google.com<pmee...@google.com>; >>> Jyrki Alakuijala <jy...@google.com>; Zoltan Szabadka <szaba...@google.com>; >>> eus...@google.com<eus...@google.com>; tha...@google.com >>> <tha...@google.com>; l...@google.com <l...@google.com> >>> Subject: Re: [ADs - Gorry and Mike] AUTH48: RFC-to-be 9841 >>> <draft-vandevenne-shared-brotli-format-15> for your review >>> Hi Gorry and Mike, >>> >>> We are unsure who the responsible AD is for this document, so we are >>> requesting that one of you (as WIT ADs) review and approve an update that >>> was made to the last sentence of the Abstract (see >>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html). >>> >>> Original: >>> This document updates RFC 7932. >>> >>> Current: >>> This document specifies an extension to the method defined in RFC 7932. >>> >>> Thank you! >>> >>> Madison Church >>> RFC Production Center >>> >>>> On Sep 8, 2025, at 3:14 PM, Madison Church <mchu...@staff.rfc-editor.org> >>>> wrote: >>>> >>>> Hi Zoltan, >>>> >>>> Thank you for your reply! We have noted your approval (see >>>> https://www.rfc-editor.org/auth48/rfc9841). >>>> >>>> Once we receive all approvals listed on the AUTH48 status page, we will >>>> move this document forward in the publication process. >>>> >>>> Thank you! >>>> >>>> Madison Church >>>> RFC Production Center >>>> >>>>> On Sep 5, 2025, at 3:36 AM, Zoltan Szabadka <szaba...@google.com> wrote: >>>>> >>>>> Hi Madison, >>>>> >>>>> I approve the RFC for publication. >>>>> >>>>> Thank you, >>>>> Zoltan Szabadka >>>>> >>>>> >>>>> On Thu, Sep 4, 2025 at 8:31 PM Madison Church >>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>> Hi Zoltan, >>>>> >>>>> Thank you for your reply! We have updated the files with your requested >>>>> changes and posted them below. >>>>> >>>>> Additionally, note that we have updated the text below from Section 9 to >>>>> match the text that appears in Section 9.2 of RFC-to-be-9842 >>>>> (draft-ietf-httpbis-compression-dictionary-19), which is also in Cluster >>>>> 509 and normatively references this document (see >>>>> https://www.rfc-editor.org/cluster_info.php?cid=C509). >>>>> >>>>> 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. >>>>> >>>>> Updated files (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9841.txt >>>>> https://www.rfc-editor.org/authors/rfc9841.pdf >>>>> https://www.rfc-editor.org/authors/rfc9841.html >>>>> https://www.rfc-editor.org/authors/rfc9841.xml >>>>> >>>>> Updated diff files: >>>>> https://www.rfc-editor.org/authors/rfc9841-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9841-rfcdiff.html (side by side) >>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html >>>>> https://www.rfc-editor.org/authors/rfc9841-auth48rfcdiff.html (side by >>>>> side) >>>>> >>>>> Once we receive all approvals listed on the AUTH48 status page (see >>>>> https://www.rfc-editor.org/auth48/rfc9841), we will move this document >>>>> forward in the publication process. >>>>> >>>>> Thank you, >>>>> Madison Church >>>>> RFC Production Center >>>>> >>>>>> On Sep 4, 2025, at 2:32 AM, Zoltan Szabadka <szaba...@google.com> wrote: >>>>>> >>>>>> I went over the diffs again, see below a few more minor findings. >>>>>> >>>>>> Section 1.5 >>>>>> >>>>>> "bytes with the MSB are also written on the left" should be changed to >>>>>> "we also write bytes with the MSB on the left" >>>>>> >>>>>> Section 3.1 >>>>>> >>>>>> "If the dictionary is context dependent, it includes a lookup table of a >>>>>> 64 word list and transform list combinations." >>>>>> >>>>>> Here the indefinite article before 64 feels wrong, since it refers to >>>>>> combinations, which is plural, so "of a 64" should be changed to "of 64". >>>>>> >>>>>> Section 5. >>>>>> >>>>>> LZ7711 --> LZ77 >>>>>> >>>>>> On Wed, Sep 3, 2025 at 4:38 PM Madison Church >>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>> Hi Authors, *Francesca, >>>>>> >>>>>> Authors - This is a friendly reminder that we have yet to hear back from >>>>>> you regarding this document’s readiness for publication. >>>>>> >>>>>> *Francesca - As responsible AD for this document, please review and >>>>>> approve the following change in the Abstract (see >>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html). >>>>>> >>>>>> Please review the AUTH48 status page >>>>>> (http://www.rfc-editor.org/auth48/rfc9841) for further information and >>>>>> the previous messages in this thread. >>>>>> >>>>>> Thank you! >>>>>> Madison Church >>>>>> RFC Production Center >>>>>> >>>>>>> On Aug 27, 2025, at 2:07 PM, Madison Church >>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>> >>>>>>> Hi Authors, *Francesca, >>>>>>> >>>>>>> Authors - Thank you for your replies! We have updated the document per >>>>>>> your request. Please see below for updated files. >>>>>>> >>>>>>> *Francesca - As responsible AD for this document, please review and >>>>>>> approve the following change in the Abstract (see >>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html). >>>>>>> >>>>>>> Original: >>>>>>> This document updates RFC 7932. >>>>>>> >>>>>>> Current: >>>>>>> This document specifies an extension to the method defined in RFC 7932. >>>>>>> >>>>>>> The files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9841.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9841.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9841.html >>>>>>> https://www.rfc-editor.org/authors/rfc9841.xml >>>>>>> >>>>>>> The relevant diff files have been posted here: >>>>>>> https://www.rfc-editor.org/authors/rfc9841-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9841-rfcdiff.html (side by side) >>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48rfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> For the AUTH48 status page, please see: >>>>>>> https://www.rfc-editor.org/auth48/rfc9841. >>>>>>> >>>>>>> Once we receive all approvals, we will move this document forward in >>>>>>> the publication process. >>>>>>> >>>>>>> Thank you, >>>>>>> Madison Church >>>>>>> RFC Production Center >>>>>>> >>>>>>>> On Aug 26, 2025, at 7:53 AM, Zoltan Szabadka <szaba...@google.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 25, 2025 at 9:59 PM Jyrki Alakuijala <jy...@google.com> >>>>>>>> wrote: >>>>>>>> I think we should change: "This document updates RFC 7932." >>>>>>>> >>>>>>>> It should be: "This document specifies an extension to the method >>>>>>>> defined in RFC 7932."" >>>>>>>> >>>>>>>> As far as I see, there are two almost independent considerations here: >>>>>>>> >>>>>>>> 1) Whether the document should have the "Updates: 7932" field. This >>>>>>>> header was added during the AD review with the following reasoning >>>>>>>> (copied here for reference): >>>>>>>> >>>>>>>> "I think this document should "Update" RFC 7932. The "Update" header >>>>>>>> tag is flexible in its usage, and doesn't necessarily mean that the >>>>>>>> updating document is a required feature of the original document >>>>>>>> ("extension" is a valid use of "Update"), instead it creates a forward >>>>>>>> link from the original doc to the update. The question in this case if >>>>>>>> having such a link from 7932 would be useful for readers of 7932. I >>>>>>>> tend to say yes." >>>>>>>> >>>>>>>> I still agree with this, so I think we should keep the Updates header >>>>>>>> field. >>>>>>>> >>>>>>>> 2) How should this header field be reflected in the abstract. >>>>>>>> >>>>>>>> The relevant GENART review comment: >>>>>>>> >>>>>>>> "The draft header indicates that this document updates RFC7932, but >>>>>>>> the abstract doesn't seem to mention this, which it should." >>>>>>>> >>>>>>>> In this regard I agree with Jyrki that the sentence "This document >>>>>>>> specifies an extension to the method defined in RFC 7932." expresses >>>>>>>> more accurately the relationship between the two RFCs. >>>>>>>> >>>>>>>> RFC9841 is its own thing that is strongly based on RFC7932, but does >>>>>>>> not change RFC7932. >>>>>>>> >>>>>>>> RFC7932 is unchanged in its previous use, including the "br" content >>>>>>>> encoding. Nothing is obsoleted, updated or changed. >>>>>>>> >>>>>>>> The RFC9841 defines a new different method "sbr" to the same >>>>>>>> ecosystem, but with different compromises. Most websites will likely >>>>>>>> keep using "br" (RFC7932), as "sbr" gives some speed gains, but >>>>>>>> requires a higher level of competence from the webmasters. >>>>>>>> >>>>>>>> What are your thoughts about this? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 25, 2025 at 6:32 PM Madison Church >>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>> Hi Zoltan, >>>>>>>> >>>>>>>> Thank you for your feedback! We have updated the document as >>>>>>>> requested. Please see below for comments and updated files. >>>>>>>> >>>>>>>>> On Aug 25, 2025, at 2:44 AM, Zoltan Szabadka <szaba...@google.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Madison, >>>>>>>>> >>>>>>>>> I noticed some editorial changes that, in my opinion, changed the >>>>>>>>> meaning of the text. Could you restore these to the original version, >>>>>>>>> or maybe propose a wording that is even clearer? >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Zoltan >>>>>>>>> >>>>>>>>> ------------------ >>>>>>>>> In Section 3.1: >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> >>>>>>>>> If the dictionary is context dependent, it includes a lookup table of >>>>>>>>> 64 word list and transform list combinations. >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> If the dictionary is context dependent, it includes a lookup table of >>>>>>>>> a 64-word list and transform list combinations. >>>>>>>>> >>>>>>>>> I think the original text should be restored here. The intended >>>>>>>>> meaning was that each entry of the lookup table is a word list and >>>>>>>>> transform list combination and there are 64 such entries. >>>>>>>> >>>>>>>> We appreciate the helpful explanation! The original text has been >>>>>>>> restored. >>>>>>>> >>>>>>>>> -------------------- >>>>>>>>> In Section 8.4.10. The "per chunks listed:" heading got concatenated >>>>>>>>> to the end of the previous field (maybe an XML formatting mistake?). >>>>>>>>> I think it should remain in a separate line, as in the original: >>>>>>>>> >>>>>>>>> Current: >>>>>>>>> varint: Pointer into the file where the repeat metadata chunks are >>>>>>>>> located or 0 if they are not present per chunk listed: >>>>>>>>> >>>>>>>>> varint: Pointer into the file where this chunk begins. >>>>>>>>> >>>>>>>>> >>>>>>>>> New: >>>>>>>>> >>>>>>>>> varint: Pointer into the file where the repeat metadata chunks are >>>>>>>>> located or 0 if they are not present >>>>>>>>> >>>>>>>>> per chunk listed: varint: Pointer into the file where this chunk >>>>>>>>> begins. >>>>>>>>> ------------------------ >>>>>>>> >>>>>>>> Thank you for catching this. We have updated this section to match the >>>>>>>> original formatting as closely as possible. Please let us know if the >>>>>>>> updates are correct. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9841.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9841.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9841.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9841.xml >>>>>>>> >>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9841-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9841-rfcdiff.html (side by side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48rfcdiff.html (side by >>>>>>>> side) >>>>>>>> >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9841 >>>>>>>> >>>>>>>> Thank you! >>>>>>>> >>>>>>>> Madison Church >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>>> On Fri, Aug 22, 2025 at 9:51 PM Madison Church >>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>> Hi Authors, >>>>>>>>> >>>>>>>>> Zoltan - Thank you for the confirmation. We have updated the >>>>>>>>> indentation per your response. >>>>>>>>> >>>>>>>>> All - Please review the document carefully to ensure satisfaction as >>>>>>>>> we do not make changes once it has been published as an RFC. Contact >>>>>>>>> us with any further updates or with your approval of the document in >>>>>>>>> its current form. We will await approvals from each author prior to >>>>>>>>> moving forward in the publication process. >>>>>>>>> >>>>>>>>> The files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.xml >>>>>>>>> >>>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-rfcdiff.html (side by side) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48rfcdiff.html (side >>>>>>>>> by side) >>>>>>>>> >>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9841 >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Madison Church >>>>>>>>> RFC Production Center >>>>>>>>> >>>>>>>>>> On Aug 22, 2025, at 5:47 AM, Zoltan Szabadka <szaba...@google.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 21, 2025 at 9:33 PM Madison Church >>>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>>> Hi Zoltan, >>>>>>>>>> >>>>>>>>>> Thank you for your reply! We have updated the document based on your >>>>>>>>>> response to our questions. Please see one followup query inline. >>>>>>>>>> Updated files have been posted below. >>>>>>>>>> >>>>>>>>>>> 19) <!-- [rfced] May we update the following unordered list into a >>>>>>>>>>> definition list for consistency with the rest of Section 8.2? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> * uncompressed: the raw bytes >>>>>>>>>>> >>>>>>>>>>> * if "keep decoder", the continuation of the compressed >>>>>>>>>>> stream >>>>>>>>>>> which was interrupted at the end of the previous chunk. >>>>>>>>>>> The >>>>>>>>>>> decoder from the previous chunk must be used and its state >>>>>>>>>>> it had at the end of the previous chunk must be kept at the >>>>>>>>>>> start of the decoding of this chunk. >>>>>>>>>>> >>>>>>>>>>> * brotli: the bytes are in brotli format [RFC7932] >>>>>>>>>>> >>>>>>>>>>> * shared brotli: the bytes are in the shared brotli format >>>>>>>>>>> specified in Section 7 >>>>>>>>>>> >>>>>>>>>>> Perhaps: >>>>>>>>>>> uncompressed: The raw bytes. >>>>>>>>>>> >>>>>>>>>>> "keep decoder": If "keep decoder", the continuation of the >>>>>>>>>>> compressed stream >>>>>>>>>>> that was interrupted at the end of the previous chunk. The >>>>>>>>>>> decoder from the previous chunk must be used and its state >>>>>>>>>>> it had at the end of the previous chunk must be kept at the >>>>>>>>>>> start of the decoding of this chunk. >>>>>>>>>>> >>>>>>>>>>> brotli: The bytes are in brotli format [RFC7932]. >>>>>>>>>>> >>>>>>>>>>> shared brotli: The bytes are in the shared brotli format >>>>>>>>>>> specified in Section 7. >>>>>>>>>>> --> >>>>>>>>>>> >>>>>>>>>>> The original unordered list format is correct here, since only one >>>>>>>>>>> of these is included, depending on the CODEC bits. >>>>>>>>>>> >>>>>>>>>>> However, looking at this part now, the "X bytes: extra header >>>>>>>>>>> bytes" and "remaining bytes: the chunk contents" should be on the >>>>>>>>>>> same indentation level. >>>>>>>>>> >>>>>>>>>> Thank you for the clarification! Regarding the indentation level of >>>>>>>>>> "X bytes: extra header bytes" and "remaining bytes: the chunk >>>>>>>>>> contents", please let us know how the text should be aligned. (That >>>>>>>>>> is, should "X bytes: extra header bytes" be indented further to >>>>>>>>>> align with "remaining bytes: the chunk contents"? Or should >>>>>>>>>> "remaining bytes: the chunk contents" be outdented to align with the >>>>>>>>>> current placement of "X bytes: extra header bytes"?) >>>>>>>>>> >>>>>>>>>> The "remaining bytes: the chunk contents" should be outdented to >>>>>>>>>> align with the current placement of "X bytes: extra header bytes". >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> X bytes: Extra header bytes, depending on CHUNK_TYPE. If present, >>>>>>>>>> they are specified in the subsequent sections. >>>>>>>>>> >>>>>>>>>> remaining bytes: The chunk contents. The uncompressed data in >>>>>>>>>> the chunk content depends on CHUNK_TYPE and is specified in the >>>>>>>>>> subsequent sections. The compressed data has following format >>>>>>>>>> depending on CODEC: >>>>>>>>>> >>>>>>>>>> * uncompressed: The raw bytes. >>>>>>>>>> >>>>>>>>>> * If "keep decoder", the continuation of the compressed stream >>>>>>>>>> that was interrupted at the end of the previous chunk. The >>>>>>>>>> decoder from the previous chunk must be used and its state >>>>>>>>>> it had at the end of the previous chunk must be kept at the >>>>>>>>>> start of the decoding of this chunk. >>>>>>>>>> >>>>>>>>>> * brotli: The bytes are in brotli format [RFC7932]. >>>>>>>>>> >>>>>>>>>> * shared brotli: The bytes are in the shared brotli format >>>>>>>>>> specified in Section 7. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.txt >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841.xml >>>>>>>>>> >>>>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-rfcdiff.html (side by >>>>>>>>>> side) >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9841-auth48rfcdiff.html (side >>>>>>>>>> by side) >>>>>>>>>> >>>>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9841 >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Madison Church >>>>>>>>>> RFC Production Center >>>>> >>>> >> >> Lode Vandevenne >> Google + Switzerland GmbH, Identifikationsnummer: CH-020.4.028.116-1 -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
