- From: Martin Thomson <mt@lowentropy.net>
- Date: Wed, 20 Mar 2019 06:05:59 -0400
- To: ietf-http-wg@w3.org
Lots to think about here. Thanks for sharing. I have a few fairly basic questions about the goals of the draft. Why do you need to use both :protocol and a setting? Isn't SETTINGS_ENABLE_CONNECT_PROTOCOL plus the new values for :protocol enough? How does a :protocol of bytestream differ from a plan CONNECT? What is the point of a :protocol of datagram? Is the idea to use UDP? The string "UDP" appears nowhere in the draft, so I've concluded that that isn't the case, except that using UDP would be the only way in which this would be different (and therefore marginally useful, modulo the obvious head-of-line stuff). FWIW, the datagram thing might work, but DATA frames aren't really designed to work that way. In order to use a datagram tunnel effectively you would have to change the complete stack for DATA to avoid coalescing of frames, buffering, splitting and all those sorts of things that are natural for something with an underlying assumption of streaming semantics. It might be better to define a new frame type for this purpose. If the point is to enable UDP, then there are a few features I might want to request. For instance, the ability to setup a listener. The ability to know what the IP and port of that listener are. The ability to set rules about what remote addresses can send to that listener (other than a fixed, CONNECTed peer). That might get closer to being useful for something like WebRTC. I would want all of that for QUIC, for instance, where head-of-line is less of a concern. But that gets dangerously close to TURN, so we'd have to have the NIH discussion in light of that. Cheers, Martin
Received on Wednesday, 20 March 2019 10:06:22 UTC