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
