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

[MikkelFJ <[e-mail]>]

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:
https://github.com/quicwg/base-drafts/pull/2857#discussion_r338250329