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

Mark Nottingham <> Wed, 24 June 2020 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 09C713A0C4C for <>; Wed, 24 Jun 2020 16:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.748
X-Spam-Status: No, score=-2.748 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_DNSWL_BLOCKED=0.001, 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: (amavisd-new); dkim=pass (2048-bit key) header.b=GT4OlsHa; dkim=pass (2048-bit key) header.b=GXJwd0Hv
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 640sY6C1bnFJ for <>; Wed, 24 Jun 2020 16:56:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1864A3A0C2E for <>; Wed, 24 Jun 2020 16:56:02 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1joFCp-0006BX-TX for; Wed, 24 Jun 2020 23:53:28 +0000
Resent-Date: Wed, 24 Jun 2020 23:53:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1joFCk-0006Am-RA for; Wed, 24 Jun 2020 23:53:22 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1joFCi-0007UC-LV for; Wed, 24 Jun 2020 23:53:22 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id F3C145C00CE; Wed, 24 Jun 2020 19:53:06 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Wed, 24 Jun 2020 19:53:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=Q QNOQZs+QUiK8LmsBI/u9brtryCYri1+dQw18vxt9Wo=; b=GT4OlsHalputE9OZW ygCMrlzdXnRGLge3Gh6O7Bu2q7g433CcoFJXY8hAvXAJhKBk/4dtn66w3I7fc/CS zxcjrW2PObMC0njBdkbc3TM9o79YrOT1VI+XhYoLMoeHpnM+a5VgpmPGDiLqmj1B BYUnV8X157yvqUANq+Dyu4fpXSJWET4cfzidnS6WSQw8leeL4kwJ6XLcGJNK8h8O W64gLJNo3oooEBRbY9vOdX6SFxfof0ZV5qy9pBktwX2nUKruS9sfN9BjSnlTEtHL RAVKFbkzA5zWPR97HMPLO3kbO9THWS190VQya+HB+YR68xUynOwxg5lFz4Js33rc Yoqnw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=QQNOQZs+QUiK8LmsBI/u9brtryCYri1+dQw18vxt9 Wo=; b=GXJwd0HvoNPe48cA5K/AQpLNCc6Ip/Asc/JOL8s8d2Mj3UZurWacKGlYx YAffNZ1L6/pACdvWQbRnB4xJsJNWKYSWLig3roCHY3X2Ubnf2IDXxy6duTsa4KIh k6FewB1pPD4TlkG1HzAdnhU/+eiKbUU7DEaXVT1v3UehEKinlBfCIYzcrDxokCia N78hFbIl5Cqgh5TkgrWB7nYxW+ufG0Cosw5kjIoRQWRn8HVH2Bkh7Nebn7q4dLZ1 yn6/+vy1BrdNwC0Evbqp4EIo/+4Zwnj3HGodrc6JPke/eQSeuvr0UjPem58CIUUr zNg/AkmPqe6Oi3BpaWESX5+fMsdXg==
X-ME-Sender: <xms:YufzXm9fxZfRQm_SFqTD2PFyXo4tLTHqJHj9JZPKUcHI1XQcLNos2A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekkedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepgffgffetvdeffedtvdduveeluddtie etveekveekudeuiefggfehgeefjeevkeegnecuffhomhgrihhnpehsvghrvhgvrhhpuhhs hhhishhprhhosggrsghlhihthhgvphhoshhtvghrtghhihhlughhvghrvgdrrghspdhhth htphhinhhtvghrrggtthhiohhnthhhrghtshhhrghpphgvnhhinhhgohhnthhhvggtohhn nhgvtghtihhonhdrihhmpdhhthhtphhsvghmrghnthhitghsrdhsohdphhhtthhpshgvmh grnhhtihgtshgsuhhnughlvgguihhnrdguohdpihgvthhfrdhorhhgpdhgihhthhhusgdr tghomhdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhn ohhtrdhnvght
X-ME-Proxy: <xmx:YufzXmt4EXeehKuyvujPp_JEgtP7KV_Miwpy4LmCT19DAjFdskspag> <xmx:YufzXsC_pChEZOhjUkdQCemahL6gDFRUvE--B1cqGp06rmLSho5d6w> <xmx:YufzXueQT9yce1OolXkZ_qFe9xwJ56wM7lJKDMH_65Pz7LHD-56hbQ> <xmx:YufzXkZRYdKH8poZ20lEvlvoWlGuZ2zCIngNy_PfjDLwYYyIo79nBw>
Received: from ( []) by (Postfix) with ESMTPA id B1FBB328005D; Wed, 24 Jun 2020 19:53:04 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Thu, 25 Jun 2020 09:53:01 +1000
Cc: " Group" <>, David Schinazi <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Ben Schwartz <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
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: 1joFCi-0007UC-LV 7e5c7d83194a85c41c6a9489e15dae2c
Subject: Re: HTTP extensions, semantics and HTTP datagrams / MASQUE / WEBTRANS
Archived-At: <>
X-Mailing-List: <> archive/latest/37821
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hey Ben,

I don't want to get too much into the mechanism yet - this is more about general guidance.

That said, you remind me that we should probably have a discussion about how pseudo-headers are (ab)used; we've already seen cases where people are using them for private purposes, and overloading :protocol has its own tricky bits...


> On 25 Jun 2020, at 4:30 am, Ben Schwartz <> wrote:
> One direction I think could be interesting is to embrace the Extended CONNECT as used by WebSocket-H2 (RFC 8441).  If we define ":protocol = tcp" as a synonym for the old-fashioned CONNECT, then ":protocol = udp" could represent the basic MASQUE case nicely, and ":protocol = webtransport" might go naturally as well (if we can't reuse ":protocol = websocket").
> The combination of :protocol and transport (H3 vs. H2) might be sufficient to indicate whether datagrams are allowed.
> On Tue, Jun 23, 2020 at 4:49 AM Mark Nottingham <> wrote:
> 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 <> 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. <>.
> > 2. <>.
> > 3. 'An Unreliable Datagram Extension to QUIC', <>.
> > 4. <>.
> > 5. <>.
> > 
> > --
> > Mark Nottingham
> > 
> > 
> --
> Mark Nottingham

Mark Nottingham