**Session Date/Time:** 16 Mar 2026 08:30

**Speaker 1:** ...each other's selves when we're talking. Thank you.

**Speaker 1:** Okay, we are at the bottom of the hour and we've got a very full room here. Kidding, I don't know if you guys can see that, but it is time for us to begin. Um, yes, just wanted to make sure that our speaker is here. So, greetings, welcome to the CBOR working group. Um, let me... there we go. Uh, so this is a summary of the Note Well. The next slide will be the Note Well. Um, but just to be clear, you've already agreed to the guidelines when you registered. You don't have to read them on the next slide because you already did agree to them. And basically, IETF participants are expected to behave in a professional manner, extend respect and courtesy to their colleagues at all times. If that seems odd or weird to you, definitely go to the link there on the slide.

**Speaker 1:** And well, that's... oh, it just lagged here. So, this is the official Note Well. I'm only going to leave it up for a few seconds because you did already agree to it, and again, if this is surprising to you, please go back, you know, please go to ietf.org/about/note-well and see, or of the many people in the room, you can scan the QR code. Um, so you've probably seen some of these tips, but very important for remote participants. Um, using a headset seems to be very helpful. Um, and definitely have your audio and video turned off. We'll sort of like try to find if people are... are... um... if that's not working. And um, please do state your name because we are going to, you know, have to do minutes from this and such like that. Any questions yet on the meeting tips? Not seeing any.

**Speaker 1:** Uh, these are just general resources. Uh, if you're looking at this remotely, you probably can't click on any of them, um, but they're also the links that you got when you registered.

**Speaker 1:** So, we've got a long agenda, but it's... it's not... it's a one-topic agenda. Well, two topics. We're doing an intro now, and then the agenda that the working group came up with is, in fact, just focusing on the [CBOR Serialization and Determinism](https://datatracker.ietf.org/doc/draft-ietf-cbor-serialization/) draft, especially recent changes and what seems to be ready to go forwards. Oh, and just as a note, our AD is in the room as well, so he will see what we're doing and such. Um, with that, Laurence, you are up. Would you like to be doing the slides or would you like me to do them?

**Laurence Lundblade:** I'd like to do the slides, and is my audio okay?

**Speaker 1:** Yeah, your audio's fine, and let me... oh, I... okay, so Christian just gave you the control. Oh, wait, no, Christian, why don't you let him control? So if you just give him slide option.

**Christian:** Laurence is in control, and the right slides are up.

**Speaker 1:** Oh, okay, very good. Thank you. Okay, so I'm going to turn off this, and Laurence, you are up.

**Laurence Lundblade:** Okay. Oh, so the slides are not preliminary anymore. I... I didn't update them um when I published them a couple of days ago. So, um... so just a status on the [CBOR Serialization and Determinism](https://datatracker.ietf.org/doc/draft-ietf-cbor-serialization/) draft. Um, this is the same status that I'm reporting as of um the March 4th interim. So, the draft -04 was published. In it, "ordinary serialization" was renamed to "PreferredPlus". The appendix that had deterministic serializations for common tags was removed; that was Appendix C. Um, the introduction was expanded to include some rationale for um why we're doing this. Um, the control operators were renamed um because of the the name from "ordinary" to "PreferredPlus" and because the the control operator `.det` was taken. Um, and then there were lots of wording improvements, um much of which came from Rohan's review a few months back. So that was the -04 draft.

**Laurence Lundblade:** And then uh this is largely the same as from the interim. Um, there are five open issues um and uh two of them are uh just some writing work, um so nothing to discuss. Um, and uh then there was the idea to move Appendix B to the main body; uh that was a request from Rohan. Um, we haven't had any discussion on that, um so nothing's changed on that. There was a discussion to move the NaN appendix to another document. This is the appendix that explains NaNs in detail. Um, I'll probably do that, um I'm generally in favor of that, but haven't done that yet. Um, then the the whole test vectors and examples, that's the big thing, um and uh I've started some work on that. I think I actually published a PR for that, although it was pretty crude. Um, and then there is also a PR from Carsten uh suggesting changes to Section 1. I've glanced at them, but I don't have um haven't kind of worked through all of them yet. Um, so I don't have too much to say on those yet.

**Carsten Bormann:** Yeah, quick comment. Rohan sent some change requests for this PR, and I started working on them, so we are making some progress there.

