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

[Martin Thomson <[e-mail]>]

I'd like to see these revised.

Getting the scope of changes right is important.  I think that what the chairs have outlined is good.  No substantive changes aside from getting them ready for HTTP/3.

As far as editorial scope goes, my view is that we allow editors (whoever that happens to be) some flexibility.  Editorial fixes can be done in parallel with normative changes, without extending the timeframe.  Or at least, not by a lot.

I think that Lucas has identified a borderline editorial issue here.  I'd be OK with trying to clear that up, even if it means a small normative change.  It seems like, as with HTTP/2, we should allow for learning from deployment here.

On Thu, Nov 5, 2020, at 10:09, Lucas Pardue wrote:
> Hi Chairs,
> 
> On Wed, 4 Nov 2020, 22:38 Mark Nottingham, <[e-mail]> wrote:
> > 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
> 
> There seems to be only one errata. It's in the origin spec and is a 
> very minor editorial thing.
> 
> What are the scale of editorial improvements on the table? 
> 
> So far I'm struggling to see much benefit to a bis activity unless it 
> does something more substantial that paragraph shuffling.
> 
> I've talked a bit about an Alt-Svc BCP-type document in the past. I 
> think that is outside your scope and I think that is fine. However, I'd 
> like to pitch the idea of improving upon the text in Alt-Svc caching. 
> 
> It doesn't seem like the persist parameter is being used as intended. 
> The statement
> 
> >    By default, cached alternative services will be cleared when the client detects a network change.
> 
> I think is misleading to operators, clients tend to act as if persist 
> is always "1". 
> 
> The doc also mentions client fallback when a "connection fails". We've 
> also seen clients falling back based on 5xx responses. Calling that out 
> more explicitly might help.
> 
> Cheers
> Lucas
> 
> >