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

Re: Call for adoption - WEBRTC-QUIC

From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 28 Nov 2018 20:10:33 -0700
Message-ID: <CAJrXDUGbo=BF4wDiALC-3NovTp5DZw3e-ZLbsqJYa-z7XmT-Qw@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Mon, Nov 26, 2018 at 11:59 AM Cullen Jennings <fluffy@iii.ca> wrote:

> I think the issue of how QUIC deal with non reliable data needs to be
> dealt with before we can use this for the data channel

The API already (at https://github.com/w3c/webrtc-quic) already has support
for unreliability.  It's a simple mechanism: just don't send

> and it is a bit premature to adopt before we have that. I also strongly
> feel that if there is a difference from server or P2P, we are doing it
> wrong -

There isn't, except in the constructor (one takes ICE, one takes a URL).
So I guess we're doing something right.

> whatever we adopt should apply to both. I think the solution should work
> for the media as well as the data channel over QUIC.

The API is just a transport.  It can send both data and media.  But getting
access to encoded media via encoders built into the browser will require
some new APIs (RtpSender doesn't provide it today).

I think we have everything we are asking for except for encoded media
access, which is what I've been asking for.

> On Nov 20, 2018, at 1: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. 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 *
Received on Thursday, 29 November 2018 03:11:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC