Change:
depending on the protocol being used.  For example, sending and receiving streams of data is conceptually the same for both an unencrypted Transmission Control Protocol (TCP) stream and operating <del> on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13 stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del> <ins> on an encrypted Transport Layer Security (TLS) RFC8446 stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of transport protocols varies based on the context of the protocols themselves: terms such as "flow", "stream", "message", and "connection" can take on many different meanings. This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As

Discussion:
Alternate proposal to address (old PR was "Add CacheContext to architecture and API", ) Define explicit Connection Groups as a way to define caching boundaries Update TLS 1.3 references to RFC 8446
This is a light-weight approach, but seems a little heavy-handed. I thought connection groups were a tool to model multi-streaming. With this PR, they become a fuzzy thing between cache context and multi-streaming abstraction. This may be the better choice, but ist definitely an Architecture decision. I liked the cache original context more.
The result of the interim discussion was that we didn't like a separate cache context object as much. Based on the discussion, we need some abstraction to say "these connections don't share state with the rest of the connections in my process, and can share between one another". The Group is a convenient way to do this. Note that you can just have one connection in its own group even. In some ways, it solves a lot of problems—it isn't sensical to say that connections in a Group can not share cache state. It I multiplex, I'm by default sharing TLS state. So if we have a separate cache context, we'll need some prohibition that you can't have multiple connections in a group have different cache contexts. Using the group as the way to define the boundary solves this.
I agree that it solves a lot of Problems and is an easy-to-use solution. The more I think about it, the more I like it. If we agree that we want to go down this road, definitely a +1 from my side modulo NAME comments. Still, if we land this one, we need to add some means of manually managing connection groups to the API in the next round.
NAME please re-review!
NAME I updated the text to avoid the implication about cloning. I didn't intend to change the behavior for Clone() being required to get multiplexing. I was more thinking that the use of the cache could be managed implicitly, while still requiring calling Clone() to actually multiplex. But, for now, I removed the text about implicit groups. Please check that this resolves your concerns!
Thanks for the reviews and input!
share NAME concerns, approving so we can submit a draft to discuss in prague...Looks good to me!LGTM! Thanks for the fixThanks – Looks good to me!