**Rohan Mahy:** Yeah, and sorry that I submitted my... my comments so late, but...

**Laurence Lundblade:** Okay. Um, so uh before jumping into the examples and test vectors, any other comments on the draft status or the issues to be worked on in the in the draft? Anything, any kind of top-level comments or discussion on that?

**Carsten Bormann:** Well, we are having an interesting discussion on the mailing list, um so I think we still haven't quite found out what we are doing here. So, I think we should continue that discussion on the mailing list, um because these are fine points and we want to make sure that we think about them properly.

**Laurence Lundblade:** Yeah, I... I mean, I... I agree. Um, we keep, I don't know, thrashing things on the mailing list in some stuff, and it it keeps, I mean, I'm in favor of it because I think it's it's continuing to to drive clarity, and I don't think it's like ratholing and wasting time, so...

**Laurence Lundblade:** Okay. So, test vectors and examples. Um, so um I'm going to talk for a little while and then I'm sure we'll have lots of interesting discussion. Um, so uh my proposal is we're testing the three serializations that are described there, and it's about the serialization. It's not about general CBOR testing, um not about like fuzzing or anything like that. Um, so like in the in the CBOR I'm proposing to test, nothing is invalid and nothing is not well-formed because it's all about serialization. So, the serializations, uh the three are of course General, PreferredPlus, and Deterministic, the three described in the document. Um, so that's that's the focus here is is those. Um, another observation here is that uh CBOR library support for serializations is is really going to vary by library. Um, and uh kind of have to think about this and accommodate this, um how this how this goes. So, um so you might have one library that supports all three serializations and perhaps they have three distinct modes: you put it in the mode for the serialization you want and then it runs in that mode. Another library may support only one serialization. I think it's perfectly reasonable for a library, for example, to support only Deterministic serialization if it's operating in an environment where that is is reasonable. Um, so then each library decides how to use the test data based on features.

**Laurence Lundblade:** Um, okay. So, um I thought about some data, test data, and um here's the what I came up with. Um, so one data item, a test data item for the integer zero. So there's a description of it, the test. So this is testing the integer zero. There is the EDN representation of it, which there actually might be for maps there are actually multiple EDN representations for a particular thing. Um, and uh then there are the three serializations. Yes, the file is [CBOR Extended Diagnostic Notation (EDN)](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/) and um I ran this thing through cbor.me and it decoded it, so yes. Um, I think that's a useful thing. This is not my forte, but I think it's I think that all work. Um, so then there's the then there are description, the representation, the um and acceptable serializations for the item. Um, this is not an exhaustive set of of serializations, but it represents the the major ones. So, you can serialize in general serialization, you can serialize zero, you know, as as those the four different five different uh length argument lengths, or you can serialize it as a big number or as a big number with an empty string. Um, in PreferredPlus and Deterministic, there's only one serialization. So that's kind of introduces you to the the schema of the test item.

**Laurence Lundblade:** And then here's the one, um I don't know if you can see that one okay, I'm not sure if you can. Um, um here's the one for a map with three items. So, in this case, because there are six, if you have a map of three items, there are you can order that six different ways, including in the EDN. Um, and map order is not significant in the data model in CBOR, so uh it's perfectly okay to write the EDN in three different orders. Um, and if you're really testing this exhaustively and thoroughly, you're going to you should test against all those three different orders. Um, and then, you know, it it serializes in General serialization in three different orders or six different orders, same with PreferredPlus allows six different orders, and then Deterministic allows only one. Um, so these two example uh data items are kind of the bracket, the sort of the top one and the bottom one. And then I picked about 10 others um to that I thought would be uh kind of reasonable to fit in here and and hit all the data types and um such. So, um...

**Rohan Mahy:** Um, on the previous slide, the general serializations, you could easily put more um, you know, more variations. Like you might just put a variation of using non-preferred size for for the length of the string and um and maybe put a variable length, an indefinite length string. Just a thought.

**Laurence Lundblade:** Yeah, so I'm uh hitting that with uh other places. So, if you look at the bottom uh near the bottom of the slide, I don't have a slide for that data, but like the array [1, 2, 3], so the the serializations for that are um both uh definite and indefinite. For the text string "Hi there", I have uh the thing with indefinite yeah, indefinite length string and a definite length string and several variants of the indefinite length string. Same for the byte string, there's a couple of variants of that. Um, okay. And then, you know, we've got a NaN and infinity and a NaN with a payload and for, you know... So that's the basic idea. I mean, I don't want to go too many of these things, but we can, you know, certainly add more as long as they keep adding value.

