Re: Time to refresh HTTP/2?

It seems like everyone wants their swing at this.

To be perfectly frank, I wasn't planning on addressing any of these.  It's a long and slippery slope.

But I will start a list and we can discuss where to draw the line. 

On Fri, Aug 28, 2020, at 23:00, Mark Nottingham wrote:
> What about priorities?

I would be opposed to publishing a new version with a replacement priorities scheme before that scheme were proven.  It might be OK to publish a version with text with the priority scheme removed, with a note about it not being interoperable in practice or some such.

Here's some historical info that seems relevant.  The following text appears in the draft, commented out:

> Note that stream dependencies have not yet been validated in practice.  The theory
> might be fairly sound, but there are no implementations currently sending these.  If it
> turns out that they are not useful, or actively harmful, implementations will be requested
> to avoid creating stream dependencies.

While this might be true, I don't want a reprise.

On Sat, Aug 29, 2020, at 00:54, Cory Benfield wrote:
> I'm +1 on this as well. I'd like to see the extensions rolled in,
> along with GREASE. I'm a bit more nervous about the priority changes
> given how relatively young they are.

Cory agrees with me, so I'm probably right....  As for GREASE, I'm reluctant to include new design work, but it might be small enough to meet the cut.

On Fri, Aug 28, 2020 at 12:59:03PM +0200, Julian Reschke wrote:
> Actually, I was going to suggest that as well, but mainly to align
> HTTP/2 with the new core specs - it would be good to say how the cleanup
> affects the references from HTTP/2.

I definitely had that in mind.  My plan is to do that once the -core drafts leave the working group (so that there is no further risk of reshuffling.

> Am 28.08.2020 um 13:27 schrieb Willy Tarreau:
> +1 as well. Wouldn't it be an opportunity to also reference (or even merge)
> the extensions such as RFC8441 which adds the ":protocol" pseudo-header ?
 
I tend to think that 8441 wouldn't make the cut; it's discrete in the same way that the ORIGIN or ALTSVC frames are.

On Fri, Aug 28, 2020, at 21:52, Julian Reschke wrote:
> And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...

8740 might make the cut.

Just to add to the list:

* midders (or multiple trailers or whatever they are) are something I'm still uncertain about
* a re-design that included better 0-RTT design is probably off the table
* removing h2c is very tempting, with similar rationale to PRIORITY

Received on Monday, 31 August 2020 00:10:54 UTC