Subject: [Taps] Discussing WebRTC API mappings in TAPS

From: Tommy Pauly <[email-masked]>
Date: Mon, 05 Nov 2018 07:19:36 +0700

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

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 5 Nov 2018 10:56:04 -0800

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-masked]> 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.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Nov 2018 15:36:25 -0500

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-masked]> wrote:

> might be a good opportunity to find people..
>