Re: Call for Adoption: HTTP/2 Bis

> On Dec 5, 2020, at 3:42 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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).

"the Chairs believe that the following is in-scope"?

Scope defines a limitation on debate and on editors. Honestly, I'd rather
just let Martin decide what he wants to work on and anything else can
require WG consensus via github PRs for additions.

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

Scope means one thing, whereas how the chairs enforce that scope is another thing.

In that case, I do not agree with your belief that HTTP/2 bis ought
to be limited with regards to strictly editorial changes, ALPN version,
replacement or elimination of the priority scheme, deprecating server
push (and properly specifying the replacement), or updating the HPACK
table to be more efficient based on actual traffic analysis.

I don't expect the editors to do that work. I want other people to feel that
they wouldn't be wasting their time if they did the research and described
it as a separate draft. WG consensus would be required to merge such
change proposals.

And if the editors finish an update before any such proposals have reached
consensus, then we go ahead and submit a bis with nothing but editorial
changes and don't worry about it til the next bis (if any).

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

I thought the process was biased on a particular design and then failed
to deal with late technical questions about that design because too much
water under the bridge. I note those same technical questions are still
being called out of scope above. When are they going to be addressed?

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

+1 on adopting h2bis with or without a scope. I think h2bis is necessary regardless.

....Roy