In terms of background, there are some things to understand about WebRTC-QUIC which may help provide context:
1. The current draft is focussed on peer-to-peer data exchange use cases, based on an RTCQuicTransport object (which models QUIC connections) and an RTCQuicStream object (which models QUIC streams). The RTCQuicTransport object takes after the RTCDtlsTransport object which was originally developed in the ORTC Community Group (see: http://draft.ortc.org) and later integrated in WebRTC (see: https://rawgit.com/w3c/webrtc-pc/master/webrtc.html), so it has been relatively stable. The RTCQuicStream object has undergone quite a few changes in order to evolve along with the IETF QUIC Transport draft (see: https://tools.ietf.org/html/draft-ietf-quic-transport ), and during the latest WEBRTC WG meetings, additional changes were discussed, in order to better align WebRTC-QUIC with the WHAT WG Streams API. On Mon, Nov 5, 2018 at 1:56 PM Peter Thatcher <pthatcher= [email protected]> wrote: > FYI, the rtcweb WG has not been involved in the discussion around the > WebRTC API for QUIC. It's only been discussed in the W3C. Naturally, some > people are in both groups, but as a group, this WG has not discussed QUIC > before (as far as I know). It might make more sense to reach out to the > W3C WebRTC WG. However, if you want to talk to people in person IETF 103 > might be a good opportunity to find people.. > > And since we're discussing TAPS and RTCWEB here, there is an area that the > experience of the RTCWEB WG can probably help the TAPS WG: the use of ICE. > I recently read through the TAPS documents and it seems that TAPS is > attempting to make an API that includes the use of ICE (it's basically a > superset of ICE, much like the combination the WebRTC protocols). In the > context of the web, that can lead to some tricky issues. > > If you wish to extend TAPS to the web, one issue you will run into is the > same that RTCWEB did around the IP privacy handling of ICE (and the > subsequent use of mDNS). Another is consent freshness. There may be > others that I can't recall. But you'll probably want to learn how the > RTCWEB WG solved these problems (for some definition of solved :) rather > than retreading them. > > > On Sun, Nov 4, 2018 at 4:20 PM Tommy Pauly <[email protected]> wrote: > >> Hello rtcweb, >> >> Based on recent proposals for WebRTC APIs to run over QUIC, the Transport >> Services (TAPS) working group will be spending some time this week looking >> at the usefulness and applicability of our flexible transport APIs for use >> in WebRTC. One of the main goals is providing an API surface that will work >> well across protocols and require minimal application effort to adopt, as >> well as being able to dynamically use newer protocols. We'd like to get >> input and feedback on how well such a model can serve the WebRTC use case. >> >> Please join us in our discussion if you're interested! >> >> Wednesday, November 7 >> 1540-1710 Afternoon Session II >> Transport Services WG >> Room: Meeting 2 >> >> Thanks, >> Tommy >> >> _______________________________________________ >> rtcweb mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtcweb >> > _______________________________________________ > rtcweb mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtcweb >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
