Draft: draft-ietf-quic-transport

Commentary: The strong requirements here were wrong . What is necessary from these sections is defining operations in QUIC that application protocols can depend on being present . Levying the requirement on implementations was incorrect . As some application protocols do n't use certain QUIC features , it is not necessary to require implementations to support features if they are not general purpose . This rephrases these requirements without normative language , instead concentrating on what services the application protocol can depend on . This translates into requirements on implementations , but only via the application protocols they intend to support . 
 S 5.4 requires that the application be able to control resource allocation of various types , including flow control and the number of permitted streams of each type ; This seems like a good idea , but it seems like one could have a reasonable QUIC stack that did not do this . 
 I would prefer to leave this . Noting that the level of control is not specified . This also suggests that the stack provide a keep - alive control , but there are likely cases ( I 'm thinking here of DNS over QUIC ) where that is unlikely to be a useful feature . The goal is to list things that the specification believes a generic stack will provide . Maybe we could avoid the implication that such an implementation is incomplete by saying that specialized implementations might provide less than a complete API . 
 willing to fight for this one ? 
 After discussing with editors , we think that it would be better to remove the MUST in this section and say something like : " A general purpose QUIC implementation provides the following functions : " and add " A specialized implementation might provide a subset of these . " The same applies to the stream operations . 
 I think that is a positive change . Borderline design issue by the sound of it . It would be good to see the PR once its available .
Paragraph (version A):
There are certain operations that an application MUST be able to
perform when interacting with QUIC streams.  This document does not
specify an API, but any implementation of this version of QUIC MUST
expose the ability to perform the operations described in this
section on a QUIC stream.
Paragraph (version B):
This document does not define an API for QUIC, but instead defines a
set of functions on streams that application protocols can rely upon.
An application protocol can assume that an implementation of QUIC
provides an interface that includes the operations described in this
section.  An implementation designed for use with a specific
application protocol might provide only those operations that are
used by that protocol.
Paragraph (version A):
Applications also need to be informed of state changes on streams,
including when the peer has opened or reset a stream, when a peer
aborts reading on a stream, when new data is available, and when data
can or cannot be written to the stream due to flow control.
Paragraph (version B):
An application protocol can also request to be informed of state
changes on streams, including when the peer has opened or reset a
stream, when a peer aborts reading on a stream, when new data is
available, and when data can or cannot be written to the stream due
to flow control.
Paragraph (version A):
There are certain operations that an application MUST be able to
perform when interacting with the QUIC transport.  This document does
not specify an API, but any implementation of this version of QUIC
MUST expose the ability to perform the operations described in this
section on a QUIC connection.
Paragraph (version B):
This document does not define an API for QUIC, but instead defines a
set of functions for QUIC connections that application protocols can
rely upon.  An application protocol can assume that an implementation
of QUIC provides an interface that includes the operations described
in this section.  An implementation designed for use with a specific
application protocol might provide only those operations that are
used by that protocol.