Change:
HPACK defines string literals to begin on a byte boundary.  They begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman encoded), followed by the <del> Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from Section B of RFC7541 is used without modification and Length indicates the size of the string after encoding. </del> <ins> string length encoded as a 7-bit prefix integer, and finally the indicated number of bytes of data.  When Huffman encoding is enabled, the Huffman table from Section B of RFC7541 is used without modification and the indicated length is the size of the string after encoding. </ins> This document expands the definition of string literals by permitting them to begin other than on a byte boundary.  An "N-bit prefix string literal" begins mid-byte, with the first (8-N) bits allocated to a previous field.  The string uses one bit for the Huffman flag, <del> followed by the Length encoded as a (N-1)-bit prefix integer.  The prefix size, N, can have a value between 2 and 8, inclusive.  The remainder of the string literal is unmodified. </del> <ins> followed by the length of the encoded string as a (N-1)-bit prefix integer.  The prefix size, N, can have a value between 2 and 8, inclusive.  The remainder of the string literal is unmodified. </ins> A string literal without a prefix length noted is an 8-bit prefix string literal and follows the definitions in RFC7541 without

Discussion:
While there are legitimate arguments for both capitalizing and not capitalizing Base, this is a smaller change and easier to be sure we got them all. That gets my vote at this point in the process. Each capitalization decision discussed in the issue is in a separate commit, in case we need to lift out and revisit one.
We had the following questions related to the terminology used in this document. a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. base vs. Base post-base vs. Post Base length vs. Length delta vs. Delta Base b) 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. Instruction / instruction (e.g., Insert Count Increment instructions) c) We see the use of both "single pass" and "one pass" in this document. Please review if these should be made uniform.
60 occurrences of "Base" vs. 31 occurrences of "base". Of those 31 lowercase instances, 22 of them are not part of the normal prose (e.g. pseudocode, section anchors, etc.) or aren't referring to this concept (e.g. "length-based", "based on"). Of the remaining nine, eight are occurrences of "post-base." Pretty clearly, our convention (deliberate or not) has been to capitalize this term. That doesn't mesh with the rest of the QUIC documents, where the convention has been to capitalize field names, not terminology. One could argue that Base is effectively a field, albeit one encoded on the wire as the sum/difference of two other values; of course, one could say the same of the QUIC packet number and we didn't capitalize that. The term "post-base" is uniformly not capitalized, except that "Post-Base" is used in the following two situations: When title-casing (probably correct) At the beginning of a sentence (probably incorrect) These two conventions don't align with each other. We should align on either "Base"/"post-Base" or "base"/"post-base".

"Length" is capitalized in several difference situations in the prose: In 4.1.2, defining string literals, "Length" is used interchangeably to refer to the length of the string and the field which contains that value. In field names ("Value Length", "Name Length") when representing the length-part of string literals In field diagrams, indicating the length of a field whose length was indicated by the previous field ("Length bytes") It seems to me that the first should be fixed while the second is fine. The third might benefit from a different means of indicating the size of the field, but it's not as obvious.
"delta" vs. "Delta Base" is used correctly, since "Delta Base" uniformly refers to the field. Lowercase "delta" is used in one instance to refer to the difference being encoded here; we could improve clarity by not using this term or by referring to the field.
I don't see any instances of (capitalized) "Instruction" in the document which aren't title-cased or the first word of a sentence. That's fine. The one instance of "One Pass" could be normalized to "Single Pass" without issue.
Fixed in .
Two small URL