Applications might require that the Reliable Size not reduce

[martinthomson]

In Section 5.1, should this say something like:

While multiple RESET_STREAM_AT frames can reduce Reliable Size, some applications might need to ensure that a minimum amount of data is always delivered on a stream. Application protocols can establish rules for streams that ensure that Reliable Size is not reduced below a certain threshold if that is necessary to ensure correct operation of the protocol.

To explicitly signal this WebTransport, as it were.

[marten-seemann]

How would an application enforce this, without reaching deep down into the QUIC layer?

[martinthomson]

I'm not thinking about enforcement, just a "if you implement this protocol and you reset a stream (or a particular type of stream), you MUST use RESET_STREAM_AT and not set Reliable Size less than X". This would not be a requirement in this document, merely a suggestion that users of this document could say this sort of thing.

If you are looking for consequences, that's something the protocol would have to manage.

[marten-seemann]

Makes sense. I think we can apply your suggestion, although I believe that even if we don't, applications can still impose this kind of requirement.

[DavidSchinazi]

Nothing in the current document prevents applications from doing this, but explicitly mentioning that it's possible is a good idea. So +1 to MT's suggestion.

[huitema]

I think the initial goal is to protect the web transport header when the WT application "resets" a stream. I would implement that in the WT API itself, so that a bare API level "Reset" always map to a "RESET AT ".