Re: Call for adoption - WEBRTC-QUIC

On Mon, Nov 26, 2018 at 12:03 PM youenn fablet <yfablet@apple.com> wrote:

> 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.
>

What do you mean by "consolidation"?


> I also think the current document needs some more work.
>

Isn't the point of adopting a document to work on it?


>
> 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.
>

We already have a PR that removes the prefix:

https://github.com/w3c/webrtc-quic/pull/73

Hopefully we'll get it landed soon.

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.
>

The names of types don't matter to JS.  It's only the methods that matter,
and none of the methods have QUIC in the name.


>
> I would prefer organizing the work as follows:
> 1. Define a modern API
> Data channels could be a source of inspiration.
>

That's what we've done.  The API doesn't really have anything to do with
QUIC.  It could work with any protocol that has a multiplicity of
streams/messages.


> WhatWG streams could be a basis for this API.
>

The next PR we plan to write is one to use WHATWG streams.


> 2. Define QUIC extensions on top of the modern API
> Constructors,
>

We've already got that.


> additional Quic specific properties...
>

There aren't really any outside of the constructor and maybe the stream
IDs.


> 3. Define a QUIC protocol mapping
> This mapping could be defined on top of an early QUIC extension proposal
> discussed during last IETF meeting.
>

What we have so far is a "mapping" so trivial that there really isn't one,
and I think that's for the best.


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

There isn't stopping anyone from making an SCTP version of the API we have
right now.  In fact, I proposed something just like that TPAC.

But I will admit that I don't think it's worth the effort.  No one is
asking for a better SCTP API.



>
>
>
> * 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 *
>
>