IETF Logo Mail Archive

Re: [dispatch] Dispatching WebTransport

westhawk <thp@westhawk.co.uk> Tue, 02 July 2019 09:46 UTC

Return-Path: <thp@westhawk.co.uk>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7068412004E for <dispatch@ietfa.amsl.com>; Tue, 2 Jul 2019 02:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uTKbXfew-LM for <dispatch@ietfa.amsl.com>; Tue, 2 Jul 2019 02:46:17 -0700 (PDT)
Received: from smtp001-out2.apm-internet.net (smtp001-out2.apm-internet.net [85.119.248.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF4012004C for <dispatch@ietf.org>; Tue, 2 Jul 2019 02:46:16 -0700 (PDT)
Received: (qmail 66332 invoked from network); 2 Jul 2019 09:46:14 -0000
X-APM-Out-ID: 15620607746630
X-APM-Authkey: 255286/0(159927/0) 443
Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 2 Jul 2019 09:46:14 -0000
Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 00DB918A06D1; Tue, 2 Jul 2019 10:46:13 +0100 (BST)
Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8Df0tftKnbyC; Tue, 2 Jul 2019 10:46:13 +0100 (BST)
Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id C6A0918A05FD; Tue, 2 Jul 2019 10:46:13 +0100 (BST)
From: westhawk <thp@westhawk.co.uk>
Message-Id: <447CFF6A-37FB-422F-B65D-4BB76F2E5CB0@westhawk.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2F147E74-942D-4835-8111-E17AC09DAC91"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 02 Jul 2019 10:46:13 +0100
In-Reply-To: <CAJrXDUGubsbRV7_FinKr_r1m+MkBBXSVw=O-3oH31+UOJGjNtw@mail.gmail.com>
Cc: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>, dispatch@ietf.org
To: Peter Thatcher <pthatcher@google.com>
References: <CAAZdMadKgUkAwnYQ7MmSR46qQZTh8+FF5BuKmc1r33SMyF91sQ@mail.gmail.com> <98EF12E4-4BF2-4FBC-852B-776A0E0118BE@westhawk.co.uk> <CAJrXDUGubsbRV7_FinKr_r1m+MkBBXSVw=O-3oH31+UOJGjNtw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/88Q7Dqij9Fp3ST5qrukjIrQG1-E>
Subject: Re: [dispatch] Dispatching WebTransport
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jul 2019 09:46:19 -0000


> On 2 Jul 2019, at 01:10, Peter Thatcher <pthatcher@google.com> wrote:
> 
> Maybe not for you, but we regularly get emails from people saying things like "It would be great to delete the mess of the WebRTC stack if there's a simpler protocol available. ICE/DTLS/SCTP all scare me”.

To be clear, I utterly sympathise with this viewpoint - no one in their right minds wants to pull libwebrtc into their server codebase.

I took one look at it and decided to write a fresh implementation that better suited my needs.
The fact that I could do that is due to the existence of RFCs for all of the  webRTC stack layers.

When implementing the datachannel I did ask a few questions of the experts, their replies were pointers
to the relevant bits of the RFCs. QUIC-RT simply isn’t in that position yet.

T.

v2.23.0 | Report a Bug | By Email