Session Date/Time: 17 Mar 2026 03:30
Sure, here's a transcript of the video:
Nitya Varshney: I'm just checking, can you hear us in the room?
Speaker 1: Can you speak louder?
Nitya Varshney: Can you hear us in the room?
Speaker 2: Yes, we can.
Nitya Varshney: Okay, great. Thank you.
Nitya Varshney: Okay, so let's get started everyone. This is the WebTransport session at IETF 125. This session is being recorded. Make sure that you've signed in to the Meetecho room, either by scanning the QR code or through the datatracker agenda. This is the IETF Notewell. Please note that we operate under a Code of Conduct. Any concerns can be reported to the Working Group Chairs, the responsible AD, or the Ombudsteam. Please also note the text regarding prompt disclosure of any IPR that you might be aware of. Here's a link to our agenda and the notes. And we have a slightly shorter session this time. Here's the agenda. Do we have any agenda bashing? I assume not, so let me hand it over to Will.
Will Law: Is he on the call? He's approaching. Cool. Is this working? Okay, is that good for Tokyo? Right, good morning. My name is Will Law from Akamai. I'm presenting the W3C WebTransport group update on behalf of my co-chair Jan-Ivar Bruaroey from Mozilla. So we published a working draft back on February 4th. That's the latest one. Our charter has been extended to June 30th at this point. And we have a timetable that is quite optimistic for a release this year. I don't want to say by July 2026, so that's what we're targeting right now, but we're certainly aiming for that. It's been several years’ work. The good news is we defined a candidate recommendation milestone for our issues. We're 100% complete on that. We've closed 90 issues, and we're looking in a really good spot at this point, which was why we published back in February to get the spec out. Next slide, please. So I just want to summarize some of the major updates and decisions that we've had on the W3C side of WebTransport since the last IETF meeting. The biggest change we've had was an integration with fetch. So for those who know the spec, we were tying in at quite a low level in fetch, and it was suggested that we tie in at the highest level. This allows us to use the connect request during fetch, it allows us to inherit any future improvements in fetch, and we also got header support, which was one of the primary requested features for the browser-based version of WebTransport. So this work has been done now. We added some additional connection stats – bytes acknowledged and application bytes sent – to improve the statistics. And we also removed framing overhead in order to give applications a better estimate of exactly how much data was being sent. Next slide. We updated the explainer. It hadn't been updated since 2021, so the examples were a little old. There was a lot of new material in there. So there’s some really nice code that's been added, code examples showing datagram usage, stream usage, constructor, all the various new constructor options that we have. So I encourage people to look at the explainer. It's really an up-to-date snapshot of where the spec is today. Next slide. There's been work done on CSP and cert verification, along with a new keyword, "unsafe-webtransport-hashes", which can be used. And we've also improved the headers constructor option. Sorry, in the constructor, there's now an opportunity to send headers. So you can send a bearer token, for example, in a format that you might be familiar with on HTTP, and send it down to the server. Next slide. And just the last two updates: we renamed "incomingMaxBufferedDatagrams" to be – sorry, "incomingHighWatermark" to be "incomingMaxBufferedDatagrams", because it was implying that there was stream-like backpressure, which there just wasn't here. We also changed it from a double to a long. These are technical changes, and I think we can go to the next slide. So the very good news within the W3C world: WebTransport has been accepted as a focus area for Interop 2026. So Interop is a hardcore effort amongst the major browser vendors to pick a subset of technologies and really dive deep into interop between them. So the fact that WebTransport has been selected as one of these is fantastic. It means our likelihood of having a highly interoperable solution by the end of 2026 is very good, and that bodes well for all the technology that depends on WebTransport in the browser, such as Media over QUIC. So thank you to the browser vendors for taking on WebTransport in this format. And then last slide. I mentioned we've closed out our candidate recommendation milestone. We're now moving to the next step of the W3C release process, which is called wide review. We ask other experts within W3C to come and review the spec, and then we will move down the release roadmap. Our goal is to get it out in approximately August 2026 of this year. Are there any questions? That is the end of our W3C report. Okay, I don't hear any. Thank you very much.
Nitya Varshney: Thank you, Will. I think we have Eric up next.
Eric Kinnear: All right, can you hear me? Thumbs up. Sweet. Awesome. All right, next slide, please. That's it, that is the next one out. Thank you. These slides are not full of tons of content because we did all the things. So we have new versions of the document updates. So we're on 12, 15, and 14. So we submitted new drafts of everything and have started last call on them. Next slide, please. Brief overview of things we changed in each document. So starting with the overview, next. We didn't change anything major in the overview. So we did a little bit of editorial cleanup, made things prettier, hopefully a little bit easier to read. Otherwise, it is the same as it was before. Next slide, please. There are also currently no open issues, and in a theme that you will hear from me at least three times today, the working group last call is currently open. So now is a great time to please actually go read these documents. Next slide, please. Let's talk real quick about H3. So just a brief summary of some of the less editorial things that changed. So we updated the security considerations. Most of this is saying that we take into account everything that is in the security considerations section in H3 itself. So obviously that applies, and then there's an additional paragraph that talks about: "Hey, this is a little bit different than other uses of H3 because the server might be opening multiple streams to the client," and that's a somewhat new thing if you're just thinking of yourself as an HTTP client. So there’s a little bit to say, "Hey, make sure that if there's a bunch of incoming streams, you correctly limit those and don't allow people to use up too many resources," that kind of thing. So that's the first part. The other one is – we spent a long time at 124 talking about this, so I'm not going to go through it all again, but this is a great moment to go read this section of the draft as you do that review that we just mentioned. So "max sessions" is gone, like we discussed last time. We essentially wrote up all the changes that we talked about. So WebTransport support is indicated by sending the "WebTransport Enabled" setting, and that is now for the server only. And thank you, Victor, for noticing that as we're doing the draft version negotiation, we still need it on the client, just for the draft versions. So there's an extra little "to be removed before publication" section saying, "Please keep sending it when you're supporting a draft version because we need that." Next slide. We added a couple of different error codes and otherwise cleaned up things about how you're supposed to handle errors and what different conditions should lead to an error. The two notable ones there are: there's now an "ALPN Error", which is if you try to use the WebTransport Available Protocols bits to say, "Hey, I want these particular application protocols," and the server gives you something that's not one of those, it'll say, "Well, that's not what we asked for. This doesn't make sense. We should stop talking now," and that's the error that it uses. Notably, if you don't supply the header, it is truly optional. So you can not supply the header and nobody should be bothered. But if you do choose to participate, you at least need to follow the rules. The other one is there's a "WebTransport Requirements Not Met" error code. So that's if you are missing, like, datagram support or some of the other things that we said were not optional. We now enforce that they are, in fact, not optional and tell you that that's why we're no longer having a conversation. Next slide, please. There's a little bit of somewhat more editorial updates to basically just say, "Hey, when you're doing flow control stuff," and you'll see this in both the H3 and the H2 document, mirroring some of the language that we have in H2 and QUIC documents themselves, saying, "Please don't just sit around waiting for somebody to send a blocked frame. Blocked frames are not the thing that you use to tell people it's time to keep moving." That's pretty straightforward, it matches how things work in H2 and H3 with QUIC, but it's explicitly stated now so that there's no confusion there. And the last one, this is a fairly carefully worded set of paragraphs where we talk about using the capsule-based protocol over H3. This is trying to capture the spirit of what we talked about at 124. And it essentially says you should always be using the H3 version of WebTransport over H3, that splits things out into independent streams that don't have to share fate and don't have head-of-line blocking and all that kind of thing, and gives a very limited set of: here are the cases where you might want to use the capsule-based protocol, and here's what you lose when you do so, so really think twice before proceeding in that direction. Next slide, please. So those are all the updates. I'm going to pause real quick in case there's questions about that, but hopefully the answer is a thumbs up and we'll totally go read those documents. Cool. All right, next slide, please. The one last thing that is still open on H3 is: if you try to talk WebTransport to a resource that doesn't exist, you respond with a 404 because that doesn't exist and it's not found, and that's pretty clear. We had an open question about what should you do if the resource does exist but doesn't support WebTransport. And in a previous meeting/issue, we hopped on using 405 as the status code, and it was I think rightly pointed out that that's maybe not the one we wanted, and that maybe we wanted – sorry, that we hopped on 406 and we said maybe that's not the one that we want, maybe we wanted 405 instead. So we're bikeshedding numbers. Thoughts, what should we use? I see Lucas in the queue.
Lucas Pardue: Hello, speaking as an individual here. Yeah, I kind of flagged this as I was looking at the review, mainly wearing like an HTTP directorate hat and assuming that they're going to read these documents and getting up to speed on some of the history about like why that number. It makes sense from a consistency perspective because that's what our H2 document currently says. But like when you go and read all the details about what 406 really means, it just doesn't seem right. This does, unfortunately, seem like an omission in the initial extended connect draft, because it talks like happy path. What happens when, you know, the other thing does what you need? But as we've continued to exercise this extended connect extension point kind of thing, we're creating more scenarios like you illustrate here: the thing exists, but it's not that one. I see this pattern quite often of people are like, "Oh, let's look through the list of status codes and this one kind of sounds okay and this one's right." All of them feel wrong to me. Like, I don't want to litigate too much here and say, like, "Oh, we're going to have to go get another status code," but I kind of wonder what was wrong with 404. Like, I know we said – or well, I don't know. My intuition from reading up is it didn't feel right. But I don't know. If you don't want to serve the thing because of conditions on the request and what it should be versus what it is and what it isn't, then it's just – it's just not there, you know? Try – try different requests in time or space or whatever it could be. But again, I don't know if we need to boil the ocean too much on this. What is the expectation on clients to deal with the status code? Like, to me, that's the question. And again, that's the reason for picking one, which is: if you served a 406 and you read the RFCs and the semantics of what the client could do with that information and what the server is trying to convey in the response with additional metadata and it gets complicated quickly. So path of least resistance here, or boiling the ocean and asking more HTTP folks. That's as much as I've got at the moment. It doesn't feel insurmountable though, and it's if this is like the blocking issue for us being done, we should really just get it sorted because it's just a number. Thanks.
Eric Kinnear: Yeah, I do notice the depth of our queue here. So, yeah, we did start with 404. There was a suggestion to use something else. I don't think we have a super – there's no very opinionated view that I've seen anyone express. So this is more of: let's truly bikeshed what number we think is the most useful to people. If we truly faceplant on this, I think 404 is fine to just leave for everything. But let's – let's drain our queue and see where we go. Christian.
Christian Huitema: Yeah, I must say that as I am implementing WebTransport over a minimal web server that is just there to support WebTransport, I am a bit puzzled by things like that. And like, we have two levels of negotiation. We can say the client connect to this URL, or you can say the client use that ALPN in WebTransport. And that gives us two ways of multiplexing on the same resource. If I am lazy and don't want to implement the ALPN negotiation protocol, I could map one ALPN, one URL, and things like that. So some clarification of what is exactly expected would be very nice for dumb implementers like me. Then the other question that I have is one of privacy. There is one particular scenario in which you have authenticated the client and you say, "No, that client shall not use WebTransport, it shall not use that particular resource." You answer what do you answer there?
Eric Kinnear: Yeah, I think that's a good point that you can both use the resource itself as well as WebTransport's above-layer negotiation. There's also: what do you do when you say, "Hey, I don't allow extended connect" versus "I do allow extended connect, but only for WebSockets and not for WebTransport," which I think is kind of the key for do we need to distinguish that. Mike.
Mike Bishop: Mike Bishop, no hats. I think to Christian's question, if the server has already authenticated the client and declines to answer the request based on who the client is, that's pretty squarely 403. We already have that covered. 405, as you indicated, like is great if you don't support any kind of connect. But if you support connect but not that... it's not really 405. So I kind of think 406 makes the most sense. But yeah, I agree this is a difficult one with no compellingly obvious answer. Thank you for noodling on it.
Eric Kinnear: Yeah, I think that's – that's a good point on – on 403. And at that point, like, I think once you've – once you've authenticated a client, you're having a specific conversation with them. I don't think that that's hugely special or different here. All right, we've got Ben. Ted, just I will shout slightly louder. I will also move slightly closer. Cool. All right, Ben.
Ben Schwartz: Ben Schwartz. Um, so channeling Mark Nottingham from an HTTP directorate review in Privacy Pass – the according to some people, the best practice for documents regarding HTTP status codes is to simply list that some category behavior should elicit a 4xx or 5xx and not attempt to codify the usage of particular specific status codes beyond the standards documents that defined those status codes in the first place. So effectively, like, it's our job to figure out whether the request is valid or not, basically whether it's a – a bad request 4xx or a broken server 5xx, and whose fault is it? And beyond that, it's up to the implementers to read the relevant RFCs and decide for themselves.
Eric Kinnear: Always something to be said for choose your own adventure, right? Ted.
Ted Hardie: Ted Hardie. Um, it would be nice if we could punt because it's certainly definitely 4xx. I do have a concern here that it would be difficult for the client to tell if you return a 405 whether it's actually the method or the support of WebTransport. So it's a little curious to me because I'm not sure what you would actually return for the currently supported methods here. I suggested in chat you consider 426, but it is actually a very weird view of what upgrade would mean. But at least in that you would be telling people at the right level go back and – and use a different substrate. Um, but if Ben's – Ben's right and we can just say 4xx and – and leave it to the HTTP director or somebody else to figure that out, I'm okay with that. I would say though again it – it feels a little cheaty, um, because I don't think we would get consistent behavior across the implementers without some advice just based on the conversation we've had today.
Eric Kinnear: Yeah, so, um, I think the discussion clearly eliminated 406, because that's talking about media types and this is not about media types at all. So, um, I tend to think that 405 is okay, um, but I do think there's a question here that we do want to answer. And I think Ben's get-out-of-jail-free card doesn't work for the reasons that – that Ted elucidated. We do want some sort of certainty on the client side about whether the server supports WebTransport. And I guess for me the question is whether or not method not allowed or 405 maps cleanly to this notion that the connect or the extended connect is a method in itself or whether the details of the protocol that's being chosen underneath the connect is invisible to the status code. And from my perspective, I sort of see extended connect as an extension of connect into a new class of methods, and so using 405 in that context sort of makes a degree of sense. Um, but clearly other people don't think that. Unsupported media type doesn't work. The upgrade required – I mean, well, clearly you just asked for an upgrade and you didn't get one. So, um, I think 426 is kind of nonsensical. 400 would also work here, um, but 400 is far too generic and it's not giving us information that the clients ultimately look for. So, um, I'm tending to think towards trying to figure out whether or not we can add some sort of header field or something so that we can be more certain about what the semantic is without having to choose a status code, because there is that possibility that 405 just means that connect isn't recognized as opposed to connect and specifically WebTransport not being recognized.
Lucas Pardue: I always find the IETF idea that IETF, the experts at IETF can't figure out what to use, so we'll leave it to implementers, like totally insane. So I'll reject that idea. But what's important to me is not about what it is, everybody's thinking about what it is, it's you have to give some unique signal to the client of what it needs to do next is how we need to think about this. And 405 doesn't – I was thinking 405 would work but I'm not sure it does. It seems like there's multiple errors where what I need to do next is different that would both be getting those 405s. So, um, you know, it's not expensive to get a new error code. I – I don't know, like, but I think we should just – we don't have to – we have to figure out what are the errors that can happen at the same time and how well you know what to do next. And if that means we need a new error code, whatever. Replying to Ben's comment. So, you know, generally we don't like to define new status codes, but um... oh, sorry, Martin, did I jump ahead of you? No, okay. Um, so I put in the chat something you can consider is a problem type. That's something I'm working on in a different working group for different needs. That might help fill the gap that this protocol pseudo-header extension field has that we don't have, like "I do support this method and the extension of it but specifically I don't support this sub-protocol negotiation like for that resource." Might be – might be an option. I – it's probably something I could sketch up because I've been working on it anyway. Um, if people don't feel allergic to that. Um, I'll see what's nice with that is it doesn't mandate a status code. You can recommend one but it doesn't like strictly need one or anything. Yeah.
Eric Kinnear: Cool. Thank you. I think it sounds like our next step here is we will have a similar conversation with many of the folks in this room and a few outside of this room in the HTTP directorate about new status codes versus if you don't want us to do that what would you suggest. Um, and the point that you already know from the settings whether or not WebTransport is expected to be supported is potentially something that we could use here but doesn't extend to the rest of everyone using extended connect. Um, so I'm – I'm hesitant to say that we need to have this WebTransport document be the thing that bites off fixing this for all extended connect users, but it would be nice to have some way to say extended connect allows you to request a set of things and the person you requested them from might choose to decline that request. All right, let's pop onto our next slide. So that was our only H3 issue. Um, so please give the document a full read. I know for many of you, even though we've got some great feedback and issues that have been filed about different portions of the document, it may be a while since you've read the whole thing from top to bottom. Um, so now is your moment. This is a great time to do so. Next slide, please. Let's talk about H2. Next slide. A couple of updates here. So we have a parallel update to the security considerations with very much the same content. We've had a couple of comments on that saying maybe it should have slightly different content. Um, so let's get that sorted out as we look at the rest of the last call feedback. Um, same idea on – on the note around flow control updates and not waiting for people there. Um, another one which was a good catch is that we have a setting for initial max stream data for bidirectional streams, but we did not actually match the way that QUIC does this with both local and remote initiated bidirectional streams. Um, so we split those out into two different settings for those, which is minor but as you're implementing worth going and double-checking in your implementation to make sure that you caught that change. Next slide, please. We clarified some of the things that happen when you update settings in H2, based on what we talked about at 124, so that text is now in there. Um, it looks good. It should be pretty straightforward. Um, we did exactly what we talked about in last meeting where new sessions basically just stamp whatever the current value is for each of the settings. We also disallowed super large error codes to match H3, so now the errors that you send back for WebTransport are consistent regardless of how they were transported. Um, and we added that last section talking about, "Hey, by the way, this capsule-based protocol could be used over other HTTP versions. Here are the components that you need from said other HTTP version in order to use it," and generally, you know, if you have H3 or you have the capability to split out streams, please go use that instead. This is not the – the thing that you're looking for. Here's what you lose if you try to use it in places you shouldn't. And next slide, please. Yeah, next slide again. Same thing here. So we have closed out all of the remaining issues in H2. Um, thank you all for filing them and discussing them and helping give feedback on that. Um, for the third time, now's a great time to read the drafts. Next slide, please. Victor said Mike question, "Are there H2 implementations that are interoperable?" I know last time at 124 we got things for – I think we don't have one right now. We – we have one in theory at least. Yeah. So, like, we have an H2 implementation. We might even have two. Yeah. So I think – I think the answer there is yes with an asterisk that we are still testing and making sure that interoperable extends beyond works in theory and exists in theory to make sure that that is actually a works in reality. Does that extend to flow control implementations also, like have we interoped on flow control? I thought – we need to check. Yeah. Um, I think we were mostly there, but I mean we're trying. Yeah. We think we do it right. But that – that does come to the broader question which was: we are trying to make sure that these documents themselves are nailed down. They are no longer nearly as much of a moving target as they have been in previous years. Um, so we've seen implementations come quite a long way in the last little bit. Um, so this is – this is a good time to go and update your implementation to make sure that it's on the latest draft. Um, you are unlikely to be thrashed quite as much as you were previously back and forth between different status things. All right, next slide, please. I think it's the end.
Nitya Varshney: Okay, thank you so much, Eric. Um, yeah, I think we have Martin next, but as Eric said, please everyone read the drafts and please file issues on the GitHub as well. Okay, I think we have Martin now.
Marten Seemann: Hello, everyone. Can you hear me? Great. Yeah, just a quick update. Um, I extended the interop runner, which is a tool used that we used during the development of QUIC that runs interop tests between different QUIC implementations, to now also support WebTransport. We currently have four implementations that are participating: Chrome, Firefox via their JavaScript APIs, my own implementation WebTransport-go, and one other server implementation. Um, these tests are run automatically every 12 hours in – in CI, and the results are posted to the website that's linked in the slide. And if you're interested in this, um, you can – you can join with your implementation. Um, building an implementation is very similar to how this works for the QUIC interop runner, so if you're already there, it should feel quite – should feel quite familiar. And yeah, would be – would be happy to onboard more implementations and get a bit – a bigger matrix here.
Speaker 1: Martin, can you talk about what the test cases are a little bit?
Marten Seemann: Yeah, so currently we have a test case for the handshake, which tests the WebTransport handshake and the ALPN negotiation. Um, we have unidirectional streams, bidirectional streams, and datagrams in both directions, so testing that both client and server can open the respective stream and send datagrams. I'm planning to add some more tests later for multiplexing, for probably for stream resets, including the partially reliable stream resets, and maybe also for the parsing of the connection close capsule. If you have any suggestions what else we should test, please – please let me know, open an issue on the GitHub repo, maybe.
Nitya Varshney: Go ahead, Christian.
Christian Huitema: Martin, do you have – I suppose you have somewhere some kind of support explaining explaining to implementers what kind of WebTransport service you're starting implementing and what what kind of packaging you expect, what are the actions and all that.
Marten Seemann: Yes, there's a protocol description in the GitHub repository where there’s a detailed explanation for how – how to build a Docker image and what each of these test cases expect.
Christian Huitema: Can you send the GitHub pointers to all that on the list or in the in some chat or something?
Marten Seemann: I already sent an email to the mailing list, I'll post a link in the in the chat here.
Christian Huitema: Okay, thank you.
Nitya Varshney: Okay, thank you so much, Martin. Lucas, do you want to say a few words?
Lucas Pardue: Yeah, sure. Um, that's effectively the end of our agenda. Um, so we had a short session, but um we've got through everything. Um, thanks to our, you know, our editors for continuing to drive down that issue list. Um, I think maybe back in Madrid last summer we threatened to run a working group last call because we were waiting for interop and kind of having this chicken and egg thing. Um, but um it took us a little while and but we're here now. We have the working group last call in case you missed it. Please do go and review those three documents. I think from my perspective, we're implementers, a lot of us, we like to focus on the H2/H3 drafts, but reading the architecture diagram too, I think, would be a useful exercise just to make sure that the description of what WebTransport is is clear. Um, I don't want to miss out on that one and then find a load of last call issues come in later, or like IETF last call, um, when we could have fixed trivial things and we have to come back to this working group. So yeah, doing those things would be great. Um, Nitya and I were discussing earlier about, you know, what would the next steps be for these documents. I think we suggested um possibly, you know, this is the first working group last call and based on how much feedback we get there could be another follow-up one. Um, like we would always have that in the pocket anyway. We want to make sure this working group is aligned. Um, what other kind of open questions I had in my mind was the level of interop based on, you know, where we were back in Madrid. Um, but from seeing and listening to the presentations today, um, both from the W3C perspective, just getting effectively the feels for work that Martin's doing say for the interop runner in the chat, some people seem very excited by that and trying to encourage them to maybe onboard too. I wasn't aware of the interop 2026 work in browser land either. Those are all giving me a very good confidence that actually we are seeing interop. Um, one of the open questions for me would be is that the latest spec or is that some early version. I think we can go away and and take that ourselves, Nitya as a kind of survey for us to do as part of what would be our shepherd’s write-up, just to make sure everything's up to speed. Um, but yeah, let's see where we get with the working group last call. Um, and yeah, probably looking at taking this forward and trying to kick it onto the IESG. Um, I want to speak to the AD about that too, but let's see. Um, obviously if you recall this set of documents at least for the H3 has a dependency on the partial reset streams, reliable reset, whatever we want to call it. Um, that's been kind of ready and good to go for a long time but also waiting on interop. I think it makes the most sense to to progress those two documents together. Um, there's not been any real change or movement there but due to the dependencies and the state and the life cycle that they are, especially if we're going to be targeting this year to do it, um, I don't see any point trying to stagger them myself. But if if people disagree, do let me know. Um, we have flexibility here. Um, I think that's all that comes to mind in my in my head. Did I miss anything? Do you want to add anything, Nitya?
Nitya Varshney: No, I think that sounds good.
Speaker 1: I might be stealing the queue but I did have a question. So with respect to reliable reset, there's a I see a lot of WebTransport implementations in the chat. Presumably everybody implemented reliable reset, so should be good, right? Uh oh. I haven't heard everyone. Yeah, I mean we all – yeah do, right? It said you had to. Did you implement that? Yeah. Cool. All right that's two. I mean this isn't the QUIC working group, um, maybe give that feedback there that if people want to move that ahead faster, there's nothing really stopping us other than time. Um, but that's an option too, I don't mind. But ultimately its main consumer is is WebTransport, so.
Nitya Varshney: Okay, um, I think that brings us to the end. Um, yeah, thank you everyone. Let's continue to do interop, file issues, read the documents, and yeah. Let's end early. Thanks. Thank you. Already the stage. Bye. See you in the draft version. Bye. See you. Bye. Thanks, everyone. Bye. Bye. Oh, my god. You're already. Bye. Bye. Bye. Oh. Bye. Bye. Good. Bye. Good job. Good job. No, seriously. Oh, good. See you at the draft version. Bye. Okay. Bye. Thanks. Everyone. Bye. Bye. Oh my god you're already bye bye bye oh bye bye good bye good job good job no seriously oh good.