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

[Mike Bishop <[e-mail]>]

I'll also note that it's relatively easy from a spec perspective to allow trailers to arrive before the end of the body, or to allow multiple sets of trailers to arrive.  I suspect most clients won't process trailers until they have the body anyway, but the real question is what clients do with multiple trailer sets.  I'm not certain whether that's in our scope or not, but that's a separate conversation.  Feel free to open an issue for that specific discussion.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Mark Nottingham
Sent: Sunday, November 10, 2019 8:01 PM
To: Roy Fielding <[e-mail]>
Cc: Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>
Subject: Re: Call for Consensus: Moving HTTP/3, QPACK and Recovery to the Late-Stage Process

Hi Roy,

Responding to the parts relevant to this CfC.

> On 7 Nov 2019, at 5:39 am, Roy T. Fielding <[e-mail]> wrote:
> 
>> 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.

Noted.

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

You misunderstand the process; the Chairs aren't pre-empting anything, the group is attempting to agree to a path to completing this work.

> The late-stage process seems to focus all of our energy into 
> in/out-of-scope arguments rather than actual text in the specifications.

I don't see any evidence for that claim; what makes you believe that?

> The last interim spent easily twice as much time discussing process 
> and process planning than it did HTTP/3. Prior interims were worse.

We spent a day talking about transport and TLS, part of a morning talking about planning the future of our work (if you want to call that "process and process planning") and the bulk of the (longer) afternoon session talking about H3. This isn't surprising, since our goal for the meeting was to get the Transport and TLS documents close to finished.

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

That is by charter; we're largely limited to mapping H2 onto QUIC. 

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

AIUI that is still our intent, and shouldn't be impeded by the late-stage process, since that work should be editorial.

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

Where are the multiple proposals you refer to? We've been working on h3 now for more than three years. If you submit them now, they'll be design issues.

I'd say that the Late-Stage process (or at least the proposal of adopting it) is working exactly as intended here -- making people realise that if they still have issues / changes that they want discussed, they need to bring them to our attention now, not as we go to WGLC.

Cheers,

--
Mark Nottingham   https://www.mnot.net/