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. --> 2) <!-- [rfced] Please verify that WIT is the correct area for this document. --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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 --> 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. --> 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... --> 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. --> 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. --> 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. --> 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. --> 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. --> 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. --> 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). --> 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. --> 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: --> 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. --> 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). --> 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 --> 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. --> 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. --> 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. --> 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. --> 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/>. --> 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) --> 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. --> 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
