> On Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind <[email protected]> wrote: > > 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?
I think the notion of stream here is just a multiplexing concept; the terminology doesn't follow the terminology in TAPS, but it's not at odds. It's just a different phrasing. > > 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? ALPN is a TLS option, so it fits into the protocol-specific options. We certainly have support for that in our implementation! (https://developer.apple.com/documentation/security/2976269-sec_protocol_options_add_tls_app?language=objc) > > 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? From the TAPS side, transport parameters in QUIC do need to be able to be configured by the app or set as a default for a given use case, so that shouldn't be an issue. > > 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? Fundamentally, TAPS is about API shape and approach. It alone doesn't define any new protocol knobs. If WebTransport needs new on-the-wire protocol changes, those need to be independent. However, the shape of creating connections, and sending and receiving messages, is something that can certainly conform to a TAPS-compliant interface. If you read through draft-vvv-webtransport-overview, it largely outlines something that is a TAPS interface, just without referencing TAPS or calling that out. So, one way to view the relationship is that WebTransport as described is a specific set of protocol features that a web-focused implementation of a TAPS system ought to build, plus a few protocol tweaks below. Thanks, Tommy > > Mirja > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