**Laurence Lundblade:** Okay, so so what do you do with these with this test data? Um, so uh there's the obvious tests, at least these these were kind of obvious at first to me. So, for each of the three serializations, you encode the EDN and see that it encoded to one of the allowed serializations for the particular um for the particular serialization. So, for example, you encode zero and if you're in if you're testing General serialization, you encode zero and make sure it's one of those seven or so different serializations. Um, if you're um encoding Deterministic serialization, well, there's only one possible right answer for that. So that's the encode test. Um, the decode test is you decode everything in the in the list and uh for for the particular serialization and make sure you get back the value zero.

**Laurence Lundblade:** So, next, the next test is just for checking decoders. I think it's fairly obvious what happens here. Um, so uh you take something like a PreferredPlus checking decoder and you run all of the data for General serialization through it and make sure it errors out except for what's allowed for PreferredPlus. And then you take the Deterministic checking decoder and run everything from PreferredPlus and General serialization through it and make sure it errors out except for the one allowed or for the the allowed Deterministic serializations. So that's for the checking decoders.

**Laurence Lundblade:** I'm reading the comments here. Okay. So, this the next one is where it gets interesting: what you do with a non-checking decoder that is fed serialization that is that's kind of not for it. So, for example, if you feed all the different General serializations into a PreferredPlus decoder that is not a checking decoder, what does it do? Um, and this has some relation to what's discussed on the list these these days. So, so I believe um it will it can decide to error out, for example, it's a PreferredPlus decoder, it decided not to do uh indefinite length, so it errors out, and that's an okay result. It's it's okay for it to error out. It's also okay um that uh it could successfully decode it, so for example, a non-shortest length CBOR argument, so you could succeed on that. And this is going to vary library by library and what features they support and all of this. Um, I'm going to show you the the really the one that really gets gets you on this, which is of course NaN payloads. So what is a PreferredPlus decoder do that's not in checking mode, how does it respond to a NaN payload? The answer I have here is basically anyway it wants. Um, the requirement for PreferredPlus a PreferredPlus decoder that's a non-checking decoder is that it decode all of PreferredPlus correctly. Um, that requirement doesn't mean it can't decode other stuff as long as, you know, other parts of General serialization. So, um and then like how do you decode a NaN payload? Um, you can error out because in this case it's a PreferredPlus decoder, you can error out because it's not required to to handle NaN payloads. You could convert it to a quiet NaN, some CPU instructions do that. You could return it as a double or a single with the the NaN payload, or you could even make up your own structure to represent a NaN payload with the sign and the payload bits. So, um... that's actually all the slides I had. Um, there's there's more text in the PR, um and I think we can have some discussion now. I didn't read all the comments yet.

**Speaker 1:** So, um I think it would be useful if we split the discussion into two parts. The uh the first slide, you know, everything other than the uh test vectors, and let's let's go through those first, then go to the test vectors because they are completely different topics. Barry, agreed?

**Barry Leiba:** Yeah, agreed, and what I was going to say is that uh it strikes me that the best approach is to put the test vectors in a separate document that's an informational reference from this one and that refers to the main document normatively. Uh, so comments on that during the discussion as well.

**Speaker 1:** Okay, Hank, you're up first. And again, we're talking about the first slide which you weren't here for.

**Hank Birkholz:** Oh, I thought I wanted to comment on test vectors, if that is appropriate I'll sit down.

**Speaker 1:** Test test vectors later.

**Hank Birkholz:** Okay. Yep.

**Laurence Lundblade:** So, I'm just to be clear, I'm not prepared for any discussion other than test vectors, and I thought we had covered everything, I thought the whole discussion was going to be on test vectors. So I'm surprised at this agenda.

**Speaker 1:** Well, it it may it may be done now, but I just wanted to make sure that we in in the group that we had a conceptual separation even though Barry and I hadn't talked about it, especially with Barry's idea of it's going to be a different document. So, um if you can go back one uh or uh go forward one or two of just where you have some of the uh the list of things that... Yes, stop there. So, um you've got two To-Dos, well, you've got three To-Dos there, the PR at the bottom is... So, Rohan, um you're online, are you able to get the additional security considerations to the working group soon?

