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 > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
