Draft: draft-ietf-masque-h3-datagram

Commentary: Minor editorial clarification . 
 H3 datagrams are associated with a stream , so it makes sense that it is only valid to send DATAGRAMs before sending the stream FIN . These packets may be received out of order however . What should receivers do with these packets ? The simplest action for the receiver is to drop any datagrams received after FIN , but I can imagine applications where the receiver would prefer to allow them to be processed for some time . Should the draft offer guidance for this ? The answer might be different if we use Flow IDs as connection scoped identifiers or the 2 - layer approach ( Stream ID+Flow ID ) discussed at the interim . 
 I think this might be a case for " MUST NOT send datagram after the stream is closed for sending , MAY ignore datagrams if detected they are received after the stream is closed . " The challenge I 've seen for implementations is that the stream read and datagram read functions operate independently . Its hard to correlate any state or actions between the two . In my case , ACK'ing a packet containing a FIN does n't mean anything about how the receiver application will read the stream data . 
 Thanks for filing this . I 'll add text to address this after we switch to the two - layer approach ( assuming that becomes official WG consensus ) 
 The proposal here was receiver MAY drop a datagram after receiving FIN , but the merged PR has receiver MUST drop . I prefer MAY , since I can envision a use case where the receiver would rather wait for a period to allow wayward datagrams to arrive , rather than declaring everything lost because of minor reordering . Is there a strong objection to changing this MUST to a MAY ? 
 Can you provide an example of a use - case for not dropping a datagram which arrived after the stream was closed ? I 'm failing to imagine an application that would benefit from this . 
 " Naive Partial Reliability " or NPR : Client sends a request to the server indicating it is willing to accept the response body of an HTTP message over DATAGRAM rather than in the stream . Server sends the headers on the stream , and a marker indicating the response will come via DATAGRAMs ( registering a context for this perhaps ) Server sends DATAGRAMs containing the response body ( and offsets ) Server sends stream FIN The client receives the stream FIN before the DATAGRAMs because of reordering , and assumes all response body was lost . Datagrams arrive at client shortly thereafter and per are dropped . 
 HTTP/2 kind of has some similar issues . It makes statements like for a short period after a DATA or HEADERS frame containing an ENDSTREAM flag is sent . Until the remote peer receives and processes RSTSTREAM or the frame bearing the ENDSTREAM flag , it might send frames of these types . Endpoints MUST ignore WINDOWUPDATE or RSTSTREAM frames received in this state , though endpoints MAY choose to treat frames that arrive a significant time after sending ENDSTREAM as a connection error ( Section 5.4.1 ) of type PROTOCOL_ERROR . and elsewhere prioritization state for a period after streams become closed . The longer state is retained , the lower the chance that streams are assigned incorrect or default priority values . 
 OK this makes sense to me , I can tweak the text to allow keeping stream state around for slightly longer . 
 This improvement is good enough for me . Thanks .
If a DATAGRAM frame is received and its Quarter Stream ID maps to a
stream that has already been closed, the receiver MUST silently drop
that frame.  If a DATAGRAM frame is received and its Quarter Stream
ID maps to a stream that has not yet been created, the receiver SHALL
either drop that frame silently or buffer it temporarily while
awaiting the creation of the corresponding stream.
Endpoints MUST NOT send HTTP/3 datagrams unless the corresponding
stream's send side is open.  If an HTTP/3 datagram is received and
its Quarter Stream ID maps to a stream whose receive side has already
been closed, the receiver MUST silently drop that datagram.  If an
HTTP/3 datagram is received and its Quarter Stream ID maps to a
stream that has not yet been created, the receiver SHALL either drop
that datagram silently or buffer it temporarily while awaiting the
creation of the corresponding stream.
Datagrams sent using the DATAGRAM Capsule have the exact same
semantics as datagrams sent in QUIC DATAGRAM frames.
Datagrams sent using the DATAGRAM Capsule have the exact same
semantics as datagrams sent in QUIC DATAGRAM frames.  In particular,
the restrictions on when it is allowed to send an HTTP/3 datagram and
how to process them from format also apply to HTTP/3 datagrams sent
and received using the DATAGRAM capsule.