From ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org Tue Mar 19 15:42:26 2024 Return-Path: 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 B1D6CC151532 for ; Tue, 19 Mar 2024 15:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="AWiTHYGR"; dkim=pass (2048-bit key) header.d=w3.org header.b="YF9YbR1p"; dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="sdVYya+u"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="rO3DNFXX" Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYxLRdStcIwa for ; Tue, 19 Mar 2024 15:42:22 -0700 (PDT) Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077D1C151093 for ; Tue, 19 Mar 2024 15:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:To:From:Date:References:In-Reply-To:Message-Id: MIME-Version:Cc:Reply-To; bh=SvhnTMPJXIKm8MgvnAAmmEMCUXJDjhlJDr1JKiu/81o=; b= AWiTHYGRZNlNDc2xGn1uCebSuhtf4q546emkFrucWqBRHR38DDy1sas8GIS56bq3kTfH+/beuWqGG YfRf0FcO4dW1V4RVQpwoRmuVYnHYjh8R3b+nsRL/GbmhydH+4F2Cj3h9D2IlWdXfaQ2lgVz75VB2+ CJ9LQzZPpCqdoCiktCnTB/SRUs4VzTV4bwaIWC9qXm5VZxQwyeDzpwYir6SHYbGLtHTmbxuWIMGd6 4m80wpJjqxNk73GUoHFmsi/Vt1bUnIMkohMYh/goxNagg8yRKp+NS0iV8RamjIlDZTsB3nhg6LEv9 E5Ni1p8VhpyPdymLHJ6ihSl8JX+Cw2BR2A==; Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from ) id 1rmi7s-003ex0-C7 for ietf-http-wg-dist@listhub.w3.org; Tue, 19 Mar 2024 22:40:08 +0000 Resent-Date: Tue, 19 Mar 2024 22:40:08 +0000 Resent-Message-Id: Received: from puck.w3.org ([34.196.82.207]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmi7p-003evt-VE for ietf-http-wg@listhub.w3.org; Tue, 19 Mar 2024 22:40:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Subject:To:From:Date:References:In-Reply-To:Message-Id: MIME-Version:Cc:Reply-To; bh=SvhnTMPJXIKm8MgvnAAmmEMCUXJDjhlJDr1JKiu/81o=; t=1710888005; x=1711752005; b=YF9YbR1pOXNicNbcW0c4n8qhlfIwBQJ1ygiLyaWeHaLJJfa msmhvVD8Olds1alEQ9hdn5uri01zHUHxhUMR9gte00zvp8D/amqJHAABTsxbSIJkljP1hEGFa7yrZ x4VcUYtfV7fNYAi6kFJLH8/M6a3CUAhUtz++R4AlMS60z6RlhEkJNBZzjTR2aaCCVDC4QwmQcaH4W RPl4jXPBixvV7zBVaTpcwjJPmG38R/4mskJWqfb4VjtdxMbPs9sK39uho5txTeBV1EbUkHzwH7K6R oQwltVaT5YSM0zSbLp0DPJ+uC085PiUNkCEryhyOQGqP6OC1RYTMZRUqLvdQUQOw==; Received-SPF: pass (puck.w3.org: domain of lucaspardue.com designates 103.168.172.155 as permitted sender) client-ip=103.168.172.155; envelope-from=lucas@lucaspardue.com; helo=fhigh4-smtp.messagingengine.com; Received: from fhigh4-smtp.messagingengine.com ([103.168.172.155]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rmi7o-009llw-01 for ietf-http-wg@w3.org; Tue, 19 Mar 2024 22:40:05 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailfhigh.nyi.internal (Postfix) with ESMTP id AAD9C11400E3; Tue, 19 Mar 2024 18:40:00 -0400 (EDT) Received: from imap53 ([10.202.2.103]) by compute3.internal (MEProxy); Tue, 19 Mar 2024 18:40:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1710888000; x=1710974400; bh=SvhnTMPJXI Km8MgvnAAmmEMCUXJDjhlJDr1JKiu/81o=; b=sdVYya+ugFtVANRb264lFVSThY uf19Q0WeijcWfAK8vBWzcKhhQ1gPA+WXHi64QS9dteVB89tZuoBomvzgsjMe+cmx OWyAvA4Et9OK1H1ldGSmf2TjdrDP/MTs57mEyiNQJyMadmLSibxucWqDdxgXUThG EDKaEwqflkBY0cu5Kh5RD/aINt2xlWw0UXqOVzUMc1izQkyk0M2qGi/eRjeQj67E 5OCpW7WMwA/v2bTbuy86/7YKGLM4aEqTpkQUP7ZB9vQ0itVqwT45p0AAw76Iy7Nv 1CTTFy0ucr2E/lxouJ4DqL4unqICH2o9LE71uwhexDLNrJEeO4qi1rqBiWaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1710888000; x=1710974400; bh=SvhnTMPJXIKm8MgvnAAmmEMCUXJD jhlJDr1JKiu/81o=; b=rO3DNFXXmUIj1WddEcOVwVOgJ02l7J42wOpUQ+cFtpZT xS+ICF4swszsMhADdwJqsIFhFAV/HM8IC+JmFgawiJdx4lVuR8HMpUUz9xM1viKF lVYotme6CuN1ZhP1tauom+635kcWajgICmBKQ6JZ4iuGE8Zl1AbtM1qUsohyx0Vm 2F/Pa3D0bZxAIMkSMooDsbwXc/z07i1kcTJMvQIV2SkStMh5g6dlmIQyDg5to/8M 0DucAtwosdGyZAAH511s8oZgxFGHZttR8VnAOhap+kj1zaD713NG70up3pa1bDZB f2LpKeqcna5A66o4Z+FEXFfYp6bc3Sql3NxTmcai3Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrledugddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfnfhutggr shcurfgrrhguuhgvfdcuoehluhgtrghssehluhgtrghsphgrrhguuhgvrdgtohhmqeenuc ggtffrrghtthgvrhhnpeeuueekuefhleettdelgeeggeettdduudejjeevvdeltdevffef keelkedthedvteenucffohhmrghinhepihgvthhfrdhorhhgpdhhthhtphdvrdgshidphh htthhpfeifvggtrghntghonhhsvghrvhgvvghnvghrghihrdgshienucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehluhgtrghssehluhgtrghsph grrhguuhgvrdgtohhm X-ME-Proxy: Feedback-ID: i23b94938:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 68E3736400B5; Tue, 19 Mar 2024 18:40:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.11.0-alpha0-300-gdee1775a43-fm-20240315.001-gdee1775a MIME-Version: 1.0 Message-Id: <8ac873e6-b4d3-4512-b334-81259b2140e3@app.fastmail.com> In-Reply-To: <93cb99e8-9450-49b8-8d7b-64c425941405@app.fastmail.com> References: <170807134367.25372.9131938145722079298@ietfa.amsl.com> <93cb99e8-9450-49b8-8d7b-64c425941405@app.fastmail.com> Date: Wed, 20 Mar 2024 08:39:37 +1000 From: "Lucas Pardue" To: "IETF QUIC WG" , "HTTP Working Group" Content-Type: multipart/alternative; boundary=4eff7fda28cc499ba7fbfa769b8006c9 X-W3C-Hub-DKIM-Status: validation passed: (address=lucas@lucaspardue.com domain=lucaspardue.com), signature is good X-W3C-Hub-DKIM-Status: validation passed: (address=lucas@lucaspardue.com domain=messagingengine.com), signature is good X-W3C-Hub-Spam-Status: No, score=-4.1 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, DMARC_MISSING=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1 X-W3C-Scan-Sig: puck.w3.org 1rmi7o-009llw-01 a8e515d145cc33dd82915a39aa758b50 X-Original-To: ietf-http-wg@w3.org Subject: Re: Proposal Towards Universal HTTP/3, with a polyfill of QUIC for TCP (Fwd: New Version Notification for draft-kazuho-httpbis-http3-on-streams-00.txt) Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/51903 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --4eff7fda28cc499ba7fbfa769b8006c9 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Apologies to remote joiners, we are dealing with some local teleconferen= cing issues and awaiting onsite support to resolve that. In the interest= of time we've commenced the agenda. Hopefully the issue is resolved soo= n. Cheers Lucas On Wed, Mar 13, 2024, at 06:24, Lucas Pardue wrote: > Hi folks, >=20 > (Top posting for clarity) >=20 > There was quite a healthy discussion about these drafts. There is time= scheduled on the IETF 119 agenda in both the QUIC WG and HTTP WG sessio= ns, however the slots are brief due to the balance of time. >=20 > I've booked a room to hold an informal side meeting on 2024-03-20 Wedn= esday 08:30-09:30; see https://wiki.ietf.org/meeting/119/sidemeetings. T= his is immediately before the QUIC WG, in order to capture and disperse = any salient points during the formal agenda slot.=20 >=20 > The room has very limited capacity. I'm particularly looking for peopl= e that have an active interest in the *transport* and *security* aspects= of QUIC on streams, or those with related use cases that have we have y= et to hear from. I intend to have remote participation support, so even = if you're onsite, please consider using that and leaving a spot for othe= rs if you don't plan to actively contribute to discussion. >=20 > Cheers > Lucas >=20 > Fri, Feb 16, 2024, at 08:24, Kazuho Oku wrote: >> Hello QUIC and HTTP enthusiasts, >>=20 >> We, Lucas and I, have submitted two drafts aimed at broadening the re= ach of HTTP/3 - yes, making it available over TCP as well. We are eager = to hear your thoughts on these: >>=20 >> QUIC on Streams: A polyfill for operating QUIC on top of TCP. >> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-quic-on-strea= ms >>=20 >> HTTP/3 on Streams: How to run HTTP/3 unmodified over TCP, utilizing Q= UIC on Streams. >> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-s= treams >>=20 >> As the co-author of the two drafts, let me explain why we have submit= ted these. >>=20 >> The rationale behind our proposal is the complexity of having two maj= or HTTP versions (HTTP/2 and HTTP/3), both actively used and extended. T= his might not be the situation that we want to be in. >>=20 >> HTTP/2 is showing its age. We discussed its challenges at the IETF 11= 8 side meeting in Prague. >>=20 >> Despite these challenges, we are still trying to extend HTTP/2, as se= en with WebTransport. WebTransport extends both HTTP/3 and HTTP/2, but i= t does so differently for each, due to the inherent differences between = the HTTP versions. >>=20 >> Why are we doing this? >>=20 >> Because HTTP/3 works only on QUIC. Given that UDP is not as universal= ly accessible as TCP, we find ourselves in a position where we need to m= aintain and extend not only HTTP/3 but also HTTP/2 as a backstop protoco= l. >>=20 >> This effort comes with its costs, which we have been attempting to ma= nage. >>=20 >> However, if we could create a polyfill for QUIC that operates on top = of TCP, and then use it to run HTTP/3 over TCP, do we still need to inve= st in HTTP/2? >>=20 >> Of course, HTTP/2 won=E2=80=99t disappear overnight. >>=20 >> Yet, by making HTTP/3 more universally usable, we can at least stop e= xtending HTTP/2. >>=20 >> By focusing our new efforts solely on HTTP/3, we can conserve energy. >>=20 >> By making HTTP/3 universally accessible, and by having new extensions= solely to HTTP/3, we can expect a shift of traffic towards HTTP/3. >>=20 >> This shift would reduce the necessity to modify our HTTP/2 stacks (we= =E2=80=99d be less concerned about performance issues), and provide us w= ith a better chance to phase out HTTP/2 sooner. >>=20 >> Some might argue that implementing a polyfill of QUIC comes with its = own set of costs. However, it is my understanding that many QUIC stacks = already have the capability to read QUIC frames other than from QUIC pac= kets, primarily for testing purposes. This suggests that the effort woul= d be more about leveraging existing code paths rather than writing new c= ode from scratch. Furthermore, a QUIC polyfill would extend its benefits= beyond just HTTP, by aiding other application protocols that aim to be = built on top of QUIC, providing them accessibility over TCP. >>=20 >> Please let us know what you think. Best regards, >>=20 >> ---------- Forwarded message --------- >> From: >> Date: 2024=E5=B9=B42=E6=9C=8816=E6=97=A5(=E9=87=91) 17:15 >> Subject: New Version Notification for draft-kazuho-httpbis-http3-on-s= treams-00.txt >> To: Kazuho Oku , Lucas Pardue >>=20 >>=20 >> A new version of Internet-Draft draft-kazuho-httpbis-http3-on-streams= -00.txt >> has been successfully submitted by Kazuho Oku and posted to the >> IETF repository. >>=20 >> Name: draft-kazuho-httpbis-http3-on-streams >> Revision: 00 >> Title: HTTP/3 on Streams >> Date: 2024-02-16 >> Group: Individual Submission >> Pages: 5 >> URL: https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-= on-streams-00.txt >> Status: https://datatracker.ietf.org/doc/draft-kazuho-httpbis-http3= -on-streams/ >> HTML: https://www.ietf.org/archive/id/draft-kazuho-httpbis-http3-= on-streams-00.html >> HTMLized: https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-= http3-on-streams >>=20 >>=20 >> Abstract: >>=20 >> This document specifies how to use HTTP/3 on top of bi-directional, >> byte-oriented streams such as TLS over TCP. >>=20 >> Discussion Venues >>=20 >> This note is to be removed before publishing as an RFC. >>=20 >> Discussion of this document takes place on the HTTP Working Group >> mailing list (ietf-http-wg@w3.org), which is archived at >> https://lists.w3.org/Archives/Public/ietf-http-wg/. >>=20 >> Source for this draft and an issue tracker can be found at >> https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=20 >> -- >> Kazuho Oku >=20 --4eff7fda28cc499ba7fbfa769b8006c9 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Apologies = to remote joiners, we are dealing with some local teleconferencing issue= s and awaiting onsite support to resolve that. In the interest of time w= e've commenced the agenda. Hopefully the issue is resolved soon.

Cheers
Lucas

On Wed, Mar 13, 2024, at 06:24, Lucas Pardue wrote:
Hi folks,
<= br>
(Top posting for clarity)

The= re was quite a healthy discussion about these drafts. There is time sche= duled on the IETF 119 agenda in both the QUIC WG and HTTP WG sessions, h= owever the slots are brief due to the balance of time.
<= div>


Hello QUIC = and HTTP enthusiasts,

We, Lucas and I, have= submitted two drafts aimed at broadening the reach of HTTP/3 - yes, mak= ing it available over TCP as well. We are eager to hear your thoughts on= these:

QUIC on Streams: A polyfill for ope= rating QUIC on top of TCP.
<= br>
HTTP/3 on Streams: How to run HTTP/3 unmodified over TCP, = utilizing QUIC on Streams.
https://datatra= cker.ietf.org/doc/html/draft-kazuho-httpbis-http3-on-streams

As the co-author of the two drafts, let me explain= why we have submitted these.

The rationale= behind our proposal is the complexity of having two major HTTP versions= (HTTP/2 and HTTP/3), both actively used and extended. This might not be= the situation that we want to be in.

HTTP/= 2 is showing its age. We discussed its challenges at the IETF 118 side m= eeting in Prague.

Despite these challenges,= we are still trying to extend HTTP/2, as seen with WebTransport. WebTra= nsport extends both HTTP/3 and HTTP/2, but it does so differently for ea= ch, due to the inherent differences between the HTTP versions.
=

Why are we doing this?

= Because HTTP/3 works only on QUIC. Given that UDP is not as universally = accessible as TCP, we find ourselves in a position where we need to main= tain and extend not only HTTP/3 but also HTTP/2 as a backstop protocol.<= br>

This effort comes with its costs, which we = have been attempting to manage.

However, if= we could create a polyfill for QUIC that operates on top of TCP, and th= en use it to run HTTP/3 over TCP, do we still need to invest in HTTP/2?<= br>

Of course, HTTP/2 won=E2=80=99t disappear o= vernight.

Yet, by making HTTP/3 more univer= sally usable, we can at least stop extending HTTP/2.

<= /div>
By focusing our new efforts solely on HTTP/3, we can conserve = energy.

By making HTTP/3 universally access= ible, and by having new extensions solely to HTTP/3, we can expect a shi= ft of traffic towards HTTP/3.

This shift wo= uld reduce the necessity to modify our HTTP/2 stacks (we=E2=80=99d be le= ss concerned about performance issues), and provide us with a better cha= nce to phase out HTTP/2 sooner.

Some might = argue that implementing a polyfill of QUIC comes with its own set of cos= ts. However, it is my understanding that many QUIC stacks already have t= he capability to read QUIC frames other than from QUIC packets, primaril= y for testing purposes. This suggests that the effort would be more abou= t leveraging existing code paths rather than writing new code from scrat= ch. Furthermore, a QUIC polyfill would extend its benefits beyond just H= TTP, by aiding other application protocols that aim to be built on top o= f QUIC, providing them accessibility over TCP.

<= div>Please let us know what you think. Best regards,

<= /div>
---------- Forwarded message ---------


A new version of Internet-= Draft draft-kazuho-httpbis-http3-on-streams-00.txt
has bee= n successfully submitted by Kazuho Oku and posted to the
I= ETF repository.

Name:     draft-k= azuho-httpbis-http3-on-streams
Revision: 00
= Title:    HTTP/3 on Streams
Date:     = 2024-02-16
Group:    Individual Submission
Pages:    5
URL:      https://www.ietf.org/archive/id/draft-kazuho-httpbis-http= 3-on-streams-00.txt
HTMLized: https://datatracker.ietf.org/doc/html/draft-k= azuho-httpbis-http3-on-streams


Abstract:

   This document= specifies how to use HTTP/3 on top of bi-directional,
&nb= sp;  byte-oriented streams such as TLS over TCP.

=
Discussion Venues

   T= his note is to be removed before publishing as an RFC.
   Discussion of this document takes place on the = HTTP Working Group
   mailing list (ietf-http-wg@w3.org), which is archived a= t




The IETF Secretariat
=




-= -
Kazuho Oku


--4eff7fda28cc499ba7fbfa769b8006c9--