Extension poster-child

[MikeBishop]

Lars had suggested a while back that BLOCKED and friends are unnecessary to the core protocol. These frames are NOT REQUIRED, but since you’re allowed to send them, every implementation must be able to receive and skip them even if they’re ignored. In HTTP/2, we decided to remove BLOCKED from the main spec and let that be reintroduced as an extension if anyone wanted. (It turned out no one did.)

As part of the review on the new Extension mechanism, Ian had suggested that we should consider actually publishing an extension to demonstrate how the extension mechanism would work. It has also proved useful in HTTP/2 to have some extensions we can point authors to and say “do it like that.”

Now that the extension mechanism is landing/landed, does the working group want to consider pulling BLOCKED and kin out to a separate document and letting it be our recommended demo extension?

[martinthomson]

Parking this. Yes, this would be nice, but we can ship without this if we have to. It's also not really something we need to concern ourselves with tracking here. (Separately, the notion of a datagram-like MESSAGE frame is being discussed and might appear soon.)

[DavidSchinazi]

The extension @martinthomson mentioned has been written up as: https://tools.ietf.org/html/draft-pauly-quic-datagram

[martinthomson]

Tokyo conclusion: we already have a few candidates. There seems little risk that we are going to fail in this regard. We have discussed two candidates in this meeting.

Also, reaffirmation that *_BLOCKED and co. are not at risk of being moved out of the spec.