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 -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
