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

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

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
>>
>>
>>