All, We have now received all necessary approvals and consider AUTH48 complete (see https://www.rfc-editor.org/auth48/rfc9841).
Thank you for your attention and guidance during the AUTH48 process! We will prepare the document for publication at this time. Best, Madison Church RFC Production Center > On Sep 26, 2025, at 11:32 PM, Jyrki Alakuijala <[email protected]> wrote: > > I approve. > > On Fri, Sep 26, 2025 at 4:47 PM Madison Church <[email protected]> > wrote: > Hi Patrick and Thai, > > Patrick - Thank you for verifying Thai’s approval! > > Thai - We have marked your approval on the AUTH48 status page (see > https://www.rfc-editor.org/auth48/rfc9841). > > Once we receive approval from Jyrki, we will move this document forward in > the publication process. > > Thank you! > > Madison Church > RFC Editor > > > On Sep 26, 2025, at 9:14 AM, Patrick Meenan <[email protected]> wrote: > > > > Thai responded with his approval on September 17th. Maybe it got missed? We > > should just be waiting on Jyrki at this point. > > > > On Fri, Sep 26, 2025 at 9:56 AM Madison Church > > <[email protected]> wrote: > > Hi Evengii, > > > > Thank you for your reply! We have marked your approval on the AUTH48 status > > page (please see https://www.rfc-editor.org/auth48/rfc9841). Note that we > > have not made any additional updates per Mike’s guidance. > > > > Once we receive approvals from Jyrki and Thai, we will move forward with > > publication. > > > > Thank you! > > > > Madison Church > > RFC Editor > > > > > On Sep 25, 2025, at 7:55 AM, Evgenii Kliuchnikov <[email protected]> > > > wrote: > > > > > > I approve then. > > > > > > On Mon, Sep 22, 2025 at 5:21 PM Mike Bishop <[email protected]> wrote: > > > I'm not certain about #2, but #1 and #3 definitely appear to be breaking > > > changes. I'd recommend strongly against making breaking changes to a > > > format in AUTH48 — this is a time for editorial corrections to the > > > document as approved, and catching instances where an editorial change > > > accidentally created an unintended technical change. > > > > > > From: Evgenii Kliuchnikov <[email protected]> > > > Sent: Monday, September 22, 2025 10:58 AM > > > To: Madison Church <[email protected]> > > > Cc: Lode Vandevenne <[email protected]>; Jyrki Alakuijala > > > <[email protected]>; Zoltan Szabadka <[email protected]>; > > > [email protected] <[email protected]>; Mike Bishop > > > <[email protected]>; Gorry Fairhurst <[email protected]>; RFC > > > Editor <[email protected]>; [email protected] > > > <[email protected]>; [email protected] <[email protected]> > > > Subject: Re: AUTH48: RFC-to-be 9841 > > > <draft-vandevenne-shared-brotli-format-15> for your review > > > Hello. > > > > > > I propose the following amendments: > > > 1) > > > Current: > > > "Then distance values of pairs in range (max allowed distance + 1).. > > > (LZ77_DICTIONARY_LENGTH + max allowed distance) are interpreted as > > > references starting in the LZ77 dictionary at the byte at > > > dictionary_address. If length is longer than (LZ77_DICTIONARY_LENGTH - > > > dictionary_address), then the reference continues to copy (length - > > > LZ77_DICTIONARY_LENGTH + dictionary_address) bytes from the regular LZ77 > > > window starting at the beginning." > > > Proposed: > > > "Then distance values of pairs in range (max allowed distance + 1).. > > > (LZ77_DICTIONARY_LENGTH + max allowed distance) are interpreted as > > > references starting in the LZ77 dictionary at the byte at > > > dictionary_address. If length is greater than (LZ77_DICTIONARY_LENGTH - > > > dictionary_address), then the reference is invalid." > > > Rationale: > > > Simplifies both encoder and decoder. Reduces ambiguity of determining of > > > what is "window starting" at the moment of continuation of copying. Most > > > likely "continuation" feature brings nearly 0 effect on density. > > > > > > 2) > > > Current: > > > "SIZE_BITS_BY_LENGTH. An array of 28 unsigned 8-bit integers, indexed by > > > word lengths 4 to 31. The value represents log2(number of words of this > > > length), with the exception of 0 meaning 0 words of this length. The max > > > allowed length value is 15 bits. OFFSETS_BY_LENGTH is computed from this > > > as OFFSETS_BY_LENGTH[i + 1] = OFFSETS_BY_LENGTH[i] + > > > (SIZE_BITS_BY_LENGTH[i] ? (i << SIZE_BITS_BY_LENGTH[i]) : 0)." > > > Proposed: > > > "SIZE_BITS_BY_LENGTH. An array of 28 unsigned 8-bit integers, indexed by > > > word lengths 4 to 31. The value 0 means 0 words of this length. Values in > > > range 1..15 represent power of two for number of words. OFFSETS_BY_LENGTH > > > is computed from this as OFFSETS_BY_LENGTH[i + 1] = OFFSETS_BY_LENGTH[i] > > > + (SIZE_BITS_BY_LENGTH[i] ? (i << SIZE_BITS_BY_LENGTH[i]) : 0)." > > > Rationale: > > > Though formulae uses bit shift for offset it is unclear that number of > > > words is exact power of two (or is zero). Moreover log2 is usually a > > > floating-point function. > > > > > > 3) > > > Current: > > > "STRING_LENGTH. The length of the entry contents. 0 for the last > > > (terminating) entry of the transform list. For other entries, > > > STRING_LENGTH must be in range 1..255. The 0 entry must be present and > > > must be the last byte of the PREFIX_SUFFIX_LENGTH bytes of prefix/suffix > > > data, else the stream must be rejected as invalid." > > > Proposed: > > > "STRING_LENGTH. The length of the entry contents. 0 for the last > > > (terminating) entry of the transform list. For other entries, > > > STRING_LENGTH must be in range 1..16. The 0 entry must be present and > > > must be the last byte of the PREFIX_SUFFIX_LENGTH bytes of prefix/suffix > > > data, else the stream must be rejected as invalid." > > > Rationale: > > > The maximum word size is 32. By adding 255 bytes of suffix and prefix it > > > becomes 542. It is unlikely that long prefixes/suffixes will give > > > considerable density improvements. But it will definitely make efficient > > > encoder implementations much more complex. Decoder also have minor > > > drawbacks from too-long transformed words. Altogether, if all the > > > stringlets have maximal size, stringlet library becomes 64KiB long; with > > > proposal - a bit over 4KiB is maximum. > > > > > > Best regards, > > > Eugene. > > > > > > On Thu, Sep 18, 2025 at 5:05 PM Madison Church > > > <[email protected]> wrote: > > > 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 > > > > <[email protected]> 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 <[email protected]> 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 > > > >> <[email protected]>: > > > >> 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 <[email protected]> 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 <[email protected]> > > > >>> Sent: Monday, September 8, 2025 4:26 PM > > > >>> To: Gorry Fairhurst <[email protected]>; Mike Bishop > > > >>> <[email protected]> > > > >>> Cc: RFC Editor <[email protected]>; > > > >>> [email protected] <[email protected]>; > > > >>> [email protected]<[email protected]>; Jyrki Alakuijala > > > >>> <[email protected]>; Zoltan Szabadka <[email protected]>; > > > >>> [email protected]<[email protected]>; [email protected] > > > >>> <[email protected]>; [email protected] <[email protected]> > > > >>> 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 > > > >>>> <[email protected]> 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 <[email protected]> > > > >>>>> wrote: > > > >>>>> > > > >>>>> Hi Madison, > > > >>>>> > > > >>>>> I approve the RFC for publication. > > > >>>>> > > > >>>>> Thank you, > > > >>>>> Zoltan Szabadka > > > >>>>> > > > >>>>> > > > >>>>> On Thu, Sep 4, 2025 at 8:31 PM Madison Church > > > >>>>> <[email protected]> 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 <[email protected]> > > > >>>>>> 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 > > > >>>>>> <[email protected]> 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 > > > >>>>>>> <[email protected]> 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 > > > >>>>>>>> <[email protected]> wrote: > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> On Mon, Aug 25, 2025 at 9:59 PM Jyrki Alakuijala > > > >>>>>>>> <[email protected]> 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 > > > >>>>>>>> <[email protected]> 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 > > > >>>>>>>>> <[email protected]> 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 > > > >>>>>>>>> <[email protected]> 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 > > > >>>>>>>>>> <[email protected]> wrote: > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> On Thu, Aug 21, 2025 at 9:33 PM Madison Church > > > >>>>>>>>>> <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
