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

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Nov 2020 09:36:54 +1100

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 4 Nov 2020 23:09:19 +0000

Hi Chairs,

On Wed, 4 Nov 2020, 22:38 Mark Nottingham, <[email-masked]> wrote:

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

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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 05 Nov 2020 12:26:55 +1100

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:
> There seems to be only one errata. It's in the origin spec and is a 
> very minor editorial thing.
> 
> 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
> 
> >

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 5 Nov 2020 10:19:13 +0100 (CET)

On Thu, 5 Nov 2020, Mark Nottingham wrote:

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

For Alt-Svc, there's this little issue I've run into when playing with it for 
HTTP/3. Not sure what to do about it, but it feels like a good time to mention 
it as it is rather annoying.

Alt-Used (RFC 7838 section 5) is a request header that only sends host name + 
port number, with no hint if that port number is TCP or UDP (or ALPN name), 
which makes at least one large HTTP/3 deployment trigger its Alt-Svc loop 
detection when only swithing protocols to h3.

IOW: If we get an Alt-Svc back that says try h3 on the same host on the same 
port that we just did h1 or h2 against.

It also makes me wonder if other clients are actually not using this header or 
how have you avoided this issue?

-- 

  / daniel.haxx.se

---

From: Mike Bishop <[email-masked]>
Date: Thu, 5 Nov 2020 19:57:37 +0000

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 <[email-masked]>
Sent: Wednesday, November 4, 2020 5:37 PM
To: HTTP Working Group <[email-masked]>
Cc: Tommy Pauly <[email-masked]>
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:

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.

Cheers,

Mark and Tommy

---

From: Erik Nygren <[email-masked]>
Date: Thu, 5 Nov 2020 19:10:52 -0500

As we've been doing HTTPS/SVCB, I've also been collecting a set of notes
for things we may want in AltSvc bis and/or tre.

Besides what has been mentioned above (HTTP/3 bindings and errata), below
are my notes I've been collecting and had been meaning to start a dialog
on...

For AltSvc-bis I'd suggest we consider:

* Fix the ALPN handling issues that David Benjamin identified.
  In particular, there are some problematic (and arguably ambiguous
semantics)
  about how to handle ALPN negotiation when an alpn presented in the AltSvc
  isn't what was negotiated during the TLS connection negotiation.
  One option would be to pull in the text we landed on for the HTTPS/SVCB
draft.
  See 6.1:
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-6.1
  (We'd opened https://github.com/MikeBishop/dns-alt-svc/issues/246 to
track.)

On the border between AltSvc-bis/tris (and could go either way):

* Improved interaction with the HTTPS/SVCB record (in-terms of which
  takes precedence and if there are safe time-bounded ways to allow
  Alt-Svc to take precedence over HTTPS records).  Either including
  a definition for echconfig or allowing an AltSvc alternative server name
  to be treated as an "AliasMode" reference to an HTTPS record might also
  be worth considering.

* Replace/fix Alt-Used.  What is there now isn't sent by a number
  of clients due to (mostly privacy?) concerns and as Daniel mentions
  above it has limitations and issues.  Ideally whatever this is would
  also work across HTTPS/SVCB and Alt-Svc in a consistent manner.
  We deferred this for HTTPS/SVCB (for a future draft)
  and there is some discussion
  in https://github.com/MikeBishop/dns-alt-svc/issues/107

Solidly for AltSvc-tris (unless we are willing to expand scope of bis):

* Provide for an Alt-Svc V2 that can be used for a number
  of media/streaming/downloads use-cases.  This has come up
  on this list a number of times.  I think this consists of:
  1) A way for Alt-Svc entries to apply to just paths/sub-origins.
    (eg, path="/episodes/ExampleShow-Season1Episode2/")
  2) A way to indicate support  (eg, an Accept-* header or a SETTING)
  3) A way to force a synchronous behavior where clients follow that
    Alt-Svc entry immediately.  (eg, a new 3xx response code that
    relies on the client having indicated support via #2.)
  4) This almost certainly wants some of the items listed above
    addressed as well (Alt-Used, HTTPS/SVCB interactions, etc).

Best, Erik

On Thu, Nov 5, 2020 at 2:57 PM Mike Bishop <[email-masked]> wrote:

> of