- From: T H Panton <thp@westhawk.co.uk>
- Date: Wed, 21 Nov 2018 10:34:34 +0000
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: Roman Shpount <roman@telurix.com>, WebRTC WG <public-webrtc@w3.org>
> On 21 Nov 2018, at 08:15, Harald Alvestrand <harald@alvestrand.no> wrote: > > On 11/20/2018 09:09 PM, Roman Shpount wrote: >> Hi, >> >> I see what is being added, but I see no explanation in this document or announcement why it is being added. > > the presentation given by Peter at TPAC is at https://www.w3.org/2011/04/webrtc/wiki/images/a/a8/WebRTC_QUIC_status.pdf > > and Peter's presentation of it is in the video recording. > It may answer some of your questions. I'm mildly anti adoption of the document at this point, Peter's presentation reenforces that. My reasoning is that a) QUIC is in no way ready for this - we heard this from Martin and Ekr in Stockholm b) The presentation above seems to be driven by server use cases, if that's so then the API doesn't seem (to me) to belong in this group. "replacement for Server Push" "please no SCTP on my server" Indeed a lot of the potential users are anti anything with an RTC prefix, which says that i) this new API surface would be better off outside RTCweb ii) RTCweb has a problem that needs fixing c) A lot of the p2p ways that this could be used are implementable with the existing SCTP/DTLS Overall I feel this low-level QUIC transport API is the wrong place to start. We should be drafting API's that give desired access to streams and media - testing them out over SCTP, then moving to QUIC once it is ready. Cart before Horse IMHO T. I also volunteer to help the folks with weak SCTP implementations....
Received on Wednesday, 21 November 2018 10:34:58 UTC