Draft: draft-ietf-quic-datagram

Commentary: There are several instances of lowercase " may " in this document . It is ambiguous if these are normative requirements or not . 
 Could you elaborate on why it 's ambiguous ? We have a reference to RFC 8174 . 
 I sometimes assume typos :) If you 're happy the present document is correct , I will close this issue 
 I 'm not aware of errors like this , do you have any specific ones in mind ? 
 Gah , fat fingered accidental close . The example that triggered opening this issue is below , I had to read this several times . Perhaps that 's just a sign that editorial tweaks would help , regardless of the exact words in use 
 I can fix this 
 Thanks !
QUIC uses a more nuanced loss recovery mechanism than the DTLS
handshake, which has a basic packet loss retransmission timer.
This may allow loss recovery to occur more quickly for QUIC data.
QUIC uses a more nuanced loss recovery mechanism than the DTLS
handshake, which has a basic packet loss retransmission timer.
This can allow loss recovery to occur more quickly for QUIC data.
Application protocols using datagrams are responsible for defining
the semantics of the Datagram Data field, and how it is parsed.  If
the application protocol supports the coexistence of multiple
entities using datagrams inside a single QUIC connection, it may need
a mechanism to allow demultiplexing between them.  For example, using
datagrams with HTTP/3 involves prepending a flow identifier to all
datagrams, see I-D.schinazi-quic-h3-datagram.
Application protocols using datagrams are responsible for defining
the semantics of the Datagram Data field, and how it is parsed.  If
the application protocol supports the coexistence of multiple
entities using datagrams inside a single QUIC connection, it can use
a mechanism to allow demultiplexing between them.  For example, using
datagrams with HTTP/3 involves prepending a flow identifier to all
datagrams, see I-D.schinazi-quic-h3-datagram.
The risk associated with not providing flow control for DATAGRAM
frames is that a receiver may not be able to commit the necessary
resources to process the frames.  For example, it may not be able to
store the frame contents in memory.  However, since DATAGRAM frames
are inherently unreliable, they MAY be dropped by the receiver if the
receiver cannot process them.
DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection may be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows
it I-D.ietf-quic-recovery.  The sender implementation MUST
either delay sending the frame until the controller allows it or drop
the frame without sending it (at which point it MAY notify the
application).
The risk associated with not providing flow control for DATAGRAM
frames is that a receiver might not be able to commit the necessary
resources to process the frames.  For example, it might not be able
to store the frame contents in memory.  However, since DATAGRAM
frames are inherently unreliable, they MAY be dropped by the receiver
if the receiver cannot process them.
DATAGRAM frames employ the QUIC connection's congestion controller.
As a result, a connection might be unable to send a DATAGRAM frame
generated by the application until the congestion controller allows
it I-D.ietf-quic-recovery.  The sender implementation MUST
either delay sending the frame until the controller allows it or drop
the frame without sending it (at which point it MAY notify the
application).