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

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Jun 2019 16:06:39 -0700

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:
https://github.com/quicwg/base-drafts/issues/2805