BLOCKED usage requirements

[quicwg]

BLOCKED usage requirements

[igorlord]

Agreed. BLOCKED is described as a useful debugging tool. It should not be a MUST.

In fact, I'd go further and change BLOCKED frame type into DEBUG frame type and allow DEBUG frames to carry key/value pairs. Some keys could be "well-known" (BLOCKED). Others could be user-defined. This could quickly evolve into an even more useful debugging tool, possibly with the clients having an ability to turn up and down transport's "DEBUG levels".

[martinthomson]

@igorlord, we have plenty of space for new frame types. Adding another point of extension in the protocol, especially one that could be rarely used, is likely to cause problems.

[janaiyengar]

We could change it to "MAY" but a debugging frame is useless if it isn't sent. What's the harm in requiring that it be sent?

[igorlord]

I think the answer to MUST/SHOULD/MAY for the BLOCKED frame must be identical to the answer to whether this frame MUST/SHOULD/MAY be retransmitted in case of a loss. See #452.

[MikeBishop]

Closed by #924.