Re: Call for Adoption: HTTP/2 Bis

Hi Roy,

> On 5 Dec 2020, at 6:59 am, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>> On Dec 2, 2020, at 4:36 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> Based upon discussion at the interim and subsequent activity on the HTTP/2 issues list, the Chairs believe that the following is in-scope for a HTTP/2 bis effort:
>> 
>> * Incorporating errata
>> * Makeing strictly editorial improvements
>> * Aligning with the publication of http-core
>> * Incorporating RFC8740 to align with the publication of TLS 1.3
>> * Updating references to other specifications as necessary
>> * Documenting additional security considerations
>> * Providing implementer guidance where appropriate
>> * Addressing problems or ambiguities where the affect interoperability, so long as the solution does decrease interoperability
>> * Making the protocol more resistant to ossification, so long as doing so does not affect interoperability
>> 
>> This effort will not create a new version of HTTP; its output will not have a distinct ALPN identifier. As such, new features and backwards-incompatible changes like updates to the HPACK static table are out of scope. For the same reason, deprecating or removing Server Push and the Priority scheme is out of scope, although implementation advice might contextualise their use. 
>> 
>> Please indicate whether you support this approach to the work; the CfA will end in two weeks on 17 December.
> 
> I support doing the work to update the RFC, but I don't see any reason to
> limit its scope as a chairs' mandate.
> 
> This is the HTTP WG. We should be working on HTTP enhancements.
> We should not stop discussion of issues just because we don't
> expect the HTTP/2 editor to write them into that specific draft.
> 
> Hence, I'd like this to be rephrased as:
> 
> There is work to be done on HTTP/2, here is what we know now, and that
> will be done within *this* specific draft. Further additions will be subject to
> WG consensus. Extensions, if any, may be discussed within other drafts.
> Prior to WG last call, the WG will decide whether any such extensions
> have progressed to the point of inclusion within HTTP/2.

This isn't proposing a "chairs' mandate" (whatever that is).

We scope our larger pieces of work so that people know whether they want to participate, and to help surface disagreements and other areas to focus on early. We've done this pretty consistently through the lifetime of the WG, and it's been helpful in assuring that we have alignment about what we're working on and visibility in to where the issues are.

The scope is confirmed by consensus (here, in the meeting, on the repo, and now on the list), but we can revisit the scope if we have consensus to do so. I.e., consensus on a general scope here does not bind the WG if it gains consensus to exceed it in the future.

In other words, what the scope adds is some amount of friction against things that are outside it; not enough to overcome if there's need to, but enough to encourage focus on a common goal, so we're able to finish in a reasonable amount of time. That's valuable to those who participate in good faith (in particular, the editors).

I think I remember you bringing up a similar objection when we chartered HTTP/2 originally. I think our experience there was a good demonstration of this in practice; having a defined scope helped concentrate and align the efforts of the group, but we didn't see it as binding when we got to issues that hadn't been anticipated; we just needed to gain consensus on how to address them.

Of course, as you point out, we can still *discuss* things on the list (etc.) even if they're not in this particular draft; we're pretty accustomed to doing several things at once.

All of that said - if there's consensus in the group to adopt h2bis without any defined scope, we can do that too. How do folks feel about that?

Cheers,

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

Received on Saturday, 5 December 2020 23:43:12 UTC