Dear RFC Editors, Please see my answers to the editorial questions inline. Could you please generate an updated text file with the changes?
Thank you, Zoltan Szabadka On Wed, Aug 20, 2025 at 2:07 AM <rfc-edi...@rfc-editor.org> wrote: > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] Because this document updates RFC 7932, please > review the errata reported for RFC 7932 > (https://www.rfc-editor.org/errata/rfc7932) > and let us know if you confirm our opinion that none of them > are relevant to the content of this document. > --> > Those are not relevant to the contents of this document. > > > 2) <!-- [rfced] Please verify that WIT is the correct area for this > document. > --> > > Yes, that seems to be the correct area. > > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. > --> > > dictionary compression lz77 > > 4) <!--[rfced] In the second figure in Section 5.1, is "more significant > byte" intended (we note that it was used in RFC 7932), or should > it be changed to "most significant byte", which is used more > often in the RFC Series? > > Original: > 0 1 > +- - - - + - - - -+ > |00001000|00000010| > +- - - - + - - - -+ > ^ ^ > | | > | + more significant byte = 2 x 256 > + less significant byte = 8 > --> > > I think the original more/less significant byte is appropriate here, since this is explaining a notational principle, i.e. which way the bytes of a multi-byte number should be read. Note that this section was taken from the closely related RFC 1951. > > 5) <!-- [rfced] We have updated the following sentence for > clarity. Please let us know of any objections. > > Original: > If a shared dictionary is set, then it can set any of: LZ77 > dictionaries, overriding static dictionary words, and/or overriding > transforms. > > Current: > If a shared dictionary is set, then it can set LZ77 > dictionaries, override static dictionary words, and/or override > transforms. > --> > > This change looks good. > > 6) <!-- [rfced] May we rephrase the following sentences to avoid using "RFC > 7932" as an adjective and for subject-verb agreement (due to multiple > behaviors being overridden)? > > i) > Current: > If a custom word list is set, then the following behavior of the RFC > 7932 decoder [RFC7932] is overridden... > > Perhaps: > If a custom word list is set, then the following behaviors of the > decoder defined in [RFC7932] are overridden... > > ii) > Current: > If a custom transforms list is set without context dependency, then > the following behavior of the RFC 7932 decoder [RFC7932] is > overridden... > > Perhaps: > If a custom transforms list is set without context dependency, then > the following behaviors of the decoder defined in [RFC7932] are > overridden... > --> > > These changes look good. > > 7) <!-- [rfced] To improve the readability of this paragraph, may we > format the text into a list as follows? Also, should "a next > dictionary" be rephrased to "the next dictionary", "a dictionary > that follows", or otherwise to use the correct article? > > Current: > If a distance goes beyond the dictionary for the current ID and > multiple word/transform list combinations are defined, then a next > dictionary is used in the following order: if not context dependent, > the same order as defined in the shared dictionary. If context > dependent, the index matching the current context is used first, the > same order as defined in the shared dictionary excluding the current > context are used next. > > Perhaps: > If a distance goes beyond the dictionary for the current ID and > multiple word/transform list combinations are defined, then the next > dictionary is used in the following order: > > * If context dependent: > * use the index matching the current context first, and then > * use the same order as defined in the shared dictionary > (excluding the current context) next. > * If not context dependent: > * use the same order as defined in the shared dictionary. > --> > > The list form looks better, "the next dictionary" phrasing is ok. > 8) <!-- [rfced] Would the following proposed text retain the original > meaning of the sentence? > > Current: > A transform consists of a possible prefix, a transform operation, for > some operations a parameter, and a possible suffix. > > Perhaps: > A transform consists of a possible prefix, a transform operation, a > parameter (for some operations), and a possible suffix. > --> > > Yes, this seems equivalent. > > 9) <!-- [rfced] The original xref citation in the XML pointed to Section 8 > of this document. We have updated as follows. Please let us know > any objections. > > Current: > Operations 0 to 20 are specified in Section 8 of [RFC7932]. ShiftFirst > and ShiftAll transform specifically encoded SCALARs. > --> > > No objections. > > 10) <!-- [rfced] We have rephrased the following sentence for > readability. Please let us know any objections. > > Original: > Next, 1, 2, 3 or 4 not transformed bytes marked as > transformed, according to the SCALAR pattern length. > > Current: > Next, 1, 2, 3, or 4 untransformed bytes are marked as > transformed according to the SCALAR pattern length. > --> > > This change looks good. > > 11) <!-- [rfced] May we rephrase as follows for clarity? > > Current: > The last byte must have its MSB set to 0, all other bytes to 1 to > indicate there is a next byte. > > Perhaps: > The last byte must have its MSB set to 0 and all other bytes must > have their MSBs set to 1 to indicate there is a next byte. > --> > > This change looks good. > > 12) <!-- [rfced] Upon converting this document to XML, we have done our > best to preserve the original indentation of definition lists > that start in Section 5. Please let us know if any specific > adjustments need to be made or if the current indentation is > satisfactory. > --> > > The indentation looks good (based on the rendered text version). > > 13) <!-- [rfced] May we rephrase the following for clarity? > > Original: > 2 bytes: file signature, in hexadecimal the bytes 91, 0. > > Perhaps: > 2 bytes: File signature in hexadecimal format (bytes 91 and 0). > --> > > This change looks good. > > 14) <!--[rfced] In Section 5, may we add "in range" to these sentences for > clarity and consistency as shown below? > > Original: > 1 byte: NUM_CUSTOM_WORD_LISTS, may have value 0 to 64 > 1 byte: NUM_CUSTOM_TRANSFORM_LISTS, may have value 0 to 64 > 1 byte: NUM_DICTIONARIES, may have value 1 to 64 > > Perhaps: > 1 byte: NUM_CUSTOM_WORD_LISTS. May have a value in range 0 to 64. > 1 byte: NUM_CUSTOM_TRANSFORM_LISTS. May have a value in range 0 to 64. > 1 byte: NUM_DICTIONARIES. May have a value in range 1 to 64. > --> > > This change looks good. > > 15) <!--[rfced] In Section 5, please consider the following changes for > consistency within the list as we note variance with "TERM times > foo" vs. "TERM times: Foo:" (for example, "NUM_CUSTOM_WORD_LISTS > times a word list" vs. "NUM_DICTIONARIES times: The > DICTIONARY_MAP:" > > Additionally, should text be added such as "listed below", > "the following" and "which contains" to introduce the next > list of items? > > i) > Current: > NTRANSFORMS times: Data for each transform: > > Perhaps: > NTRANSFORMS times the data for each transform listed below: > > ii) > Current: > If and only if at least one transform has operation index > ShiftFirst or ShiftAll: > > NTRANSFORMS times: > > Perhaps: > If and only if at least one transform has operation index > ShiftFirst or ShiftAll, then NTRANSFORMS times the following: > > iii) > Current: > NUM_DICTIONARIES times: The DICTIONARY_MAP: > > Perhaps: > NUM_DICTIONARIES times the DICTIONARY_MAP, which contains: > --> > > All of these changes look good. > > 16) <!--[rfced] Would the following text (second sentence that starts with > "Encoding") be easier to read if it was a complete sentence as > shown below (note that the first sentence is included for context > only)? > > Also, under "6 bits", should "value" be singular or plural (e.g., > "must have values in" or "must have a value in")? > > Original: > The compressed data stream is backwards compatible to brotli > [RFC7932] and may optionally have the following differences: > > Encoding of WBITS in the stream header: The following new > pattern of 14 bits is supported: > > 8 bits: Value 00010001 to indicate a large window brotli stream. > > 6 bits: WBITS. Must have value in range 10 to 62. > > Perhaps: > The compressed data stream is backwards compatible to brotli > [RFC7932] and may optionally have the following differences. > > If the encoding of WBITS is in the stream header, then the following > new pattern of 14 bits is supported: > > 8 bits: Value 00010001 to indicate a large window brotli stream. > > 6 bits: WBITS. Must have a value in range 10 to 62. > --> > > The proposed change is not correct here, WBITS is always present in the stream header, so the sentence should not be conditional. I propose the following change instead: --- In the encoding of WBITS in the stream header the following new pattern of 14 bits is supported: 8 bits: Value 00010001 to indicate a large window brotli stream. 6 bits: WBITS. Must have a value in range 10 to 62. --- value should be singular since it is a single value per stream > 17) <!-- [rfced] May we rephrase the following sentence for clarity? > > Current: > File signature, in hexadecimal the bytes 0x91, 0x0a, 0x42, 0x52. > > Perhaps: > File signature in hexadecimal format (bytes 0x91, 0x0a, 0x42, and 0x52). > --> > > This change looks good. > 18) <!--[rfced] Is it correct that "bit" is singular in "bit 0 and 1", > "bit 2 and 3", and "bit 4-7"? Or should these instances be > updated as "bits 0 and 1", "bits 2 and 3", and "bits 4-7"? We > note 1 instance of "bits 2-7" in Section 8.4.3. > > Current: > bit 0 and 1: Version Indicator... > > bit 0 and 1: Dictionary source: > > bit 2 and 3: Dictionary type: > > bit 4-7: Must be 0 > --> > > These can be updated to plural form. > > 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. > > 20) <!--[rfced] In Section 8.4.2, the formatting of the list is hard to > read. While we note that this style follows RFC 7932, please > consider if you would like to update to a format that is more > typical in other RFCs. For example, see the excerpt below from > RFC 9188. > > Original: > id: name field. May appear 0 or 1 times. Has the following format: > > N bytes: name in UTF-8 encoding, length determined by the > field length. Treated generically but may be used as > filename. If used as filename, forward slashes '/' > should be used as directory separator, relative paths > should be used and filenames ending in a slash with > 0-length content in the matching data chunk should be > treated as an empty directory. > > mt: modification type. May appear 0 or 1 times. Has the following > format: > > 8 bytes: microseconds since epoch, as a little endian signed > twos complement 64-bit integer > > Perhaps: > id (N bytes): Name field. May appear 0 or 1 times. Has the following > format: name in UTF-8 encoding, length determined by the > field length. Treated generically but may be used as a > filename. If used as a filename, forward slashes '/' > should be used as directory separators, relative paths > should be used, and filenames ending in a slash with > 0-length content in the matching data chunk should be > treated as an empty directory. > > mt (8 bytes): Modification type. May appear 0 or 1 times. Has the > following > format: contains microseconds since epoch, as a little-endian, > signed two's complement 64-bit integer. > > Example from Section 4.1 of RFC 9188: > > Checksum (1 byte): This contains the (one's complement) checksum sum > of all 8 bits in the trailer. For purposes of computing the checksum, > the value of the Checksum field is zero. This field is present only > if > the Checksum Present bit is set to 1. > > First SDU Length (2 bytes): This is the length of the first IP packet > in > the PDU, only included if a PDU contains multiple IP packets. This > field is present only if the Concatenation Present bit is set to 1. > > Connection ID (1 byte): This contains an unsigned integer to identify > the anchor and delivery connection of the GMA PDU. This field is > present only if the Connection ID Present bit is set to 1. > --> > > This change looks good. > > 21) <!-- [rfced] We note that there are a few instances throughout the > document where asterisks "*" are used for emphasis. Would you > like to utilize the <strong> element in the XML? In the HTML and > PDF outputs, <strong> yields bold text. In the text output, > <strong> yields an asterisk before and after, similar to how it's > used currently. > > Current: > * If a field is present, then it must be present in *all* other > repeat metadata chunks when the copied chunk contains this field. > --> > > Yes, the <strong> element may be utilized in these cases. > > 22) <!--[rfced] In Section 8.4.11, how may we rephrase this sentence > for clarity? We note that "header" is not used elsewhere when > referring to "container flags"; should it be removed for > consistency? > > Original: > Chunk that closes the file, only present if in the initial container > header flags bit 2 was set. > > Perhaps: > The final footer chunk closes the file and is only present if bit 2 > of the initial container flags was set. > --> > > This change looks good. > > 23) <!-- [rfced] Please review the following reference. The original URL > for this > reference (https://developers.google.com/closure/templates/) redirects to > a page titled "Closure Tools" (https://developers.google.com/closure). > > Is this reference still correct or is an update needed? Note that the only > instance of this reference being cited in the text is shown below. > > Current (text): > Another idea is to extend existing web template systems (e.g., Soy > [SOY]) to allow developers to mark secrets that must not be > compressed. > > Current (reference): > [SOY] Google Developers, "Closure Tools", > <https://developers.google.com/closure/templates/>. > --> > > The redirected url looks correct. > 24) <!-- [rfced] FYI - We have added expansions for the following > abbreviations > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > most significant bit (MSB) > least significant bit (LSB) > personally identifiable information (PII) > --> > > These expansions are correct. > > 25) <!-- [rfced] Please review the "Inclusive Language" portion of the > online > Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > and let us know if any changes are needed. Updates of this nature > typically > result in more precise language, which is helpful for readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> > > I did not find any changes that are needed. > > Thank you. > > Madison Church and Karen Moore > RFC Production Center > > > On Aug 19, 2025, at 4:57 PM, RFC Editor via auth48archive < > auth48archive@rfc-editor.org> wrote: > > *****IMPORTANT***** > > Updated 2025/08/19 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9841.xml > https://www.rfc-editor.org/authors/rfc9841.html > https://www.rfc-editor.org/authors/rfc9841.pdf > https://www.rfc-editor.org/authors/rfc9841.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9841-diff.html > https://www.rfc-editor.org/authors/rfc9841-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9841-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9841 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9841 (draft-vandevenne-shared-brotli-format-15) > > Title : Shared Brotli Compressed Data Format > Author(s) : J. Alakuijala, T. Duong, E. Kliuchnikov, Z. Szabadka, > L. Vandevenne > WG Chair(s) : > Area Director(s) : > > > -- > auth48archive mailing list -- auth48archive@rfc-editor.org > To unsubscribe send an email to auth48archive-le...@rfc-editor.org > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
