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

Re: Clarifications: Call for adoption - WEBRTC-QUIC

From: youenn fablet <yfablet@apple.com>
Date: Thu, 29 Nov 2018 14:44:08 -0800
Cc: public-webrtc@w3.org
Message-id: <6D7C00BB-0824-4422-A50F-35D507FF9FEC@apple.com>
To: Harald Alvestrand <harald@alvestrand.no>
With the current document, I am against adoption.

I am for instance unclear whether the scope is RTC-only (seems to be implied by the current document) or includes client-server as well (seems to be where the document editors want to move IIUIC).

I agree with Roman about having a specific set of requirements. Here is a try at listing some that make sense to me:
- The API should serve both RTC and client-server use cases
- It should be possible to define a mapping of this API to different protocols (QUIC, SCTP, WebSocket)
- The API should take inspiration from the existing data channel API, its level of abstractness and current feature set (multiplex, unreliability…)
- The API should reuse existing web primitives where it makes sense. Using WhatWG streams should in particular be investigated.

While some requirements are not met yet by the current QUIC document, it seems ongoing work will address at least some of these.

The name of the current document (webrtc-quic) is also a potential problem if it tries to specify everything.
I wonder whether the spec work should not be split in more items that could advance at their own pace.
Here is a potential list (each item might not deserve its own spec):
- API definition
- QUIC API specialization
- API mapping to QUIC
- QUIC API for client-server
- SCTP API specialization
- API mapping to SCTP
I would think smaller and more focused documents to be easier to adopt by the WG.

Hope this helps,

> On Nov 29, 2018, at 4:35 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> When tallying the arguments and positions for or against adoption, I was
> unable to determine clearly the position of the following people who
> have participated in the thread:
> - Youenn Fablet
> - Cullen Jennings
> - Sergio Garcia Murillo
> - Lennart Grahl
> - Alexey Aylarov
> - Roman Shpout
> I could make guesses based on commentary, but that would be guesswork;
> it would be better if the people themselves were to say "Favors
> adoption", "Against adoption", or "Does not wish to be counted".
> I also note that in Lyon there were ~10 people supporting adoption; so
> far I've tallied 9 people supporting adoption on the list; if the
> remaining supporters wish to be part of the tally, they'd better speak
> up now. (I think both of the people not supporting adoption in Lyon have
> spoken up.)
> Harald
> Den 20.11.2018 09:57, skrev Harald Alvestrand:
>> **
>> *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/
>> 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 22:44:36 UTC

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