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

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 <mbishop@evequefou.be> wrote:

> 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 <mnot@mnot.net>
> Sent: Wednesday, November 4, 2020 5:37 PM
> To: HTTP Working Group <ietf-http-wg@w3.org>
> Cc: Tommy Pauly <tpauly@apple.com>
> 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
>