Re: [QUIC] draft-shade-quic-http2-mapping comments

Mark Nottingham <mnot@mnot.net> Fri, 22 July 2016 14:40 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289B012D5CE for <quic@ietfa.amsl.com>; Fri, 22 Jul 2016 07:40:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ieAAkH6Vqq8h for <quic@ietfa.amsl.com>; Fri, 22 Jul 2016 07:40:17 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 85A2012DB08 for <quic@ietf.org>; Fri, 22 Jul 2016 07:40:17 -0700 (PDT)
Received: from dhcp-b2b0.meeting.ietf.org (unknown [31.133.178.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 01DC422E256; Fri, 22 Jul 2016 10:40:09 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <d8af823c-0877-8c65-347f-edc3966fc3dd@greenbytes.de>
Date: Fri, 22 Jul 2016 16:40:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C259459-718A-46BD-B78D-F4FAFFA35AA4@mnot.net>
References: <CAGD1bZYWgZDkXhsdSVz9k47DiPjiW+TJomfZ9A1yeA6mAEzZ1g@mail.gmail.com> <d8af823c-0877-8c65-347f-edc3966fc3dd@greenbytes.de>
To: "Julian F. Reschke" <julian.reschke@greenbytes.de>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/E4Dfkn7j4gf8Akdrvrsyg6IJ4XU>
Cc: Jana Iyengar <jri@google.com>, quic@ietf.org
Subject: Re: [QUIC] draft-shade-quic-http2-mapping comments
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list to discuss QUIC standardization <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2016 14:40:20 -0000

> On 22 Jul 2016, at 2:54 PM, Julian Reschke <julian.reschke@greenbytes.de> wrote:
> 
> Hi there,
> 
> thanks for splitting the documents. Here are some early comments on draft-shade-quic-http2-mapping.
> 
> At some point we'll need to decide what HTTP/2-over-Quic is. Is it just a mapping to a different mapping to a different transport, or is it the next major revision of HTTP, thus essentially HTTP/3.
> 
> I'm asking because these seem to be conflicting goals, and it would be good to clarify that as soon as possible. That said:
> 
> The slides showed in the IETF Berlin Bof session specifically mentioned that a client success rate of 93% might be good enough (or close to that), as we can always fall back to HTTP/2-over-TLS. I do not disagree with that, but it essentially means that the client-visible semantics MUST be the same as for HTTP/2 (in particular as HTTP/2 over TLS in theory could fall back to HTTP/1.1 over TLS). The impact of this might be different for a browser such as Chrome compare to other users of HTTP.

To be more explicit -- this turned out to be a sticky point in the HTTP/2 work; because we were chartered to be suitable for all common uses of HTTP, we needed to support it for both HTTP and HTTPS URLs, to the disappointment of those who felt that the new protocol was only suitable for HTTPS.

A fair amount of confusion / wrangling could be saved by some thoughtful chartering here, I suspect...

By the way, I wouldn't say "fall back to HTTP/1" -- it's more "fail to upgrade to HTTP/2."

Cheers,

--
Mark Nottingham   https://www.mnot.net/