Draft: draft-ietf-webtrans-http3

Commentary: This matches agreement at the last interim . We should separate this into a different draft , but for now this will make the draft match implementation . 
 Partially addresses . cc 
 Http3Transport currently assumes that server - initiated bidirectional streams and datagrams can only be used for WebTransport . I suggest we prefix each server - initiated bidirectional stream and datagram with a new HTTP/3 frame type for WebTransport . This way , a future standard could define it 's own frame type to run alongside WebTransport . 
 Using an H3 frame type for server initiated bidi streams would also make the design more consistent , instead of the asymmetric design there is today . It costs a byte per bidi stream , but it seems worth it for consistency and flexibility . For datagrams , I believe that we 'd want to be able to coexist with other H3 extensions , such as MASQUE , and I believe that 's possible without any extra overhead by adding a Session -Datagram flow ID mapping when a WebTransport session is created . 
 If it 's a single byte , it 's more of a stream type ( like the unidirectional stream - type ) than a frame type , right ? There 's a discussion  pointed me to in , where it 's suggested that datagrams belonging to a WebTransport session use the Flow ID = to the Session ID . It would be nice to avoid the extra state and lookup . 
 Ah yes , it 's more of a stream type . In that case , I 'm unsure of whether there 's a good way of eliminating the asymmetry . The only option I can think of is to not use a stream type for server bidi streams and only use the frame , like for the client initiated bidi streams ? Thanks for the pointer to , it looks like there are a few potential designs for datagrams flow IDs . If in doubt , simpler is probably better . I 'll think more about this one . 
 I agree we should use the same mechanics for client and server bidi streams . 
 After thinking about this more , not having a stream type does n't seem so bad to me and it does provide symmetry . Stream types seem like an obvious design choice , but I believe HTTP/3 is sufficiently constrained that one could infer the stream type based on the first frame on the stream . For example , the control stream MUST start with SETTINGS . In retrospect , having both stream types and frame types is a bit awkward , and it likely would have been cleaner to only have frame types , but that ship has sailed . 
 After having implemented this for hackathon , I can confirm that the lack of stream preface on server - bidi streams is annoying and requires special casing ( I actually simulate receiving one ) . Let 's please add one . I took a bit of a shortcut and treated the stream preface as both a stream type AND a frame type . After peeking at the unidirectional stream input to discover that it 's WT , I let the parser run on that and treat it as a frame type , making it symmetric with the bidi case . Is it possible to define a reserved frame type with the same value as the stream type ? 
 Given HTTP/3 does not have a stream type varint for bidi streams , I think a potential way forward is to say that the first frame on the bidi stream can indicate the ' type ' of the stream , but that there is no explicit type identifier on the wire . Feel free to ignore the below comment , as it 's apparently unchanged from January Looking back , SETTINGS is required to be the first frame on the control stream , so the control stream type is a bit redundant and the same is true for QPACK and I believe could be true for server push ? Obviously we 're not going to redesign HTTP/3 stream and frame types at this stage in the process , but making bidi streams consistent for both perspectives seems preferable to me . 
 Discussed at IETF 110 . There seems to be a general agreement that we should make server - initiated bidi streams use the same encoding as client - initiated ones ( that is to say , frames ) . There was some interest expressed in splitting definition of server - initiated bidi streams into their own draft ; and are to reach out to httpbis about the appropriate venue for that . 
 Just bringing some of the discussion from here : HTTP should provide some consistent guidance for the format of HTTP/3 extension streams . Client - bidi extension streams have to start with a frame or series of frames , to be compatible for H3 . One of these frames has to identify the type of stream . This is how WT is currently specified . Unidirectional streams all start with a Stream Type , but after that are inconsistent in H3 the control stream is : Stream Type + Frames QPACK Streams are : Stream Type + QPACK instructions  streams are : Stream Type + Preface ( Push ID ) + Frames Stream Type seems like a more general extension mechanism , since it can be used to completely decouple from HTTP/3 frame parsing . 
 I find stream types to be less extensible than frames : frames allow you to do anything that stream types do , while additionally providing more opportunity for extensibility . I would prefer server - initiated bidirectional streams to behave like client - initiated bidirectional streams instead of unidirectional streams , as that makes implementations simpler . 
 January Me said : So I think I 'm arguing against myself and I 'm going to stop . My other comments on this thread we that I did n't like was the asymmetry of WT uni streams , which currently are . My past self seemed to be advocating that we change WT uni streams to or perhaps . Do we want general guidance about how extensions should use Stream Type vs Frames on unidirectional streams -- specifically that there should be at least one frame ? 
 The place to put that guidance would have been draft - ietf - quic - http , and I think that ship has sailed . For unidirectional streams , I like your framing proposal as that enables extension frames down the road . 
 Well , not too late to put out a BCP or something , especially if there 's going to be some kind of formal guidance on server - initiated bidi streams . I 'll open a separate issue about changing the WT uni framing . 
 I think this specific issue was fixed by . Please reopen if I 'm wrong .
WebTransport clients can initiate bidirectional streams by opening an
HTTP/3 bidirectional stream and sending an HTTP/3 frame with type
"WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be
the frame type, followed by the session ID, encoded as a variable-
length integer, followed by the user-specified stream data (fig-bidi-
client).  The frame SHALL last until the end of the stream.
WebTransport servers can initiate bidirectional streams by opening a
bidirectional stream within the HTTP/3 connection.  Note that since
HTTP/3 does not define any semantics for server-initiated
bidirectional streams, this document is a normative reference for the
semantics of such streams for all HTTP/3 connections in which the
SETTINGS_ENABLE_WEBTRANSPORT option is negotiated.  The format of
those streams SHALL be the session ID, encoded as a variable-length
integer, followed by the user-specified stream data (fig-bidi-
server).
WebTransport endpoints can initiate bidirectional streams by opening
an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type
"WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be
the frame type, followed by the session ID, encoded as a variable-
length integer, followed by the user-specified stream data (fig-bidi-
client).  The frame SHALL last until the end of the stream.
HTTP/3 does not by itself define any semantics for server-initiated
bidirectional streams.  If WebTransport setting is negotiated by both
endpoints, the syntax of the server-initiated bidirectional streams
SHALL be the same as the syntax of client-initated bidirectional
streams, that is, a sequence of HTTP/3 frames.  The only frame
defined by this document for use within server-initiated
bidirectional streams is WEBTRANSPORT_STREAM.
TODO: move the paragraph above into a separate draft; define what
happens with already existing HTTP/3 frames on server-initiated
bidirectional streams.