Compatible version upgrade

draft-ietf-quic-http.md

@@ -182,7 +182,7 @@ includes an explicit port.
 
 This document defines the "quic" parameter for Alt-Svc, which MAY be used to
 provide version-negotiation hints to HTTP/QUIC clients. QUIC versions are
-four-octet sequences with no additional constraints on format.  Leading zeros
+four-byte sequences with no additional constraints on format.  Leading zeros
 SHOULD be omitted for brevity.
 
 Syntax:
@@ -303,9 +303,9 @@ or specify a value of zero for the QUIC transport parameter
 ## Unidirectional Streams
 
 Unidirectional streams, in either direction, are used for a range of purposes.
-The purpose is indicated by a stream type, which is sent as a single octet
-header at the start of the stream. The format and structure of data that follows
-this header is determined by the stream type.
+The purpose is indicated by a stream type, which is sent as a single byte header
+at the start of the stream. The format and structure of data that follows this
+header is determined by the stream type.
 
 ~~~~~~~~~~ drawing
  0 1 2 3 4 5 6 7
@@ -423,15 +423,15 @@ A frame includes the following fields:
   : A payload, the semantics of which are determined by the Type field.
 
 Each frame's payload MUST contain exactly the identified fields.  A frame that
-contains additional octets after the identified fields or a frame that
-terminates before the end of the identified fields MUST be treated as a
-connection error of type HTTP_MALFORMED_FRAME.
+contains additional bytes after the identified fields or a frame that terminates
+before the end of the identified fields MUST be treated as a connection error of
+type HTTP_MALFORMED_FRAME.
 
 ## Frame Definitions {#frames}
 
 ### DATA {#frame-data}
 
-DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets
+DATA frames (type=0x0) convey arbitrary, variable-length sequences of bytes
 associated with an HTTP request or response payload.
 
 DATA frames MUST be associated with an HTTP request or response.  If a DATA
@@ -736,7 +736,7 @@ made in relation to every response in which server push might be needed without
 duplicating pushes.
 
 A server that uses the same Push ID in multiple PUSH_PROMISE frames MUST include
-the same header fields each time.  The octets of the header block MAY be
+the same header fields each time.  The bytes of the header block MAY be
 different due to differing encoding, but the header fields and their values MUST
 be identical.  Note that ordering of header fields is significant.  A client
 MUST treat receipt of a PUSH_PROMISE with conflicting header field values for
@@ -921,11 +921,11 @@ head-of-line blocking.  See that document for additional details.
 
 An HTTP/QUIC implementation MAY impose a limit on the maximum size of the header
 it will accept on an individual HTTP message.  This limit is conveyed as a
-number of octets in the `SETTINGS_MAX_HEADER_LIST_SIZE` parameter.  The size of
-a header list is calculated based on the uncompressed size of header fields,
-including the length of the name and value in octets plus an overhead of 32
-octets for each header field.  Encountering a message header larger than this
-value SHOULD be treated as a stream error of type `HTTP_EXCESSIVE_LOAD`.
+number of bytes in the `SETTINGS_MAX_HEADER_LIST_SIZE` parameter.  The size of a
+header list is calculated based on the uncompressed size of header fields,
+including the length of the name and value in bytes plus an overhead of 32 bytes
+for each header field.  Encountering a message header larger than this value
+SHOULD be treated as a stream error of type `HTTP_EXCESSIVE_LOAD`.
 
 ### Request Cancellation
 
@@ -1343,8 +1343,8 @@ HTTP_GENERAL_PROTOCOL_ERROR (0x00FF):
 
 HTTP_MALFORMED_FRAME (0x01XX):
 : An error in a specific frame type.  The frame type is included as the last
-  octet of the error code.  For example, an error in a MAX_PUSH_ID frame would
-  be indicated with the code (0x10D).
+  byte of the error code.  For example, an error in a MAX_PUSH_ID frame would be
+  indicated with the code (0x10D).
 
 
 # Security Considerations

draft-ietf-quic-invariants.md

@@ -123,7 +123,7 @@ A QUIC packet is the content of the UDP datagrams exchanged by QUIC endpoints.
 This document describes the contents of those datagrams.
 
 QUIC defines two types of packet header: long and short.  Packets with long
-headers are identified by the most significant bit of the first octet being set;
+headers are identified by the most significant bit of the first byte being set;
 packets with a short header have that bit cleared.
 
 Aside from the values described here, the payload of QUIC packets is
