Re: Call for adoption - WEBRTC-QUIC

> On Nov 20, 2018, at 12:57 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
>  From the Lyon summary of decisions:
> "The WG will ask the list if we should adopt the WEBRTC-QUIC API document (in room: 2 opposed, ~10 in favor)"
> The question is whether we should adopt this document:
> 
>   https://w3c.github.io/webrtc-quic/ <https://w3c.github.io/webrtc-quic/>
> 
> as a Working Group document
> 
> Adoption as a WG document does not mean commitment to any specific part of the API, or any specific timeline for processing the document to CR and beyond, but does mean that we can issue the document as a first public working draft (FPWD) and ask for IPR declarations (if any).
> 
> My personal read is that adoption as a WG document means that "we have consensus that there is a problem here that needs solving, the problem is within the scope of this WG, and this document is a start on the way to solving it".
> Non-adoption would indicate either that the problem shouldn't be solved, that the problem is out of scope for this WG, or that this document is so far away from the right solution that it's not a starting point the WG wants to consider.

I agree there is a use case and a problem to be solved.
I also agree the problem is within the scope of this WG.

I think that the scope of the work/definition of the problem needs some consolidation.
I also think the current document needs some more work.

Taking an example, the current document introduces a RTCQuicStream.
The name ties it to RTC which is too restrictive as one of the driving use case is a better client-server messaging API.
The name also ties it to QUIC (what if we end up with a FSTR protocol) and to QUIC streams which might or might not map to what will be used in practice at the QUIC protocol layer.
In contrast, the current data channel API does not explicitly surface SCTP concepts.

I would prefer organizing the work as follows:
1. Define a modern API
Data channels could be a source of inspiration.
WhatWG streams could be a basis for this API.
2. Define QUIC extensions on top of the modern API
Constructors, additional Quic specific properties...
3. Define a QUIC protocol mapping
This mapping could be defined on top of an early QUIC extension proposal discussed during last IETF meeting.

As a bonus, nothing will prevent interested parties to define extensions of this modern API for other protocols like WebRTC SCTP.


> 
> We are seeking both statements of support and statements of opposition. The chairs will tally the responses and attempt to draw a conclusion.
> 
> Please state your opinion to the list on or before Wednesday, November 28.
> 
> Harald, for the chairs
> 
> 
>