Error handling

[martinthomson]

There is no error handling capability in the protocol at all.

We need a framework for describing how errors are handled. That might reuse HTTP/2 signaling (which might not be the best idea if we are serious about this being mostly generic) or they might use a new frame type for signaling session-level errors.

The HTTP/3 draft has a termination signal; that might be the best option.

[ekinnear]

Agreed, there's basically a paragraph for every frame type/mechanism about what to do when the peer violates behavioral requirements that we've left out until we've got this.

It seems like having a non-HTTP/2 dependent mechanism would be useful, and I don't think we need much more than "we're done here because X reason" like the H3 doc has.

[DavidSchinazi]

Chair notes from IETF 112 meeting: plan to align with WebTransport over HTTP/3 as much as possible, wait for progress there

[DavidSchinazi]

Discussed in editors' call - looks like this can be solved by saying that a receiver that detects a violation or other fatal error needs to reset the h2 stream.

[DavidSchinazi]

Chair: discussed at IETF 116. Consensus in room was that the receiver that detects a violation or other fatal error needs to reset the h2 stream.

[DavidSchinazi]

Chair: discussed at IETF 117. Consensus in room was that the receiver that detects a violation or other fatal error needs to reset the h2 stream.

(Yes, this is copy-pasted from the last one... we just need a PR)

[DavidSchinazi]

Chair: discussed in editor's meeting. This does not need discussion time at IETF 118, see previous comments for planned resolution.

[DavidSchinazi]

Chair: as part of resolving this, recommend resolving #101 in the same PR