Draft: draft-ietf-quic-qpack

Commentary: Includes the invariants piece of and and a fix for . There are also a bunch of changes that are n't visible in the text diffs . I have n't done anything about the following : References were updated by the RPC , but not here . There 's a bunch of xi : include stuff to wade through there . The RPC has removed a trailing end - of - line from \<artwork\element content , which we ca n't do ( maybe something kramdown - rfc2629 can deal with ) . kramdown - rfc2629 produces definition lists with \<t\elements in the definition body : \<dd\<t . The RPC removed these . We might be able to do some post - processing . ( They the default attribute , but that can be ignored . ) \<bcp14\elements were ; see . 
 Invariants Section 5.2 : This document uses " Connection ID Lengths " , but draft - ietf - quic - transport uses " Connection ID lengths " . Would you like to make usage of this term in these two documents consistent ? Original ( this document ): include the Connection ID Lengths , Source Connection ID , or Version fields . Original ( draft - ietf - quic - transport ): Destination and Source Connection ID fields , and Version fields of a long header packet are version - independent . Suggested ( this document ): include the Destination Connection ID Length , Source Connection ID Length , Source Connection ID , or Version fields . Suggested ( draft - ietf - quic - transport ): Source Connection ID Length , Destination Connection ID , Source Connection ID , and Version fields of a long header packet are version independent . I think that this is good and we should take the suggestions . 
 LGTM . I like the consistency . 
 Yes . I think we 've been consistent that the noun " length(s ) " is not capitalized when talking about the value , but the name of the field ( " Destination Connection ID Length " ) is . However , it 's reasonable to make this sentence reference the fields which are being affected rather than the information they convey . 
 Fixed in 
 The RPC suggested : I think that this can just be : " Functionality " is incorrect . 
 I do n't have a strong opinion between either , but would tend to prefer the shorter text . 
 +1 
 -invariants does n't use this section . IANA has received that message . So it can be removed for publication . 
 This probably applies to -recovery also . 
 Removed from recovery draft in commit 
 The tag has been by the RPC to all uses of 2119 language . We should work out how to ensure that the XML we provide them can do the same . A short python script is probably the best option here as that will allow us to parse XML rather than rely on regular expressions catching these properly ( though a regex is probably still necessary ) . 
 Fixed in . 
 These are all either improvements or neutral . These are good .
Paragraph (version A):
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-qpack>.
Paragraph (version A):
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
version is still a work in progress.  For trial deployments, please
use earlier versions.
Paragraph (version A):
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-http>.
Paragraph (version A):
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-recovery>.
Paragraph (version A):
This document has no IANA actions.
Paragraph (version A):
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-invariants>.
Paragraph (version A):
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-tls>.
Paragraph (version A):
DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC.  This
version is still a work in progress.  For trial deployments, please
use earlier versions.
Paragraph (version A):
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-transport>.
Paragraph (version A):
When a draft implementation receives a Version Negotiation packet, it
MAY use it to attempt a new connection with one of the versions
listed in the packet, instead of abandoning the current connection
attempt; see handle-vn.
Paragraph (version A):
The client MUST check that the Destination and Source Connection ID
fields match the Source and Destination Connection ID fields in a
packet that the client sent.  If this check fails, the packet MUST be
discarded.
Paragraph (version A):
Once the Version Negotiation packet is determined to be valid, the
client then selects an acceptable protocol version from the list
provided by the server.  The client then attempts to create a new
connection using that version.  The new connection MUST use a new
random Destination Connection ID different from the one it had
previously sent.
Paragraph (version A):
Note that this mechanism does not protect against downgrade attacks
and MUST NOT be used outside of draft implementations.
Paragraph (version B):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgments are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY choose not to send an ACK frame with
outgoing frames until an ack-eliciting packet has been received.
Paragraph (version B):
An endpoint that is only sending non-ack-eliciting packets might
choose to occasionally add an ack-eliciting frame to those packets to
ensure that it receives an acknowledgment; see ack-tracking.  In that
case, an endpoint MUST NOT send an ack-eliciting frame in all packets
that would otherwise be non-ack-eliciting, to avoid an infinite
feedback loop of acknowledgments.
Paragraph (version A):
An endpoint that is only sending ACK frames will not receive
acknowledgments from its peer unless those acknowledgments are
included in packets with ack-eliciting frames.  An endpoint SHOULD
send an ACK frame with other frames when there are new ack-eliciting
packets to acknowledge.  When only non-ack-eliciting packets need to
be acknowledged, an endpoint MAY wait until an ack-eliciting packet
has been received to include an ACK frame with outgoing frames.
Paragraph (version A):
A receiver MUST NOT send an ack-eliciting frame in all packets that
would otherwise be non-ack-eliciting, to avoid an infinite feedback
loop of acknowledgments.
Paragraph (version A):
A variable-length integer error code that indicates the reason for
closing this connection.  A CONNECTION_CLOSE frame of type 0x1c
uses codes from the space defined in transport-error-codes.  A
CONNECTION_CLOSE frame of type 0x1d uses codes from the
application protocol error code space; see app-error-codes.
Paragraph (version B):
A variable-length integer error code that indicates the reason for
closing this connection.  A CONNECTION_CLOSE frame of type 0x1c
uses codes from the space defined in transport-error-codes.  A
CONNECTION_CLOSE frame of type 0x1d uses codes defined by the
application protocol; see app-error-codes.
Paragraph (version A):
Several pre-standardization versions will likely be in use at the
time of publication.  There is no need to document these in an
RFC, but recording information about these version will ensure
that the information in the registry is accurate.  The document
editors or working group chairs can facilitate getting the
necessary information.
Paragraph (version A):
The initial contents of this registry are shown in iana-error-table.