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]
