Change:
This is one potential design for the identifier at the start of the CONNECT-UDP datagram payload. Note that this PR is against the design team consensus branch, not main. . .
During the HTTP Datagrams Design Team meeting on 2022-01-20, we reached consensus to move forward with the dynamic approach, so I'm merging this PR.

Discussion:
4. <ins> This protocol allows future extensions to exchange HTTP Datagrams which carry different semantics from UDP payloads.  Some of these extensions can augment UDP payloads with additional data, while others can exchange data that is completely separate from UDP payloads.  In order to accomplish this, all HTTP Datagrams associated with UDP Proxying request streams start with a context ID, see format. Context IDs are 62-bit integers (0 to 2 -1).  The context ID value of zero is reserved for UDP payloads, while non-zero values are dynamically allocated: non-zero even- numbered context IDs are client-initiated, and odd-numbered context IDs are server-initiated.  Extensions can use the next available context ID for their own purposes.  Note that, once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. Additionally, note that the context ID namespace is tied to a given HTTP request: it is possible for the same numeral context ID to be used simultaneously in distinct requests. 5. </ins> When associated with UDP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see HTTP-DGRAM) has the following format: <del> The design team meetings will continue until morale improves. </del> <ins> A variable-length integer that contains the value of the Context ID.  Endpoints MUST silently drop any received HTTP Datagram which carries an unknown Context ID. </ins> The payload of the datagram, whose semantics depend on value of the previous field.  Note that this field can be empty. <del> UDP packets are encoded using HTTP Datagrams with the To Be Determined field set to TBD0.  When the To Be Determined is set to TBD0, the Context Payload field contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). </del> <ins> UDP packets are encoded using HTTP Datagrams with the Context ID set to zero.  When the Context ID is set to zero, the Context Payload field contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). </ins> Clients MAY optimistically start sending proxied UDP packets before receiving the response to its UDP proxying request, noting however

request with a failure, or if the datagrams are received by the proxy before the request. <del> 5. </del> <ins> 6. </ins> Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching.

independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. <del> 5.1. </del> <ins> 6.1. </ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot

on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. <del> 5.2. </del> <ins> 6.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP

packets it sends to the server.  These do not relate to the ECN markings of packets sent between client and proxy in any way. <del> 6. </del> <ins> 7. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad

Proxies MUST NOT introspect the contents of UDP payloads as that would lead to ossification of UDP-based protocols by proxies. <del> 7. </del> <ins> 8. </ins> <del> 7.1. </del> <ins> 8.1. </ins> This document will request IANA to register "connect-udp" in the HTTP Upgrade Token Registry maintained at