Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

["Roy T. Fielding" <[e-mail]>]

> On Nov 5, 2019, at 5:01 PM, Mark Nottingham <[e-mail]> wrote:
> 
> Previously, we've moved to the 'late-stage process' documented at [1] for the Transport and TLS drafts. The chairs and editors now feel that it's time to move the Recovery, HTTP/3, and QPACK drafts to that process as well.
> 
> As before, this is because we're getting to a stage we feel the documents would benefit from slower and slightly more formal process, so that the rate of change is not so high, changes that do occur are well-vetted, and the documents get closer to reflecting consensus in the working group.

I don't think that process has worked well for QUIC.

There are specific issues that are contentious enough to timebox
and conclude, in a formal (and faster) fashion than was done before.
That makes sense when needed for a specific issue. I don't know
of any such issues for those three drafts. IOW, I don't know of any
issues for which it makes sense for the Chairs to pre-empt the
specification authors in deciding what can or cannot result in
changes to the drafts just because of the timing of when the
issue was raised.

The late-stage process seems to focus all of our energy into
in/out-of-scope arguments rather than actual text in the specifications.
The last interim spent easily twice as much time discussing process
and process planning than it did HTTP/3. Prior interims were worse.
I don't even recall the last time contents of the HTTP/3 spec being
discussed on list, outside of very specific issues related to transport.

I would like to see HTTP/3 written with HTTP in mind, not as a set
of diffs against h2. I would like this working group to shift its focus
away from transport issues (now that they are largely resolved and
awaiting final edits) and into active discussion of HTTP/3. The only
example we have of that is the https discussion, which revealed a
necessary issue for http-core to resolve and is expected to iterate
back onto HTTP/3.

This is not a small undertaking, but it isn't a massive one either.
Basically, import the bits of h2 that are necessary to explain HTTP/3's
operation and intent, and then start referencing the http-core drafts
instead of 723x. Yes, I know that is risky, but it is the right thing to do.
And it needs to be done before http-core is finished, since that effort
exists largely to place the right content (in the right places) for
HTTP/3 to reference.

That's a far better use of our time than arguing about what stage
the HTTP/3 documents are in.

I would also like to see the details of interop testing reported on list,
to the extent that people are willing/able to report them in public
(i.e., nothing specific to vendors or products). In particular,
I'd like to know how much of HTTP practice has actually been
exercised by those tests. Is it still limited to HTTP/0.9 interop?
Have we looked at long sessions interleaved with short spatter?
What about API-driven, non-browser traffic?

I have no idea what the status is with QPACK, but we should
learn a lesson from the last time and make sure the fixed
compression dictionary (if any) is based on traffic at more than
one proxy or origin server. Or at least have each of the major
deployments generate their local "best" encoding and do some
cross-testing of the N choices (plus one or two based on a
hand-crafted expert merge).

I would like for HTTP/3 to have a mechanism for communicating
metadata (like trailers) in mid-stream, both for requests (e.g., priority)
and responses (e.g., chained sigs). That has been a design goal for HTTP
since 1995 or so. HTTP/1.1 had it, albeit limited to chunked extensions.
It has been proposed multiple times and keeps getting postponed
because of "concern about scope". This is not a semantics issue
(they are just optional trailers that arrive early) -- it is a multiplex
framing issue (a new frame type and expectation to process).

> If we do this, we're saying that we have gained consensus on what remains in these documents, excepting their outstanding issues. As per our charter:
> 
> """
> Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified.
> """

-1  I don't think the non-transport issues have been discussed to the
     point where most issues could be reasonably opened, so saying
     we have consensus on the initial document is premature.
     We have been waiting for a transport consensus.
     Let's get that consensus and spend more energy on HTTP/3.

....Roy