Change:
API mappings for SCTP are as follows: <del> Connection objects represent a flow of SCTP messages between a client and a server, which may be an SCTP association or a stream in a SCTP association.  How to map Connection objects to streams is described in NEAT-flow-mapping; in the following, a similar method is described.  To map Connection objects to SCTP streams without head-of-line blocking on the sender side, both the sending and receiving SCTP implementation must support message interleaving RFC8260.  Both SCTP implementations must also support stream reconfiguration.  Finally, both communicating endpoints must be aware of this intended multiplexing; NEAT-flow-mapping describes a way for a Transport System to negotiate the stream mapping capability using SCTP's adaptation layer indication, such that this functionality would only take effect if both ends sides are aware of it.  The first flow, for which the SCTP association has been created, will always use stream id zero.  All additional flows are assigned to unused stream ids in growing order.  To avoid a conflict when both endpoints map new flows simultaneously, the peer which initiated the transport connection will use even stream numbers whereas the remote side will map its flows to odd stream numbers.  Both sides maintain a status map of the assigned stream numbers.  Generally, new streams must consume the lowest available (even or odd, depending on the side) stream number; this rule is relevant when lower numbers become available because Connection objects associated to the streams are closed. </del> <ins> Connection objects can be mapped to an SCTP association or a stream in an SCTP association.  Mapping Connection objects to SCTP streams is called "stream mapping" and has additional requirements as follows.  The following explanation assumes a client-server communication model. Stream mapping requires an association to already be in place between the client and the server, and it requires the server to understand that a new incoming stream should be represented as a new Connection Object by the Transport Services system.  A new SCTP stream is created by sending an SCTP message with a new stream id.  Thus, to implement stream mapping, the Transport Services system MUST provide a newly created Connection Object to the application upon the reception of such a message.  The necessary semantics to implement a Transport Services system's Close and Abort primitives are provided by the stream reconfiguration (reset) procedure described in RFC6525. This also allows to re-use a stream id after resetting ("closing") the stream.  To implement this functionality, SCTP stream reconfiguration RFC6525 MUST be supported by both the client and the server side. To avoid head-of-line blocking, stream mapping SHOULD only be implemented when both sides support message interleaving RFC8260. This allows a sender to schedule transmissions between multiple streams without risking that transmission of a large message on one stream might block transmissions on other streams for a long time. To avoid conflicts between stream ids, the following procedure is recommended: the first Connection, for which the SCTP association has been created, MUST always use stream id zero.  All additional Connections are assigned to unused stream ids in growing order.  To avoid a conflict when both endpoints map new Connections simultaneously, the peer which initiated association MUST use even stream ids whereas the remote side MUST map its Connections to odd stream ids.  Both sides maintain a status map of the assigned stream ids.  Generally, new streams SHOULD consume the lowest available (even or odd, depending on the side) stream id; this rule is relevant when lower ids become available because Connection objects associated with the streams are closed. SCTP stream mapping as described here has been implemented in a research prototype; a desription of this implementation is given in NEAT-flow-mapping. </ins> If this is the only Connection object that is assigned to the SCTP <del> association or stream mapping has not been negotiated, CONNECT.SCTP is called.  Else, unless the Selection Property "activeReadBeforeSend" is Preferred or Required, a new stream is used: if there are enough streams available, "Initiate" is just a local operation that assigns a new stream number to the Connection object.  The number of streams is negotiated as a parameter of the prior CONNECT.SCTP call, and it represents a trade-off between local resource usage and the number of Connection objects that can be mapped without requiring a reconfiguration signal.  When running out of streams, ADD_STREAM.SCTP must be called. </del> <ins> association or stream mapping is not used, CONNECT.SCTP is called. Else, unless the Selection Property "activeReadBeforeSend" is Preferred or Required, a new stream is used: if there are enough streams available, "Initiate" is just a local operation that assigns a new stream id to the Connection object.  The number of streams is negotiated as a parameter of the prior CONNECT.SCTP call, and it represents a trade-off between local resource usage and the number of Connection objects that can be mapped without requiring a reconfiguration signal.  When running out of streams, ADD_STREAM.SCTP must be called. </ins> If this is the only Connection object that is assigned to the SCTP <del> association or stream mapping has not been negotiated, CONNECT.SCTP is called with the "user message" parameter.  Else, a new stream is used (see "Initiate" for how to handle running out of streams), and this just sends the first message on a new stream. </del> <ins> association or stream mapping is not used, CONNECT.SCTP is called with the "user message" parameter.  Else, a new stream is used (see "Initiate" for how to handle running out of streams), and this just sends the first message on a new stream. </ins> "Initiate" or "InitiateWithSend" returns without an error, i.e. SCTP's four-way handshake has completed.  If an association with <del> the peer already exists, and stream mapping has been negotiated and enough streams are available, a Connection Object instantly becomes Ready after calling "Initiate" or "InitiateWithSend". </del> <ins> the peer already exists, stream mapping is used and enough streams are available, a Connection Object instantly becomes Ready after calling "Initiate" or "InitiateWithSend". </ins> Failure of CONNECT.SCTP. TIMEOUT.SCTP or ABORT-EVENT.SCTP. LISTEN.SCTP.  If an association with the peer already exists and <del> stream mapping has been negotiated, "Listen" just expects to receive a new message on a new stream id (chosen in accordance with the stream number assignment procedure described above). </del> <ins> stream mapping is used, "Listen" just expects to receive a new message with a new stream id (chosen in accordance with the stream id assignment procedure described above). </ins> LISTEN.SCTP returns without an error (a result of successful CONNECT.SCTP from the peer), or, in case of stream mapping, the

Discussion:
This is a manual re-application of all the changes to -impl in PR . (Other methods didn't easily work because the master has changed quite a bit during discussion of PR ; at least I found no easy way).
Sec 10.6 of taps-impl is pretty confusing: .. there's yet more. Maybe I should read NEAT-flow-mapping, or remind myself about the details of SCTP, but I think the third sentence (To map Connection Objects...) is not well-constructed. There are three conditions here: both SCTPs must: support 8260,support stream reconfiguration, ANDknow what's going on. But what do these conditions enable? Is it mapping connections to streams at all? Is it mapping them without HOL blocking (i.e., if not met, I still can map but there is HOL blocking)? Something else?
Guilty as charged! I wrote this and I can fix it. Meanwhile, I'll explain: 8260 => to reduce HOL blocking delay. stream reconfiguration => to save memory and be able to re-use stream numbers, and to realize the role of a FIN (stream reset = FIN) know what's going on => yes, but this is an application requirement ... the applications on both sides must be able to handle this. E.g., a server written over a TAPS system could just listen on all protocols, including streams, and get whatever kind of Connection (including, possibly, one that's really only a stream) - and then answer on it (I actually tested exactly this with NEATPy). This server can handle this easily. Another server could be a native TCP server, certainly not expecting SCTP, let alone Connections riding on streams - this server could not handle this. The client application, when connecting, must know what it's doing. I can make a PR to explain these matters in the text.