**Rohan Mahy:** Yes.

**Speaker 1:** Okay, great. Where "soon" means what?

**Rohan Mahy:** By Friday.

**Speaker 1:** Excellent. Yeah. Great. Um, the second To-Do is the whole test vector example thing. Um, Laurence, so for the last bullet, the PR from Carsten... Yes. Sorry, someone just said speak into the mic. Um, thank you. So, the PR from Carsten, Laurence, do you feel like that that's something that can be dealt with so that you could have a new draft within a week or so, or like I I don't know how you as the author feel how big that is. Are you, you know, is it fairly tractable um to to get it so that the working group can see um Carsten's words with your interpretation? Is that like is a week a reasonable amount of time for that?

**Laurence Lundblade:** Um, I'm I'm either going to work this week I'm either going to work on test vectors or the PR from Carsten. I'm not going to work on both this week. There's there's...

**Barry Leiba:** Fair. Therefore, leave the test vectors for later. Let's get the main document going.

**Laurence Lundblade:** Um, I think the test vectors are actually pretty important and that's why I chose to to have the discussion on them. Um, I...

**Speaker 1:** I I think the test vectors are important also, but I think they are an adjunct to the main document, not necessarily part of it.

**Laurence Lundblade:** Yeah, I I don't, and Carsten doesn't either. I think they're actually quite important.

**Speaker 1:** Say more about that, please.

**Laurence Lundblade:** Um, when I started writing the test vectors, uh working through them, it made me understand what we were doing better, particularly like the last the last slides I presented. Um, and there are examples also, um they help you understand how these apply to a library, um and um I mean I think there's a a lot of depth and and it makes all the stuff that we're discussing in prose real. So I I think they're... it really illustrates the difference in, you know, what the different serializations do and you can really see it there, you know, and it's laid out.

**Speaker 1:** Rowan, you're next.

**Rohan Mahy:** Yes. I mean, I I don't disagree with anything you just said, Laurence, but the I don't think that we're going to have test vectors where we're going to have conversations that are going to spin off for for days and weeks at a time because we couldn't come to consensus on on some aspect of a test vector. I think it's just work, it's just turning the crank and doing some and there's going to be some light back and forth, but the text, you know, the other open issues uh that they could potentially take an unbounded amount of time unless we focus our energy on them first.

**Carsten Bormann:** Yeah, um I somewhat agree with Laurence. I I think it's it's really elucidating to look at these test vectors and I think most people who uh actually like the current draft haven't really thought about the issues that that are being nicely demonstrated by by the test vectors. So, I think uh at the point where we are making a decision whether this this draft is going into the right direction, uh we probably need these test vectors. And I wouldn't call them test vectors, but examples. They are called examples in RFC 8949 and they are there to illustrate the the main text of of the document.

**Speaker 1:** Okay, I'm next in the queue. Um, so I I agree with Rohan, and what I'm the question I have for you, Laurence, that uh and kind of following up on what Carsten said, is there's we need the examples so that readers of the document can better understand what we're saying, and there's we need to write the examples so we as we're writing the document get it right. And I'm trying to tease those apart, that uh the extent to which we can write the document and do the examples, test vectors, whatever you want to call them later or alongside it without holding up the main document. If if they're necessary for us to get the main document right, we need to understand that and we need to understand why. So, go ahead and comment on that. Thanks.

**Laurence Lundblade:** I think it's helping get some of the the framing and introduction uh text correct. The hardest stuff to get correct.

**Speaker 1:** Okay, okay. Sounds good. We will take that under advisement, and then let's talk about test vectors. Hank, you had jumped up earlier.

**Hank Birkholz:** Sorry, no hand raised, this is Hank. Um, yeah, have to for the minutes. Um, I think there are like a low low number of uh four-digit examples. Um, it feels to me that's not the the internet draft is not the right place for that.

**Speaker 1:** What do you think there is a right place, or are you...?

**Hank Birkholz:** Yeah, yeah, I would think that's a GitHub thing or maybe a Wiki if necessary, but I would like to see them in a GitHub repository that makes a lot of sense. And not in the final document and and then a few selected examples in the document to elaborate on that as a representative thing that I think they're that is good, because if you engineering stuff, you are going to the examples and use what is closest to the thing you want to do. But for the for the whole set of the examples, and if there is a different place, I think it's better. Yeah.

