Code change:
directions.  In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header <del> section.  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. </del> <ins> section.  (Note that only a single HTTP request starting the capsule protocol can be sent on HTTP/1.x connections.)  In HTTP/2 and HTTP/3, the data stream of a given HTTP request consists of all bytes sent in DATA frames with the corresponding stream ID.  The concept of a data stream is particularly relevant for methods such as CONNECT where there is no HTTP message content after the headers. </ins> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If a new HTTP Upgrade Token is only defined over

Related discussion:
text: In Section 2: When running over HTTP/1, requests are strictly serialized in the connection, therefore the first layer of demultiplexing is not needed. Is there any actual possibility to run more than a single request with HTTP datagram support over an transport connection? When one runs an HTTP request that enables datagram I don't see how it would be possible to close that request in any other way than closing the underlying transport connection. Or are there a way that I am missing that would enable one to close this request, and then issue another pipelined HTTP request that also uses HTTP datagrams? Is there a need to clarify this, or make it clear that only a single HTTP request with datagram can be sent?
In section 2, we've yet to mention anything about how the rest of the spec operates. So the comment in isolation is correct when talking about the general concept of multiplexin. I see your point but I'm not sure saying anything more here will help. Section 4.1 provides the details that implementers need to do the right thing.
Okay, but lets include Section 4.1 also into this. I assume you are referring to this sentence: In HTTP/1.x, the data stream consists of all bytes on the connection that follow the blank line that concludes either the request header section, or the 2xx (Successful) response header section. But, per URL this body length length rules will be those that could govern a closure of a HTTP request enabling datagram. Would it be realistic to actually make it clear that if one enable HTTP Datagram transport close is the only, way or is that just creating additional rules making implementation even more? Otherwise do we need additional analysis if there are possibility that any of these rules could actually result in a closing a HTTP request?
There is no HTTP content on upgrade requests, we should link to the definition of Upgrade URL and make things slightly more clear in Section 4.1.
Ok, I guess it becomes a question of which method for enabling datagram one uses, if this is an upgrade or a new method. And I would note that Connect method appears to have some interesting exceptions compared to other methods. Which I think makes this into a requirement on the using method/upgrade that uses HTTP datagrams to actually specify this aspect.
I've written up to clarify that pipelining is not supported.