Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS

Mark Nottingham <mnot@mnot.net> Tue, 23 June 2020 08:49 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 AC3983A17F1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jun 2020 01:49:09 -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=VgNESPao; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t4OheakS
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 EaBtw1LW-L1T for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jun 2020 01:49:07 -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 7EEED3A17EE for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Jun 2020 01:49:07 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jneZD-0003Z8-R7 for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Jun 2020 08:46:08 +0000
Resent-Date: Tue, 23 Jun 2020 08:46:07 +0000
Resent-Message-Id: <E1jneZD-0003Z8-R7@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jneZB-0003XZ-Us for ietf-http-wg@listhub.w3.org; Tue, 23 Jun 2020 08:46:05 +0000
Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mnot@mnot.net>) id 1jneZ7-0008ED-1r for ietf-http-wg@w3.org; Tue, 23 Jun 2020 08:46:05 +0000
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 58DED5C039E; Tue, 23 Jun 2020 04:45:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 23 Jun 2020 04:45:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=J TmHzkFfiBrUBL7nwnYC7gfpVPiPz2PlQ1gOs7f/+lM=; b=VgNESPaopeb19UBN0 fp0UhBujc9qfSL6ZQ8fiW3OVF/b9GWAObTrjaLmaBOIj1vWhcBbxjaanLZNKGGBI PrvOT8MD9yvy5sYZJ9eW/gVWctJ05QMJeQinPq5ygI1UAbu7Qnm/Z22oC2MJvq9a eddYvuXmmMZg3C8hAMuRCEiVsCtrXdIMTnkxL5iLh3gNw+DzxHxnr7Wnw0ngs4VR /9RAVQKW+3Tnk8NQEYTfNEyHZSvrRVCeZ/UZKdLRkE+Z3hML6QvMnpWkuAoGAIti RGV+S6PvBxhzwd03S80eJC8NGBF8uBgme6DNkeJOlW9H2Bc34NfP2V5P3EYkMP7B cgkVA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=JTmHzkFfiBrUBL7nwnYC7gfpVPiPz2PlQ1gOs7f/+ lM=; b=t4OheakSnmaxBdTxoWMAyuJ8ewbveITLbUqWGBlSfziHDZNZ7U2yP+a4i 7cAx8eCU+ghb0KCbjFCTQ4kyU1ajiHV3fTiQiSWYoG51RufL5Dh1Fq2c+gfY3JCn KF7se0ynzTsjD2ppbKBhbal1DPP14sV1xwCUPX+mlFtPeKxGNqFJ6RqLCRTDWgKG QPgCHb47znmLY6ZY0E7lz/8YXtpGXHxuQLTO421ywvCZXmAxLCiQ3S+uryW9Eep6 u0qDsUK2FGxSoyLMBY1qDTnxCUcDDIGBTFDpLQC/Kjx9TuGPzA+ii8Sz2hkggVfn WoHHCDyndoL+qpnLzKSTEGQp9VILQ==
X-ME-Sender: <xms:OsHxXnp-6yNl8zy1hl6u7Xpo8YGq58TIIBXaEkz9WJpkxvqeH3XM3w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekgedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepgffgffetvdeffedtvdduveeluddtie etveekveekudeuiefggfehgeefjeevkeegnecuffhomhgrihhnpehsvghrvhgvrhhpuhhs hhhishhprhhosggrsghlhihthhgvphhoshhtvghrtghhihhlughhvghrvgdrrghspdhhth htphhinhhtvghrrggtthhiohhnthhhrghtshhhrghpphgvnhhinhhgohhnthhhvggtohhn nhgvtghtihhonhdrihhmpdhhthhtphhsvghmrghnthhitghsrdhsohdphhhtthhpshgvmh grnhhtihgtshgsuhhnughlvgguihhnrdguohdpihgvthhfrdhorhhgpdhgihhthhhusgdr tghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvght
X-ME-Proxy: <xmx:OsHxXhqSVIv3NGZmbmOg-wvXUnZFM1fUUZWZe_IaoAYnmKO4g51sUw> <xmx:OsHxXkPpnYHbGyEP6LAKUnF_YUdFJ-SsJ6BhOpBzk9GT-OuuIyAFiw> <xmx:OsHxXq7vdXhnNN577Q-G4xMkmDt3B8Ox6D25A-0CynHIR2oPtg-Viw> <xmx:O8HxXsQCjpgcaIJzGRUCEI6e93ja9nlgihJVCRlmeUVW9SDVsUeowg>
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 60CDF30674AD; Tue, 23 Jun 2020 04:45:45 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <54E08031-1892-4CC0-A6CF-0CAA4BFF679B@mnot.net>
Date: Tue, 23 Jun 2020 18:45:41 +1000
Cc: David Schinazi <dschinazi.ietf@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <02858E1D-C010-4404-ADF3-5EB97D4B32B3@mnot.net>
References: <54E08031-1892-4CC0-A6CF-0CAA4BFF679B@mnot.net>
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.25; envelope-from=mnot@mnot.net; helo=out1-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: titan.w3.org 1jneZ7-0008ED-1r f11961a5014d179cf3586129582dedf7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <https://www.w3.org/mid/02858E1D-C010-4404-ADF3-5EB97D4B32B3@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37813
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>

My personal .02 on this (and I'd be very curious to hear others' reactions) --

We don't have a good track record of creating extensions or new capabilities that don't map into HTTP semantics. Server Push is probably the poster child here. As such, creating a version-specific extension for DATAGRAMs without mapping them into a method (or whatever) seems like it's leaving an attractive nuisance around; how will it show up in APIs? How will it interact with intermediaries? Etc.

We also don't have a lot of precedent for a HTTP version-specific extension that does something completely separate to the HTTP interaction that's happening on the connection. I'm not sure that it would be something we want to encourage.

All that said, we're not the protocol police; I don't think we should _stop_ this, but I do think that if we want this to succeed, it might work better as something packaged together with CONNECT-UDP (or however it gets expressed in HTTP).

AIUI the one big argument for factoring it out into a separate draft is that MASQUE might want to use it *without* a method (etc.) for IP proxying. So that might be a conversation to have (although that use case has been delayed, I think).

Another potential consumer could be a header on CONNECT (or even other methods?) that allows unreliable delivery but degrades gracefully to reliable delivery on hops that don't provide it. Even then, it seems like such a spec could reference the wire formats, etc., in CONNECT-UDP once that's defined.

Overall - I have a preference for this to be rolled into a CONNECT-UDP (or similar) spec, but can live with it as a separate doc, provided that some thought is put into warning potential users about some risks.

What do other folks think?


> On 23 Jun 2020, at 9:40 am, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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/
> 
> 

--
Mark Nottingham   https://www.mnot.net/