Ok, thanks for this.I would further suggest that an example flow be included; even if it is just two or three datagrams. Showing it all in operation is always helpful.
Eliot On 17.09.21 02:05, Tommy Pauly wrote:
Agreed that the word “strongly” can simply be removed.Applications using QUIC can choose to associate particular datagrams with data sent on a stream—like HTTP/3 choosing to add a value calculated based on stream IDs into the payload of the DATAGRAM frame—but such associations do not belong to the transport protocol.https://github.com/quicwg/datagram/issues/52 <https://github.com/quicwg/datagram/issues/52>Thanks, TommyOn Sep 16, 2021, at 4:48 PM, Martin Thomson <[email protected] <mailto:[email protected]>> wrote:On Fri, Sep 17, 2021, at 07:00, Eliot Lear wrote:DATAGRAM frames belong to a QUIC connection as a whole, and are not strongly associated with any stream ID at the QUIC layerWhat does "strongly associated" mean in this context? Apologies if this is well trodden ground.This is unfortunately so well-trodden that this text was added without consideration for people who weren't involved in the trampling process.I think that "strongly" can be struck here, it's working too hard. And smart people will latch onto it.Context:When we use DATAGRAMs in HTTP (and likely in other contexts) there will be a need to bind each DATAGRAM to a (request) stream. That's necessary to ensure that flows of DATAGRAMs can be routed by gateways and the like along with the stream. There were lots of debates about how to manage that binding and the layer at which it would be documented. This text is likely intended to record the conclusion that this document definitely isn't where that sort of binding occurs, but for someone without that history. It doesn't really achieve that though and because it doesn't need to (why would you think that any association exists?), it ends up being distracting.
OpenPGP_signature
Description: OpenPGP digital signature
