W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2018

Re: Towards a new charter for the WebRTC Working Group

From: T H Panton <thp@westhawk.co.uk>
Date: Tue, 2 Jan 2018 11:42:27 +0000
Cc: Martin Thomson <martin.thomson@gmail.com>, Dominique Hazael-Massieux <dom@w3.org>, Bernard Aboba <Bernard.Aboba@microsoft.com>
Message-Id: <FAA7845A-1058-4731-B76F-99FE0A09A0CE@westhawk.co.uk>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>


> On 2 Jan 2018, at 05:26, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> Martin said: 
> 
> "What are the plans for the protocol pieces for the new items?  I
> haven't seen any plans - or internet-drafts - for those, and the bulk
> of the work for some of these items is protocol work.  For instance, I
> can understand why the group might choose not to rely on SDP for
> negotiating new features, which leads to some API work, but the bulk
> of the QUIC datachannels work is in defining protocols, not the API."
> 
> [BA] The QUIC API presented at TPAC depends only on currently chartered work in the IETF QUIC WG (e.g. the QUIC transport document) as well as resolution of the QUIC multiplexing problem (by whatever approach the IETF decides on). 
> 
> As the QUIC transport document evolves, the QUIC API will presumably evolve as well (e.g. the proposed API currently provides a bi-directional stream abstraction). 
> 
> As Peter noted, it should be possible to implement the RTCDataChannel API on top of the proposed QUIC API once the IETF defines the protocol for QUIC datachannels.
> 

I don't think I've seen the requirements/use-case doc for QUIC - or indeed any discussion about why only QUIC will do whatever the need is. 
If we are picking a new protocol we should be _super_ clear why.
The current multilayer protocol soup at least has the advantages that each ingredient is reasonably well known and
well specified. Most of them have multiple tested public implementations.

This is useful in 2 ways:
1) it makes the spec possible to implement in a reasonable timeframe.
2) it makes it relatively easy to handwave about the security properties of the stack.
e.g: "You were going to use x over DTLS - this is just the same, but has ICE support and works in a browser"

Given that we haven't implemented 1.0 anywhere yet, I'm a bit negative about 2.0 including a load of new untested stuff
without really good reasons.

T.
Received on Tuesday, 2 January 2018 11:42:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 2 January 2018 11:42:52 UTC