HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Mark Nottingham <mnot@mnot.net> Mon, 22 June 2020 23:44 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 75E9E3A127D
for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 22 Jun 2020 16:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Level:
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001]
autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=mnot.net header.b=WuTqVMHw; dkim=pass (2048-bit key)
header.d=messagingengine.com header.b=S+TCt4fJ
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 do8aSPLxoUOY
for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>;
Mon, 22 Jun 2020 16:44:31 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18])
(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 AB3943A127E
for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 22 Jun 2020 16:44:31 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92)
(envelope-from <ietf-http-wg-request@listhub.w3.org>)
id 1jnW3l-0000F5-Dr
for ietf-http-wg-dist@listhub.w3.org; Mon, 22 Jun 2020 23:41:05 +0000
Resent-Date: Mon, 22 Jun 2020 23:41:05 +0000
Resent-Message-Id: <E1jnW3l-0000F5-Dr@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79])
by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <mnot@mnot.net>)
id 1jnW3i-0000DP-3x
for ietf-http-wg@listhub.w3.org; Mon, 22 Jun 2020 23:41:02 +0000
Received: from out4-smtp.messagingengine.com ([66.111.4.28])
by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <mnot@mnot.net>)
id 1jnW3g-0003wT-AN
for ietf-http-wg@w3.org; Mon, 22 Jun 2020 23:41:01 +0000
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.nyi.internal (Postfix) with ESMTP id B54D35C0BEC;
Mon, 22 Jun 2020 19:40:45 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute4.internal (MEProxy); Mon, 22 Jun 2020 19:40:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from
:content-type:content-transfer-encoding:mime-version:subject
:message-id:date:cc:to; s=fm3; bh=7cMHYGUZnpkNcRp3m3gSRrLn40AWR7
S+phRwBUMXtz4=; b=WuTqVMHwEHGR6ayeu3pXDcVNFLW20P2X1EaDUyvOBeceZU
7DAt8dNIfF89B91KR38pQc/89rpNAZMWwOYdLZ/M917R9sV2X9gmVPwDw8mUoZ/i
GHQVwVR8bKzyaeRuaWMnoHUqNNIeNVXrX6aNI/eH/vh8Qq5E+iGDHNmsfkee8TLh
3cEOSEF2fA6eH//Kpfm/2gfOXAIdg+pz/AA1C+IX60ywqOiI3g/ektjEvf0j99u5
GbpQIdVXQ79Y0IdpEA1ZsweqamVxlcpu6K+moABxlBAQ2SfN5lOFndYd6fScRcjK
wuAjklhvVvkdc7ASkb+jJtuJTqFTw1i/wEBvvWyA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:message-id:mime-version:subject:to:x-me-proxy
:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=7cMHYG
UZnpkNcRp3m3gSRrLn40AWR7S+phRwBUMXtz4=; b=S+TCt4fJTbGWo73AWsWssO
qS/H+AwUO7nwbX30d9Hs59YVUYhvjqN2aozGL5eKxSt67hB1hisrEq370GbZoEnU
glko4kn9ItjCPOSxhVxg8HOkJA07mAFaJV94l2nwiyQ31QGypYIWhCZfyW8o+UQh
kR9nu9zuIHfpg/xUJoz1kcq2YK5AWfxsTI3hS8fSQXKM3554E2TFFORc/v/vjfAu
Tz2D1XIkSWT7bhhaK1q8Q9mYeC9mjsR5rQu6KVj8vsmqTFIhE9bRimv7eoqsQuaz
1wRVyTvZVjGL3BFdfKStopkKbKcr7hn+Co9UEvep8tXgQeAvLlABIKKPHdwzOtRg
==
X-ME-Sender: <xms:fEHxXhmmH_3jHEQVmEzt9TvKjAIQzsIfjJd_ARa4VEP790VPVc5Seg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekfedgvdegucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd
hhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhho
thdrnhgvtheqnecuggftrfgrthhtvghrnhepkeekkefgveevleeugeeujeeitdeukeegie
efgeelledttdffjeekudffvddtfeeknecuffhomhgrihhnpehhthhtphhsvghmrghnthhi
tghsrdhsohdphhhtthhpshgvmhgrnhhtihgtshgsuhhnughlvgguihhnrdguohdpihgvth
hfrdhorhhgpdhgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrddu
jedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih
hlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:fEHxXs1KtkqrGYL4BTgHBGOozJeXl0nPvZ6WuDFPeMFSwDxJ5wkoeA>
<xmx:fEHxXnpfLkmk2RV_ET0JtezO8v4kTseoRTUKlrQaDFUk5TaJ0wRR7w>
<xmx:fEHxXhmv4eepToxbA6147E3xIJZHOSfGQf8Yk-123n7LaIc_Kx30kA>
<xmx:fUHxXo8kzAAJgEaBroHaqzDTmnS2Xoa8INgV9p_DQ3jLeSbjzl42Vw>
Received: from macbook-air.mnot.net (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251])
by mail.messagingengine.com (Postfix) with ESMTPA id C7F0B3280059;
Mon, 22 Jun 2020 19:40:43 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Message-Id: <54E08031-1892-4CC0-A6CF-0CAA4BFF679B@mnot.net>
Date: Tue, 23 Jun 2020 09:40:40 +1000
Cc: David Schinazi <dschinazi.ietf@gmail.com>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Received-SPF: pass client-ip=66.111.4.28; envelope-from=mnot@mnot.net; helo=out4-smtp.messagingengine.com
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1jnW3g-0003wT-AN ded0f8b09374d3d357072e70e32d6935
X-Original-To: ietf-http-wg@w3.org
Subject: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <https://www.w3.org/mid/54E08031-1892-4CC0-A6CF-0CAA4BFF679B@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37809
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi all, The new MASQUE[1] and WEBTRANS[2] working groups both wish to define new protocols using QUIC DATAGRAM frames[3] that are not conveying (existing) HTTP semantics, but are intended to be usable over (at least some versions of) a HTTP connection. MASQUE's purpose is to proxy UDP and potentially IP (like a VPN) over a HTTP/3 connection. For WEBTRANS, the purpose is to create a browser-exposed, WebSocket-like protocol that allows unreliable delivery (which may also use CONNECT-UDP). These summaries are just my understanding; for a more complete picture, see the respective charters and related WG discussion. It's not yet clear how or even if these protocols will map into HTTP semantics. Some have proposed something like a CONNECT-UDP method; others seem to favour negotiating a new protocol using SETTINGS or a similar version-specific mechanism directly, avoiding the definition of any generic HTTP semantics. So far, the most concrete proposal we have is draft-schinazi-quic-h3-datagram,[4] which defines how QUIC DATAGRAM frames are surfaced in HTTP/3 without any mapping them into generic HTTP semantics (like a method, status code, header, etc.). Thus, a specification using them has the choice of defining a generic HTTP extension (like CONNECT-UDP, mapping them into HTTP semantics) or a version-specific extension(like SETTINGS, bypassing generic semantics). Before these groups get too far down the road, we have an opportunity to give them some guidance about how to extend both HTTP's semantics overall, and specific versions of HTTP -- keeping in mind recent core discussions.[5] The most relevant question is whether new, non-HTTP protocols on a HTTP connection should be bootstrapped by generic HTTP semantics (e.g., a method), version-specific semantics (e.g., SETTINGS), or something else. There's also a question as to whether something like draft-schinazi-h3-datagram is the right approach, or whether it should also include generic HTTP semantics "bundled in." Do folks have any thoughts about this? Cheers, 1. <https://datatracker.ietf.org/wg/masque/about/>. 2. <https://datatracker.ietf.org/wg/webtrans/about/>. 3. 'An Unreliable Datagram Extension to QUIC', <https://tools.ietf.org/html/draft-ietf-quic-datagram>. 4. <https://tools.ietf.org/html/draft-schinazi-quic-h3-datagram>. 5. <https://github.com/httpwg/http-core/issues/44>. -- Mark Nottingham https://www.mnot.net/
- HTTP extensions, semantics and HTTP datagrams / M… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Ben Schwartz
- Re: HTTP extensions, semantics and HTTP datagrams… David Schinazi
- Re: HTTP extensions, semantics and HTTP datagrams… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Mark Nottingham
- Re: HTTP extensions, semantics and HTTP datagrams… Ben Schwartz
- Re: HTTP extensions, semantics and HTTP datagrams… Eric Kinnear
- Re: HTTP extensions, semantics and HTTP datagrams… Lucas Pardue