Description of Working Group The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport API https://wicg.github.io/web-transport. The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of reliable messages. Attention will be paid to the performance of the protocol, with particular attention to the protocol’s overhead and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new transport protocols but will instead use existing protocols such as QUIC and TLS/TCP. The group will pay attention to security issues arising from the above scenarios so as to protect against creation of new modes of attack. To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. The requirements will include those arising from the WebTransport API. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol extensions and the needs of the WebTransport API. The group will also coordinate with related working groups within the IETF, such as QUIC and HTTPBIS, as appropriate. In particular, if the working group needs any changes to or extensions of the core protocols, those issues will be raised with the relevant working groups for decisions on how best to handle them. If those decisions result in work in WebTrans, the working group last calls for that work will again be sent to the relevant working groups. The group also needs to coordinate with TAPS, as they are working on related message-based APIs and it's important to make sure there aren't conflicts and/or duplications.