W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 1 Sep 2021 22:18:07 +0100
Message-ID: <CALGR9oYnOLrHN5i_Z3acUWk+ioCaDzQxD5gEopCz8DRu0=Y25A@mail.gmail.com>
To: Ryan Hamilton <rch@google.com>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
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
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)


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

On Wed, Sep 1, 2021 at 9:11 PM Ryan Hamilton <rch@google.com> wrote:

> 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 <mbishop@evequefou.be> 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.
>> -----Original Message-----
>> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
>> Sent: Wednesday, September 1, 2021 11:50 AM
>> To: Mike Bishop <mbishop@evequefou.be>
>> 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
Received on Wednesday, 1 September 2021 21:18:32 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 1 September 2021 21:18:33 UTC