Draft: draft-ietf-masque-h3-datagram

Commentary: points out that in order to correctly forward DATAGRAMs between transports where the QUIC DATAGRAM frame is n't always available , intermediaries need the ability to parse some capsules . 
 CAPSULE was easier to understand when it was fully opaque . When should I choose to define a semi - opaque CAPSULE vs defining a new frame ? Are n't both constructs effectively hop - by - hop ? 
 you 're the one who asked for this :-) The benefit of a semi - opaque capsule is that it allows defining new capsules without having to update every single intermediary in the chain , because intermediaries forward all unknown capsules .
CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL
only be sent in client-initiated bidirectional streams.
Intermediaries MUST forward all received CAPSULE frames in their
unmodified entirety on the same stream where it would forward DATA
frames.  Intermediaries MUST NOT send any CAPSULE frames other than
the ones it is forwarding.  Intermediaries respect the order of
CAPSULE frames: if an intermediary receives two CAPSULE frames in a
given order, it MUST forward them in the same order.
CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL
only be sent in client-initiated bidirectional streams.
Intermediaries forward received CAPSULE frames on the same stream
where it would forward DATA frames.  Each Capsule Type determines
whether it is opaque or transparent to intermediaries: opaque
capsules are forwarded unmodified while transparent ones can be
parsed, added, or removed by intermediaries.
Endpoints which receive a Capsule with an unknown Capsule Type MUST
silently drop that Capsule.  Intermediaries MUST forward Capsules,
even if they do not know the Capsule Type or cannot parse the Capsule
Data.
Unless otherwise specified, all Capsule Types are defined as opaque
to intermediaries.  Intermediaries MUST forward all received opaque
CAPSULE frames in their unmodified entirety.  Intermediaries MUST NOT
send any opaque CAPSULE frames other than the ones it is forwarding.
All Capsule Types defined in this document are opaque, with the
exception of the DATAGRAM Capsule, see datagram-capsule.  Definitions
of new Capsule Types MAY specify that the newly introduced type is
transparent.  Intermediaries MUST treat unknown Capsule Types as
opaque.
Intermediaries respect the order of opaque CAPSULE frames: if an
intermediary receives two opaque CAPSULE frames in a given order, it
MUST forward them in the same order.
Endpoints which receive a Capsule with an unknown Capsule Type MUST
silently drop that Capsule.
Receipt of a CAPSULE HTTP/3 Frame on a stream that is not a client-
initiated bidirectional stream MUST be treated as a connection error
of type H3_FRAME_UNEXPECTED.
The DATAGRAM Capsule is transparent to intermediaries, meaning that
intermediaries MAY parse it and send DATAGRAM Capsules that they did
not receive.  This allows an intermediary to reencode HTTP/3
Datagrams as it forwards them: in other words, an intermediary MAY
send a DATAGRAM Capsule to forward an HTTP/3 Datagram which was
received in a QUIC DATAGRAM frame, and vice versa.
Note that while DATAGRAM capsules are sent on a stream,
intermediaries can reencode HTTP/3 datagrams into QUIC DATAGRAM
frames over the next hop, and those could be dropped.  Because of
this, applications have to always consider HTTP/3 datagrams to be
unreliable, even if they were initially sent in a capsule.