All right, three after the hour. Why don't we go ahead and get started? I don't believe there's anything exciting to mention on the AIs. So just a reminder, we decided to cancel, obviously, next week's phone call due to coupon. And then after that, people are going to start taking vacations. So we decided to cancel basically the rest of the meetings for the year. And I would believe we agreed to start back up again on January 10th. So everybody have nice vacations. See you back then. Community time. Is there anybody who's new on the call who wants to bring up a topic that is not on the agenda? All right, moving forward then. All right, SDK work. Austin, since you haven't been able to join the call there, I'll try to give the status as best as I can remember. We have been having weekly phone calls. Everybody's been going through the process of upgrading their SDK code to support 0.2 with the assumption that the vote was going to pass, plus putting the version number 0.1 is just flat out wrong given the state of things. So everybody's been upgrading. We are planning on calling it alpha when we talk about this at KubeCon next week. Everybody's felt comfortable with that. Mainly that will then encourage people to actually start playing with it because some people don't like playing with things if it doesn't have an official label of some kind. I've just this morning finished the one slide that I put in the deck for the SDK work. I'll send a message to the SDK Slack channel. But the point of this is just to tell you guys it's there and to look it over. And if you have any comments or suggestions for edits, please let me know. As I said, it's just one slide with not a lot of text. We also noticed that there was no governance documentation in our SDKs yet. So I'm gonna, I agree to take the first pass at writing that up. As of right now, the general plan is to have the governance stock be shared in the main repo, meaning the spec repo under our SDK directory. That way we don't have to duplicate it in every single SDK. Each SDK will have its own equivalent of an owner's file. So list of maintainers may be different per SDK, but at least then the governance stock should be consistent across all of them. But we are gonna leave the door open for a particular SDK to tweak the governance if they need to. So we'll just provide a baseline, but then they can augment it slightly if they wanted. If for some reason what they wanna change isn't simply additive and they actually wanna change something in the base, then they can create their own version of the governance stock. But at least for the time being, everybody seemed to think we should at least try to have the same governance model across all of them. So let's not duplicate the text. I assume that we'll put a link in the read-me's of each of the SDKs linking back to that? Of course, yes, yep. That's part of the, actually, I don't know what to guess. Should we also do that for a common code of conduct? That would make sense, yeah. I think I kind of view that as part of the whole governance model. Yeah, okay. Yep, actually I'll make a note of that. That sounds like great progress. Yep, great progress. Yep. Anybody who's been on the calls, can you guys think of anything that I missed or any topic anybody else wanna bring up relative to SDKs? Okay, we do have code for all five out there.  And Austin, since you haven't been on the calls, that we actually do have a PR for the spec repo for a very high level sort of design document that's meant to be sort of a guide for all the SDKs so that they can sort of have the same look and feel as best they can, even though there will be language specific differences. We wanted to try to get them to have similar functionality at a high level or like I said, basically get the same look and feel. So I encourage everybody to take a look at that, including you, Austin. That makes sense. On our company's end, we're still strongly committed to this and we have like a handful of releases that we're trying to get out the door that involve cloud events. We're just taking our sweet time trying to get it right. So we hopefully have some cool stuff to announce around cloud events early next year. Excellent, sounds great. All right, anybody else have any questions or comments on the SDK stuff? All right, Kathy, I see you joined. Is there anything from the workflow stuff you want to mention? No, not this time. All right, cool, thank you. Kukan, all right, so the slides are there. I did take the Shanghai ones and convert them over to use the Seattle template. I've been updating my version or the slides that I was gonna talk to. Kathy and Clements, I don't think they've necessarily done anything or I've started that yet, but I expect that to happen relatively soon. In fact, we have a phone call right after this to talk about the progress on that. But anybody else on the call, please feel free to review what's there. If you have any comments, I suspect there probably won't be a whole lot of changes from what was in Shanghai, since it obviously was only a couple of weeks ago. But if you think that something does need to change for this audience, please let us know. And the link to it is right here. Okay, any questions or comments from anybody? All right, demo, we are planning on showing this at the Kukan next week. It's not too late to add your endpoint if you do want to add one. I believe right now we have about seven or eight or something like that. One more company is planning on doing it. It doesn't take a whole lot for me to add it. So I can add it pretty quickly up to the date. The only constraint I have is I do have a chart that lists out all the various companies there. So I may have to start shrinking things if we get too many more people. But that's not a concern. I'd rather add your endpoint than we're at the slide later. So if you do want to add an endpoint, just please let me know. The, this design doc here, it should be all you need to know if you want to add an endpoint. It's relatively straightforward. Pretty much just a random number picker for more than anything else. All right, any other questions or comments on that? All right, cool. I'm moving forward. All right, before we get into the other PRs, we have a vote on 0.2 release. I will go through and do the voting in a second. There was a comment from somebody though, maybe even Dennis, that he was hoping to get this cloud events SDK spec proposal merged into 0.2 since we're going to be kind of advertised in the SDK work at Ku Klun. He thought it might be good to have that as merged into the merge, had that PR merged in time. Technically the vote did not include that obviously because the PR is still pending. However, that document is non-normative. It doesn't touch our spec whatsoever. It's strictly additive. So what I wanted to do was to get a sense from the group whether you guys would be okay with considering adopting that PR and sliding it into the 0.2 release or whether you guys wanted to be a stickler for the process and say no, the vote did not include it, therefore it shouldn't include it. I'm okay either way, but I wanted to get a sense from the group whether you guys want to allow that one in or not. Anybody have any feelings one way or the other? I think it's a good idea to mention it because even if it's not like part of the spec just to mention it so that people know it exists, I think it's a good thing to put in there. That's my opinion. Okay, thank you. Anybody else have any comments? Okay, so tell you what, let's just, actually let me ask this question. Is there any objection to considering this PR for merging into 0.2? There's still gonna be the question of whether we actually wanted to merge the PR itself because whether it's good enough, but I'm just asking whether there's any objection to even considering it for 0.2 at this time. Okay, not hearing any objection. Let's very quickly then quickly look at this PR. I think it's been out there for at least a week or so. I don't think Dennis is on the call to talk about it. So let me just ask the question. Have people had a chance to look at it and are there any concerns or comments here? As I said, this is just a high level document that just tries to get a sort of a baseline of consistency across the SDKs and it is very much a work in progress. As you can definitely tell near the end here, there's a whole bunch of TBAs to be, I guess, added. But it seemed like a pretty good starting point to me. Are there any questions or comments on this? Also, I have not got a chance to look at this yet. Could we have a few days to merge this before it's merged to take a look at? Well, if we don't merge it right, if we don't merge it right now, then it's not gonna make 0.2. Because the 0.2 votes gonna close into sex. So Kathy, it sounds like you'd rather not include it in 0.2. Is that correct? I don't think she was saying that. I think she's saying she just wants a little bit more time to look at this and could we like make an exception and say, we'll look at this and vote asynchronously and include this in 0.2? That sounds nice. I'm just trying to think about the process here because asynchronous votes are technically supposed to take a week, which I think is your problematic for KubeCon and people getting ready for KubeCon. I'm just not sure, just from a process perspective, I'm not quite sure how to adhere to what we've done or what we agreed to. That's my only concern. Yeah, that's what I was trying to say, Doug. I think it's maybe, we may be rushing things if we try to merge it before with the clear point too. But I think it would be good to at least mention in 0.2 that there is the SDK coming and maybe leave the PR on merge for now. Well, we're definitely, well, okay, when you say mention the SDK in 0.2, can you elaborate on what you mean by that? Just mention that there is work happening for creation of an SDK and it's coming soon just so that people when they read the documentation for 0.2, they will know that this is coming even though the actual details are not present there. Are you thinking of like a mention in the README or where you think? Yeah, and the README, yeah, the README would be a good place. The README already has it, if you look at the change. You're right. If you look at the change, it's actually just expanding it to add additional documentation, but it already says in addition to the documentation that mentioned above, there are also a set of SDKs. Right, so the README does already talk about SDKs in terms of their existence, yes. In that case, it's probably good enough for 0.2 and not merge the PR. I'd say if we're considering a 1.0 vote, then I might say hold off, but given that this is just 0.2, I think we can push this one. Yeah, and on my end, Doug, I appreciate us wanting to get this stuff right, but I also really am a big fan of just getting this in front of users and giving them something to use ASAP and because this is just an Alpha product and we kind of have lots of opportunities down the line to change it. I feel comfortable just putting this out there. Definitely chatting with lots of customers and users every single day and I'm just dying for something that I can give them that actually makes the specification accessible so they can start using it in their projects and stuff. And I know as soon as we have something, we'll start getting a lot of valuable feedback and be able to make more informed product decisions. Okay, so Kathy, do you have any additional thoughts on this before I start putting out an idea? Yeah, I'm open, I'm fine, yeah. You're okay with merging it? Yeah, I'm fine, others are okay. Yeah, I mean, keep in mind that this is just a draft document that pretty much everything in our repo, right? And as I said, it's completely non-normative, doesn't force anybody to do anything. It doesn't even technically force the SDK writers because they haven't actually formally, you know, like approved it as much other than it's just a draft. Okay, so is there any objection to adopting this PR? Okay, not hearing anything. Okay, so now let's go back to the votes and to be perfectly clear, the 0.2 vote is based upon the spec after Lakshmi's phone call with all the PRs that we approved last week merged. Plus now it's gonna include this additional document from Dennis. And when I do my release notes, nope, that's not it. I'm sorry, I'm looking at the wrong one, darn it. And here are the release notes I'm gonna include, I tried to include everything I could think of that was relatively large. Okay, so we had some people already starting to vote. I will actually ask the people who voted yes before just to make sure they're not gonna change their mind based upon this of the PR that we merged, just to be perfectly safe in terms of voting. Roberto or I'm sorry, Adobe, do you wanna change your vote? Sorry, I was on mute. Yeah, no, I don't want to change my vote. Okay, Alibaba, do we have someone from Alibaba on the call? I don't think so. Okay, Kristoff or someone from Commerce Tools on the call? Okay. I'm sorry, is that someone talking? Yeah, sorry, I'm joining by phone. Is that Kristoff? Yeah, there is me by phone, sorry. I do not want to change my vote. Excellent. I'm cool with it the way it is. Okay, thank you very much for speaking up. And I added you to the agenda, or to the attendee list. Okay, what about Confluent? Neil, are you there? I don't see him. Anybody from Fujitsu? Okay, Rachel? Yeah. Is that a yes vote? Yes, that's a yes vote. Okay, yeah, IBM hasn't changed. What about Intel? David Lau? I don't see David. Okay, what about Itao or Itao? Okay, Clemens, do you want to change your vote? I would not like to change my vote, it's a yes. Okay, thank you. What about NAIC? Dan Barker, are you there? That's it. All right, what about Colin Nats? Yes. Yes, okay, Nordstrom. I am representing Nordstrom. I think I'm okay with this. All right, cool, thank you. Oracle, Chad? Yeah, where he is. All right, Jim, PayPal? Yeah, I'm here, I'm late joining. I haven't looked to this, I'm afraid, so I'm abstaining. Okay, fair enough. William Redhat. I'm broxying Jim Curtis' vote because he joined the discussions, I wasn't here. He's saying yes, so you're saying yes. Excellent. Klaus, SAP, or anybody from SAP? Do you guys want to change your vote? Okay, I don't see anybody. All right, Mr. Mark? I'm a yes. All right, Vlad, are you still a yes? I'm still a yes. Okay, and what about Tapini? All right, so did I miss anybody who thinks they have voting rights? All right, we have 12 yeses, no nos, and there's one abstain, which acts as a no vote, so the vote passes. Thank you guys very much. I will do the exciting process of getting that out there. All right, this one's approved. All right, next on the agenda. Rock, actually, let me ask a question. For releasing 0.2, obviously I'm gonna merge the PR, create the release and stuff like that. Can anybody think of anything process-wise that they want to mention that I shouldn't forget to do? I think I have everything lined up, but I want to make sure I'm not forgetting anything. So it's creating the GitHub release, merging all the PRs we talked about, and I think that's about it. Can anybody think of anything else? Add the SDK to the release notes, because it was missing, and the PR stuff, tweets, and stuff like that. Okay, I got the SDK. What was the last thing you said? PR stuff, like tweeting about it, I know that CNCF do announcements. Okay, okay, yes. Yes, good idea. All right, cool, anything else? Do you have any suggested tweets or suggested PR stuff we can use to promote this? This is not my forte. I personally do not. Maybe. Yeah, anybody else on the call have anything? We'd be good if there's something that we all felt okay about, and we could potentially use to explain it to people what's the 0.2 release in a sentence. Yeah, if you guys want, what we could do is take it to the Slack channel and wordsmith a little on some ideas for a common tweet that we could all kind of share. Is there a blog post coming out? I had not, I don't have one planned. I was probably gonna do one, but I haven't started anything I could have done. I already tweeted before you asked. Oh, that's clever. Well, there you go. We could just retweet Clemens' one. No, no, no, that was not, I just made the statement that the vote just passed. Could we get something on the CNCF blog? I'm sure we probably could. Does someone want to volunteer to create one? I could try to find some time. It's just gonna be a stretch for me. Give a workflow that I can definitely try. I'm excited about it. I'm just super over committed. Yeah, I think we all are. Okay. Let's leave it. If somebody wants to volunteer to write a blog, please let us know in the Slack channel. And we could try to get it uploaded onto the CNCF website. I think we're allowed to do that. I'll double check with Dan or Chris. But if not, you know, maybe I'll try to write the language. But before anybody starts writing, please make a comment in the Slack channel. So we don't duplicate effort there. So the blog is about this release. Yes. Okay. Hi, Doug. This is Sonya. Quick question. When are we looking to get it out? We say it. I mean the blog post. Yeah. Well, I would hope before KubeCon. Yeah. Okay. If it's sometime next week, I could probably take it on, but I'm also prepping and going to KubeCon. Yeah, that's, that's the problem. I think for most people on the problem. Yeah. Okay. I mean, technically I guess as long as it's out there before. Our first session, which is the intro, but to be honest, if we can get the blog out there before the keynotes, we may be able to arm twist somebody who's has a keynote to mention it as well. Because I know Dan and Chris have done that in the past for us. So I want to, I think it's best to say, I think it's best to assume we went out there before KubeCon. Let me do this. I'm not committing. Let me, let me take a look at more of the details of the PR, because this is only my second time that I'm meeting with you guys and see if I could whip something up pretty quick and send it out to the group. That would be my end of dates tomorrow, but that would require that folks provide input or feedback or, you know, as quickly as possible. Yeah, do whatever you can. But before you or anybody else actually starts writing something, put a message into the Slack channel, because you may have other people try it as well. Like I said, I don't want to duplicate effort. If we're waiting for next week, I can likely whip something out. I'll help with this over the weekend too. Yeah. I mean, obviously next week is better than before KubeCon, but the sooner the better. Whoever can start would be great. All right. Yep. Cool. Let's see where are we? Okay. Rocket MQ. Unfortunately, my mind is mush right now. Clemens, where are we on this one? Do you remember? I think we, what we learned last, last week was that we found that it doesn't meet either the bar of being a standard that is, or a protocol that's being used outside of single projects, nor one that is category defining. So it doesn't meet the bar for our criteria. That's what we were. In the meantime, in the meantime, obviously, they would have some additional conversations, but I don't think they've, they've, they've changed any of that. Okay. So for me, the yardstick is, does it help interoperability amongst multiple product, product and projects? If we add this binding and the answer here is very clearly no, because nobody would read that spec except for the Rocket MQ team. Okay. And thank you for the refresher. And I did comment in the PR itself about this. I'll give you guys a second to read it because I'm not sure everybody's had a chance to. So we'll give you just a minute or so to read this over before we ask anybody for comments. Okay. Can I just give my opinion and solicited? Yes, please go ahead. I don't feel like I know enough about what the standard, the default standards are, especially in China, like that's the part that gets my attention to say that it is not, and I would rather skew on the side of letting more things in rather than being overly restrictive here. That's my, that's my first impulse. Okay. Anybody comment want to comment on that? Or anything else related to this? For me, the metric is how many implementations are there. And I don't know any implementation except for Rocket MQ that influence that protocol and haven't seen any. And I understand that the product may be used in China a lot. But that doesn't mean anything. If a lot of customers are using, sorry, Doug, IBM MQ, which has a close protocol, that doesn't mean anything for interoperability because it has a close protocol. And, and so for me, the yardstick is do it, do we do it? Because we do product, we do protocol bindings. We don't do product bindings. And this is a product binding. So I would say, I would say it does matter for interoperability. Like for example, if, if it's widely used and people want to be able to start consuming cloud events and then use that, like they might want to pass it through some system that they have and that could interoperate with something else. So like they just want an easy access point to start using this. And, and I know that it's closed and it's not an entirely open source implementation. There aren't multiple implementations. But if the goal is to make this serialization format as widely available as possible, like it doesn't hurt us in any way to make it, like to, to let them publish a spec for it. Let me tell you what my problem is with that. It's, it's also about implementation matrix, right? I know I went and wrote this is sharp SDK, this is sharp SDK now supported. And, and HTTP and when I can, I'll also support now. Other people are writing SDKs for go, et cetera, et cetera. Every single additional protocol and protocol and product binding we add multiplies the maintenance effort and the implementation effort in every run time and language binding. I would much rather prefer for us to say, here are the protocols for particular pillars, use case pillars that we know. And we're actually pretty well set up for that because we there's not a ton of overlap between the ones that we have. And really bet on those and double down on those and be principle principles and keep the complexity of our implementation matrix for the SDK down. Rather than be happy to invite every product to go in and add a cloud events binding where we then on the SDK side have to go and support yet another one and yet another one and yet another one. The whole point of the SDK side is that it's the whole point of having these protocol standards is that the implementation matrix keeps is manageable for everybody who wants to support those things. And otherwise we're going to get into a situation as you are with JMS where in Java where yeah, there's a standard but nobody really implements it fully because there is a multitude of different messaging products which are happily which were during the day of JMS were happily just speaking to their own preparatory protocols. And if you were using JMS you were getting kind of the worst of our worlds and that's the thing I want to avoid. So it's really about keeping the implementation matrix less complicated and betting on a number of favorites that we're really picking. Okay. So I think Alex you're trying to speak in there so your hand is up next. I think that was you right. Yeah. You know what was being said resonated with me as well in terms of trying to create an inclusive community where we want this to be widely adopted as a standard what you know what if their team has so much impetus that they want to create this spec and don't you know contribute it and actually maintain it. How much of a burden is it for us? What's going to happen if we exclude them? Could this be a like an alpha spec? Is there another level where you could accept it and review it in time? Since we're only at 0.2 are we cutting people off too early? Okay. Thank you Alex. So my hands up next. I wanted to get people's thoughts I guess in particular Clemens your thoughts on that paragraph or sentence that I have highlighted because basically it says we would like to see at least one open source implementation and at least a dozen independent vendors using it. I believe they meet that criteria don't they? Because they have one implementation and according to them they have hundreds of companies using it which I think satisfies that at least a dozen independent vendors using it. So I'm trying to understand from a strictly processed perspective do they not meet the criteria in the second bullet? I guess that question is more for Clemens and I'll stick you implicitly into the Q comments but I want to let Rachel go because I think she had her hand up next. Okay. My comment was I totally understand the need to minimize the burden on the people who are developing the SDK. I'm sympathetic to that. I suspect that the people who are willing to propose the spec are probably willing to help out with some of that work. Don't know if that will be true for sure. And the other point that I would like to say is like a larger point which is this is a very young spec. Like that I feel like there's a greater risk that we will spend a lot of time building this and no one will ever use it. Then there is that then like we spend a lot of time building this and now we have too much work to maintain it for all the people that want to use it. So like my bias right now would be if someone is excited to use it and wants to propose something I'm not saying we should accept every spec that comes in. I'm saying like our like if people are excited to use it we should help encourage them and not discourage them and push them away. Thank you, Rachel. Clemens like kind of forcing you to raise your hand. I was wondering if you could address some of the comments that have been made. I want to hear what you have to say about this sentence I have highlighted. So for me the first sentence is the one that I care more about and the question is does this protocol have a de facto standard status for the ecosystem category? And RocketMQ is a message broker. And if there is a de facto standard status in the message broker arena there is two preparatory protocols. One is typical and the other one is MQ. And then there is one open protocol that fights against those and that is MQP. And I don't see RocketMQ being a de facto standard. Now you can go and it shows up nowhere where I can see. And it might be a function of being able to see behind the great firewall of China. I'll admit that. But again, I only see one implementation of that. And then it's like, of course, practically we would like to see at least one open source implementation under the umbrella. And at least it doesn't depend on us using it. I think of that taken together as something that fits Kafka. Because it is a de facto standard in its category. Like everybody is using that thing and there's one implementation of it. But I don't think of RocketMQ being at the same level. Everybody knows Kafka. But probably most of you didn't know RocketMQ before Alibaba proposed that by me. So that's my, again, I'm not vehemently against it because of where it comes from. I just think it doesn't, I would rather, frankly, I would rather have RocketMQ snap to a protocol that we all speak. Rather than us here go and snap to the idiosyncrasies of a particular product. If it's not a category defining thing. That's kind of my, I'm all for interop. And I think less protocol helps. Okay. Thank you, Collins. Heinz, I think your hand might be up next. Yes. A couple of quick things. I agree with Clement. Totally. Quick point. Our company Solis has actually bypassed TIPCO as far as messaging implementation. So just want to throw that out. However, one important thing is we already have the JSON payload. That is a way to implement it if you are doing something proprietary. So it's not that there's nothing. However, I almost like to suggest that we have a generic protocol binding where as long as you have a capability within your messaging API to do a user-definable header, which is being used right now with our protocol bindings, that would definitely motivate companies such as ours to write our own, for our proprietary APIs, our own protocol bindings. As long as there was a spec for a generic protocol bind. So I'm wondering if that might be an option to get more deployment and more interest than, but again, I agree we should keep it pure that it should be only four things that are open standards and are specified or else as Clement's points out, you're going to have hell trying to propose these and everybody is going to try and get the proprietary stuff embedded in this as well. So can you elaborate a little on what you mean by a generic protocol binding? Well, right now, if you look at how we do the AMQP or the REST or even the MQTT, what it appears has been defined is you create user-definable protocol headers where you're defining name, value pairs where you specify what is the label going to be, which is slightly different for AMQP versus AMQT versus REST, and then you define what is the actual values and their castings, its string, its integer, whatever. But there is a different one where Clement's done a good job defining this where he's created things in the, for example, the name values for AMQP has kind of a convention they follow, so there's that protocol binding is going to have a slightly different name than it does for MQTT. However, that doesn't mean that we can't maybe regenerate the generic one where we have, this is, you know, a common set of name, value pairs and casting for the values, what those definitions mean, and if you support user-extensible headers, then you should be able to write your own protocol binding for your own products. And if there is an interoperability, so for example, I look at Solis where if it comes in as one of our proprietary, we can go out AMQP or REST and do that vice versa. That means our clients that want to use special functions that we have in our broker that are beyond what the specs have, it allows us to still do those bindings and still interoperate, if not through our products, but also our gateways and everything else. So not, you know, not every protocol binding should necessarily be part of the API that, you know, the group has to worry about. In some cases, the vendors will probably be interested in doing that adoption, but for that, you would need a generic protocol binding. Does that make sense? It does. Thank you very much. It helps me understand it anyway. Thank you. I don't see anybody else's hand up. However, Jim, you did make a comment to the chat. Would you like to elaborate on that verbally? Sorry. Yeah. Not speaking on mute. Yeah. I think this comes back to the standards question. I would be more in favor of doing something in terms of the open messaging spec, but having looked at that, that spec is very Java centric at the moment, even though it claims that there's other language supports. So I don't know if that binding could be recast in terms of open messaging. I don't know if that would address some of the previous gentleman's comments as well. I mean, if there was no messaging to solid binding, then that would then just naturally sort of fall through. I mean, that was my assumption. On the one side, these people are saying RocketMQ is very widely used. And on the other hand, they're saying it's the first implementation of open messaging. That was my angle to try and recast it in terms of the other spec. Okay. Thank you. That's a really interesting idea. The recasting on top of over messaging. Right. Should we have an open messaging spec? Well, we did have a proposal come in. I believe we rejected it. And the reason why we rejected it is because open messaging literally lifted text from us. And the open messaging spec is exactly at the same level of where we are here with this project. We're doing eventing. And the open messaging spec is effectively trying to do something that is very, very similar for messaging, which means it has kind of more elements of reply to and to and kind of addressing and addressing elements, et cetera. But it's hard to map the abstraction that we have here on the abstraction that open messaging provides. So in terms of going forward here, so part of me is sort of jump into a conclusion that says there's a very bullying choice in front of us, basically yes or no. But before we head down that path, can anybody see an option here where there's some way to morph this PR into something that may be acceptable to the group? Or does it really just come down to yes or no? Do we want rocket MQ? Yeah, I think Jim gave us an option for that. Well, but the problem is we rejected open messaging. We can revisit decisions that we made, though. Yeah, that is true. Do people think that we should revisit that decision? Well, is that an option that people want to consider, put it that way? And something like, you know, you don't have to make a decision right now, because I'm not going to propose that we close this pull request even if everybody voted no right yet, because I do want to give people more time to think about it. But what do people think about revisiting the open messaging decision? Well, not so much the open messaging one. I think the other issue here is that if we keep cutting people off, then that could leave a bad taste in people's mouths, even though it's well intentioned. Is there another angle where we could say, okay, we'll host your binding specification, but we won't manage it. So you become a central repository for proprietary bindings. But you do it on the understanding that though the vendors that publish that are responsible for maintaining it, and it doesn't fall to us, that we become a librarian more in that case. I don't know if that opens up even more cans of worms, but I just feel that there should be some way for a proprietary vendor to plug into this mechanism. Sorry, Clemens. I actually think that's okay. So if we made, if we made that, and then I think that's a good idea. So if we made a folder that's called projects, or products of some sort, you can say, here's a document that you own, and you can go and put that there. And because you have a, you know, protocol that's not, that's not meeting our criteria, but you still want to provide visibility for, you know, how that maps to your product. I don't think that's, I don't think that's, that's, that's terrible. It's just a question of, you know, what is, what is the canonical thing that everybody needs to, needs to support? And if someone wants to go and publish, publish, here's how product that's maps to a product. I think that's great. It actually would not be very different than what we do for document extension stuff either. It's a similar. And I see that exactly as a parallel. Yeah, Alex. Yeah, Alex, do you hear your hands up? Yeah, so that, that sounds like something that could help with some of the objections we had about being, being perhaps too exclusive or too high bar. And it would remind me of something like the, the landscape and the scenes. Yeah. There's projects that are listed that aren't necessarily donated yet, but might be in the future. And it kind of has a parallel with that. That's true. And I apologize. I apologize. Hines. They're old. Or is that new? Yeah. No, that's new. Oh, I'm sorry. Go ahead. Hines. I'm sorry. I skipped your mistake. No, actually, this ties into what I had mentioned before was if we had a generic spec for any protocol. This is exactly what a lot of vendors have done. And it, this idea of a catalog or repository is an excellent suggestion where if you did have a generic binding, leave it to the vendors to do the bindings, which we've done multiple times for other, you know, payload and protocol standard things. And, you know, you would be able to get the links into, you know, through the web link. So here's other vendors that probably be more people interested in participating. It would help in interoperability. I think it would be quite valuable. I really liked the idea of a library or a repository as well. All right. This is John. Sorry. Sorry. I'm on the call so I can't raise my hand. Yeah, please go ahead. I like the idea of this two tier approach. My question is, do we have a bar for what, you know, what the expectation is as to the quality, right? Do we have the equivalent of some kind of test suite or something like that? That, you know, if you pass this suite of whatever compatibility test, then you get this stamp. And if you don't, right, that's a different level of, you know, that lack of interoperability, right? So that somebody looking as a user, right, as a customer of this, one of the problems with these kind of open repositories is they end up being a dumping ground, right? So that some vendor can get a check mark and claim, you know, claim Halo status. We support all these open standards, but they don't really, right? Which I think is part of Clemens concerns, you know, around officially blasting these back. Yeah. Interesting.  Okay, I'm going to assume it's old. Jim, your hand was up there. Did you want to say anything? Yeah, just very quickly. I don't need to drop off, unfortunately. Maybe there's a way to use this as a, almost like a pathway to a first class support. So like Rocket MQ may elevate itself to an open messaging, you know, compliant thing as when that becomes more widely available. But I agree that there's a flip side to this with the dumping ground and, you know, setting more standards around what you need to do to meet the bar. I think it deserves more discussion. Okay. Kathy, were you going to say something in there? I thought I heard you trying to speak. Yeah, I think I agree with that, you know, I think if we do not have, what's the purpose of this? We would like to promote interoperability, right? If you know, if some particle cannot meet that standard, then it is just like a dumping ground. Okay. So it seems like there may be enough people on the call to warrant somebody writing up a proposal for us to consider having this sort of, another tier of transfer binding specifications similar to our documented extensions, stuff that we have. Is there somebody who'd be willing to write up that pull request to put the proposal out there? I probably should have asked this question before Jim ran away. Yeah. So it was this idea. Is there anybody else on the call who'd like to take a first pass at this? I know there was at least more than one person who was interested besides Jim. Okay. Okay. I'll do it because I want it to exist. There you go. Thank you. Thank you. All right. Thank you very much, Rachel. Okay. So that, but that then says to me that we don't necessarily have to decide this rocket PR. Okay. We'll wait until we get this other discussion resolved. And then take it from there. Is there any. Just leave them hanging. We should probably respond to them in some way, right? Oh yeah. I'll do that. Yes. Actually. Thank you. I'll make a note. Otherwise I'll forget. I apologize. I was typing in a window. You guys can see. There you go. Okay. Anything else relative to either the PR, the Rachel agreed to a draft on it. Or on the rocket MQ PR itself. Okay. I believe the other PRs are still either under discussion or we're waiting for an update from Thomas. On this PR though, Clemens. Do you think you could take the action to reach out to those guys and set up a phone call? I grant that it may not happen until next year, but I think I think a face to our virtual face to face discussion might speed up the conversation a little rather than comments to the PR. Yeah. We'll have to do that early next year. But yes. Okay. Cool. Thank you. I can't type today. It even happens to you. What? We have to do that early next year. But yes. Okay. Cool. Thank you. I can't type today. It even happens to you. What? We started my first name. Huh. Weird. I don't know why I did that. I usually spell it right. Maybe it's the Google. The Google. Yes. Sorry. No offense. All right. That's technically the end of the agenda. Are there any other topics people would like to bring up before I do final world call? There was just one. I think I joined a few minutes ago. A few minutes late. Must have already done this. But the KubeCon. Inter-rock demo. What? What was the status of that again? For the most part it's basically ready. I think there's one other company that's trying to get their end pulling up and. And added to it. But other than that. I think it's basically done. I haven't heard any concrete suggestions for edits. So. Without those. It's it. We had a little bit. We had a little bit of. A pixelation problem on all of the logos. Okay. So. Do you have a Mac? Yes. Okay. So what I'm being told from the person who's working on this is that this is a known issue with Max. And the only way to fix it is to actually. Scale it. Up. And then scale it back down through some really weird hoops. You have to jump through. And that's going to really muck with their logic in terms of how the bubbles flow and stuff like that. I can ask them to take a look at it. But to be honest. I didn't think it was critical enough to pull them off of other work. To work to fix that. Relatively minor issue. But it is just a Mac specific issue to be honest. Is what I mean. Probably be demoed on a Mac as well. Maybe. Yeah. I'll ask them to see how much work it really is. But I don't consider that to be the highest priority at this point. To be honest. Okay. And so how many people have we got now? We have the next one. Hold on a minute. Yeah. Oops. Okay. Let's go to that. Okay. Okay. Great. Thanks. Yeah. So hopefully we'll have eight before the actual demo itself. And we're not going to change the event type or anything. No, we are offset. Everybody's doing 0.2. Yes. One more. Function. One more. One more. One more. One more. One more. One more. One more. One more. One more. One more. One more. One more. One more. We will come up with one more function. I'm sorry. Say it again. We will come up with one more function. That's fine. Yeah, that'd be good. Just. I would appreciate it if you let me know with more than five minutes before the demo. Yes. I hope by tomorrow sometimes. Okay. Yeah, that'd be great. Like I said, it's not a big deal for me to add it. Just let me know the URL and and I need the URL to the endpoint and a URL to what logo you want displayed. Okay. Yeah, thanks for recapping for me. Yep. Not at all. Any other topics you want to bring up? Okay. In that case. Final roll call. I heard Kathy. Richard. Farad, are you there? Yeah, I'm here. Thanks, Doug. Excellent. Joe Sherman. Joe did you. Joe may have vanished. What about Fabio? Yeah, I'm here. Okay. Did I miss anybody else on the roll call? Close. I think I have. If not, I'll put you here. Yeah, I think I'm okay. Maybe I missed you. Okay, class. Joe Sherman had to drop off like 10 minutes ago for higher priority. Yeah. Well, you got Microsoft covered. So you guys are good. Anybody else? Oh, what about? Oh, I'm sorry. Thiago. Are you there? I just noticed that name in there. Thiago. Okay. I don't hear him. All right. Cool. Any, uh, in that case, I believe we're done. And we'll see if fair know you guys next week. If not, everybody have a good vacation and we'll talk again. January 10th. I believe is the next call. All right. Thank you guys. Bye. Happy holiday. Bye. Bye. Bye.