Change:
If I understood this right: URL URL if this is even a reasonable source ... then what this attack does, is to take the TCP connection away underneath the application's feet. Then, an application may still expect parts of a message but they may in fact never arrive because the Connection is in fact gone. Doesn't this mean that this exploits a detachment between TCP and a protocol atop TCP, which doesn't inform the application of the arrival of a FIN? In this case, I don't understand the concern raised by NAME in : the delivery of "outstanding partial messages" means that the receiver has them in the buffer, and then a FIN arrives - upon reception of the FIN, these "outstanding partial messages" should be delivered. That seems right to me. I may easily be completely off track! But either way, NAME also noted in that the attack should be described, so I don't think that this PR satisfies the issue as it stands.
A contrived example of the problem is if you intend to execute "rm -rf /some/path" and it somehow gets truncated to "rm -rf /". Protocols need to be designed in such a way that they deal properly with partial messages. I think the proposed text is fine.
Aha! That's completely different than my reading of the Wikipedia page. Then that's fine, I also agree.
My 2c: You can always design bad apps: I don't think transports should be designed to do application data checks... applications should do that on the data they send.
The new text seems to say what it should, although I don't see what this is an "attack", it would happen naturally when communications breaks.
Maybe we should discuss this. I see the need for something here as twofold: Warn users that they should not ignore the API-enabled distinction between full and partial messages. Make sure implementors properly classify partial messages as partial, so truncated messages (whether resulting from an attack or not) are presented to the application in a way that it can respond appropriately. Specifically because TAPS provides message and layer abstractions (for security and framing), it's imperative that the implementor of each stage of the pipeline preserve the partial/full message distinction because unlike applications built on top of TCP sockets the application author may not have the ability to detect a partial message because windowing/framing at the lower layers aren't exposed to the application. Based on this conversation, it sounds like we do need the text to make this a bit clearer.
I think this is useful to keep in. Security considerations are always good to point out. Happy to take suggestions for clarity.
Under the doc says: Emphasis mine. This is a key enabler of truncation attacks, so the interface should only do this if the application is well aware of the implications of receiving partial messages and/or if the partial nature of the message is made clear to the application.
Perhaps would also need to spell-out what constitutes a truncation attack?
Should go into API security considerations to tell apps to be careful to not assume that when a connection closes that their received data was complete and/or well-formed.
This LGTMLGMT with NAME additions

Discussion:
path fails and fallback or re-establishment is supported in the Transport Services system. <ins> Applications should also take care to not assume that all data received using the Transport Services API is always complete or well- formed.  Specifically, messages that are received partially receive- partial could be a source of truncation attacks if applications do not distinguish between partial messages and complete messages. </ins> The interface explicitly does not require the application to resolve names, though there is a tradeoff between early and late binding of addresses to names.  Early binding allows the API implementation to