Many network topologies lead to situations where transport protocol proxying is beneficial. For example, proxying enables endpoints to communicate when end-to-end connectivity is not possible or to apply additional encryption where desirable (such as a VPN). Proxying can also improve client privacy, e.g., by hiding a client's IP address from a target server. Proxying technologies such as SOCKS and HTTP(S) CONNECT exist, albeit with their own shortcomings. For example, SOCKS signaling is not encrypted and HTTP CONNECT is currently limited to TCP.

The primary goal of this working group is to develop mechanism(s) that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTP connection. The group has specified CONNECT-UDP and CONNECT-IP, collectively known as MASQUE, to enable this functionality. MASQUE leverages the HTTP request/response semantics, multiplexes flows over streams, uses a unified congestion controller, encrypts flow metadata, and enables unreliable delivery suitable for UDP and IP-based applications.

The MASQUE working group will complete its adopted documents:
 - an extension to CONNECT-UDP for ECN and DSCP support
 - an extension to HTTP Datagram protocols for compressing and deriving datagram fields

It may also adopt an informational document describing the MASQUE architecture and a standards-track document defining qlog events for the MASQUE protocols. The working group will not adopt any other work.

The working group will consider how the protocols it defines might operate over versions of HTTP that use TCP rather than QUIC, for use when QUIC is unavailable.

IP multicast is out of scope. Extensions providing generic capabilities that might include IP multicast are acceptable on the basis of their application to other use cases. For example, a generic IP proxy might be used for both unicast and multicast communication. For such generic capabilities, designs will not explicitly preclude multicast, but they will not focus on multicast-specific features.

Impacts on address migration, NAT rebinding, and future multipath mechanisms of QUIC are not anticipated. However, the working group should document these impacts, or those of any other QUIC developments, if they arise.

Extensions to HTTP Datagrams will be coordinated with HTTPBIS. The group will coordinate closely with other working groups responsible for maintaining relevant protocol extensions, such as HTTPBIS, QUIC, or TLS. It will also coordinate closely with ICCRG and TSVWG on congestion control and loss recovery considerations, and intarea for IP Proxying.

When these deliverables are complete, the working group will close.