Draft: draft-ietf-masque-connect-ip

Commentary: Aligning CONNECT - IP with the changes in HTTP datagrams and CONNECT - UDP . 
 when do you plan to merge the other PRs ? 
 I plan on merging the other PRs as soon as we have WG consensus , which ( assuming no objections ) should happen at the end of the month ( see )
Paragraph (version A):
Along with a request, the client can send a REGISTER_DATAGRAM_CONTEXT
capsule HTTP-DGRAM to negotiate support for sending IP packets in
HTTP Datagrams (packet-handling).
Paragraph (version B):
The client SHOULD also include the "Capsule-Protocol" header with a
value of "?1" to negotiate support for sending and receiving HTTP
capsules (HTTP-DGRAM).
Paragraph (version A):
IP packets are encoded using HTTP Datagrams HTTP-DGRAM with the
IP_PACKET HTTP Datagram Format Type (see value in iana-format-type).
When using the IP_PACKET HTTP Datagram Format Type, full IP packets
(from the IP Version field until the last byte of the IP Payload) are
sent unmodified in the "HTTP Datagram Payload" field of an HTTP
Datagram.
Paragraph (version A):
In order to use HTTP Datagrams, the client will first decide whether
or not it will attempt to use HTTP Datagram Contexts and then
register its context ID (or lack thereof) using the corresponding
registration capsule, see HTTP-DGRAM.
Paragraph (version A):
When sending a registration capsule using the "Datagram Format Type"
set to IP_PACKET, the "Datagram Format Additional Data" field SHALL
be empty.  Servers MUST NOT register contexts using the IP_PACKET
HTTP Datagram Format Type.  Clients MUST NOT register more than one
context using the IP_PACKET HTTP Datagram Format Type.  Endpoints
MUST NOT close contexts using the IP_PACKET HTTP Datagram Format
Type.  If an endpoint detects a violation of any of these
requirements, it MUST abort the stream.
Paragraph (version B):
This protocol allows future extensions to exchange HTTP Datagrams
which carry different semantics from IP packets.  For example, an
extension could define a way to send compressed IP header fields.  In
order to allow for this extensibility, all HTTP Datagrams associated
with IP proxying request streams start with a context ID, see
payload-format.
Paragraph (version B):
Registration is the action by which an endpoint informs its peer of
the semantics and format of a given context ID.  This document does
not define how registration occurs.  Depending on the method being
used, it is possible for datagrams to be received with Context IDs
which have not yet been registered, for instance due to reordering of
the datagram and the registration packets during transmission.
Paragraph (version B):
A variable-length integer that contains the value of the Context
ID.  If an HTTP/3 datagram which carries an unknown Context ID is
received, the receiver SHALL either drop that datagram silently or
buffer it temporarily (on the order of a round trip) while
awaiting the registration of the corresponding Context ID.
Paragraph (version B):
The payload of the datagram, whose semantics depend on value of
the previous field.  Note that this field can be empty.
Paragraph (version B):
IP packets are encoded using HTTP Datagrams with the Context ID set
to zero.  When the Context ID is set to zero, the Payload field
contains a full IP packet (from the IP Version field until the last
byte of the IP Payload).
Paragraph (version A):
Extensions to this mechanism MAY define new HTTP Datagram Format
Types in order to use different semantics or encodings for IP
payloads.  For example, an extension could define a new HTTP Datagram
Format Type which enables compression of IP header fields.
Paragraph (version A):
This document will request IANA to register IP_PACKET in the "HTTP
Datagram Format Types" registry established by HTTP-DGRAM.