Re: Call for adoption - WEBRTC-QUIC

> On Nov 26, 2018, at 12:32 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> Cullen said: 
> 
> "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 and it is a bit premature to adopt before we have that."
> 
> [BA] The existing QUIC transport supports the "one message per stream" model for partial reliability:
> https://github.com/quicwg/ops-drafts/issues/15 <https://github.com/quicwg/ops-drafts/issues/15>
> 
> The WebRTC-quic API has added support for unreliable transport (e.g. see: https://w3c.github.io/webrtc-quic/#dom-rtcquicstreamparameters <https://w3c.github.io/webrtc-quic/#dom-rtcquicstreamparameters> ) based on this. To enable RTCDataChannel partial reliability to be fully supported, attributes such as maxRetransmits or maxPacketLifetime could be added to RTCQuicStreamParameters along with corresponding support in the underlying QUIC implementation. 
> 

But my impression was the QUIC WG did not view that as the right way do this. 


> The DATAGRAM proposal (see: https://tools.ietf.org/html/draft-pauly-quic-datagram <https://tools.ietf.org/html/draft-pauly-quic-datagram> ) can also be supported with a relatively minor change: 
> https://github.com/w3c/webrtc-quic/issues/77 <https://github.com/w3c/webrtc-quic/issues/77>
> 
> Cullen also said: 
> 
> "I also strongly feel that if there is a difference from server or P2P, we are doing it wrong - whatever we adopt should apply to both."
> 
> [BA] There are only minor differences, which relate to the constructor (which takes a URL for client-server rather than the RTCIceTransport used in P2P), the authentication model (client-server supports certificate validation rather than the self-signed certificates in P2P) and CORS (required for client-server). There are similar differences between the WebSockets API and the RTCDataChannel API. 


OK, but if they are minor, I think both version need to be defined in the same spec at same time and not leave one till the mythical "later". 

> 
> An early draft of the client-server API can be seen here:
> https://rawgit.com/w3c/webrtc-quic/client-server2/index.html <https://rawgit.com/w3c/webrtc-quic/client-server2/index.html>
> 
> From: Cullen Jennings <fluffy@iii.ca <mailto:fluffy@iii.ca>>
> Sent: Monday, November 26, 2018 10:57 AM
> To: Harald Alvestrand
> Cc: public-webrtc@w3.org <mailto:public-webrtc@w3.org>
> Subject: Re: Call for adoption - WEBRTC-QUIC
>  
> 
> 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 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 - whatever we adopt should apply to both. I think the solution should work for the media as well as the data channel over QUIC. 
> 
> 
> 
>> On Nov 20, 2018, at 1:57 AM, Harald Alvestrand <harald@alvestrand.no <mailto: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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwebrtc-quic%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C45c39b89705841d2ee9208d653d1508f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636788555795098300&sdata=%2FUiuJegt%2F2iNqPB%2FZz09G39Z2193YCnD99LMeiB9JkQ%3D&reserved=0>
>> 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