[quicwg/base-drafts] Rationalize terminology around transport/application interactions (#2805)

Mike Bishop <notifications@github.com> Tue, 18 June 2019 23:06 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 C0BF81202BE for <quic-issues@ietfa.amsl.com>; Tue, 18 Jun 2019 16:06:42 -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_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 ttEE5XiQ6r-4 for <quic-issues@ietfa.amsl.com>; Tue, 18 Jun 2019 16:06:40 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.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 C105A1202A7 for <quic-issues@ietf.org>; Tue, 18 Jun 2019 16:06:40 -0700 (PDT)
Date: Tue, 18 Jun 2019 16:06:39 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560899199; bh=Pz9aozmalSRX0Zcbq4eaGGTaWOcDBquokaGpbcJCA+g=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=HZfSuBNOIYU6IkJWb0lWOGSV1cExn3+DUcGpnytVd5JOT3XhumxFemct9MjFjbqSF 1AdO+AqadSV0+x18JbmESTKPd2eZIyrLO4Y1+d14eI2NOZFYY6ZtEAAoRwspOGiYzO iByBVK3dWLWY8Yv4oa5QQinBOtpJw8A7DF9cJ3fo=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK74KR34LXQZXLVUQBV3C2QP7EVBNHHBWSDWSM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2805@github.com>
Subject: [quicwg/base-drafts] Rationalize terminology around transport/application interactions (#2805)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d096e7fa9da5_18fb3fe7beecd96c10344f"; 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/KHXu7rVMMwCKQCHw7AiC5EumTqs>
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: Tue, 18 Jun 2019 23:06:43 -0000

Define terms for the operations which an application can cause a transport to take, and for the events of which the application can be notified by the transport. This should close #2677, in the process.  This issue should:

- Eliminate the term "trigger" when talking about QUIC frames
- Try not to mention specific QUIC frames at all
- Remove "send a QUIC RESET_STREAM" from 7.2.4
- Remove "sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY send the error code HTTP_REQUEST_REJECTED in the corresponding RESET_STREAM" from 4.1.2
- Reword references to sending values in particular transport parameters

I believe those essential functions are:

- On the connection:
   - Open a connection, specifying certain properties that translate to transport parameters
   - Receive incoming connections, which will possess certain properties based on the peer's transport parameters
   - Participate in deciding whether to accept 0-RTT based on embedded data
   - Provide data to be embedded in resumption tokens
   - Cooperate to control keep-alive, either by sending PINGs directly or by telling the transport that the connection can't be allowed to time out
   - Immediate close
- On the stream:
   - Read data
   - Write data, understanding at what point flow control credit has been committed
   - Close the sending part
   - Request closure of the receiving part

The events we depend on are connection closure and stream closure.

This is largely editorial, since it's mostly defining terminology, but we'll also likely be mandating that QUIC stacks expose these features, so that's normative/design.  (Obviously the 0-RTT ones will be "if implemented" requirements.)

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