On Wed, Jul 5, 2023 at 1:05 AM Martin Thomson <[email protected]> wrote:
> On Wed, Jul 5, 2023, at 08:15, Matt Joras wrote: > > I'm not sure I understand the concern here > > 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. > > 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). > Yeah I agree about truncation risks. There's variation in how applications will interface with their stack of choice and transform or present this up through their own APIs. Making the new thing conspicuous can go some way to helping avoid weird edge cases that might hurt. We've already seen a bit of this with abstraction layers over H2 and H3 that needs to smooth over the differences related to STOP_SENDING, with varying success. This seems to add another variant to the problem. Cheers Lucas
