Draft: draft-ietf-webtrans-http3

Commentary: This PR updates draft - ietf - webtrans - http3 to account for the MASQUE HTTP Datagram Design Team changes that landed in draft - ietf - masque - h3 - datagram-06 . 
 h3 - datagram provides an ability to multiplex multiple datagram contexts over a single flow of datagrams associated with a stream . This feature is optional ; an endpoint can disable contexts by sending a register - without - context capsule . We currently do not have a use for multiple contexts ; there are potential extensions that could utilize those ( e.g. multiple datagram queues with different priorities ) , but those would not make it into the first version of the spec . There are roughly two approaches we could potentially take here : WebTransport servers to handle multiple contexts correctly even if we do n't use those currently . WebTransport servers to reject any kind of context registration other than register - without - context , unless there 's an extension negotiated via a header . The first option has the drawback of complexity that would not benefit most server implementers . The downside of the second option is that if we go with it , we would need to wait for the headers from the server before sending any datagrams . cc who can probably add more 
 ( no hats ) Since you 've isolated some potential extensions that could benefit from contexts , I strongly believe that WebTransport should not preclude them . Having just implemented this , the complexity is honestly very minor . I 'll also note that this complexity will be inside the QUIC / h3 library and not inside the WebTransport - server code . Multi - purpose QUIC / h3 libraries will support contexts for CONNECT - UDP . So I strongly prefer the first option . 
 There 's not much difference one context with an ID and one context without an ID . If you want to profile something on top of H3 datagram down to a single context , just say that like " we only define how to use one context , endpoints have no means to use more , extensions could change that " . 
 I think  was proposing to allow servers to not have to implement REGISTERDATAGRAMCONTEXT . I think we should not do that . WebTransport without extensions will use either no context or a single context , but servers need to support both . 
 Yeah I do n't like that idea , it breaks future use .. Support both register capsule but limit the number to one if you want that today . 
 YAGNI says if you do n't know that you need it , you do n't build it . I would reserve use of these for future use , but say that in this version they are n't used . 
 the trickiness there is around negotiation of extensions . Capsules and context IDs are end - to - end , so we ca n't negotiate a new context - using extension via SETTINGS . If we rely on HTTP headers for negotiating extensions , we waste a round trip before being able to send core protocol datagrams . The benefit of the current design ( where contexts are optional to use but mandatory to implement ) is that it allows a client to immediately start using datagrams with or without contexts before it 's received the response headers . 
 I 'm not sure this would be a significant problem in practice . Most protocols usually perform some kind of negotiation first , meaning that the first flight is most likely to be just stream data ( CONNECT - UDP is the only exception to this as far as I know ) . 
 I would prefer to not expose contexts because it causes the API to diverge from QUIC transport . And so far , the API is modeled very close on that API . I believe that 's been a good choice . If you want multiple streams of datagrams , you can open multiple WebTransport sessions or potentially use H3 - datagram directly if you only need datagrams . 
 we 're not suggesting exposing contexts to JavaScript . This is about the interaction between draft - ietf - webtrans - http3 and draft - ietf - masque - h3 - datagram . 
 If we 're not exposing it in  , then it seems like it 's not a core feature of WebTransport . On a practical note , we 've decided that for the fallback options , we 'll layer a QUIC - lite streaming + datagaram layer on top of H2 or H1 . If we wanted to also support datagram contexts , I think we 'd have to pull in all of HTTP/3 , since that lives in h3 datagram , not datagram . I do not want to pull in all of H3 as well to add this currently unused functionality . Tell me if I 'm missing something . 
 So I think that the question is a bigger one : is there sufficiently large set of protocols that would use context identifiers , such that they all might benefit from common machinery in support of them ? This is a question for draft - ietf - masque - h3 - datagram more than this document , but it 's a question that I 'm not confident about . This document very much does n't need the mechanism , but - unfortunately - it has to engage with it , if only to get it out of the way . 
 I think you 're misunderstanding how contexts work , have you read the latest version of draft - ietf - masque - h3 - datagram ? ( ) let 's take the conversation about contexts to draft - ietf - masque - h3 - datagram .
Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT
HTTP Datagram Format Type (see value in iana-format-type).  When
using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport
datagram payload is sent unmodified in the "HTTP Datagram Payload"
field of an HTTP Datagram.  When sending a registration capsule using
the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format
Additional Data" field SHALL be empty.
Datagrams can be sent using HTTP Datagrams.  The WebTransport
datagram payload is sent unmodified in the "HTTP Datagram Payload"
field of an HTTP Datagram.
This document.