Subject: FW: New Version Notification for draft-bishop-httpbis-origin-h3-00.txt

From: Mike Bishop <[email-masked]>
Date: Wed, 1 Sep 2021 16:00:21 +0000

Since we've adopted RFC7838bis, my draft which redefined the ALTSVC (and later ORIGIN) frame(s) unchanged for HTTP/3 no longer needs to cover the frame it was originally written for.  I've removed the portions which apply to ALTSVC and republished it as a new -00 addressing ORIGIN only.  This is a dead simple draft, but please give it a look to make sure it's not *too* simple.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Wednesday, September 1, 2021 11:50 AM
To: Mike Bishop <[email-masked]>
Subject: New Version Notification for draft-bishop-httpbis-origin-h3-00.txt

A new version of I-D, draft-bishop-httpbis-origin-h3-00.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:		draft-bishop-httpbis-origin-h3
Revision:	00
Title:		The ORIGIN Extension in HTTP/3
Document date:	2021-09-01
Group:		Individual Submission
Pages:		3
URL:            https://www.ietf.org/archive/id/draft-bishop-httpbis-origin-h3-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-origin-h3/
Html:           https://www.ietf.org/archive/id/draft-bishop-httpbis-origin-h3-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-origin-h3

Abstract:
   The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but
   needs to be separately registered.  This document describes the
   ORIGIN frame for HTTP/3.

The IETF Secretariat

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 1 Sep 2021 13:07:02 -0700

I'm glad to see the ORIGIN frame moving forward! While I'm definitely a
supporter of closing any gaps between HTTP/2 and HTTP/3, the ORIGIN frame
in particular seems to fill an active need. For servers which have certs
with multiple names but backends that only handle a single origin, 421
offers a solution, but at the cost of an RTT. The ORIGIN frame, on the
other hand, has no such limitation.

On Wed, Sep 1, 2021 at 9:04 AM Mike Bishop <[email-masked]> wrote:

> Since we've adopted RFC7838bis, my draft which redefined the ALTSVC (and
> later ORIGIN) frame(s) unchanged for HTTP/3 no longer needs to cover the
> frame it was originally written for.  I've removed the portions which apply
> to ALTSVC and republished it as a new -00 addressing ORIGIN only.  This is
> a dead simple draft, but please give it a look to make sure it's not *too*
> simple.
>
> URL:
> https://www.ietf.org/archive/id/draft-bishop-httpbis-origin-h3-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bishop-httpbis-origin-h3/
> Html:
> https://www.ietf.org/archive/id/draft-bishop-httpbis-origin-h3-00.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-origin-h3
>
>
> Abstract:

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 1 Sep 2021 22:18:07 +0100

Hey Mike,

Maybe it's a tad too simple:

* I was kind of surprised to be reminded that RFC 8336 requires receivers
to only ignore the frame on a non-zero stream. We tended to be a bit more
assertive in HTTP/3. Perhaps there was a good reason in RFC 8336? If not,
maybe it's time to be stricter.
* RFC 8336 does some weird hand waving with flags, and we don't have those
in HTTP/3. Your I-D talks mainly about payload commonly, so skirts the
matter. But I wonder if something would need to be said here, for example
H2-H3 converter intermediaries that might find someone sends flags that
they can't forward. This type of thing is mentioned in
https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#appendix-A.2.4,
where it is suggested the H2 flags would be accommodated as part of the H3
frame payload.
* In a similar vein, the possible size of an H3 frame is a larger than H2.
It seems to possible to split H3 frames into several H2 frames if it was
really required, since the Origin Set will be updated in order anyway.
* The discussion of Origin Set, especially with regards to coalescing, is
perhaps a little too light.
* The stuff in RFC 8336 about the "h2" is pretty obvious to map over
conceptually. But the ongoing discussions about ALPN proliferation might
come into play
* There's no explicit payload definition, which I suspect is on purpose.
Core HTTP/3 frame and payloads tend to use varints, so using a fixed-size
Origin-len might catch some out.
* There's a very nitpicky errata about the ORIGIN payload format, which is
being imported ;-) [1]
* *maybe* there's something to be said here about ORIGIN and alt-svc,
because we are likely expecting HTTP/3 services to have been discovered via
those means already (as oppposed other HTTP versions)

Cheers,
Lucas

[1] - https://www.rfc-editor.org/errata/eid5378