Draft: draft-ietf-masque-h3-datagram

Commentary: Add Notes : None to all IANA registrations s / DGRAM / QUIC - DGRAM s / STRUCT - FIELDS / STRUCTURED - FIELDS Use HTTP style for SF field declaration 
 We had the following questions related to terminology use : a ) The following terminology appears to be used inconsistently . Please review these occurrences and let us know if / how they may be made consistent . capsule protocol vs. Capsule Protocol ( may need an IANA update ) Upgrade token vs.   ( note that RFC - to - be 9297 contained a question about " connect - udp " HTTP Upgrade Token vs. " connect - udp " upgrade token ) capsule type vs. Capsule Type ( should " field " follow the capped version ? ) capsule vs.  ( generally ) b ) RFC 9000 uses " stream ID " . Should " Quarter Stream ID " be made " Quarter stream ID " ? This would match the use of " QUIC stream ID " in this document as well . c ) Please review the use of quotes with header field ( and possibly field ) names . The companion document ( draft - ietf - masque - connect - udp-15 ) most frequently uses double quotes around header field names . Should this document do the same ? d ) May we update to use " Item Structured field " ( with field lowercase ) to match other field names ? FYI : RFC 8941 uses " Item Structured Header " . 
 we should figure this out in tandem with CONNECT - UDP . Captalization of our new terms is on us . But the HTTP stuff stuff should defer to the HTTP style guide ; meaning When defining a field , the first instance should be quoted When referring to a field defined in a different document , the first instance should include a reference , and all instances should be unquoted Use the suggested style of importing Structured fields types . To address d ) then just say " The " Capsule - Protocol " header field is an  " 
 And while we 're here : 1 ) HTTP style prefers that citations use the label . 2 ) I wonder if we should label the reference to QUIC DATAGRAM with a prefix like , which would line up clearly against without confusion . 
 a ) I like capitalizing our new terms b ) I prefer Quarter Stream ID over Quarter stream ID but I do n't care too much c ) Happy to follow HTTP style guide for quoting of headers d ) sure Sure I 'm ok with STRUCTURED - FIELDS QUIC - DGRAM sounds good 
 Also let 's use " upgrade token " without capitals to match RFC 9110 
 We had the following questions regarding the IANA Considerations section . a ) The " HTTP/3 Settings " registry also contains Date , Contact , and Notes fields . Should these be to the of this document ? b ) The " HTTP/3 Error Codes " registry also contains Date and Notes columns . Should these be to of this document ? c ) The " HTTP Capsule Types " registry also contains a Date column . Should be updated to match ? 
 Consistently including seems fine . The date field does n't need putting in the RFC . IANA can change that as they see fit during their actions . 
 I do n't care , either way seems reasonable to me 
 Let 's close with no action . Adding does n't help anyone . 
 Actually , we 'll add Notes as part of
HTTP extensions (as defined in HTTP) sometimes need to access
underlying transport protocol features such as unreliable delivery
(as offered by DGRAM) to enable desirable features.  For example,
this could allow for the introduction of an unreliable version of the
CONNECT method and the addition of unreliable delivery to WebSockets
WEBSOCKET.
HTTP extensions (as defined in HTTP) sometimes need to access
underlying transport protocol features such as unreliable delivery
(as offered by QUIC-DGRAM) to enable desirable features.  For
example, this could allow for the introduction of an unreliable
version of the CONNECT method and the addition of unreliable delivery
to WebSockets WEBSOCKET.
When HTTP is running over a transport protocol that supports
unreliable delivery (such as when the QUIC DATAGRAM extension DGRAM
is available to HTTP/3 H3), HTTP Datagrams can use that capability.
When HTTP is running over a transport protocol that supports
unreliable delivery (such as when the QUIC DATAGRAM extension QUIC-
DGRAM is available to HTTP/3 H3), HTTP Datagrams can use that
capability.
If an HTTP/3 Datagram is received and its Quarter Stream ID maps to a
stream that has not yet been created, the receiver SHALL either drop
that datagram silently or buffer it temporarily (on the order of a
round trip) while awaiting the creation of the corresponding stream.
If an HTTP/3 Datagram is received and its Quarter Stream ID maps to a
stream that cannot be created due to client-initiated bidirectional
stream limits, it SHOULD be treated as an HTTP/3 connection error of
type H3_ID_ERROR.  Generating an error is not mandatory because the
QUIC stream limit might be unknown to the HTTP/3 layer.
If an HTTP/3 Datagram is received and its Quarter Stream ID field
maps to a stream that has not yet been created, the receiver SHALL
either drop that datagram silently or buffer it temporarily (on the
order of a round trip) while awaiting the creation of the
corresponding stream.
If an HTTP/3 Datagram is received and its Quarter Stream ID field
maps to a stream that cannot be created due to client-initiated
bidirectional stream limits, it SHOULD be treated as an HTTP/3
connection error of type H3_ID_ERROR.  Generating an error is not
mandatory because the QUIC stream limit might be unknown to the
HTTP/3 layer.
When processing capsules, a receiver might be tempted to accumulate
the full length of the capsule value in the data stream before
handling it.  This approach SHOULD be avoided because it can consume
flow control in underlying layers, and that might lead to deadlocks
if the capsule data exhausts the flow control window.
When processing Capsules, a receiver might be tempted to accumulate
the full length of the Capsule Value field in the data stream before
handling it.  This approach SHOULD be avoided because it can consume
flow control in underlying layers, and that might lead to deadlocks
if the Capsule data exhausts the flow control window.
The "Capsule-Protocol" header field is an Item Structured Field; see
STRUCT-FIELD.  Its value MUST be a Boolean; any other value type MUST
be handled as if the field were not present by recipients (for
example, if this field is included multiple times, its type will
become a List and the field will be ignored).  This document does not
define any parameters for the Capsule-Protocol header field value,
but future documents might define parameters.  Receivers MUST ignore
unknown parameters.
The "Capsule-Protocol" header field is an Item Structured Field; see
STRUCTURED-FIELDS.  Its value MUST be a Boolean; any other value type
MUST be handled as if the field were not present by recipients (for
example, if this field is included multiple times, its type will
become a List and the field will be ignored).  This document does not
define any parameters for the Capsule-Protocol header field value,
but future documents might define parameters.  Receivers MUST ignore
unknown parameters.