**Laurence Lundblade:** Um, you're saying that there are too many of these things here and um it will be too much of too much in the document. That's that's what you're saying.

**Hank Birkholz:** Yeah, I assume it's like 2,000, 3,000-ish today. So that's obviously not in an internet draft, sorry in an RFC in the end.

**Laurence Lundblade:** 2,000 what?

**Hank Birkholz:** Examples. Or test vectors, which is a word that you can wrap around an example if you know what you're doing. So I would call them examples in any case and uh where did you get that number?

**Hank Birkholz:** Uh, I think last time when we IETF 125, when we were at the hackathon.

**Laurence Lundblade:** There's 13 lines here. No, there's 13... these are the 13 lines I'm proposing to put in the.

**Hank Birkholz:** Yeah, okay. This this could be good these 13 is a good number, 3 plus 10, was a good number to to be in an internet draft I guess, but I think the not not all examples should go into the that we have.

**Laurence Lundblade:** I I just want to put these 13 in. I I want them curated. I don't want any enormous... yeah, there's other people that have lots of things, but my proposal is only like these 13 and the they would exist in EDN files in GitHub and then they would be included in the document. Um, I mean I'll build the EDN files anyways and then, you know, if we if we want if they turn out to be too many, then we can take some out, so...

**Hank Birkholz:** Yeah, no, I I'm not afraid of that number. I went to the screen because I'm a today I'm a little bit short-sighted. Okay. And and uh yeah, those look okay. I don't know if there might be one or two that is a fringe case uh that we could skip, but uh this is minuscule, so we can do that in the other document and that's fine. Okay. That's not for today. Okay.

**Laurence Lundblade:** Um, oh no, no, sorry, sorry.

**Speaker 1:** No problem. Dave.

**Dave:** Yeah, I just want to speak in favor of includ- not calling these test vectors. I think that's calling them test vectors is what we're getting wrapped around the axle on. Um, examples are extremely important, and I know from my own standards authoring that whenever I say paragraph blah blah blah paragraph example, for example, and then I give something, examples are very visual. And I know that when when reviewers read a document for especially for the first time, they go straight for the example and and that's what they read, and then maybe later they will read the prose. So, I examples inline or at least in an appendix in the document, um I think are extremely valuable and I consider those to be different than test vectors, which are boring and thorough and, you know, they're very different in my mind. And I think the document definitely needs to include examples.

**Speaker 1:** Thank you. Anyone else on this? Carsten, you have your you're unmuted, were you going to say something?

**Carsten Bormann:** I I don't know how to work this yet, Laurence. I'm on a microphone in the same situation we have some...

**Speaker 1:** We have no idea what you just said, Carsten, it's uh heavily uh lots of distorted.

**Carsten Bormann:** Okay.

**Speaker 1:** Give the chairs a moment here, please.

