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

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