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
