RE: For discussion: scope for AltSvc and ORIGIN bis efforts

[Mike Bishop <[e-mail]>]

Given that there is at least some interest in discussing substantive changes 
to Alt-Svc following the design of HTTPS/SVCB, it seems odd to consider a bis 
and a potential tre in relatively quick succession.  However, that discussion 
might not lead to a new document, so we need to pick something to do in the 
meantime.

I think it would be cleaner to do a patch-only fix to this issue and leave a 
full revised document for that discussion if it materializes.  However, I have 
no objection to bis documents in the meantime if that's the preferred approach 
in the WG.

-----Original Message-----
From: Mark Nottingham <[e-mail]>
Sent: Wednesday, November 4, 2020 5:37 PM
To: HTTP Working Group <[e-mail]>
Cc: Tommy Pauly <[e-mail]>
Subject: For discussion: scope for AltSvc and ORIGIN bis efforts

At the interim, we discussed Mike's draft to revise some HTTP/2 extensions to 
work with HTTP/3:
https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-altsvc-quic

After discussion, the most viable way forward seemed to be to revise both of 
those documents to include HTTP/2 and HTTP/3 mechanisms, rather than just 
creating a "patch" RFC that updates them for HTTP/3.

The Chairs support doing so, but want to see a well-defined scope of work for 
the effort.

As a starting point, we believe that the following should be in-scope for the 
effort:

* Porting the ORIGIN and ALTSVC frames to HTTP/3
* Incorporating errata
* Editorial improvements

Other changes would be out of scope. In particular, anything that is 
incompatible with the current definition or use of these frames in HTTP/2 
would not be suitable.

However, improvements in how they are specified could be in-scope, provided 
that there is strong consensus to include them.

Comments on this scope -- including proposals for additions -- are welcome; 
we'll issue a Call for Adoption if we can get to a general agreement about 
that.

Cheers,

Mark and Tommy