Hi taps folks (also cc’ing the WebTransport list), I assume that people on the taps list are aware of the WebTransport effort that will have a BoF meeting on 13:30-15:00 Wednesday. I had another look at the WebTransport documents today in order to better understand the scope of WebTransport compared to taps.
Looking at https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 I believe that this should be covered by pooled connections in taps + use of partial messages. WebTransport proposes to use streams as the base concept while we in taps explicitly decided against this but to use messages instead which also aligns with other protocols that are discussed in WebTransports like Websockets and WebRTC data channels. Unfortunately the draft doesn’t give any reasoning for that choice but I would still think that use of particle messages in taps should be equivalent at it is explicitly designed to address applications that actually need streaming. What do people think? Further looking at https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 this draft defines a new ALPN value and a QUIC extension. I guess in taps we have not explicitly considered ALPN so far but we really would need to do that in any case! I guess one could see this as a protocol specific property but maybe it’s even worth to be more explicit here. Did anybody consider ALPN already? Regarding the new QUIC transport parameter I have to say that the purpose it not fully clear to me from the draft. However it seems that this is supposed to support some kind of access control that is performed on the application layer but by a more trusted entity than the client application itself. It is not fully clear to me what the trust assumptions are, however it does seems that is should not be a transport parameter that is protocol specific but rather some function on the higher layer. However, to be able to make a proposal here, I would probably need to understand the purpose better. Do people have any insights? Do people have thoughts? What is missing in taps to also cover the full web use case? Is that something we want to account for in taps? Or what is the difference that would not fit with the taps approach? What am I missing? Mirja _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
