> On 29. Nov 2018, at 17:16, Justin Uberti <juberti@google.com> wrote: > > Here is a thread (from 2011) that discusses this topic. Of particular interest may be the goals enumerated in said thread, which sound like requirements for a generic data transport: > > - Unreliable data transmission > - Datagram oriented > * Size limited by MTU > - Path MTU discovery needed > * Fragmentation by the application > - Low latency, i.e. Peer to Peer preferable > - Congestion Controlled, to be > * Network friendly > * Not become a Denial of Service tool > - Security > * Confidentiality > * Integrity Protected > * Source Authenticated (at least bound to the signalling peer) > * Ensure consent to receive data Am I missing something or aren't the above requirements fulfilled by the SCTP-based data channels? Best regards Michael > > > On Thu, Nov 29, 2018 at 4:59 AM westhawk <thp@westhawk.co.uk> wrote: > > >> On 29 Nov 2018, at 13:23, Zhu, Jianjun <jianjun.zhu@intel.com> wrote: >> >> On 2018/11/29, 12:25 PM, "Ted Hardie" <ted.ietf@gmail.com> wrote: >> >> That leaves me puzzled as to why this is the best WG to develop an API for it. As a data transport for HTTP/3, it seems like this would be of broader interest within the W3C. >> >> >> Transferring data between peers is in WebRTC WG’s scope. I’m curious about was there any debate on adopting data channel. >> >> > As I recall, there was some debate. Our experience at that point was that adding data in a side channel was a good way to augment a call and that DTMF didn’t do it, nor would server routed websockets. > The data channel discussion was framed around area I think. > > Standalone data channel (with no associated call) came later and was a surprising success (at least to me). > > T. > > > >> >> Best Regards, >> Jianjun >Received on Thursday, 29 November 2018 20:13:23 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC