Draft: draft-ietf-webtrans-http3

Commentary: Also ban sending it anywhere that 's not the beginning of the stream . Potentially also and 
 cc 
 I 'm curious how anyone has got handling of the WEBTRANSPORTSTREAM frame working based on strict following of the specs . WT over H3 says : H3 says in Type ( i ) ,  ( i ) , Frame Payload ( .. ) , } snip  over h3 says of the frame : So it appears that WT is trying to omit the length field to imply an Indefinate length , but H3 does n't allow that . I 'd expect a standard H3 frame parser to read the first N bytes of the session ID and incorrectly parse that as the length . I don;t think you can special case this frame , because your breaking the H3 contract that unknown frame types have a correct length that allows them to be read and discarded . One option ( lets call it A ) would be to say that has a length field of MAXVAL and then create a new caveat that if you 're a WebTransport supporting endpoint , you do n't need to create a connection error the stream if it is FIN'd before that length is reached . However , that has the unfortunate problem of consuming 8 bytes at the start of every stream . Another option ( B ) might be to say that the frame is fixed length as so : Type ( i ) = 0x41 ,  ( i ) , Session ID ( i ) , } Meaning the frame only contains the Session ID field , and the length of that frame is truly the length of Session ID - satisfying the general H3 requirements . Then after this frame , you switch into WebTransport bidi streams as we seem to be going towards on . However , H3 endpoints that read this frame and discard it , would then move on to parsing the subsequent bytes as frames ( when the sender never intended that ) and bad stuff might happen . 
 We already discussed this in . The expectation for unknown H3 frames to have length does not apply here : WebTransport support is explicitly negotiated via SETTINGS , meaning that by the time someone sends WEBTRANSPORT_STREAM , both peers know they support it . 
 Thanks for reminding of that . Given the discussion on , if ee go that way I do n't think we should bother calling this an HTTP/3 frame . For all intents and purposes it is n't . Rather , we could make it clearer that WebTransport is a semantic extension to H3 that permits client bidirectional streams to start with a special byte sequence that changes the stream purpose and meaning . 
 It needs to be registered in the h3 frame type IANA registry to avoid conflicts though 
 You could seek to reserve the codepoint to help prevent unintended interop problems , we already do that e.g. 
 At the end of the day calling this an infinite - length - frame or a non - frame - that - is - reserved - in - the - list - of - frames ends up being the same thing implementation - wise . My personal two cents is that infinite - length frame is easier to explain and reason about . 
 I disagree . With the proposal on , we 're making a non - frame that ca n't have anything before or after it . This is a very special thing that sticks out and I doubt is likely to be replicated . So I 'd like to hear what other implementers have done or would do . My implementation that reads from streams already has branches that go into frame parsing mode or not depending on the stream type . If I were to add the code , I 'd model it as a different stream type that is only supported when WebTransport is enabled and it would n't touch my frame parsing part at all . edit : ( comment ) given HTTP/3 already has the notion of stream types , I do n't know why we need to invent another special concept in HTTP/3 to support WebTransport . 
 Chair : discussed in editor 's meeting , thinks this is resolved by . do you agree ? 
 Sorry I missed that PR as I was on holiday . I believe that channels the spirit of my PR , and addresses the original issue here I think the text could continue to have some editorial improvements to better highlight how much of a divergence this is for request streams , but lets track the separately . 
 Awesome , thanks Lucas ! Closing based on that comment . For the remaining editorial bits , please file a separate issue or PR :-) 
 The draft says : It is unclear if it is allowed to send other frames before sending the WEBTRANSPORTSTREAM frame . I ca n't think of any currently defined HTTP/3 frame that would make sense to send here , but that might not be the case with future extensions . At the very least , it would be nice of grease frames could be sent . 
 touches on this issue for unidirectional WT streams - eg : should they be defined as a sequence of TLV frames followed by a WT TV frame which converts the stream to unframed ? 
 What is the value in sending grease frames on these streams ? Specifically to allow for future extensions that send other frames before WEBTRANSPORT_STREAM ? 
 I can imagine sending a PRIORITYUPDATE or something of that nature , though it 's not clear to me it 's worth the effort compared top just not using any frames on the stream before WEBTRANSPORTSTREAM . 
 Chair : discussed at IETF 114 , consensus in the room to be consistent between unidirectional and bidirectional require WEBTRANSPORTSTREAM to be the first frame on a bidirectional stream this also disallows extension frames before WEBTRANSPORTSTREAM 
 I was n't in the room but following up on the meeting recording , I could support this proposal . However , I do n't understand how we make the  actually do what we describe here robustly , so I opened 
 WT uni streams are currently defined as This was awkward to implement , and asymmetric with how client - initiated bidi WT streams are implemented ( and now server - initiated bidi -- with a frame ) . I 'd like to propose we change WT uni streams to or perhaps 
 Not discussed at IETF 111 . I do n't see the point in trying to match this up with bidi streams . All this achieves is wasting bytes for the frame type field . 
 I tend to think the current design is fine as well . If you think about the first value of the unidirectional stream being a frame type , not a stream type , then I think they do conceptually align with the Bidi WT streams ? 
 Paging in context ... I think my reason for suggesting this was that my parser always wants to consume the stream - type when it dispatches a unidirectional stream , but given the similarities to the other WT stream types , I wanted to use the generic frame parser after dispatch . I made it work by not consuming the type - byte in this special case . A side effect of defining it as is that one could more easily add extension frames before the TV frame in the future , at the cost of an extra byte now . I can live with it as is too . 
 Should I add this to the agenda for the next meeting , or should we just leave this as - is and close this issue ? 
 Given the relation to the issue just opened ^ covering a similar topic on bidi streams ( eg : which frames are allowed before TV ) , maybe we should have a brief discussion ? I think they should behave similarly . I have the context paged in now before the meeting . It sounds like suggested Grease frames as a possible use case , in addition to " future extensions " suggested here . Maybe a frame for signaling the initial priority in the bidi - case is plausible ? Grease frames may be marginal in this context ( you ca n't send one on a QPACK stream either ) , and any extension needs to be enabled via SETTINGS ( or capsules or headers ? ) anyways so said extension can change the format of WT streams . I 'll counter that the cost ( 1 byte per stream ) is low and it 's easier to bake in the flexibility from the start rather than bolt it on later . I 'll reiterate that I can live with the current scheme . 
 I think that the unidirectional design ( having a dedicated stream type ) is the much cleaner solution . There is greasing for unidirectional stream types in HTTP/3 , so I do n't think we need to do anything here . I wish we also had stream types for bidirectional streams in HTTP/3 , so that ship has sailed . 
 - I read your position on the other issue and assumed you wanted future extensions to be able to send frames before the WT stream became unframed . If that 's true , I do n't understand why you would want that capability for bidi streams but not uni streams . 
 At IETF 114 , we discussed uni / bidi streams and there was consensus in the room to be consistent between unidirectional and bidirectional . See 
 Chair : understanding is that this is let 's keep the related discussion going on in which is still open
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.
WebTransport endpoints can initiate bidirectional streams by opening
an HTTP/3 bidirectional stream and then immediately sending a special
signal value 0x41, followed by the associated session ID, both
encoded as a variable-length integer; the rest of the stream is the
application payload of the WebTransport stream (fig-bidi-client).
This document registers the special signal value 0x41 as a
WEBTRANSPORT_STREAM frame type.  While it is registered as an HTTP/3
frame type to avoid collisions, WEBTRANSPORT_STREAM is not a proper
HTTP/3 frame, as it lacks length; it is an extension of HTTP/3 frame
syntax that MUST be supported by any peer negotiating
"SETTINGS_ENABLE_WEBTRANSPORT".  Any attempt to use
WEBTRANSPORT_STREAM as a frame type outside of the very first byte of
the stream MUST be treated as a connection error of type
H3_FRAME_ERROR.