Re: [quicwg/base-drafts] Define terms for application actions (#2857)

MikkelFJ <> Wed, 23 October 2019 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA41F12012D for <>; Wed, 23 Oct 2019 13:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wNaH1c4u_p0r for <>; Wed, 23 Oct 2019 13:02:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C769A120129 for <>; Wed, 23 Oct 2019 13:02:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 318105204D6 for <>; Wed, 23 Oct 2019 13:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571860942; bh=CCiZvCCI0ZMjpPLx/GgrC64uQ0yV+85DYkHdJn141yQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M4UgLleCV071OXcJTWA4KXHlNkG/yYJPjW35zZvCECOTO62ieO5h3KvP7OZGkLTxX nHOp0SN0hE1Tkpc6CtkXub08TcrKwH6HCOIbPicPCDMBGlQosYqRewvmy113uTxfxK 28QgeIfELM0yhkU3PSZIIIarDxROgo3UtB5TZ1KY=
Date: Wed, 23 Oct 2019 13:02:22 -0700
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2857/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Define terms for application actions (#2857)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db0b1ce22c4f_30693fe0726cd9683678c"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Oct 2019 20:02:25 -0000

mikkelfj commented on this pull request.

> +
+- listen for incoming connections, which prepares for the exchange described in
+  {{handshake}};
+- if Early Data is supported, embed application-controlled data in the TLS
+  resumption ticket sent to the client; and
+- if Early Data is supported, retrieve application-controlled data from the
+  client's resumption ticket and enable rejecting Early Data based on that
+  information.
+In either role, applications need to be able to:
+- configure minimum values for the initial number of permitted streams of each
+  type, as communicated in the transport parameters ({{transport-parameters}});
+- control resource allocation of various types, including flow control and the
+  number of permitted streams of each type;
+- identify whether the handshake has completed successfully or is still ongoing

I'm not objecting to this term being defined, but I do suspect there is an issue if the now infamous PR #3121 gets merged. But, as it hasn't yet, and there is pushback, I'll see where it goes. Defining exactly what is, or might be, wrong requires a deep analysis because one peer can consider a handshake complete without the other peer agreeing, and sometimes that might be fine while in other cases not so much, like path migration.

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