**Speaker 1:** Okay, so we we just we had been talking about this a little bit before, that uh as everybody knows we've parked [Packed CBOR](https://datatracker.ietf.org/doc/draft-ietf-cbor-packed/) and [CBOR Extended Diagnostic Notation (EDN)](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/) until we get through this document. I think we're at a state in this document now where we can um work on the test vectors so the examples, let's let's just try calling them examples, where we can we can let you work on the examples on the side and go back to the other documents and and start working on [Packed CBOR](https://datatracker.ietf.org/doc/draft-ietf-cbor-packed/) and [CBOR Extended Diagnostic Notation (EDN)](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/) and get them revive them and get them finished. Um, what does the working group as a whole think of that path? Not that we've given you much like you just heard that, but because we just made it up, but uh Hank.

**Hank Birkholz:** I'm just going to say yay.

**Speaker 1:** Right, somebody's happy. Um, and and my sense is that we go we should go for [Packed CBOR](https://datatracker.ietf.org/doc/draft-ietf-cbor-packed/) first and um because I I understand there are people waiting for that to finish and um yeah. Some discussion. Rohan.

**Rohan Mahy:** Yeah, I mean, SD-COT has a currently has a it has a normative requirement on on EDN.

**Speaker 1:** Okay, so maybe EDN.

**Rohan Mahy:** Yeah, so I think yeah, actually I think EDN is probably closer to finishing anyway. Um, but Andy.

**Andy:** No, I I was mentioning this out in the hallway, the there I thought there was a someone who had a dependency on EDN, so... Yeah. We're not the only ones, but I know SD-COT does because because we use it extensively to describe what SD-COTs look like. So.

**Speaker 1:** So, but Andy, given that this is sort of you were the one who had said let, you know, with us, let's do serialization first as a way to see if we can be moving forwards well, does this park, look at others, does that sort of meet your your since you are the one testing whether we are moving at a reasonable pace.

**Andy:** Yes, that helps. Okay, great. Thank you. Great.

**Speaker 1:** And there's more in the queue. Rowan. Old hand. Laurence.

**Laurence Lundblade:** Uh, I'm just going to say my proposal for the serialization draft is to uh get the the examples section into uh at least a reasonable shape and publish a draft -05 with it in about two weeks. And if there's something else that uh manages to get done in that time, that'll also get uh pulled into the -05 draft. But um the main uh focus for the -05 draft would be to get the examples in and like the description and the text on how to use it. That way it's out there for everybody to look at and then uh I can go back to working on the other stuff while people are looking at the at the examples.

**Speaker 1:** Great, great. Thank you. That sounds good. Hank.

**Hank Birkholz:** Uh, yeah, this is Hank. I just uh want to second Rohan. Yeah, yeah, our draft has a normative dependency on EDN, so but you can do one thing and also not not do the other I guess.

**Speaker 1:** Okay, okay. So, um Laurence you're still in the queue, are you wanting to say something more about this or not? Okay, great. Um, good. Is there anything else? We still have time, but we also now have a lot of stuff in front of us. Anything else for this meeting? We the chairs will talk since we're both here physically in the room with at least a half of a dozen people. Um, and we will we'll move what we just talked about to the mailing list. Um, I we don't have to ask the mailing list is this what you all want to do, we're able to do that as long as our AD agrees and he just has, so... but he's getting up to the mic again.

**AD:** Can you can you restate for the record exactly what the plan is?

**Speaker 1:** No, because we... Okay. Oh, okay. But but we will restate on the list within the day or two what the plan is. Okay. Right. The the general answer is to let Laurence continue working on serialization and the examples while we unpark one or both of the other documents and start and resume working on them, likely starting with [CBOR Extended Diagnostic Notation (EDN)](https://datatracker.ietf.org/doc/draft-ietf-cbor-edn-literals/). Okay, okay.

**Speaker 1:** Okay, if that's it, I think we are finished for the day. Thank you. Um, this was very productive. Um, we will yeah, so so Barry and I will Barry and Christian and I will come to some agreement, we'll just start mailing with Christian soon, um and uh come up with a plan and we'll we'll send it to the list. Um, Andy, do you want us to try to talk to you in the hallway before we do that?

**Andy:** No, I think if you can come up with an agreement, I don't think I need to approve it. Okay. Sounds good.

**Speaker 1:** So, Christian, we'll try to grab you offline so we can figure out a time because you're not in Asia time zone, I assume. So.

**Christian:** Um, no, but I'd be like given that we have a bit more of meeting time, we could just like continue continue... Yeah, yeah. That sounds good. Why don't we do that after we we shut this down. So, okay, very good. It's what, something like um 10 10:15 a.m. your time?

**Christian:** Yeah, I have a bit I have a bit of time before my next thing starts.

**Speaker 1:** Okay, sounds good. So, thank you very much to the group. We will uh shut down the meeting. We're going to go have a meeting, um and see you all on the list. Thanks. Thank you all, bye.

**Carsten Bormann:** Thank you.

**Speaker 1:** Thanks, ciao. Do we have a way of shutting it down or do we just let it...? Oh, we just yeah, I don't think there's a way of ending the meeting, I think we just leave it, I guess. I thought when you leave, I thought when the chairs leave, you can say end the meeting. Uh, didn't... all it said is uh don't log me on automatically next time is the only option, which is different. Okay, um at least it's working, right? Yeah, ish. Carsten to unmute plus still showing the slides, so um it doesn't matter, oh, now it doesn't. There we go, something in these samples. Um, so I've been I've been in at CB I can see I can see... Yeah, so so my bad for not explaining deeply into more detail, but I I had heard that there was a which is fine. So, so why don't we take the what's a good way for the three of us to...