This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"body": "Is \"to the encoder\" intended? Should this be \"within the encoder\" or might \"contain\" be made \"limit\" or something else?\n\nOriginal:\n\n QPACK is designed to contain the more complex state tracking to the\n encoder, while the decoder is relatively simple.\n",
"body": "Note that we updated instances of 'artwork type=\"drawing\"' to type=\"ascii-art\". However, we wonder if any of these should be tagged as sourcecode instead. Please review. \n\nOriginal (in the XML): \n <artwork type=\"drawing\" name=\"\" align=\"left\" alt=\"\"> \n\nSee <https://authors.ietf.org/rfcxml-vocabulary#sourcecode> for more information about sourcecode. \n",
"body": "The repeated \"when\" clauses in this sentence make it\n difficult to parse. If our suggestion does not correctly capture\n your intent, could you please rephrase?\n\n\nOriginal:\nA stream becomes unblocked when the Insert Count becomes\nunblocked when the Insert Count becomes greater than or equal to the\nRequired Insert Count for all encoded field sections the decoder has\nstarted reading from the stream.\n\nPerhaps:\nA stream becomes unblocked when the Insert Count becomes\nunblocked. When the Insert Count becomes greater than or equal to the\nRequired Insert Count for all encoded field sections, the decoder has\nstarted reading from the stream.\n\n",
"body": "May we update \"Huffman-coded\" with \"Huffman encoded\" in this text to match other uses?\n\nOriginal:\nThey begin with a single bit flag, denoted as 'H' in this document\n(indicating whether the string is Huffman-coded), followed by the\nLength encoded as a 7-bit prefix integer, and finally Length bytes of\ndata.\n",
"createdAt": "2022-03-25T17:40:09Z",
"updatedAt": "2022-03-25T17:40:09Z",
"closedAt": null,
"comments": []
},
{
"number": 4972,
"id": "I_kwDOBGXJj85GZZ5B",
"title": "To avoid awkward hyphenation, may we rephrase this text?\n\nOriginal (comment 6)",
"body": "To avoid awkward hyphenation, may we rephrase this text?\n\nOriginal:\nThe string uses one bit for the Huffman flag,\n followed by the Length encoded as an (N-1)-bit prefix integer. \n\nPerhaps:\nThe string uses one bit for the Huffman flag,\n followed by the Length encoded as a prefix integer of (N-1) bits.\n",
"createdAt": "2022-03-25T17:40:10Z",
"updatedAt": "2022-03-25T17:40:10Z",
"closedAt": null,
"comments": []
},
{
"number": 4973,
"id": "I_kwDOBGXJj85GZZ5L",
"title": "Should the following text be formatted using <aside>? (comment 7)",
"body": "Should the following text be formatted using <aside>? See the definition at <https://authors.ietf.org/rfcxml-vocabulary#aside>.\n\nOriginal:\n\n Note: Padding schemes only provide limited protection against an\n attacker with these capabilities, potentially only forcing an\n increased number of guesses to learn the length associated with a\n given guess. Padding schemes also work directly against\n compression by increasing the number of bits that are transmitted.\n\nOriginal:\n\n Note: Simply removing entries corresponding to the field from the\n dynamic table can be ineffectual if the attacker has a reliable\n way of causing values to be reinstalled. For example, a request\n to load an image in a web browser typically includes the Cookie\n header field (a potentially highly valued target for this sort of\n attack), and websites can easily force an image to be loaded,\n thereby refreshing the entry in the dynamic table.\n\n",
"body": "RFC-to-be 9114 (draft-ietf-quic-http) includes the following note to indicate that the registrations have a status of permanent and the Change Controller is the IETF. Should a similar statement be included in this document? \n\nFrom RFC-to-be 9114:\n The initial allocations in these registries created in this document\n are all assigned permanent status and list a change controller of the\n IETF and a contact of the HTTP working group (ietf-http-wg@w3.org).\n\nIn addition, note that the padding in the Settings, Stream Types, and Error Codes differs from what appears in the IANA registry. IANA included the following note when they notified us that their actions for RFC-to-be 9114 were complete:\n\n NOTE: In the new registries, the padding has been adjusted for consistency from one\n registry to another and with iana.org/assignments/quic. We understand that there may\n be a request to change it.\n\nWe have asked Mike (as editor of RFC-to-be 9114) to review, as the padding for the HTTP/3 registries is now inconsistent with the padding for the HTTP/2 registries. Please review and dicuss and let us know if any updates are needed. \n",
"body": "Throughout, the document uses \"SETTINGS_\" as the first part of thte HTTP/3 setting names. We have updated this sentence for consistency. Please let us know if any corrections are needed. \n\nOriginal:\n\n For fomatting reasons, the setting names here are abbreviated by removing the 'SETTING_' prefix.\n\nCurrent: \n For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.\n\n",
"body": "We had the following questions related to the terminology\nused in this document.\n\na) Throughout the text, the following terminology appears to be used \ninconsistently. Please review these occurrences and let us know if/how they\nmay be made consistent. \n\nbase vs. Base\npost-base vs. Post Base\nlength vs. Length\ndelta vs. Delta Base\n\nb) We have updated the following terminology to use the form on the right consistently to match what we feel was the intended use. Please review and let us know any objections.\n\nInstruction / instruction (e.g., Insert Count Increment instructions)\n\nc) We see the use of both \"single pass\" and \"one pass\" in this\ndocument. Please review if these should be made uniform.\n",