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