> My concern is that a sender can send some amount of data, then decide to > reliably deliver only a prefix of that data. This allows that to happen > with no signals to a receiving application that might indicate something > different than a complete delivery of the stream. But the receiving > application has somewhere between the cutoff point and the complete stream > on hand. The receiving application will be ignorant of these two offsets. >
If an application chooses to do this, of course it has to expect the receiver reading different amounts of data from the stream. This is exactly the same as the "errorful" case, except there's no error code. An implementation could also choose to convey all the information about the received CLOSE_STREAM frame as part of its API. All of this happens when the stack is upgraded, not due to a deliberate > choice on the part of the application. Hence, my choice of the word > "truncation". Hence, my preference for applications to opt in to this by > allocating an error code for the purpose (or status code, if you will). > I'm still not clear on how this would happen transparently to an application. I would imagine it would only be used by application protocol specifications that require the functionality. It's not as if an existing QUIC application specification will expect the QUIC implementation to start sending CLOSE_STREAM's without error codes automatically if the peer supports the extension, just like it would not expect the QUIC implementation to start automatically sending CLOSE_STREAMs with errors without a new application specification -- how would it even know to send them without application cooperation?
