Change:
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

Discussion:
A unique index for each entry in the dynamic table. <del> A reference point for relative and post-base indices. </del> <ins> A reference point for relative and post-Base indices. </ins> Representations that reference dynamic table entries are relative to a Base.

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

Each encoded field section is prefixed with two integers.  The Required Insert Count is encoded as an integer with an 8-bit prefix <del> using the encoding described in ric.  The Base is encoded as a sign </del> <ins> using the encoding described in ric.  The Base is encoded as a Sign </ins> bit ('S') and a Delta Base value with a 7-bit prefix; see base. 4.5.1.1.

described in relative-indexing. To save space, the Base is encoded relative to the Required Insert <del> Count using a one-bit sign ('S') and the Delta Base value.  A sign bit of 0 indicates that the Base is greater than or equal to the value of the Required Insert Count; the decoder adds the value of Delta Base to the Required Insert Count to determine the value of the Base.  A sign bit of 1 indicates that the Base is less than the Required Insert Count; the decoder subtracts the value of Delta Base from the Required Insert Count and also subtracts one to determine the value of the Base.  That is: </del> <ins> Count using a one-bit Sign ('S' in fig-base-index) and the Delta Base value.  A Sign bit of 0 indicates that the Base is greater than or equal to the value of the Required Insert Count; the decoder adds the value of Delta Base to the Required Insert Count to determine the value of the Base.  A Sign bit of 1 indicates that the Base is less than the Required Insert Count; the decoder subtracts the value of Delta Base from the Required Insert Count and also subtracts one to determine the value of the Base.  That is: </ins> A single-pass encoder determines the Base before encoding a field section.  If the encoder inserted entries in the dynamic table while encoding the field section and is referencing them, Required Insert Count will be greater than the Base, so the encoded difference is <del> negative and the sign bit is set to 1.  If the field section was not </del> <ins> negative and the Sign bit is set to 1.  If the field section was not </ins> encoded using representations that reference the most recent entry in the table and did not insert any new entries, the Base will be <del> greater than the Required Insert Count, so the delta will be positive and the sign bit is set to 0. </del> <ins> greater than the Required Insert Count, so the encoded difference will be positive and the Sign bit is set to 0. </ins> The value of Base MUST NOT be negative.  Though the protocol might <del> operate correctly with a negative base using post-base indexing, it </del> <ins> operate correctly with a negative Base using post-Base indexing, it </ins> is unnecessary and inefficient.  An endpoint MUST treat a field block <del> with an S bit of 1 as invalid if the value of Required Insert Count </del> <ins> with a Sign bit of 1 as invalid if the value of Required Insert Count </ins> is less than or equal to the value of Delta Base. An encoder that produces table updates before encoding a field section might set Base to the value of Required Insert Count.  In <del> such a case, both the sign bit and the Delta Base will be set to </del> <ins> such a case, both the Sign bit and the Delta Base will be set to </ins> zero. A field section that was encoded without references to the dynamic table can use any value for the Base; setting Delta Base to zero is one of the most efficient encodings. <del> For example, with a Required Insert Count of 9, a decoder receives an S bit of 1 and a Delta Base of 2.  This sets the Base to 6 and enables post-base indexing for three entries.  In this example, a </del> <ins> For example, with a Required Insert Count of 9, a decoder receives a Sign bit of 1 and a Delta Base of 2.  This sets the Base to 6 and enables post-Base indexing for three entries.  In this example, a </ins> relative index of 1 refers to the fifth entry that was added to the <del> table; a post-base index of 1 refers to the eighth entry. </del> <ins> table; a post-Base index of 1 refers to the eighth entry. </ins> 4.5.2.

4.5.3. <del> An indexed field line with post-base index representation identifies </del> <ins> An indexed field line with post-Base index representation identifies </ins> an entry in the dynamic table with an absolute index greater than or equal to the value of the Base. This representation starts with the '0001' 4-bit pattern.  This is <del> followed by the post-base index (post-base) of the matching field </del> <ins> followed by the post-Base index (post-base) of the matching field </ins> line, represented as an integer with a 4-bit prefix; see prefixed- integers.

4.5.5. <del> A literal field line with post-base name reference representation </del> <ins> A literal field line with post-Base name reference representation </ins> encodes a field line where the field name matches the field name of a dynamic table entry with an absolute index greater than or equal to the value of the Base. This representation starts with the '0000' 4-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.  This is <del> followed by a post-base index of the dynamic table entry (post-base) </del> <ins> followed by a post-Base index of the dynamic table entry (post-base) </ins> encoded as an integer with a 3-bit prefix; see prefixed-integers. Only the field name is taken from the dynamic table entry; the field