Draft: draft-ietf-quic-http

Commentary: This renders much better in HTML and the text format does not suffer for it . Conversion process was almost entirely mechanical : Cleanup used emacs because I know that wraps reliably . With the macro sequence : Then for each file it was basically just : Though I had to manually wrap the changelogs because emacs got greedy . 
 Since recovery is only in the pseudocode , LGTM .
Paragraph (version A):
An endpoint that is attempting to gracefully shut down a connection
can send a GOAWAY frame with a value set to the maximum possible
value (2^62-4 for servers, 2^62-1 for clients).  This ensures that
the peer stops creating new requests or pushes.  After allowing time
for any in-flight requests or pushes to arrive, the endpoint can send
another GOAWAY frame indicating which requests or pushes it might
accept before the end of the connection.  This ensures that a
connection can be cleanly shut down without losing requests.
Paragraph (version A):
A client has more flexibility in the value it chooses for the Push ID
in a GOAWAY that it sends.  A value of 2^62 - 1 indicates that the
server can continue fulfilling pushes that have already been
promised.  A smaller value indicates the client will reject pushes
with Push IDs greater than or equal to this value.  Like the server,
the client MAY send subsequent GOAWAY frames so long as the specified
Push ID is no greater than any previously sent value.
Paragraph (version A):
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit
is 2^23 encrypted packets; see gcm-bounds.  For
AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the
number of possible packets (2^62) and so can be disregarded.  For
AEAD_AES_128_CCM, the confidentiality limit is 2^21.5 encrypted
packets; see ccm-bounds.  Applying a limit reduces the probability
that an attacker can distinguish the AEAD in use from a random
permutation; see AEBounds, ROBUST, and GCM-MU.
Paragraph (version B):
encrypted packets; see ccm-bounds.  Applying a limit reduces the
probability that an attacker can distinguish the AEAD in use from a
random permutation; see AEBounds, ROBUST, and GCM-MU.
Paragraph (version A):
For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is
2^52 invalid packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305,
the integrity limit is 2^36 invalid packets; see AEBounds.  For
AEAD_AES_128_CCM, the integrity limit is 2^21.5 invalid packets; see
ccm-bounds.  Applying this limit reduces the probability that an
attacker can successfully forge a packet; see AEBounds, ROBUST, and
GCM-MU.
Paragraph (version B):
invalid packets; see ccm-bounds.  Applying this limit reduces the
probability that an attacker can successfully forge a packet; see
AEBounds, ROBUST, and GCM-MU.
Paragraph (version A):
Use of the same key and ciphertext sample more than once risks
compromising header protection.  Protecting two different headers
with the same key and ciphertext sample reveals the exclusive OR of
the protected fields.  Assuming that the AEAD acts as a PRF, if L
bits are sampled, the odds of two ciphertext samples being identical
approach 2^(-L/2), that is, the birthday bound.  For the algorithms
described in this document, that probability is one in 2^64.
Paragraph (version A):
Streams are identified within a connection by a numeric value,
referred to as the stream ID.  A stream ID is a 62-bit integer (0 to
2^62-1) that is unique for all streams on a connection.  Stream IDs
are encoded as variable-length integers; see integer-encoding.  A
QUIC endpoint MUST NOT reuse a stream ID within a connection.
Paragraph (version A):
If a max_streams transport parameter or a MAX_STREAMS frame is
received with a value greater than 2^60, this would allow a maximum
stream ID that cannot be expressed as a variable-length integer; see
integer-encoding.  If either is received, the connection MUST be
closed immediately with a connection error of type
TRANSPORT_PARAMETER_ERROR if the offending value was received in a
transport parameter or of type FRAME_ENCODING_ERROR if it was
received in a frame; see immediate-close.
Paragraph (version A):
The packet number is an integer in the range 0 to 2^62-1.  This
number is used in determining the cryptographic nonce for packet
protection.  Each endpoint maintains a separate packet number for
sending and receiving.
Paragraph (version A):
A QUIC endpoint MUST NOT reuse a packet number within the same packet
number space in one connection.  If the packet number for sending
reaches 2^62 - 1, the sender MUST close the connection without
sending a CONNECTION_CLOSE frame or any further packets; an endpoint
MAY send a Stateless Reset (stateless-reset) in response to further
packets that it receives.
Paragraph (version A):
Packet numbers are integers in the range 0 to 2^62-1 (packet-
numbers).  When present in long or short packet headers, they are
encoded in 1 to 4 bytes.  The number of bits required to represent
the packet number is reduced by including only the least significant
bits of the packet number.
Paragraph (version A):
The maximum acknowledgment delay is an integer value indicating
the maximum amount of time in milliseconds by which the endpoint
will delay sending acknowledgments.  This value SHOULD include the
receiver's expected delays in alarms firing.  For example, if a
receiver sets a timer for 5ms and alarms commonly fire up to 1ms
late, then it should send a max_ack_delay of 6ms.  If this value
is absent, a default of 25 milliseconds is assumed.  Values of
2^14 or greater are invalid.
Paragraph (version B):
or greater are invalid.
Paragraph (version A):
The largest offset delivered on a stream - the sum of the offset and
data length - cannot exceed 2^62-1.  Receipt of a frame that exceeds
this limit MUST be treated as a connection error of type
FRAME_ENCODING_ERROR or CRYPTO_BUFFER_EXCEEDED.
Paragraph (version A):
The first byte in the stream has an offset of 0.  The largest offset
delivered on a stream - the sum of the offset and data length -
cannot exceed 2^62-1, as it is not possible to provide flow control
credit for that data.  Receipt of a frame that exceeds this limit
MUST be treated as a connection error of type FRAME_ENCODING_ERROR or
FLOW_CONTROL_ERROR.
Paragraph (version A):
A count of the cumulative number of streams of the corresponding
type that can be opened over the lifetime of the connection.  This
value cannot exceed 2^60, as it is not possible to encode stream
IDs larger than 2^62-1.  Receipt of a frame that permits opening
of a stream larger than this limit MUST be treated as a
FRAME_ENCODING_ERROR.
Paragraph (version A):
A variable-length integer indicating the maximum number of streams
allowed at the time the frame was sent.  This value cannot exceed
2^60, as it is not possible to encode stream IDs larger than
2^62-1.  Receipt of a frame that encodes a larger stream ID MUST
be treated as a STREAM_LIMIT_ERROR or a FRAME_ENCODING_ERROR.
Paragraph (version A):
For codepoints that are encoded in variable-length integers (integer-
encoding), such as frame types, codepoints that encode to four or
eight bytes (that is, values 2^14 and above) SHOULD be used unless
the usage is especially sensitive to having a longer encoding.
Paragraph (version B):
and above) SHOULD be used unless the usage is especially sensitive to
having a longer encoding.