Change:
Also ban sending it anywhere that's not the beginning of the stream. Potentially also and
cc NAME
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 URL Type (i), Length (i), Frame Payload (..), } snip WT 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 doesn'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 don'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, Length (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 don't think we should bother calling this an HTTP/3 frame. For all intents and purposes it isn'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. URL
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 can'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 wouldn't touch my frame parsing part at all. edit: (added comment) given HTTP/3 already has the notion of stream types, I don't know why we need to invent another special concept in HTTP/3 to support WebTransport.
Chair: discussed in editor's meeting, NAME thinks this is resolved by . NAME 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 WEBTRANSPORT_STREAM frame. I can'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 wasn't in the room but following up on the meeting recording, I could support this proposal. However, I don't understand how we make the WEBTRANSFORM_STREAM 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 don'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.
NAME 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 NAME 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 can'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 don'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.
NAME - 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 don'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

Discussion:
4.2. WebTransport endpoints can initiate bidirectional streams by opening <del> 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. </del> <ins> 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. </ins> HTTP/3 does not by itself define any semantics for server-initiated bidirectional streams.  If WebTransport setting is negotiated by both