Endpoint requirements for unknown Capsules

Hi folks,

I have a question about how endpoints (not intermediaries) should approach
handling HTTP Capsules and I'm looking for some WG input.

RFC 9297 defined HTTP Datagrams and the Capsule Protocol[1]. During
standardization, the primary use case was for proxying UDP over HTTP (RFC
9298).

9297 defines Datagram capsules and 9298 defines how an Upgrade or extended
request accompanied with a connect-udp token, when successful, enables
*both* UDP proxying and the Capsule protocol. Once the request is set up it
is the expectation that Datagram capsules are exchanged, modulo HTTP/3
which also has a native QUIC Datagram mapping (so endpoints can exchange
either form).

RFC 9297 section 3.2 states:

> Endpoints that receive a Capsule with an unknown Capsule Type MUST silently
drop that Capsule and skip over it to parse the next Capsule.

This is inspired by HTTP/2&3 frame design with the goal of extensibility
and maintenance*. We have GREASE capsule codepoints and unknown real
extensions can be used with causing things to fall over. So far so good.

Recently, RFC 9484 was published, defining IP over HTTP. This defined a
connect-ip token and 3 new capsule types, ADDRESS_ASSIGN, ADDRESS_REQUEST,
and ROUTE_ADVERTISEMENT.

So here's the question:

Assume there's an endpoint that supports both IP and UDP tunneling. It
knows about the tokens and the capsules I mentioned above. If it receives a
request for connect-udp and accepts it, then receives an ADDRESS_ASSIGN
capsule what should it do?

The text in RFC 9297 seems a little ambiguous and I tried to map out the
options

a) The ADDRESS_ASSIGN capsule is unknown in the context of RFC 9298, so it
MUST be ignored
b) The ADDRESS_ASSIGN capsule is unknown in the connect-udp context of the
target resource of the request over which the capsule protocol is using, so
it MUST be ignored
c) The ADDRESS_ASSIGN capsule is known to the endpoint. However, it is
undefined and so is silently dropped
d) The ADDRESS_ASSIGN capsule is known to the endpoint. Since this capsule
is unexpected for connect-udp, the server treats this as some form of
protocol violation (stream or connection close).

Option (d) seems drastic but is more in the theme of dealing with the
"Harmful consequences of Tolerating the Unexpected" [4], so might actually
be The Right Thing TM.

We have other specs like WebTransport queuing up 13 new capsule
registrations. If there's anything we could do to clarify the situation
(such as a short update doc to RFC 9297) then now seems like the right time
to be doing it. So please let me know your opinions.

Cheers,
Lucas

* There are other considerations for intermediaries but I'm overlooking
that complication right now.


[1] - https://www.rfc-editor.org/rfc/rfc9297.html
[2] - https://www.rfc-editor.org/rfc/rfc9298.html
[3] - https://www.rfc-editor.org/rfc/rfc9484.html
[4] - https://www.rfc-editor.org/rfc/rfc9413.html#section-4