IETF Logo Mail Archive

[QUIC] h2 mapping - extensions

Patrick McManus <pmcmanus@mozilla.com> Thu, 03 November 2016 21:39 UTC

Return-Path: <pmcmanus@mozilla.com>
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 182BC129AD9 for <quic@ietfa.amsl.com>; Thu, 3 Nov 2016 14:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.735
X-Spam-Level:
X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 2E-VeYmnVm55 for <quic@ietfa.amsl.com>; Thu, 3 Nov 2016 14:39:57 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id CE940129980 for <quic@ietf.org>; Thu, 3 Nov 2016 14:39:57 -0700 (PDT)
Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6DE943A015 for <quic@ietf.org>; Thu, 3 Nov 2016 17:39:57 -0400 (EDT)
Received: by mail-oi0-f46.google.com with SMTP id v84so112900490oie.3 for <quic@ietf.org>; Thu, 03 Nov 2016 14:39:57 -0700 (PDT)
X-Gm-Message-State: ABUngvfOjzp9zgMzi8cfNRK5hdslNAZo4A3vtYbYelzIGIePuyuWyZtRbY4B6qIo00JWBxVP7EKu22IL229rmg==
X-Received: by 10.107.57.135 with SMTP id g129mr2772288ioa.178.1478209197054; Thu, 03 Nov 2016 14:39:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.228.236 with HTTP; Thu, 3 Nov 2016 14:39:56 -0700 (PDT)
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 03 Nov 2016 17:39:56 -0400
X-Gmail-Original-Message-ID: <CAOdDvNpGf7bcwt3Nyqk0_HPPSoXE-w8ZeYEdo4c76vpuXku0mg@mail.gmail.com>
Message-ID: <CAOdDvNpGf7bcwt3Nyqk0_HPPSoXE-w8ZeYEdo4c76vpuXku0mg@mail.gmail.com>
To: quic@ietf.org
Content-Type: multipart/alternative; boundary="001a114ac3e218237c05406c6649"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/q3DzfYTDLXRDrCLekwNPiMlcvWc>
Subject: [QUIC] h2 mapping - extensions
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <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: Thu, 03 Nov 2016 21:39:59 -0000

Hi Robbie, Mike, et al. Thanks for getting the ball rolling with
https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00..

What is the thinking about rfc 7540 h2 extensions and the h2/quic mapping..
particularly the way it allows unspecified frame types which may or may not
require negotiation.

it seems some of these extensions may have stateful issues across streams,
ala hpack and some may not.

If the extension were only defined for h2-over-quic that would be for the
extension to sort out.. but it doesn't seem like we are limiting things to
quic vs tcp, or are we?

-Patrick

v2.23.0 | Report a Bug | By Email