Only Fetch?

[LPardue]

This ticket is perhaps the opposite of #166. Is HTTP the only thing that a user agent can do, that might fail due to network problems? I'd say no.

For instance, WebSockets are a popular application protocol for the Web. Things can and do go wrong with them. Failure could often be underlied by the same causes as HTTP - like a DNS problem. Other times, WebSockets might be handled differently on the server side (think an L7 load balancer that forwards WebSocket Upgrades to a different backend).

WebSocket isn't too dissimilar from the request/response model. However, something like WebTransport is quite different and more complicated. There's opportunity for errors with WebTransport, especially since its "new". Should it be in scope or explicitly out of scope? (I'd argue for in scope if it can be done).

[mmocny]

The goal of #166 is specifically to improve NEL specification in terms existing established spec concepts, rather than to just limit it to fetch(). We should of course also extend similar for WebSockets / Transport as needed!

Q: What is the current status of specs for WebTransport?

[LPardue]

@wilaw and @jan-ivar can you speak to the status of WebTransport specs please?

[wilaw]

@LPardue - the WebTransport spec is still in Working Draft status. We are aiming to have a Candidate Recommendation soon. Some of the issues assigned to that CR milestone involved WebTransportError, so the error interface is not yet guaranteed to be stable.