[quicwg/base-drafts] Changing protocol elements: Is this text strong enough? (#2985)

Mike Bishop <notifications@github.com> Thu, 22 August 2019 15:18 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 8DF621208C6 for <quic-issues@ietfa.amsl.com>; Thu, 22 Aug 2019 08:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_HELO_NONE=0.001, SPF_PASS=-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 kQnJGoBpVyC0 for <quic-issues@ietfa.amsl.com>; Thu, 22 Aug 2019 08:18:14 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.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 58257120152 for <quic-issues@ietf.org>; Thu, 22 Aug 2019 08:18:14 -0700 (PDT)
Date: Thu, 22 Aug 2019 08:18:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1566487093; bh=Xxgw2YqgRblfPe5AxhHa/1X+wZy6GGsMzDg6oxXjfxo=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Ks+XO4gaH30AhpPCM1zYO9Fzq+JbX2jCnH3Kk7Nvi0bePUltjUTUsSawqKkMbG32N 4itY08zNHXDMxxsw9lwiCz6ln+ZjugGhJ8rzL/XGSjP6/FQvzYGqbt+W+xajp6p3gI 0dbCJdK6FDb5sFkvvr/GYU7ZMAZMbwGIGOJvzrAQ=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYPSP4734WCRFLPUU53NPSLLEVBNHHBZWRADI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2985@github.com>
Subject: [quicwg/base-drafts] Changing protocol elements: Is this text strong enough? (#2985)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d5eb2356ecd4_56203fb2d4acd96c1117264"; 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/ON93fPuxj7FqB6dljcXznzDp0ao>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 22 Aug 2019 15:18:17 -0000

> Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. **In this case, it could also be necessary to coordinate when the revised layout comes into effect.**

Unlike HTTP/2, HTTP/3 has no indication when the peer has received and processed SETTINGS.  This means that any extension which redefines a basic protocol element (e.g. HEADERS uses something other than QPACK or uses a different static table; PRIORITY frames should be interpreted differently) has to define its own coordination mechanism -- and that coordination mechanism will be unwieldy (see #84).

#2958 would give the necessary ordering for server settings -- they are effective for all server data -- but would only make sense if one side considered the other's SETTINGS prior to sending its own.  The server cannot do this in the current scheme or in #2958 for 1-RTT connections.

Should we simply remove the misleading suggestions that elements of the mapping can be redefined, pointing people instead to creating replacement frames (HEADERS2, PRIORITYEX, etc.)?  Or is the verbiage here that you're on your own to coordinate that switch sufficient hard-hat warning?

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