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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> >>> Sent: Monday, September 8, 2025 4:26 PM >>> To: Gorry Fairhurst <[email protected]<mailto:[email protected]>>; >>> Mike Bishop <[email protected]<mailto:[email protected]>> >>> Cc: RFC Editor >>> <[email protected]<mailto:[email protected]>>; >>> [email protected]<mailto:[email protected]> >>> <[email protected]<mailto:[email protected]>>; >>> [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>; >>> Jyrki Alakuijala <[email protected]<mailto:[email protected]>>; Zoltan >>> Szabadka <[email protected]<mailto:[email protected]>>; >>> [email protected]<mailto:[email protected]><[email protected]<mailto:[email protected]>>; >>> [email protected]<mailto:[email protected]> >>> <[email protected]<mailto:[email protected]>>; >>> [email protected]<mailto:[email protected]> >>> <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 25, 2025 at 9:59 PM Jyrki Alakuijala >>>>>>>> <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Aug 21, 2025 at 9:33 PM Madison Church >>>>>>>>>> <[email protected]<mailto:[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]
