Code change:
QUIC, and applications ought not to use private keys intended for server authentication as keys for client authentication. <del> Moreover, Transport Services systems MUST NOT automatically fall back </del> <ins> Moreover, Transport Services systems must not automatically fall back </ins> from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </del> <ins> secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired.  Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </ins>

Related discussion:
text: This proposal consolidates normative language into the section on design principles (now requirements), using the suggestions in .
Please review the latest updates!
Early art-art review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is a warning-sign that the interface document is a normative reference for the architecture document. As the documents are currently constructed, a new reader cannot grasp the architecture without inferring some of it through reading the interface. Consider reformulating the architecture document as an overview - introduce principles, concepts, and terminology, but don't attempt to be normative. (There are signs that this may already be, or have been, a path the document was being pushed towards). If nothing else, rename it, and acknowledge that the actual architecture is specified using the interface definition. Note that the first sentence of the Overview in the interface document also highlights the current structural problem.
I don't entirely agree with this ART-ART comment: I think I might well agree with moving more of the description to this Arch document, but as discussed before, I also think it useful here to set the actual requirements for the architecture, and to define the architecture. It may need to be much clearer that this architecture consists of more the API.
For completeness, this is the first statement of the interface document review: This document reads fairly well. I have some structural concerns (see the early review of the architecture document). In particular I think this document contains the actual definition of the architecture and some of that is inferential.
Discussion at September 2021 interim: pass through this document with a view toward making it a high level introduction, not an architecture definition: "An Introduction to the Transport Services Architecture". remove normative language from this document (moving it to API, where necessary). move details not useful in a high level intro to API.
I disagree with this conclusion at first pass—we did a specific analysis and pass on this over a year ago, with PR . The normative language and the standards-track aspect was very intentional and something the WG had consensus on. The point is that the API is a specific incarnation of the TAPS architecture, but there are overarching architectural properties that go beyond a specific abstract API.
I completely agree with Tommy here, and recommend we fix this in . We should also of course check for any stray text or missing concepts.