@@ -154,21 +154,21 @@ version-specific semantics are marked with an X.
 ~~~
 {: #fig-long title="QUIC Long Header"}
 
-A QUIC packet with a long header has the high bit of the first octet set to 1.
-All other bits in that octet are version specific.
+A QUIC packet with a long header has the high bit of the first byte set to 1.
+All other bits in that byte are version specific.
 
-The next four octets include a 32-bit Version field (see {{version}}).
+The next four bytes include a 32-bit Version field (see {{version}}).
 
-The next octet contains the length in octets of the two Connection IDs (see
+The next byte contains the length in bytes of the two Connection IDs (see
 {{connection-id}}) that follow.  Each length is encoded as a 4-bit unsigned
 integer.  The length of the Destination Connection ID (DCIL) occupies the high
-bits of the octet and the length of the Source Connection ID (SCIL) occupies
-the low bits of the octet.  An encoded length of 0 indicates that the connection
-ID is also 0 octets in length.  Non-zero encoded lengths are increased by 3 to
-get the full length of the connection ID; the final value is therefore either 0
-or between 4 and 18 octets in length (inclusive).  For example, an octet with
-the value 0xe0 describes a 17 octet Destination Connection ID and a zero octet
-Source Connection ID.
+bits of the byte and the length of the Source Connection ID (SCIL) occupies the
+low bits of the byte.  An encoded length of 0 indicates that the connection ID
+is also 0 bytes in length.  Non-zero encoded lengths are increased by 3 to get
+the full length of the connection ID; the final value is therefore either 0 or
+between 4 and 18 bytes in length (inclusive).  For example, an byte with the
+value 0xe0 describes a 17 byte Destination Connection ID and a zero byte Source
+Connection ID.
 
 The connection ID lengths are followed by two connection IDs.  The connection
 ID associated with the recipient of the packet (the Destination Connection ID)
@@ -196,7 +196,7 @@ version-specific semantics are marked with an X.
 ~~~~~
 {: #fig-short title="QUIC Short Header"}
 
-A QUIC packet with a short header has the high bit of the first octet set to 0.
+A QUIC packet with a short header has the high bit of the first byte set to 0.
 
 A QUIC packet with a short header includes a Destination Connection ID.  The
 short header does not include the Connection ID Lengths, Source Connection ID,
@@ -239,7 +239,7 @@ either does not understand or does not support might send a Version Negotiation
 packet in response.  Packets with a short header do not trigger version
 negotiation.
 
-A Version Negotiation packet sets the high bit of the first octet, and thus it
+A Version Negotiation packet sets the high bit of the first byte, and thus it
 conforms with the format of a packet with a long header as defined in
 {{long-header}}.  A Version Negotiation packet is identifiable as such by the
 Version field, which is set to 0x00000000.

draft-ietf-quic-qpack.md

@@ -165,6 +165,7 @@ The dynamic table can contain duplicate entries (i.e., entries with the same
 name and same value).  Therefore, duplicate entries MUST NOT be treated as an
 error by a decoder.
 
+
 ### Maximum Table Size
 
 The encoder decides how to update the dynamic table and as such can control how
@@ -184,12 +185,13 @@ the dynamic table is less than or equal to the maximum size.
 This mechanism can be used to completely clear entries from the dynamic table by
 setting a maximum size of 0, which can subsequently be restored.
 
+
 ### Calculating Table Size
 
 The size of the dynamic table is the sum of the size of its entries.
 
-The size of an entry is the sum of its name's length in octets (as defined in
-{{string-literals}}), its value's length in octets, and 32.
+The size of an entry is the sum of its name's length in bytes (as defined in
+{{string-literals}}), its value's length in bytes, and 32.
 
 The size of an entry is calculated using the length of its name and value
 without any Huffman encoding applied.
@@ -464,7 +466,7 @@ This string format includes optional Huffman encoding.
 
 HPACK defines string literals to begin on a byte boundary.  They begin with a
 single flag (indicating whether the string is Huffman-coded), followed by the
-Length encoded as a 7-bit prefix integer, and finally Length octets of data.
+Length encoded as a 7-bit prefix integer, and finally Length bytes of data.
 When Huffman encoding is enabled, the Huffman table from Appendix B of [RFC7541]
 is used without modification.
 
@@ -507,7 +509,7 @@ string literal (see Section 5.2 of [RFC7541]).
    +---+---+-----------------------+
    | H |     Value Length (7+)     |
    +---+---------------------------+
-   | Value String (Length octets)  |
+   |  Value String (Length bytes)  |
    +-------------------------------+
 ~~~~~~~~~~
 {: title="Insert Header Field -- Indexed Name"}
@@ -527,11 +529,11 @@ represented as an 8-bit prefix string literal.
    +---+---+---+---+---+---+---+---+
    | 0 | 1 | H | Name Length (5+)  |
    +---+---+---+-------------------+
-   |  Name String (Length octets)  |
+   |  Name String (Length bytes)   |
    +---+---------------------------+
    | H |     Value Length (7+)     |
    +---+---------------------------+
-   | Value String (Length octets)  |
+   |  Value String (Length bytes)  |
    +-------------------------------+
 ~~~~~~~~~~
 {: title="Insert Header Field -- New Name"}
@@ -846,7 +848,7 @@ values that are not to be put at risk by compressing them (see Section 7.1 of
    +---+---+---+---+---------------+
    | H |     Value Length (7+)     |
    +---+---------------------------+
-   | Value String (Length octets)  |
+   |  Value String (Length bytes)  |
    +-------------------------------+
 ~~~~~~~~~~
 {: title="Literal Header Field With Name Reference"}
@@ -870,7 +872,7 @@ the header field name is represented using the post-base index of that entry
    +---+---+---+---+---+-----------+
    | H |     Value Length (7+)     |
    +---+---------------------------+
-   | Value String (Length octets)  |
+   |  Value String (Length bytes)  |
    +-------------------------------+
 ~~~~~~~~~~
 {: title="Literal Header Field With Post-Base Name Reference"}
@@ -899,11 +901,11 @@ represented as an 8-bit prefix string literal.
    +---+---+---+---+---+---+---+---+
    | 0 | 0 | 1 | N | H |NameLen(3+)|
    +---+---+---+---+---+-----------+
-   |  Name String (Length octets)  |
+   |  Name String (Length bytes)   |
    +---+---------------------------+
    | H |     Value Length (7+)     |
    +---+---------------------------+
-   | Value String (Length octets)  |
+   |  Value String (Length bytes)  |
    +-------------------------------+
 ~~~~~~~~~~
 {: title="Literal Header Field Without Name Reference"}