 I don't think, I think that is Vladimir at the bottom, but I don't think he has a microphone yet. We'll circle back around. All right, let's go ahead and get started. Lots of fun topics. All right, community time. Are there any, anybody on the call, not a normal attendee or anybody have any community related topics they want to bring up? All right, moving forward. All right, SDK subgroup. We were supposed to have a meeting right before this. The topics really came up, so nothing really to bring up there. Demo call. So we are making some progress on the demo. We hopefully will have a call right after this one for those of you who can make it to keep working through the sample workflows and stuff. For those of you who are kind of waiting on the sideline until we get everything nailed down with concrete examples for you to start coding to. Not quite there yet. I feel like we are getting really close though. So keep an eye out. If you're not on the Cloud Events demo Slack channel, ping me and I'll invite you. That's where the latest information will be discussed. Moving forward. Kukani Yu. The agenda is out. I don't think we've made any changes there or made any progress relative to presentations, people to review. The Practitioner Summit agenda is out. I apologize. I don't think I put the, I think I put a link. No, I didn't think I put it in our Slack channel. I'll try to find the link to the agenda. The working group session, the session that Kathy and I were going to present that, that one was accepted. So we do have something there to talk about our work here. And that will include a teaser for the other sessions that we have during Kupkan itself. So we did get in there. So that's good. Kupkan Sien. Oh, I'm sorry. This agenda doc here is actually not correct. That's actually for China. I apologize. So if just as an FYI, in case you did submit something for China, the agenda is out. Our group did get 135 minutes session for Cloud Events and 135 minutes session for serverless. They didn't have enough room for intro and deep dive. So we do at least have those. And we'll in the future be talking about the planning sessions for those. But I think it's a little far out. So we need to worry about it quite yet. I have not put together the presentation yet for yearly review for May 7th. And that's available for you guys to review. I'll let you guys know. And with that, we can jump into PRs. But did anybody have any topic at a higher level they want to bring up before we jump into PRs? All right, cool. Moving forward then. All right. Tim opened up a PR. Now, normally, because this was opened up, I believe just yesterday or so, we would normally ask people to wait. However, this is just a very minor change to the primer doc. And it's just a sample AWS Cloud Events. I'm sorry, Cloud Watch event. So I thought maybe you guys could just take a quick look at this and approve it. It should be very, very obviously non-carnit diversals. And this is just what they do today. And this is just in that section of the primer where we say basically, you know, what's in the community today and so people can see what's out there. Merged. Thank you. Kristoff, yes. Quickly, I was also thinking about maybe taking out one or two of the both the other AWS examples, I mean, because this is the one that actually matters. Does anybody be upset? The other ones are some random SNS thing and so on. When it comes to events, though, the one I put in is the one that matters. Okay. Kristoff, you have your hand raised. Did you want to bring up something related to this? Just a question. Why is there a white space in the resources? That seems a bit unusual to me. Oh, you mean right here? Yeah. Okay. Do me a favor. Assuming we approve this, could you update the PR? Actually, wait a minute. There's more updates then. So is there any objection then to not only accepting this addition with the space fixed, but then also removing per Tim's request? So there's the SNS one and I guess, oh, here's the other one. Okay. And then we would miss one. So you want to remove those two and then add that one, right? Correct. Okay. So you don't care about those scenarios? They're not really general purpose events. They're just bundles of data that people happen to send on a particular messaging service. Oh, okay. So this is just, so they don't depend on the channel. They're just chasing the people through in there. Yeah, I actually have no idea what they really are, to be honest. Okay. Well, then that makes sense to drop them. Yeah, I mean, especially since you are the AWS wrap, it makes sense that you're asking them to be dropped and they should be dropped. But Vlad had your hand raised. I'll update the PR. Yeah, just one last quick question for Vlad, since you raised your hand a second ago, is there something you wanted to add to it, Vlad? No, my concern was this rest. Okay, cool. Okay. So to be very clear, if we approve this, Tim will remove the space here, and we'll remove SNS and the kinesis one. Any questions on that? Okay, any objection to approving it? Cool. Thank you. Just editorial. I might ask people to observe the astonishing similarity between the one that I put in and the cloud events structure. Stunningly. Yes. Okay, let's see the space and remove the other AWS examples. Cool. Thank you, Tim, for that. Appreciate it. All right, this one, I think I might have opened this two days ago. Oh, 22 hours ago, so a little over a day. Okay, so this one, while it is new, it is very, very straightforward. Basically, there are a couple of editorial things that Clemens did not get a chance to pick up before we approved his subject PR. You can see here it's just changing stars to dashes. Just for consistency with the rest of the doc. And I believe someone had a comment that Clemens forgot to pick up, which is just add the phrase if present, it must be an unempty string. Just adding if present. And that's mainly just to be consistent with the rest of the spec. More stars to dashes, fixing some blanks at the end of lines here. And the rest is stars dashes and blanks. Hopefully you guys are okay with these strictly editorial changes. I am certainly thankful. Oh, one last other thing. Subject attribute I put back takes around subject that way it stands out as not an English word but rather an attribute name. Right. Okay. Any questions or concerns about this one. Strictly editorial nature. Okay, any objections to approving. Well, thank you guys very much. All right, Christoph. I believe this is an extension. Yeah, this is an excuse we discussed this, I don't know, some time ago. I'm waiting for zoom to get out of the way that I can click on it. Sorry. Yeah, so it's been open. I guess most people have already seen it. But the idea is to implement the claim check pattern for the data attributes. So this is only for the data attribute and not multiple references. Yeah, so this describes how you can put this URL or you are I reference instead or in addition to the data attribute there. The middle where can decide that they that it drops the data or replaces the data with the data reference. I believe the text of this is pretty much the same as what you had before when you had the PR as adding it to the main spec. Is that, is that correct? Yes. Yes. Okay, so I thought. Okay. I keep in mind as you guys think about this one, this is an extension so the bar is definitely lower than a spec app spec change. Any discussions on this one. Okay, really nothing. I don't know how to interpret that. Okay, Jim, you're up. Yeah, and I'm sorry, I've been mentally out of it for a week or so being sick. The only comment I have around this, maybe for Kristoff is that it's a little bit odd that the middle where I think can we're giving me the guidance that the middle where or intermediary can sort of drop the data and then pass references to it. It's sort of, I sort of wonder whether that's really an end to end contract between the emitter and the eventual subscriber, because there's no guarantees that a subscriber will have the ability to resolve a reference. I think I just, I think it's, there's a possibility that you said a dangerous model by doing that. The publisher could could generate inline data, but then the subscriber receives a reference and it's not able to dereference it. I know that's basically a problem of moving it from the main spec into an extension. Well, yeah. Okay, you're right. So is that just an artifact of the PR itself or does that are you suggesting that requires a change? No, and what I know it is an extension so there is no guarantee that a subscriber implements this actually if we would put it into the main spec it will be sort of every subscriber was will be, you know, should have an understanding of this field versus now it is well optional. So it is, if you are a middleware you cannot know if your subscribers will support this data ref attribute or not. But anyway, it is in the sense that it has been built it is not always guaranteed that the every subscriber can necessarily follow this. So if you have the case where use the clam check pattern to make sure that no one reads the data who shouldn't. In this case, only the subscribers that have a pre shared secret can read it anyway. So yeah, it is sort of if we build it in, then it means that a someone has to build the chain right someone has to subscribe the middleware to the publisher and then the last subscriber to the middleware and someone has to understand that the middleware can then add the data attribute. And that's how you can fix that. Yeah, you have to kind of assume the producer or the receiver knows about the extension. The same is true for things like tracing right where you, we have an extension to find, and if the receiver doesn't know about tracing doesn't care. And that's what it is. I guess the difference here though is in this particular case that's very possible that you will not include the data attribute. And so the receiver who doesn't know about this attribute will look at the data attribute not being there and say Oh, it's just an empty event. Right. I think the, what the background of this is we have this size limitation. So if you are a middleware and someone sends you, I don't know, a one megabyte data attribute. And then you try to forward it on to another different protocol where you are restricted to a smaller size, let's say 64 kilobytes. Then either you just drop the event, which is maybe not so good, or you use this claim check pattern so that the consumer then at least gets the event and then can get the data through the data ref. That's the idea, or one of the ideas. Yeah, I definitely understand the usefulness of it. I just kind of wish there was a must understand header flag that we had in soap so you can force the guy to make sure you understand it. I know I thought I had to mention it. There were some useful things in soap. Yes, there were. Okay, any other questions or comments on this. Jen your hand, can't tell if your hand is up or down or what. Yeah, I just got trigger finger, I think. One, and it was probably a rather dismissive comment I made on on Kristoff's original PR was the fact that whether there was some way to address this using the data content type methodology to sort of say well the data is not actual data it's a reference to data. I'm not sure if you guys discussed that when I was off last week, but that was the only other sort of comment I'd had on this issue. No, I don't believe we did discuss that because I think actually Kristoff you may have been off last week as well. I think that I think Clemens you may have made a similar comment in the past as well. I missed that last comment. Oh, Jen was just saying that it's possible to put the reference to the to the claim check stuff or a reference to the data inside the data element itself as opposed to inside a separate element. Yeah, and I think that's for me that's the preferred solution to keep the event to keep the event small. And then the event might actually turn and might actually point at different kinds of data elements you eventually want to go and pull. And you probably also want to go and describe the be a little bit more descriptive about the data that you are referring to. And that's all something that's well housed, I think in the in the data. The other, the other challenge that exists in making this a generic mechanism is obviously also that whoever is the receiver of that of the event needs to have a sense and visibility to the to whoever is the publisher or where the publisher store that data. And that's always good. So, how do people feel about this going forward. I said it is an extension, so it doesn't have to be at higher bars things with the spec and one of the nice things about it being extension is we can get to see we get we get to see what kind of uptake there is in the community for this versus some other solution that people may have. I don't have a problem with this going in as an extension. I sort of. I maybe I have more of a problem if middleware providers start randomly applying those extensions. You know when I'm not expecting it to happen. So, if it's an end to end contract between the original event emitter and it's trusted subscribers then, you know, I think that's where extension sort of work. Yeah. But the middleware should just be passing, you know, should just pass on. So, I don't think this. I don't, I guess I'm not really advocating for this to be a soul for the message size problem, which I think is is something that Christoph had raised from a middleware perspective. You said that you said you don't see this as solving the size problem. No, it does. If I'm a publisher and I want to send a big message if I want to store it somewhere and send a reference, I would absolutely use this mechanism. Yeah. Right. I think it's a little bit dangerous is if a piece of provider middleware suddenly decides that it's received a message that it wants to pass around via reference and then expect all of its consumers to know about this extension and then, you know, apply it. That's really what I'm driving. But, but that goes back to the case of you have to have an end to end agreement. And even if it's one to end environment. Yeah. Yeah. Yeah. Yeah. Okay. Any other questions, comments. Okay. Any objection to adopting this. Actually, hold on a minute. Let me just check one thing here. I'm not hearing objections. That's all good. But I think there actually may be a process. I don't want to violate that process because I think extensions might require. Where is it? Maybe it's the extension. Is it the extension itself. Then we have a rule that said, we have to ask paragraph. Where is it at least two voting members state their support for its inclusion. Okay. So do you at least two voting members voting members as defined by something to voting members saying that they that they support this thing being added. Christoph, you're a voting member, right. I wasn't there last time I'm not. Maybe I'm actually out of it at this point. Oh, hold on. Yeah. Yeah. I'm not saying that's a process issue if you can vote for your own work. Not. The thing is, we actually discussed that and we actually did allow it exactly because if you don't allow it, then. If a voting member wants to get their thing in, they have to get up. They could play a game by getting a proxy. They just avoid the whole bunch of gameplay and say, look, the features of feature regardless of who mentioned it, even if it's the person who mentioned it, they should be able to say, yes, I want it. It just it actually avoids game playing instead of ads game playing. So, okay. Yeah. So hold on a second. Let me just double check here. I apologize. My machine is getting kind of slow. All right. So here are the voting members Christoph, you are actually a voting member so you can both your own things and you do. I just wanted to raise their hand as the second voting member. Yes, I will. Jim. Okay, cool. All right. And I'll ask, probably ask the question is there any objection to approving this. All right, cool. Thank you guys. So, Jim. Christoff. As voting members, I'll clean that up there. Thank you guys. And thank you Christoff for the work you put on that I know it took a while, but thank you. Scott is not on the call. Do you guys want to wait until he's on the call to discuss this quoting issue, actually, either Scott or Adam or on the call, or would you guys like to discuss it now. I'm inclined to wait until he's one of those guys are on the call, but it's up to you guys if you think we can discuss it without them. We should wait. Okay. Okay. Any objection to waiting. Okay. Unfortunately. Okay, so we had this whole issue about what is going to be used for uniqueness for messages because right now the spec says source and ID together. Well, it actually doesn't technically say that I think the spec technically says for every producer the ID must be unique for every single event. And the reply from that, that means ID plus source, and I believe somebody. Who was it somebody opened up a PR to actually clarify that to say that it's actually source plus ID, it could be used for D dupe and stuff like that, and that's fine. But then there were some issues raised about whether types be included in there. And that was actually raised by Scott. I don't think it's the main proponent of that, even though I think maybe one or two other people that may have kind of raised their hand and said yeah, that makes sense. For the people on the calls I don't think we resolve this today without at least Scott since he has this I think a strong opinion on this, but for people on the call. What's the general sense for from you guys do you want to keep it as it is today where kind of ID alone is the unique factor or I guess ID plus source or the unique is the unique that sort of is a couple for an event to determine uniqueness or do you guys think we need to include type in there. So my sense is that the source identifies who's raising the event and then ID is it whatever number space or ID space in the source wants to sign through the event. And that's sufficient that that creates sufficient uniqueness. That includes the type but I don't know what that adds, because then you would, in fact, you would scope the ID to the source and type first, and then create an ID space kind of for source and type. And that makes that doesn't make a lot of sense to me. Okay, thank you. Jim, I think your hand might have been next. No sorry that was accidentally raised by three with clients. Okay, thank you. Tim your hands up. Relating experience in our event processing. The idea is just the ID. Everybody uses you you you ideas which is plenty of bits and that's a nice simplifying assumption. You don't have to do any multi part keys or anything like that. Yeah, okay. So my only comment with that is something that we've seen in the past is that obviously outside of concepts of cloud events. We can't guarantee that our clients are going to generate globally unique IDs. Yeah, so we always have to pair it with a client ID to actually, you know, create a global unique space that that would be my only comment. Otherwise you have to enforce that that ID is a GID or whatever, which I don't think we do today. I made this comment on a previous call. My issue is that for the type we say this should be should start with a reverse DNS. So we kind of try to make the type globally unique for the source we don't require such a thing. So for source, I could just say this is slash user, right, and then there could be like a lot of people who say slash user is a wallet for me, but it could be Facebook, Twitter, GitHub, anyone could have that like slash user is pretty generic. So we could also think about saying okay this source should also you should try to make the source globally unique then my concern kind of goes away. If you don't do that and I think type is nice in there because it contains reverse DNS and sort of makes sure that it's then globally unique. Yeah, but that's, that's not, that's not the reason why you, where you have the, the, the type unique. Like, that's, that might be a nice element that you can use for uniqueness of, but, but it's not guaranteed to be unique. And certainly not unique for the source because it really like if you have the Microsoft.blog.created event. How does that, that's a universal thing that might be used all over the place. How does that help you with the uniqueness for you in the individual event instance. You always have, have to have the idea in there, of course, I didn't want to take the idea out. But it's, it's, I think the idea is that the idea is the thing that that varies. And that's being, that's being generated by some relative to some counter that you keep. And then, and then you have a relative, you have a source is identified and whether that source now sprinkles that, that, that number space with another unique identifier, which is unique, but then, you know, is not doesn't constrain the number space. What does that help. The point is that we are like, we are two completely separate producers, we could choose the same number space, and we could choose the same source. You couldn't be able to because it starts in your eye. And we're, we're allowing it to be to be a to be a URI reference. That's true. But basically, the URI should uniquely identify that that the source. I mean, that's that's exactly what I'm saying. Then we should go in and we should tell the people. We should use URI reference use a full URI to make sure that it is globally unique. Something like slash users is a very bad idea because that's probably going to clash. So if you're GitHub, use GitHub.com slash users. And if your Twitter use Twitter.com slash users, then we should be more explicit in the spec about this. That's all I'm trying to say. I think I agree with you. And I think I think it makes a whole lot of sense to provide additional guidance in the spec around source. I wouldn't want to go so far as to make it a must. And I don't think you're suggesting that I think you're suggesting some guidance with this should kind of a stuff and say, you know, the value of source should be globally unique. But, you know, there may be some environments where you just want to do slash user and that's perfectly fine for your environment. But yeah, I think additional guidance there doesn't make a whole lot of sense from my perspective. And I just want to say I agree with what Clemens said I I don't see what type adds in terms of uniqueness. And in fact I think if you actually did add type in there we then have to explain what it means for the same source to have two events with the same ID. Because then obviously ID means something beyond just some random number. Right, what does it mean. It implies some of these have implied to me some sort of correlation between these two events. And we then have to define what that correlation means. And I don't, I didn't think we want to head down that path. And that's that's why I'm kind of against type being in there as well. But, okay, so go ahead Kathy. Yeah, I just want to add. Yeah, I think I also agree, you know, it's a source plus ID that you know uniquely identify, you know, that event. Because I, you know, it's easy to scope that uniqueness of the ID within a source, but it's not easy to scope, you know, ID globally because there's so many different event sources is hard to coordinate, you know, all the events. And I think I do not, I think that's more complication. All right, thank you. So let me ask this, is there anybody on the call who thinks that adding type would be a good idea. Okay. So in that case we'll do this. I'll, I'll talk to Scott offline and see how he feels about this. But obviously I don't want to resolve this without him on the call since I think he has some strong feelings about that and maybe you can convince everybody that type action doesn't make I guess I just want to get a sense for the mood of the room. So thank you guys I think I got that. Okay. Now, another one from Scott. So unfortunately we can't. I guess if we ever really agreed with this we could we could resolve it if we wanted, but basically Scott wants to change the current version of the spec to zero three. I actually don't think this I know I'm moderator I probably shouldn't jump in here but I do want to join but anyway, I actually think this is a bad idea, because we aren't at zero three yet and I think that would actually cause more confusion for people. What I would rather suggest is, if you want to change it to something. It is like zero dot three dot alpha or release candidate or something like that to make it clear that this isn't really 0.3 it's a pre 0.3 type of thing. But I wanted to get a sense from the room of what you guys thought about something like that. I actually made a formal proposal to Scott to modify SPR to do that. So I had a conversation with Scott about this and I somewhat agreed with him going forward with this PR. The, the issue was that I believe it was batch support had had zero dot two hard coded in it but that wasn't that wouldn't be supported in zero dot to therefore it was inaccurate. So having something other than zero dot to to reflect new changes that we've been adding prior to release would be good. We need that for coding really we need to have a string that is not zero to and it could be 0.2 bis or 0.3 alpha I don't care but we need to have a different string. In case it wasn't clear I definitely agree with changing it to something I just don't want to be zero three because I think that's just as bad and misleading for people. So, I've heard zero dot. What did you say clear zero that to a bis zero point to this that was a bit of a joke. Okay. Got it. Okay. Um, so maybe we should. I mean you guys. So what is there is there a string that people would like to put in there I mean I think in the past, someone even suggested putting the word master in there or something like that to represent, you know, it's the master branch and that's clearly not a real sember thing. I prefer a spring like master latest whatever it's clear that pay this is really really not a version. This is not bad. My only concern with latest is if you think about the Docker world latest means of all the versions out there this is the latest one that was built. And I wouldn't want someone to think that this is the latest version of the spec meaning at this point in time it latest is as an alias for zero to. Yeah, I agree with the latest is a good idea. That's my like concern. I do like master though because I think that's very clear for anybody who's geeky enough to actually go find it in GitHub. Mark, do you have a sense of what I mean what what do you what's your take on something like master or some other string that you might have to discuss with Scott. Now we we just discussed whether it should be zero that three to reflect the new changes that have come in. You know, zero dot x master. That works. Anybody else have an opinion. Okay, I've heard two different proposals. Master zero dot x dot master. Anybody want to voice an opinion for one way or the other. I think I think that we need to separate out. Where do we want to say what is the latest version, which would be a zero dot three or zero four versus the examples that should just be agnostic with respect to a specific version, except when we're doing a release that has specific features that are implemented in that version. Interesting. So are you, are you actually suggesting that the examples don't actually put a real version number, but the spec itself does have a version number. Yes, that's what I'm implying. Because as we release the spec we want to be able to say, here's, here's the string that you should be seeing in to reflect that version. But the, but the, the, all of the other examples don't necessarily need that. I'm just wondering if that's going to cause confusion for people to say, why do some examples have a number and some don't. So let's take this one step at a time. Right. I think I'm not hearing anybody disagree that we should probably change the master branch version from zero dot two to something. Okay. Master zero dot X dot master. Somebody needs to speak up in voice and opinion. One way or the other. I wasn't going to start picking on people. Current version dot master seems good. Actually, okay, let me get some clarity. Mark, when you said X, did you actually mean the letter X or the current version dot master. I meant, I meant the letter X, not, not the numeric current. Okay. Eric, do you feel, I think that was Eric, right? Do you feel strongly about. I would prefer that it. Yeah, well, not terribly strongly. I think we could spend too much time on this, but I would prefer a number that relates to the space that's being worked on over the version that's being worked towards on master. That would then. Okay. Well, that would then imply something like in today's state of things it would be zero dot three dot some word that implies not ready yet. Right. Like alpha beta working document or something like that right. Is that that's what you're suggesting right Eric. Correct. Right. What about zero dot three dot WIP for work in progress. Anybody have any other suggestions for what that word might be. Well, I guess Mark, would you be okay with heading that direction. Yeah, I'm fine. Okay. Are there any of these are going to solve the problem. I know I'm just trying to get to an answer. So I'm hearing zero dot three dot something. Somebody think of a word quick. Okay, let me do this. You guys are too quiet sometimes I swear. What about work in progress WIP or we refer master that way people have to guess what WIP means. Work in progress is nicer than master in my opinion. Okay, let's geeky. Okay. So I have a vote for WIP. I'm going to pick on people here mark. What do you think. What I've been commenting. Okay. You better watch out. I'm going to start agreeing with Clemens and just tell you to put this in there. Okay, God, no. Okay, ginger. I'm going to pick on you. What do you think W zero dot three dot WIP. Yes or no. I prefer WIP over master. Okay. Okay. Since you guys are going to be quiet, I'm going to put a form for holes out there. Is there any objection to asking Scott to change his PR to be zero dot three dot WIP. All right. That was exciting. Thank you. All right. I'll talk to Scott. Thank you. All right. This one. Kathy, you're still on the call right. Oh, Kathy, you left. I was going to ask her. Never mind. Since she was the lone holdout on this one, we can't ask her about that. Okay. Let me see if there's anything that we're at the end of the normal PR list. So hold on a minute. Let's see if there's anything we could talk about. I think everything's up for discussion. We're already covered. I guess one thing, Clemens, your size PR was approved. But I think there were some edits you needed to make. Yeah, sorry. Yeah, that's fine because we were actually waiting for Rachel to do some things. There was still some possible open discussions around this one. I think you weren't on the call that day. But there were some massive things that Rachel wanted to do. But in the meantime, yeah, she wanted to go and propose something right. Yeah, but if you if you can at least rebase the PR, so there's ready to go. If that thing doesn't turn into anything, then we're ready to go. Cool. Okay. So I will disappear for two weeks. Really? You're going on vacation again? Sorry. Well, it seems like it was just like yesterday you were on vacation or something. I don't know. I apologize to everybody that I'm in Germany. It was like Balanced Dog. I know, I know. I don't know what that concept means. Anyway, I think we're technically at the end of the agenda, but are there any other topics people would like to bring up? So related to Clemens size PR. Yes, I can. Okay, I kind of gave up on the having one size per transport. So we're going to have different sizes now, but I still think we discussed this, where it should be a limit or a guarantee. And I think we already discussed this so I would be. I still think we should make this not a constraint, but a guaranteed size. And that's what we already discussed on January 17 as I commented there, which was quite some time ago. I would still like to see that change. Hold on. The first comment from me here. So we already discussed this, like, I guess everybody forgot it by now. Well, we discussed whether we should want to have a size constraint as is in this PR or size guarantee. And then we decided we want to have a size guarantee, which is also I changed that in my initial PR. Yeah. So we can have all that discussion again or we can say we already discussed it. And we decided for a guarantee. Which way you like. I'm going to claim ignorance on this. So help me out here. What specific change would you like to see in this PR based upon that discussion. The changes that instead of saying there's a limit of 64 kilobytes, it should say there is a minimum guard guaranteed size of 64 kilobytes. For example, this should not exceed 64 will turn into a way. Now this, this one is okay. I think this. And then, sorry. The, the, the, the. Down here. Well, there. Yeah. I think there was another line that I commented on, but it should generally it shouldn't be named a constraint. The, it should be. So if you know that, I don't know, your, your whole chain supports one megabyte, then you should be in compliance with the spec. If you send out a something that's one megabyte. But you are because there's no must rule. Yeah. That's what I was kind of at the state of my PR as well, but still it's like a, I think, how would I say this. So that you don't feel bad about yourself because you're violating a should you still should be in compliance with all the shoots right. There's two, one is you shouldn't be putting putting you shouldn't be putting more than 64 K K on the wire. And then the other one is as a consumer, your limits should not be less than 64 K. So effectively, one is be careful. Don't put anything more than 64 K but on the other side is you should be if you're putting a limit on this. It should not be less than 64 K. So if someone shows up the 64 K, you should be taking that. But, but I leave, I leave, those two shoulds are, are one is be careful about how much you post and the other one is believing about how much you take. Yeah, but I think what we discussed is that the actually did the three or four line. You can turn around in saying like it basically that shouldn't be there. Like you can still post events that are larger. But you can't. There's nothing that forbids you to put a mango bite on the wire. It's just you're you're running against the should not rule, but that's okay. It's not recommended that you do that. Well, okay. For me, it will. I would feel better if it's not a shit. Whatever, like we discussed it before and we, we, I had specifically the name constraint in there and the working group said to me, don't use constraint use guarantee. I mean, we need to have find some language that is is basically limiting what the what the or informing the implementation for that we have some phrases that we're using may should mass, etc. And so that's, that's what that's what's being used to anything as lesser. I don't know what else to put here. So, Christophe, are you looking for a must online 304. No, I'm not looking for a must. What, what, what specific change would you like to see then I'm just a little confused. I apologize. So it shouldn't be named a constraint. It should be named a minimum guaranteed size. You mean up here online to 92. And then it shouldn't say you should not publish an event that exceeds that, but you should be aware that if you publish something above that consumers way may reject this. So if you do that, you're on your own, but it's not like you're completely fine if you are aware that everyone who all your consumers will accept like 10 megabytes, then feel free to send 10 megabytes. Okay, so I think what you're saying is you'd like to change the title and you'd like this line to be augmented, excuse me, to say post event should not exceed 64 K and receivers may reject messages that they consider too big or greater than 64 K. No, that's already a paragraph below. Okay, then. And I'm still confused as to what the specific text you'd like to see online 304. Well, I can make a proposal, but I think we can also look at my PR, which I changed based on the feedback that I got from the group. So we voted on this one, and I'll do the internal changes and you can go and then make an amendment to PR. So to be fair, we were voting on a direction before, and then we agree that once we got that direction, we then would do editorial things. So, so Christoph, well, it's two stages or one Clemens I think if you can make the editorial changes that you agree with that have been suggested already because I think most are strictly editorial can do those Christoph if you could put a sentence on this PR with the exact text that you'd like to see so that Clemens and the rest of the group can can look at it. I think that'd be helpful. Okay. Okay. I think the way that I did it in my my PR is that I didn't talk about the size as itself but I just said like 64 kilobytes is what every consumer should accept. But no published event should be above it. Okay. For my, for my way of looking at it, I think that's similar to what's already being said but put the exact words that you'd like to see in there so Clemens go look at it and see if it actually changes what his intent was and then we can have a discussion. I just for me personally, without seeing the exact text you'd like to see it's a it's hard for me to follow the exact set of changes to know whether I would agree or disagree. I think in terms of implementation, it is not a big change, but it was more like we look at all the sizes we had. We saw there are message queues to go up into several megabytes. And we want to, we didn't want to exclude those. We didn't want to set a low limit and saying, we know you run on a message queue that supports 61 megabyte, and you are forced to go with 64 kilobytes, more or less, we want to say it's completely fine if you go above that. Maybe you're aware that maybe you're not, you will not be fine. Not be fine if you switch to different transports, which we know say anyway because once we switch to the transport layer the whole 64 kilobytes on the wire format so you don't know what will happen anyway. Right. Okay, but I do think the next steps here is just, if you can propose an exact text revealed to consider I think that'd be the best way forward. Yeah, I'll do that. Okay, cool. Thank you. Okay, any other topics people want to bring up or anything that seems like I missed. Okay, in that case, before you guys are vanishing hold on a sec. Last minute attendance check. Fabio you there. Actually I see you there meeting edits. Jim I know you're there. Kathy was there. Vladimir you there. I'm here. Excellent Erica are you there. I'm here. Okay. There's a name on there that meant I didn't see for then gale falcon. Are you there. Actually, it seems to have dropped. Frederick are you there. I'm here. Excellent. Anybody else that I may have missed. All right, cool. Thank you guys very much. Oh, I should point out, we have a cloud event demo call in seven minutes, same slack channel or same zoom channel. If you want to join the discussion, you can hang on or dial back in seven minutes. Otherwise, everybody else is free to go. Thank you guys very much. We'll talk next week. Thanks. Bye guys.