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

[Lucas Pardue <[e-mail]>]

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


>