[quicwg/base-drafts] Indicate support for optional protocol chunks. (#1600)

Mike Bishop <notifications@github.com> Tue, 24 July 2018 17:51 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1AA91130E80 for <quic-issues@ietfa.amsl.com>; Tue, 24 Jul 2018 10:51:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Lgtj30XmI4IZ for <quic-issues@ietfa.amsl.com>; Tue, 24 Jul 2018 10:51:02 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31142130E20 for <quic-issues@ietf.org>; Tue, 24 Jul 2018 10:51:02 -0700 (PDT)
Date: Tue, 24 Jul 2018 10:51:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1532454661; bh=/WXZC6Cj2UXv/eo/YZ+lF08ByPnfBNHPEuvZEJIu58I=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=c8vN+7ImorpQ6I14lZEAuRE9Wa/FyYzEd9m6ZfUu6jOyzEf6+jMJHyJkQvl4iTqtI AcftgqXzyX8RZcYbEFAmfF1gSBASXpRAsXAcW5ZPl9K5BWQduqHLkI/BOw0FC6wFpt gjywGJeArmswAVWj8JC5HL1Q/Ev3keIGSyNzkbNE=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab269e7558a573ac88f4d18b1c43f1053e08f6444792cf00000001176f290592a169ce14832871@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1600@github.com>
Subject: [quicwg/base-drafts] Indicate support for optional protocol chunks. (#1600)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b57670557298_1a053fe7522d45b414969e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/LWIjSU0Mt2kODJKGst62X6e9Xf0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2018 17:51:05 -0000

Suggestion received in side conversation:  Enable the HTTP community to experiment with priority schemes and/or save bytes by defining settings indicating what priority schemes are supported.  Doc defines "none" and "this one", future extensions can define new ones.

This may or may not be necessary.  Any extension that defines a new priority scheme would presumably already define a setting to declare that it's supported, and the client will pick the one it likes best of what the server indicates support for.  Dealing with a client who combines frames from multiple priority schemes isn't something we need to define for HTTP/QUIC.  We could conceivably define a list format of priority scheme types, get a registry, etc. but that seems overkill when the SETTINGS space is large and the set of priority schemes likely to see much deployment is so small.

So this really boils down to a hint which permits a server to say "I don't support priority, so don't bother" or indicate that it really does support the current scheme.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: