Re: BLOCKED frame specification

On 16/04/2014 10:08 p.m., Roberto Peon wrote:
> Bleh.
> We have address space in the frame opcodes, lets use that instead of adding
> new semantics to things which are unstructured.

Indeed. Since the editors or WG decided that frames shall not be
extensible there are opcodes to spare in abundance. Whereas ping codes
are potentially open to extensions still by other drafts.

> The only bit of information that is needed is when the remote end is not
> blocked (confirming that it was blocked intentionally/whatever seems like a
> waste). That is enough for tuning and debugging.

Confirming that it is not-blocked could be as simple as sending the next
frame for the stream in response to the BLOCKED query. Or perhapse an
empty non-final DATA frame if one wishes.

/2c

Amos

Received on Wednesday, 16 April 2014 13:19:36 UTC