Here is a thread <https://www.ietf.org/mail-archive/web/rtcweb/current/msg00197.html> (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 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 16:17:27 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC