Draft: draft-ietf-quic-qpack

Commentary: M - x set - variable fill - column 80 
 Oops -- I tried to merge this manually and wound up pulling junk into the branch . Fixing .
Paragraph (version A):
Each entry possesses both an absolute index which is fixed for the
lifetime of that entry and a relative index which changes based on
the context of the reference.  The first entry inserted has an
absolute index of "1"; indices increase sequentially with each
insertion.
Paragraph (version B):
Each entry possesses both an absolute index which is fixed for the
lifetime of that entry and a relative index which changes based on
the context of the reference.  The first entry inserted has an
absolute index of "1"; indices increase by one with each insertion.
Paragraph (version A):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 at the transport layer, offering comparable
security to running TLS over TCP, but with improved connection setup
latency.
Paragraph (version A):
This document describes a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on design of HTTP/2.  This
document identifies HTTP/2 features that are subsumed by QUIC, and
describes how the other features can be implemented atop QUIC.
Paragraph (version B):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 at the transport layer, offering comparable
security to running TLS over TCP, but with improved connection setup
latency (unless TCP Fast Open RFC7413} is used).
Paragraph (version B):
This document defines a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on the design of HTTP/2.  This
document identifies HTTP/2 features that are subsumed by QUIC, and
describes how the other features can be implemented atop QUIC.
Paragraph (version A):
A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other
streams.  On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer.  The transport
layer buffers and orders received QUIC STREAM frames, exposing the
data contained within as a reliable byte stream to the application.
Paragraph (version B):
A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other
streams.  On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer.  The transport
layer buffers and orders received QUIC STREAM frames, exposing the
data contained within as a reliable byte stream to the application.
Although QUIC permits out-of-order delivery within a stream HTTP/3
does not make use of this feature.
Paragraph (version A):
Frames are used on control streams, request streams, and push
streams.  This section describes HTTP framing in QUIC.  For a
comparison with HTTP/2 frames, see h2-frames.
Paragraph (version B):
As discussed above, frames are carried on QUIC streams and used on
control streams, request streams, and push streams.  This section
describes HTTP framing in QUIC.  For a comparison with HTTP/2 frames,
see h2-frames.
Paragraph (version A):
Each frame's payload MUST contain exactly the identified fields.  A
frame that 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.
Paragraph (version B):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
When opening a new request stream, a PRIORITY frame MAY be sent as
the first frame of the stream creating a dependency on an existing
element.  In order to ensure that prioritization is processed in a
consistent order, any subsequent PRIORITY frames MUST be sent on the
control stream.  A PRIORITY frame received after other frames on a
request stream MUST be treated as a stream error of type
HTTP_UNEXPECTED_FRAME.
Paragraph (version B):
When opening a new request stream, a PRIORITY frame MAY be sent as
the first frame of the stream creating a dependency on an existing
element.  In order to ensure that prioritization is processed in a
consistent order, any subsequent PRIORITY frames for that request
stream MUST be sent on the control stream.  A PRIORITY frame received
after other frames on a request stream MUST be treated as a stream
error of type HTTP_UNEXPECTED_FRAME.
Paragraph (version A):
Note that the root of the tree cannot be referenced using a Stream ID
of 0, as in RFC7540; QUIC stream 0 carries a valid HTTP request.  The
root of the tree cannot be reprioritized.  A PRIORITY frame sent on a
request stream with the Prioritized Element Type set to any value
other than "11" or which expresses a dependency on a request with a
greater Stream ID than the current stream MUST be treated as a stream
error of type HTTP_MALFORMED_FRAME.  Likewise, a PRIORITY frame sent
on a control stream with the Prioritized Element Type set to "11"
MUST be treated as a connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version B):
Note that unlike in RFC7540, the root of the tree cannot be
referenced using a Stream ID of 0, as in QUIC stream 0 carries a
valid HTTP request.  The root of the tree cannot be reprioritized.  A
PRIORITY frame sent on a request stream with the Prioritized Element
Type set to any value other than "11" or which expresses a dependency
on a request with a greater Stream ID than the current stream MUST be
treated as a stream error of type HTTP_MALFORMED_FRAME.  Likewise, a
PRIORITY frame sent on a control stream with the Prioritized Element
Type set to "11" MUST be treated as a connection error of type
HTTP_MALFORMED_FRAME.
Paragraph (version A):
A server can send this frame to indicate that it will not be
fulfilling a promise prior to creation of a push stream.  Once the
push stream has been created, sending CANCEL_PUSH has no effect on
the state of the push stream.  A QUIC RESET_STREAM frame SHOULD be
used instead to abort transmission of the server push response.
Paragraph (version A):
A CANCEL_PUSH frame is sent on the control stream.  Sending a
CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a stream error of type HTTP_WRONG_STREAM.
Paragraph (version B):
A server can send the CANCEL_PUSH frame to indicate that it will not
be fulfilling a promise prior to creation of a push stream.  Once the
push stream has been created, sending CANCEL_PUSH has no effect on
the state of the push stream.  A QUIC RESET_STREAM frame SHOULD be
used instead to abort transmission of the server push response.
Paragraph (version B):
A CANCEL_PUSH frame is sent on the control stream.  Receiving a
CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a stream error of type HTTP_WRONG_STREAM.
Paragraph (version A):
An endpoint MUST treat a CANCEL_PUSH frame which does not contain
exactly one properly-formatted variable-length integer as a
connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
Parameters MUST NOT occur more than once.  A receiver MAY treat the
presence of the same parameter more than once as a connection error
of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
Each value MUST be compared against the remaining length of the
SETTINGS frame.  A variable-length integer value which cannot fit
within the remaining length of the SETTINGS frame MUST cause the
SETTINGS frame to be considered malformed and trigger a connection
error of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
The SETTINGS frame affects connection state.  A badly formed or
incomplete SETTINGS frame MUST be treated as a connection error
(errors) of type HTTP_MALFORMED_FRAME.
Paragraph (version B):
Parameters MUST NOT occur more than once in the SETTINGS frame.  A
receiver MAY treat the presence of the same parameter more than once
as a connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
The GOAWAY frame carries a QUIC Stream ID for a client-initiated
bidirectional stream encoded as a variable-length integer.  A client
MUST treat receipt of a GOAWAY frame containing a Stream ID of any
other type as a connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version B):
The GOAWAY frame is always sent on the control stream.  It carries a
QUIC Stream ID for a client-initiated bidirectional stream encoded as
a variable-length integer.  A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type HTTP_MALFORMED_FRAME.
Paragraph (version A):
The MAX_PUSH_ID frame is always sent on a control stream.  Receipt of
a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type HTTP_WRONG_STREAM.
Paragraph (version A):
A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type
HTTP_MALFORMED_FRAME.
Paragraph (version B):
The MAX_PUSH_ID frame is always sent on the control stream.  Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type HTTP_WRONG_STREAM.
Paragraph (version B):
A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type
HTTP_UNEXPECTED_FRAME.
Paragraph (version A):
A server MUST treat a MAX_PUSH_ID frame payload that does not contain
a single variable-length integer as a connection error of type
HTTP_MALFORMED_FRAME.
Paragraph (version A):
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see frame-push-promise).  A server MUST treat a
DUPLICATE_PUSH frame payload that does not contain a single variable-
length integer as a connection error of type HTTP_MALFORMED_FRAME.
Paragraph (version B):
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see frame-push-promise).
Paragraph (version A):
A client sends an HTTP request on a client-initiated bidirectional
QUIC stream.  A server sends an HTTP response on the same stream as
the request.
Paragraph (version B):
A client sends an HTTP request on a client-initiated bidirectional
QUIC stream.  A client MUST send only a single request on a given
stream.  A server sends one or more HTTP responses on the same stream
as the request, as detailed below.
Paragraph (version A):
When the server aborts its response stream using
HTTP_REQUEST_CANCELLED, it indicates that no application processing
was performed.  The client can treat requests cancelled by the server
as though they had never been sent at all, thereby allowing them to
be retried later on a new connection.  Servers MUST NOT use the
HTTP_REQUEST_CANCELLED status for requests which were partially or
fully processed.
Paragraph (version A):
In this context, "processed" means that some data from the stream
was passed to some higher layer of software that might have taken
some action as a result.
Paragraph (version B):
When the server aborts its response stream using
HTTP_REQUEST_CANCELLED, it indicates that no application processing
was performed.  In this context, "processed" means that some data
from the stream was passed to some higher layer of software that
might have taken some action as a result.  The client can treat
requests cancelled by the server as though they had never been sent
at all, thereby allowing them to be retried later on a new
connection.  Servers MUST NOT use the HTTP_REQUEST_CANCELLED status
for requests which were partially or fully processed.
Paragraph (version A):
When a client request is first sent, its parent and weight are
determined by the PRIORITY frame (see frame-priority) which begins
the stream, if present.  Otherwise, the element is dependent on the
root of the priority tree.  Placeholders are also dependent on the
root of the priority tree when first allocated.  Pushed streams are
initially dependent on the client request on which the PUSH_PROMISE
frame was sent.  In all cases, elements are assigned an initial
weight of 16 unless an PRIORITY frame begins the stream.
Paragraph (version B):
When a client request is first sent, its parent and weight are
determined by the PRIORITY frame (see frame-priority) which begins
the stream, if present.  Otherwise, the element is dependent on the
root of the priority tree.  Placeholders are also dependent on the
root of the priority tree when first allocated.  Pushed streams are
initially dependent on the client request on which the PUSH_PROMISE
frame was sent.  In all cases, elements are assigned an initial
weight of 16 unless a PRIORITY frame begins the stream.
Paragraph (version A):
Servers can aggressively prune inactive regions from the priority
tree, because placeholders will be used to "root" any persistent
structure of the tree which the client cares about retaining.  For
prioritization purposes, a node in the tree is considered "inactive"
when the corresponding stream has been closed for at least two round-
trip times (using any reasonable estimate available on the server).
This delay helps mitigate race conditions where the server has pruned
a node the client believed was still active and used as a Stream
Dependency.
Paragraph (version B):
Because placeholders will be used to "root" any persistent structure
of the tree which the client cares about retaining, servers can
aggressively prune inactive regions from the priority tree For
prioritization purposes, a node in the tree is considered "inactive"
when the corresponding stream has been closed for at least two round-
trip times (using any reasonable estimate available on the server).
This delay helps mitigate race conditions where the server has pruned
a node the client believed was still active and used as a Stream
Dependency.
Paragraph (version A):
Once sent, the server MUST cancel requests sent on streams with an
identifier higher than the indicated last Stream ID.  Clients MUST
NOT send new requests on the connection after receiving GOAWAY,
although requests might already be in transit.  A new connection can
be established for new requests.
Paragraph (version B):
Once GOAWAY is sent, the server MUST cancel requests sent on streams
with an identifier higher than the indicated last Stream ID.  Clients
MUST NOT send new requests on the connection after receiving GOAWAY,
although requests might already be in transit.  A new connection can
be established for new requests.