Draft: rfc9204

Commentary: 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.  post - base vs. Post Base length vs. Length delta vs.   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 are n'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 does n't mesh with the rest of the QUIC documents , where the convention has been to capitalize field names , not terminology . One could argue that  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 did n'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 do n'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 ( "  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 do n't see any instances of ( capitalized ) " Instruction " in the document which are n'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
Paragraph (version A):
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
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.
Paragraph (version A):
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,
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.
Paragraph (version B):
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
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.
Paragraph (version B):
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,
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.
Paragraph (version A):
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
negative and the sign bit is set to 1.  If the field section was not
encoded using representations that reference the most recent entry in
the table and did not insert any new entries, the Base will be
greater than the Required Insert Count, so the delta will be positive
and the sign bit is set to 0.
Paragraph (version A):
The value of Base MUST NOT be negative.  Though the protocol might
operate correctly with a negative base using post-base indexing, it
is unnecessary and inefficient.  An endpoint MUST treat a field block
with an S bit of 1 as invalid if the value of Required Insert Count
is less than or equal to the value of Delta Base.
Paragraph (version A):
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
relative index of 1 refers to the fifth entry that was added to the
table; a post-base index of 1 refers to the eighth entry.
Paragraph (version B):
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
negative and the Sign bit is set to 1.  If the field section was not
encoded using representations that reference the most recent entry in
the table and did not insert any new entries, the Base will be
greater than the Required Insert Count, so the encoded difference
will be positive and the Sign bit is set to 0.
Paragraph (version B):
The value of Base MUST NOT be negative.  Though the protocol might
operate correctly with a negative Base using post-Base indexing, it
is unnecessary and inefficient.  An endpoint MUST treat a field block
with a Sign bit of 1 as invalid if the value of Required Insert Count
is less than or equal to the value of Delta Base.
Paragraph (version B):
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
relative index of 1 refers to the fifth entry that was added to the
table; a post-Base index of 1 refers to the eighth entry.