Re: Call for Adoption: HTTP/2 Bis

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