Re: For discussion: scope for AltSvc and ORIGIN bis efforts
Erik Nygren <erik+ietf@nygren.org> Fri, 06 November 2020 00:13 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12003A093D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 5 Nov 2020 16:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.647
X-Spam-Level:
X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb5NqtbaSjUj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 5 Nov 2020 16:13:53 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DF83A08F6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 5 Nov 2020 16:13:52 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kapLc-00027L-UI for ietf-http-wg-dist@listhub.w3.org; Fri, 06 Nov 2020 00:11:20 +0000
Resent-Date: Fri, 06 Nov 2020 00:11:20 +0000
Resent-Message-Id: <E1kapLc-00027L-UI@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <nygren@gmail.com>) id 1kapLa-00026a-OB for ietf-http-wg@listhub.w3.org; Fri, 06 Nov 2020 00:11:18 +0000
Received: from mail-wr1-f52.google.com ([209.85.221.52]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <nygren@gmail.com>) id 1kapLX-0005io-Vc for ietf-http-wg@w3.org; Fri, 06 Nov 2020 00:11:18 +0000
Received: by mail-wr1-f52.google.com with SMTP id x7so3748514wrl.3 for <ietf-http-wg@w3.org>; Thu, 05 Nov 2020 16:11:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N1XEzAnoona7uEeD5p7ylHD+HWc3QxahG/7n+lUVj+4=; b=EQa7ZwWQg2cP7NzBcp1s03mTfPGg67uNB0cUGCGZe49N8JlUw8gl57zNBsqfSvN3N8 CESN5Ti+T3KXqgj5Kj5Q0Q/vOKECRogOm76JtqpQ1HJUzKPdbIFOthKhNFEHR7Px4M3h U21LVjDhq+PUuD3w77+fujEgoZzyJimgPigu6hvn0Q41TRSHTTlgHAE2YFvNeoOQ/iIF m01Tx0jGRIHMwZstOSc808hapL6MN+W9TrUf6YNu/lgaqEDrEB77NmESaSV5KDUjWcK+ vYq+TyTMGPbzVCr3TqOzzktXRFyfxXseHK2kSVRe6pxYCNYk2SFnsUDJIo6JnS/ClAhx 8T9A==
X-Gm-Message-State: AOAM533oMmgF1AyPfoTCPRzxYGZw1CfMxsrx2nw6kfrpMsVO0ud9GiGB pDLh/ZHZKW59PPfW6ilMuvpqXWZTcRv/1ZFqml4=
X-Google-Smtp-Source: ABdhPJzznSlBvNRHysWHzuor9VshwNpynIZ0PN+XSWCJAsu/ScNiLNzyWSlw2mbvKGtkblg7nlEqdHkwFCqNG7jHmR8=
X-Received: by 2002:adf:dc4c:: with SMTP id m12mr5778334wrj.177.1604621464276; Thu, 05 Nov 2020 16:11:04 -0800 (PST)
MIME-Version: 1.0
References: <BBA5F9B9-7788-41DA-853E-FADD7EF20B24@mnot.net> <CH2PR22MB2086E2536BF74C5DAF8B1D0FDAEE0@CH2PR22MB2086.namprd22.prod.outlook.com>
In-Reply-To: <CH2PR22MB2086E2536BF74C5DAF8B1D0FDAEE0@CH2PR22MB2086.namprd22.prod.outlook.com>
From: Erik Nygren <erik+ietf@nygren.org>
Date: Thu, 05 Nov 2020 19:10:52 -0500
Message-ID: <CAKC-DJjTCoh7RjgmAXzBkZZmw=JyvATnS-5mYDetaxA4go74Ag@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>, David Benjamin <davidben@google.com>
Content-Type: multipart/alternative; boundary="0000000000006091d505b3650c43"
Received-SPF: pass client-ip=209.85.221.52; envelope-from=nygren@gmail.com; helo=mail-wr1-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1kapLX-0005io-Vc 75d1746b2789d8d7d800bc2deb292c30
X-Original-To: ietf-http-wg@w3.org
Subject: Re: For discussion: scope for AltSvc and ORIGIN bis efforts
Archived-At: <https://www.w3.org/mid/CAKC-DJjTCoh7RjgmAXzBkZZmw=JyvATnS-5mYDetaxA4go74Ag@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38191
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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 >
- For discussion: scope for AltSvc and ORIGIN bis e… Mark Nottingham
- Re: For discussion: scope for AltSvc and ORIGIN b… Lucas Pardue
- Re: For discussion: scope for AltSvc and ORIGIN b… Martin Thomson
- Re: For discussion: scope for AltSvc and ORIGIN b… Daniel Stenberg
- RE: For discussion: scope for AltSvc and ORIGIN b… Mike Bishop
- Re: For discussion: scope for AltSvc and ORIGIN b… Erik Nygren