Lines Matching refs:to
15 and that were specific to QUIC
22 a pluggable record layer interface to be implemented to enable this to be less
23 intrusive, more maintainable, and to harmonize the existing record layer
28 * The application must have the ability to be in control of the event loop without
29 requiring callbacks to process the various events. An application must also have
30 the ability to operate in “blocking” mode.
33 The fully functional release will provide the ability to plug in more
43 be able to use OpenSSL to build an HTTP/3 client on top of OpenSSL for the
47 it should be possible for external libraries to be able to use the pluggable
50 * The next major release number is intended to be reserved for the fully
51 functional QUIC release (this does not imply we expect API breakage to occur as
58 * We do not plan to place protocol versions themselves in separate providers at
69 In addition to the QUIC requirements, the OMC also required that:
71 * The objective is to have shorter release timeframes, with releases occurring
86 * The objective is to have APIs that allow applications to support any of our
87 existing (or future) security protocols and to select between them with minimal
91 treated separately by our APIs. In the context of QUIC, APIs to be able to
93 objective of being able to select which security protocol is used, APIs that
94 encompass that capability for all protocols will need to be added.
98 usage needs to remain simple.
100 * We need to enable the majority of our existing user’s applications to be able
101 to work in a QUIC environment while expanding our APIs to enable future
102 application usage to support the full capabilities of QUIC.
105 (outside of OpenSSL) to be able to use the TLS stack within OpenSSL – however
111 * Make it easy for our users to communicate securely, flexibly and performantly
114 * We will provide unified, consistent APIs to our users that work for all types
115 of applications ranging from simple single stream clients up to optimised high
123 There are different types of application that we need to cater for:
126 interactions. We want to be able to enable them to transfer to using single
130 interactions. We want to be able to enable them to transfer to using single
131 stream QUIC easily. More likely to want to do multi-stream.
134 APIs; using custom network interaction BIOs in order to get the best performance
136 using fibres). Would prefer to use the existing APIs - they don’t want to throw
137 away what they’ve got. Where QUIC necessitates a change they would be willing to
140 * New applications. Would be willing to use new APIs to achieve their goals.
150 applications should be able to pick whatever protocol they want to use
152 * It shouldn’t be harder to do single stream just because multi stream as a
155 * It shouldn’t be harder to do TLS just because you have the ability to do DTLS
164 * The internal architecture should allow for the fact that we may want to
168 received via QUIC to only be copied from one buffer to another once. The
169 "single" copy allowed is to allow for the implicit copy in an encrypt or decrypt
173 data to be sent. No copies of that data are made until it is encrypted. Once
175 to the kernel for sending via a system call.
180 available to (or supplied by) the application with no further internal copies
186 This section summarises those requirements from the above that are specific to
201 interactions. We want to be able to enable them to transfer to using single
