Original text:
particular, this can avoid (re-)sending data that relies on a previous transmission that was never received.  Allowing applications to interact with messages is backwards- compatible with existings protocols and APIs, as it does not change the wire format of any protocol.  Instead, it gives the protocol Properties (datatransfer).  Message Properties can also be specified during data transfer to affect specific Messages. <del> Connection: A Connection object represents an active transport protocol instance that can send and/or receive Messages between local and remote systems.  It holds state pertaining to the underlying transport protocol instance and any ongoing data transfer.  This represents, for example, an active connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP. </del>  Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding

Reviewer comments:
This updates the definition of a TAPS connection to allow a TAPS implementation to do connection pooling and multi-streaming. It removes the limitation from a TAPS connection to relate to exactly one underlying transport connection and hints that underlying transport connections my be created automatically. This is one result of the discussion around PR .
All comments should be addressed – ready for merge
Thanks for the changes! LGTM.
That seems OK, can we fix: / It can also represent a pool of transport protocol instance/ to be /instances/ or whatever the plural is of a transport protocol instance? Gorry
The arch definition of connection should add a sentence to say that there may be multiple flows (MPTCP, MPQUIC, or even connection pooling) below the abstraction. This was assumed but not stated.
May be fixed by PR
Solved by
LGTM modulo the small fixes pointed out by NAME

Revised text:
particular, this can avoid (re-)sending data that relies on a previous transmission that was never received. <ins> the ability to automatically assign messages and connections to underlaying transport connections to utilize multi-streaming and pooled connections. </ins> Allowing applications to interact with messages is backwards- compatible with existings protocols and APIs, as it does not change the wire format of any protocol.  Instead, it gives the protocol Properties (datatransfer).  Message Properties can also be specified during data transfer to affect specific Messages.  <ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between local and remote systems.  It holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  This represents, for example, an active connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP.  It can also represent a pool of transport protocol instance, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance. </ins> Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding