Re: Call for Adoption: HTTP/2 Bis

I think that based on the defined scope, any basic GREASE mechanisms that can be proved out to be useful and deployable would fit in scope for the H2 bis effort, but not any changes requiring a new ALPN without a further adoption call.

I also don’t think it’s a problem to let specifications of GREASE for H2 that are still more experimental to stay in separate documents as we get more experience. 

Best,
Tommy

> On Dec 19, 2020, at 12:43 PM, Ian Swett <ianswett@google.com> wrote:
> 
> 
> Thanks Tommy, one follow-up question.
> 
> If people attempt to deploy GREASE for HTTP/2 more widely and it's found to be non-deployable, it seems like the second half of this bullet indicates GREASE should be dropped, but that's not the conclusion I'm getting from the above discussion.  Can you clarify that?
> 
> Making the protocol more resistant to ossification, so long as doing so does not affect interoperability
> 
> A question for the working group is: Are there servers that are going to actively pursue GREASE in H2?  We might do some, but it'll be limited in scope due to past issues.
> 
> Ian
> 
>> On Thu, Dec 17, 2020 at 5:28 PM Tommy Pauly <tpauly@apple.com> wrote:
>> Hello all,
>> 
>> Thanks for all the feedback and discussion on the HTTP/2 Bis effort!
>> 
>> Based on the expressed support, we will be adopting this as a working group document. We’ll plan on starting out with the limited scope that’s been proposed (and was previously discussed on GitHub). Of course, the working group can later decide to expand this scope if necessary; any extended scope would be handled as a separate adoption call to go into this document.
>> 
>> Best,
>> Tommy
>> 
>> > 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.
>> > 
>> > Cheers,
>> > 
>> > --
>> > Mark and Tommy
>> > 
>> > 
>> 
>>