 All right, it is three after the hour. Why don't I go ahead and get started? I assume you guys can see my screen, okay, right? I'll take that as a yes. All right, moving forward. So I don't think there's anything special to mention on the AIs when Austin gets on. If I don't remember, please somebody remind me we need to now again to set up the next SDK call. Community time, so for those of you who are new, this is a time when people who don't normally join the group can bring up topics for discussion. Is there anybody on the call who's new that would like to bring up a topic? And Josh, I already have your topic added to the agenda, I believe. Anybody else? All right, moving forward then. Without Austin here for the SDK, I don't think anything's really happened there other than the GoLang SDK repo that VMware was working on was just officially moved over this morning to our org in GitHub. So if there's anybody on the call who would like to be added as a maintainer to any of the SDKs, please let me know. Because as of right now, I think I've only added one person as a maintainer on one of the projects. And obviously we need more because otherwise nothing's gonna get done. So please let me know if you wanna actually work on those and now's the time to jump in as a maintainer while there's nothing there. Kathy, I don't see her on the call. So I don't think anything's happened there though relative to the workflow subgroup. She joined, I'll ask her again. So if I forget, so please remind me but I don't think anything's happened there. We did have a meeting relative to the Shanghai KubeCon sessions. You can see the links to the document and the slides that we're working on. Mainly Kathy, Clemens and myself will be doing some presentations for the intro and deep dive. I don't think there's a whole lot of stuff in there right now. I think Kathy's the only one that's actually added some information to the slides. But whether you're going or not, feel free to review those. And if you have any questions or comments or suggestions, please speak up and we'll try to get them accommodated. Airop work. I haven't heard a whole lot from anybody about the interop demo that we're trying to do for KubeCon Seattle. So what I wanna do is try to force the discussion. So I will be sending out a doodle poll. Unfortunately, due to travels and stuff, I need to make it end kind of early. So expect the doodle poll to come out later this afternoon but I will shut it down by end of business tomorrow with the hopes that we can maybe have a meeting early next week to start talking about the interop demo. Okay, so just a heads up, keep an eye out for our doodle poll note. All right. And with that, I think we can now jump into PR stuff or discussions. So last time we were talking about casing of our properties and we had, I think, at least four different options in front of us. Now, Clemens, you closed one this morning, 3.27, I believe. Do you wanna talk a little bit about why you closed that one? Clemens, I can't hear you for talking. Can anybody hear Clemens or is it just me? How about this? There you go, it's better, thank you. Yeah, the microphone didn't work apparently. Yeah, so I had two PRs which basically went through them last time which are effectively the same but the second one and the first one here on the list effectively introducing the underscore character and then separating all the terms with underscores and it ended up looking very, super clunky, I think. And to effectively limit the choices unless someone really, really, really, really wants to insist on the underscores and then I can go and revive it. But so this is the one, yes. So I closed that one because ultimately I think the one where we have simply we're certainly the character set to lower keys, characters serves the purpose and if we're doing a further cleanup of names where we strike like the event prefix, et cetera then legibility is not going to be that terrible. And so I'm basically retracting the underscore alternative. Okay, and someone on last week's call it may have intimate care. Remember I mentioned that some web servers have problems with underscores. So I did a quick search this morning and I did find this link, I stuck into the agenda doc that talks about some issues that some servers like NGNX has with them you can tell it to support it but you have to go out of your way to support it. So I thought that was kind of an interesting little bit of additional information. And then if we allow them and then we have to go remap for HTTP then like we're entering. So no matter what separator we use we're running into different tastes that languages and infrastructure have with the separators. So that's why I'm favoring having none. And then we have the same issue with case folding and that's why I'm favoring we only have lower case characters and that's how we avoid most of the problems. I understand people's desire for legibility, et cetera but ultimately it's about interoperability and with the least common denominator approach we can achieve maximum interoperability at the price of some legibility which is ultimately alleviated by having an SDK that then seems native to the prospective runtime environment where it can be Pascal case or can be Kevill case, et cetera. Okay, so let me go ahead and pick on Joshua because Joshua you had opened up I believe this is just an issue not a PR about promoting or suggesting the idea of a snake case thing using underscores. Would you like to talk to that at all? I mean, if we go all lower case then that solves my issues. So nothing to add really. My issue was like Clemens was saying some of our databases don't are not case sensitive and so then we would have a little bit of difficulty in terms of these long field names that would kind of get munged once they all became a single case. Okay. So I like the idea of reducing the choices because I think it makes any kind of vote we have easier. So let me ask this question. Does anybody have any objection or concerns with Clemens closing 327, which is the one that adds the notion of allowing an underscore? My only concern is that some people they point out that they would rather have underscores. So nothing else. So I guess what I'm wondering then with that comment are there other people on the call? Well, let me put it this way. Are there people on the call who would like to advocate for having an underscore character in there in essence reopening 327 and making that one of the choices for a vote? I don't. I've been somewhat curious what if the conversation would be all that different if it were a dash, but I'm not, I don't have the strong opinion here. Okay. Yeah, I think you would find more system problems with dashes. Okay. So I'm not hearing anybody asking for 327 to be reopened. In that case, am I correct? Am I assumption that we're basically then back to, I guess, I wanna say two choices, but technically it's three because we could choose to do nothing and leave it as is. But the two alternatives for making changes are 317, which is camel case, and 321, which is lower case everything with no underscores. I believe those are the two choices in front of us. Christoph, would you like to talk to 317? I think you might have missed last week's phone call where we're talking about this. So you didn't get the chance to really advocate for 317, I don't believe. I actually was there last week, but we ran out of time. Okay. Yeah. Well, I don't, before we kind of start arguing maybe, I wanna say that I opened the first PR and my main concern was that the spec currently doesn't really define what a character set is, that it allows wide space control characters and so on. And it doesn't define how HEP headers look. And I think it's good that we now have two PRs to choose from and they both address these concerns. So I'm also super happy if Claments PR gets merged. I think it addresses the same things and that's really a big step forward. So that's the big picture for me. Interesting. That said, I still prefer camel case. It looks nicer. And so what I did is, basically I didn't touch any of the attribute names. I kept them as camel case, but I restricted the character set to ASCII. This allowed basically anything that is not an African American character. The difference to Claments is that I, or the difference is basically that I still allow the case sensitivity. Yeah. And that's basically for the main spec. And then the question is how do you do it in the HEP, which is actually, I think the only transport way, maybe someone can correct me if I'm wrong, but I think all other transport layers that we currently support also support case sensitivity. So then the HGP headers are the only ones that don't. And so here the kind of the convention in HGP headers is that you separate words by dash. So I tried to build an algorithm that says if there's a dash in front of a character, you have to treat it as uppercase. And if there's no dash, it should be lowercase. And given that we are in the FK character set, it is actually fine with case folding. I'd say case folding is a big mess. If you're in YouTube eight, what's the sort of FK it should all work out. Yep. That's I think everything I want to say to it. Okay. Are there any questions for Kristoff on his suggestion here? Okay. So in my case, let's open this up for a broader discussion then. Are there people who would like to speak in favor or against either the two proposals, meaning 321 versus 317, to try to convince the group one way or another? Welcome back. This is Josh. I'll just say that one of the reason that I brought up 327 is because in what I think I mentioned in databases, in some of our databases, there was no case sensitivity. So that mapping kind of gets, I know it looks better in, I know chemo case looks better in JSON and elsewhere, but in some of the databases, it would look very bad. Just pointing that out. Okay. Anybody else have any comments? My only net is that if we choose 317, can we please decide that the D on ID can be lowercase instead of having a dash between I and D? We could probably do that as a follow-up PR, yeah. Any other persuasive comments one way or the other? You guys are not this passive. I know you guys have strong opinions. Come on. Okay. Well, if no one wants to say anything, I'm of the opinion then that because we only have two choices in front of us, the choice, well, let me put it this way. Is there anybody who believes that we need to leave it as is? Okay. Not hearing that. It does sound like we have to make some kind of change. This is the consensus of the group. So it sounds like we have a Boolean choice in front of us. 317 versus 321. What I'd like to do then is start off, do a formal vote. And I think per the latest governance rules, it's going to be a seven day vote. So which means it'll end the beginning next week's call. What I'll do is I will put a comment into the, I don't have one PR to look at. I think I sort of thought this thing through. I was actually going to do a CI VS vote because I thought we had three choices. So tell you what, I will figure out which PR to pick on and put a note in there asking people to vote one way or the other for 317 or 321. And you guys will have until the beginning of the phone call next week to vote. Is there anybody who would like to vote right now? Otherwise I was just going to wait for people that may put comments into the PR itself. This is Josh. I can vote right now for 321. Okay. Oh, I'm sorry, Josh. You don't have voting rights. I apologize. Oh, no worries. I apologize. So of those who have voting rights, let me go back over here and get the link. I apologize. Since you're new to the group, Josh, you had no clue about the wonderful bureaucracy we have. So anybody, any company that has a green box associated with their name can vote. I'm assuming most people know whether they've been attending enough to know what they can vote right now or not since my machine is dead slow. I can vote for, can I vote for Microsoft? Okay. So Microsoft wants to go for, I'm sorry, wait Microsoft, you wanted to vote for what? Okay, I was going to say, I thought you said Kimmel. Okay. No. I'm a little confused there. Okay. Is there anybody who'd like to vote right now? Anybody else? I'm sorry. Yeah. Yeah, it's Jim. I was going to do 321 as well. Okay. PayPal is 321. Anybody else would like to vote now? You don't feel obligated. You guys can definitely wait till later. But if you want to get out of the way, feel free to speak up. Or it's trim 321. Okay. Anybody else? Google 321. Okay. Anybody else? All right, I'm not hearing anybody. And it's Kimmel case, 317. I'm sorry, that's the, it's Brazil Bank, right? Yeah. I can't remember how to spell that. What is it again? ID UA. What? Yeah. Got it. And you said you wanted 317. Oh. Okay. And you wanted 317, correct? Yes. Okay. Got it. All right. Anybody else would like to vote now? All right, cool. In that case, please wait for the comments in the PR and then you can vote over there. And you have until the beginning of next Thursday's phone call to do that. All right. Is there any other discussion points on the case, property casing issue that people would like to bring up before we move on? Okay. Oh, next on the agenda. Protobuf, I don't see Spencer on the call. Rachel or Thomas, Kim, what are you guys talking to this or should we wait for him to be on the call? I can say some things about it if that's useful. I think if you had looked at this before and you had made comments, your comments have probably been addressed in this version so it's worth looking at it again. This is, this doesn't try to serialize things any differently. It doesn't try to match up JSON to protobuf in any way. So it's just dealing with protobuf. So take a look, see if there's anything, like my expectation of this is that there's nothing controversial in this. We'll see if that's true. All right. I left out short as by the way. It's very short read. I liked it. Anybody have any questions or comments on it? Anybody have a chance to look it over? I haven't looked it yet. Okay. Yeah, I did make some relatively minor suggestions or comments in there, Rachel. Maybe you can ping Spencer. I think all my comments were mainly editorial or relatively minor types of things, but overall it seemed like it was okay to me. So thank you guys very much for doing that. Yeah. Okay. Anybody else have any questions or comments? Oh, you guys are so quiet today. This is weird. Okay. I guess we'll keep moving on then. Joshua, make event ID optional. This should be fun one. You wanna talk to this one? Sure. Yeah. So we started having some discussions this issue and I mean, so my initial feeling was probably the same as I think what you guys initially decided was that, hey, you know, an event ID is a good thing to have. And then we realized that we actually didn't need it at all. We didn't wanna have it because it would become a secondary source of truth for what isn't a unique event for us. And we're one company, but we have one group that's mission is to have an accurate accounting of events that happen in the company. And we don't necessarily, you know, want to, we don't wanna make the effort on the bureaucracy side to make sure that every group that's going to be submitting events into the platform is gonna create the event IDs correctly. So we said, you know, there's no need for an event ID. There's no need for anyone to create one because even if we're not gonna necessarily trust it. So for us, we just want, you know, the data that's coming in. And as I mentioned in the original comment, the data being who created the event in which system at what time and what type of event it is, is enough to uniquely identify the event in every case that we have. So if we decide that we do want unique IDs that are a single field, then what we wanna do is to create those at the platform layer, which is downstream of where the event is initially created. So that we know that we're doing it. We know exactly what the logic is for creating that unique ID. We know that it maps one to one onto a certain set of fields. So that's the reason this whole thing came about. And I know that there's definitely feelings that, hey, you know, having that single event ID field would make downstream, certain downstream things easier. And the only thing I think that, I mean, in addition to the deduplication reason, I think that, you know, there's another reason to have a single field event ID on there, which is that, you know, if you have a system that needs to look up an event, like, you know, you just wanna pull it up or have a URL to it or something like that, then having a single field is a good thing. My contention though, is that at the point where you do need the single event ID field, you can annotate the event with that, you know, but not necessarily force everyone who is producing the event to create one because that might just end up misleading folks. So that's all I have to say about it. Okay, I see some people coming off me. Would anybody wanna have a question or comment? Yeah, from the platform perspective. So from an intermediary middleware messaging perspective. Let's say you're producing an event and then you expect that event to pop out somewhere else and there are, you know, three or four moving pieces and routers in the middle that take care of taking your event in, holding it, moving it, forwarding it and then making it ultimately available to you, just basically for diagnostics, when you say, hey, I'm missing this event and I wonder where it is. The great thing about the event ID is that it is a field that we know of because it is in cloud events and that we will put into logs and so that we will have in our tracing information. So if you show up at our support, we'll be able to use that ID to gather with your tenant information to go with that event and basically create that evidence trail to help you. If you are using another combination, you're effectively forcing us as a cloud provider to do a correlation query through, you know, several trailing events at worst to try to find your event and so having an ID is fairly useful. Yeah, so I saw this argument as well. I think, I mean, that makes some sense for sure. What I think about it though, is that what you're talking about is kind of like a trace ID use case. And again, I think that will certainly be useful under certain circumstances, like you said, where you have complicated pipeline of things happening. But I think that using the event ID for the trace is not necessarily, I don't know. I mean, it's not necessarily the ideal solution because there can be a more dedicated field for tracing. If you need one, then you add it in. Yeah, but see the point is, me as an infrastructure provider who builds generic messaging infrastructure, right? The point of, almost the point of why we're participating here is because we want to have standardized minimal metadata that we can rely on that everybody sends so that we can then provide services like traceability and diagnostics, et cetera, and debugability ultimately, based on top of those features. So you turning on an extra extensions to turn on features that we have, that becomes fairly complicated. And that's why message IDs are required in messaging systems, and that's why these event IDs are made required here because middleware can help you with that. And even if it's not complicated, even if it's just a topic with a dispatcher, there you already, and you're not operating it, then you already want to have traceability. And that's why the ID here is required. Yeah, and just to add on to Clemens, these cases, event ID is also hugely important for idempotency. And though it may be possible within your specific application domain to build idempotency on the specific events that you produce, the whole point to cloud events is interop. And we want to make sure that anyone who receives a cloud event can use it for idempotency. So like, though it may sound a little harsh, if you want to pass on messages that are not cloud events within your system, that's fine. But like, once it actually goes to any other consumer, it should probably follow a standard convention on how to have things like idempotency or identification of these envelopes. Correct, can I just, I was gonna go ahead? Yeah, sorry. Just to push on that on maybe Clemens point a little bit. As these events move between providers, doesn't that tracing argument fall away there? Because it's only, I must admit, as well since I read the spec, is that event ID meant to be globally unique to everybody or unique to a publisher or unique to a tenant cloud provider? I always assumed it was an idea signed by the guy that generated it and it was just unique to them. Unique within the scope of the providers what the spec says as of right now. The cloud provider or the provider of the event? And I guess maybe I'm overloading the term now because I think there are people on this call that would be looking to use these events or these structures outside of the context of a cloud infrastructure provider. I apologize, I used the wrong word. Producer, not provider. Producer, okay. We have to source identifier and then think of the ID being relative to that. Right, okay. So it's unique within that source ID. Yeah, but okay. Does that make it globally unique? And I'm just pushing on your tracing use case. Together it will be, yeah. And within a cloud provider platform. Yes, I mean practically speaking, we can also mandate that it'll be good. We're just having it. Right, no, I understand that. I am just trying to understand the level of uniqueness that this group think is applicable. I think this board have a very good discussion. So what's the unique scope? If you say this unique for the event producer scope then it might not be unique for the service platform scope. It won't be, it might not be unique globally. But how can you guarantee all these different producers they can cooperate well that they all use different event IDs? Isn't it going to be contextualized within the source context like Clemens said? But then again, the domain through which that cloud event can travel is going to be security restricted anyway. And so then that context is further a further boundary within which it needs to be unique. So I don't think saying it needs to be globally unique between everyone on the cloud provider is actually an issue because the security implications of that would be massive. So as we have these boundaries that's where the uniqueness defines its context and that's where it's needed. So you are saying it's unique globally? Is that your point? I'm saying it shouldn't have to be unique globally amongst everyone within a cloud environment but within the development, within the context within of what it's interoperating with. That makes sense. Not really, right? Because for example, if like for so I'm a serverless platform I could deal with over, I mean maybe like over 10 event sources, different event sources. How could I be sure those event sources they cooperate well, they're going to send out, they're going to assign the unique event IDs? Because they'll have unique sources in the first place. Pardon? They will have a unique source and then each is going to have a unique event ID. Yeah, I agree it's unique per that source but if I receive events from many different sources and those sources belong to different event producers, different vendors, I don't think as an event consumer as a serverless platform, I can be a piece of mind that all those event IDs are unique globally and all unique for per the platform scope. I think what I'm hearing them say though is that event ID uniqueness is scoped to the source URI, is that correct? Yeah, to the source URI I think that's not, is that can be guaranteed but I'm just thinking, we cannot guarantee it's unique globally or unique per the consumer scope. If that consumers receive events from different event sources, different event vendors, producers or vendors. So I think also the usage of this event ID, although I agree it is implementation but I'm just wondering actually, I think this PR raise a very good point. So how, I mean, what is a scope we can use it? I'm not saying we should not have it but I think we need to clearly define this so to avoid misunderstanding or misuse it. I think my point was the company that we work with, when are they going to reach all the security considerations that are required? If our events are going to be naked or non-encrypted within the context of other events which we don't trust, there's always going to be some kind of security context which is trusted and within that security context, you know who you're talking to and you know the other organizations and that's the boundary within which you have the ability to understand whether or not it's going to be unique. So let me just say effectively. So let me just go to the speaker key to go to the other hands up. Ryan, you had a question? No, I don't have a question but it sounds like someone mentioned that the producer has its own unique ID. So the consumer just concatenate the producer and the event ID, that's a global unique. Isn't that the case? So it's the combination of producer ID and the event ID is a global unique ID. When you say producer ID, you mean the source ID, right? The source ID, yeah. Yes, it would be. Yeah, yeah. So I think what I'm hearing, I think I'm hearing is sort of two different discussions going on here at once. One is Joshua's proposal, which is to make it optional. But then there's a secondary discussion here which just talks about whether the text around event ID needs to be clarified with respect to the uniqueness aspect. And I think those are almost separate discussions because whether we adopt Joshua's proposal or not, I think based on what I'm hearing, it sounds like people do want a little more clarity around what the uniqueness is for the event ID. Is that a fair statement? Yes, I think so. Okay, so let's take that as a follow-on discussion. And we'll start a separate thread about that one. But let's try to circle back around to the optionality aspect of event ID. I'm hearing a few people say that they think it's important to be there, which is why it was required in the first place. Is there anybody, I see Joshua's on the side of keeping it optional. Is there anybody else who would like to speak in favor of making it optional? Okay, I'm not hearing a whole lot of support for that position than Joshua. Is this something you'd like to pursue further if I have more discussions in there or how do you want to go forward? I mean, I think that's fair enough. Like if you want to define the cloud platform to start at the point at which the event ID has been defined, that's fine. And we'll just keep our stuff that doesn't have an event ID in it separate from that. And if we need to use any tools for an interoperability sake, then we'll transform it into a proper cloud event by creating the idea at that point. Okay, you said something in the introduction of your issue and it kind of stuck in my head. I just wanted to get some clarity. When you were talking, you said something along the lines of there may be some issue with people generating the event ID properly. And it was the notion of it being generated properly that I got a little confused by, can you elaborate on why people would have the difficulty because it's just a string. It's not even a GUID. So what did you mean by properly? Well, what I mean is that it has the meaning that it's intended, right? So for instance, we mentioned, somebody mentioned item potency, right? So if someone is, let's say, generating a GUID every time they make the call and they do that for each retry, that obviously wouldn't be what we expected. When this is something we've seen before, is people have accidentally set it to a constant value or not set it at all and then it's a constant value. And then obviously that's not what we want. So by setting it properly, that's kind of what I mean. Or maybe they make it a hash of a certain set of fields but they're not the right set of fields. Gotcha. So yeah. Okay, so guaranteeing the uniqueness aspect. Okay, that makes sense. Thank you. Yeah. Okay. So then in moving forward here, since I'm not hearing anybody else arguing in favor of this proposal, am I hearing the consensus of the group as of right now is that we close this issue? I'm not hearing any objections to that. So Joshua, keep in mind that just because we may close an issue doesn't mean that we can't reopen it, especially if new data pops in. Like for example, you come across a use case that we just hadn't thought about that everybody does care about. And making it required, it becomes problematic. We can definitely reopen these things. Okay, sounds good. Okay, cool. Okay, before we move on though, is there any other comments or questions on this one before we move on? Okay, cool. Thank you, Joshua. I appreciate you joining the call. Okay, so we have a Kafka transport binding PR out there. And it's been out there for quite a while. Let's see, so August. And unless I messed up, I don't believe the author has actually commented on any of the questions, comments or anything in here. And I've asked them several times to speak up or they're gonna address these questions or comments. I have heard back from them. I did give them sort of a little bit of a warning shot saying, you know, if you don't speak, don't mention anything by this Thursday, I'm gonna propose that we actually close this. But what I wanna first do is ask, is there anybody on the call who would like to champion this and own it going forward? I wasn't afraid to say this, but I feel that is something we should have. I tend to agree, but without a champion, it's gonna be a little hard. So do we have somebody going to volunteer to drive this one forward? Yeah, I'm happy to take that on. It's Neil here. Okay, Neil. Excellent, thank you, Neil. Let me put that in the minutes. I'll add a comment to the issue, or sorry, to the PR saying that you volunteered to do it. And they obviously can speak up and object, but I think probably the best way to move forward is probably open up another PR that just picks up their commits and adds stuff to it. Cause I don't think you have the access rights to actually modify their PR directly. That's right. Okay. Thank you very much. Hey, Doug, Neil, this is David Baldwin. Can you add me to that as well? And I'll see if I can help Neil out or ask me, my team help Neil out. That sounds good to me. If you need it, Neil, I'm not sure if you do or not, but no, that's great. Thanks. Okay, excellent. Thank you guys very much. I felt a little weird closing it, but without any movement, it was a little hard. So thank you guys very much. Let's see. Last item on the agenda. This one has actually been there for a while. From a process, I'm sorry, from a release process perspective, I don't think we were very clear about whether we're going to version each of our documents independently from each other or bundle them all together. So what I did is put out just a strawman proposal here to suggest that basically we take all of our normative specs and the primer and group them together as a single logical unit, which means as we move to point 2.3 or 1.0 or whatever, everything will get tagged with that particular version number, regardless of whether that particular doc itself has changed. That way everything is sort of at a consistent sem-ver number. The only doc as of right now that would not be included in there is the extension document, since that's more like a wiki page more than anything else. But it would include the main spec, the primer, the transport bindings, all those things would get lumped together. And so that's my proposal for how we handle versioning of our docs. What do people think? Is silence okay? Don't care, hate it? It just, it has a lot of implications to think through. It's not that I'm not like, I don't care. It's probably, like, is it worth thinking? Like, it's probably worth laying out and being really explicit about how this works, right? Can you elaborate a little on what you're looking for? So like, we have a lot of moving parts. We have a lot of specs right now and thinking about like what it was like for them to move along at their own pace or all move together through semantic versioning has different implications. Like say I'm thinking about the JSON spec, the JSON spec is fine, but this other, like the proto spec needs to increment. I might be miffed if I had to like continually like increment. So for example, if every time something increments, we increment every single thing, we're going to get up to pretty high numbers pretty quickly, for example. And I don't know, it's just probably worth thinking about rather than just saying like this looks fine. I think this is probably the right thing to do. I'm just saying we should think about it for a second. Yeah, and I'm not, unless everybody was saying, yeah, yeah, yeah, let's do this. I wasn't going to actually push to resolve this one today. I just wanted to bring it up to people's attention because I do think we need to get this resolved at some point. So I agree with you. Definitely take some time, look this over. Just to let you guys know, my biggest reason for choosing this path is because the idea of each spec being version independently scared me a little because of the cross product of what spec of X goes with what spec of Y and which one match up. It just sounds like it's going to be a maintenance nightmare or a linkage nightmare, trying to keep all those things in sync. And letting people know which one to go with which spec. It just sounds like it could be a real pain in the butt. Yeah, I wonder if we can come up with a process that fixes that where we don't end up in weird situations where like on one hand I totally get the primers for version two should be associated with version two. But if I add to the primer in order to help people better use version two, it's weird that that now makes version 2.1. So keep in mind that this doesn't necessarily mandate when we modify, I'm sorry, when we increment the minor version number, right? So for example, a non normative change could technically be a, what's the third digit? The buzz. It's revisional, but yeah, I should have given revisional bump in the example. It still is a little bit weird that like we can't improve the documentation and have that show up in the results for how to use 1.0.0. Yeah, something to think about, yes. Okay, obviously I said, don't want to push this. Just take some time to think about it. Are there other ideas that people have on the call here that they'd like to offer? Even if it's just something you just thought of at this exact moment and hasn't been fully thought through just to get some brainstorming going? I think this sort of works because we should allow changes to documents at the minor or patch level. Yeah, so you're trying to group a family of things together, yeah? And that's really to me the major version. I guess it's whether you treat major and minor as a, dare I say, a releasable item because all those other things are really saying, yeah, I want to add a Kafka binding to version 0.1. That shouldn't change the major release of that spec family. That is true because we are trying to follow the semver pattern so everything should be backwards compatible within the X dot Y. Yes, exactly. Well, I mean, it's whether you want to take it to X dot Y or whether you just want to take it to X. I mean, we follow our API versioning internally at PayPal, follows that major version semantic. So you subscribe to a major version of something and everything's compatible within that. So stuff can evolve at minor or patch levels and you can add new features without, or mappings without breaking stuff. So it's where you want to pin the level of grouping that I think is important. So that's interesting and I'm a little nervous about suggesting this, but sometimes additional text for clarity sake isn't necessarily a bad thing even if it is a bit duplicative. Semver kind of defines all this already, right? And Semver basically says all minor versions are supposed to be compatible anyway. But would it be useful to call out that aspect in this definition? That way people understand that, just because we go to 1.1 doesn't necessarily mean you have to jump up to 1.1 because 1.0 is still fully compatible. If you don't need the extra features of 1.1 then you're perfectly okay sticking with 1.0. I mean, would additional text like that help or would it run the risk of potentially saying the wrong thing and then being inconsistent with Semver itself? Because I don't like duplicating text. Okay, not hearing anything. I'm not gonna add unless someone says so. Okay, so take your time, think this over. It'll still be on the agenda for next week. I don't think we're necessarily in a huge rush, but obviously before we get to 1.0 we need to make this kind of a decision going forward. Anything else on this topic before we move on? Okay, and that gives a technique at the end of the agenda. Are there any of these other PRs out there that are actually ready that I missed? Because I don't think any of them are technically ready. Okay, are there any of the topics that people would like to bring up for discussion at all on today's call? Hi, hi, Doug. Yes, hello. This is Mauhiro. I have a question about the workload subgroup meeting. I put my question in the meeting about and I got the calendar application schedule by email today and the update is just time. The stocking time is just a shift to stocking into something. And I just wondering are we going to have a meeting in next week? Oh, that's an excellent, well, I'm sorry. I had a very hard time hearing you. I think my connection is really bad. Are you asking, you're asking whether we're gonna have a meeting next week, correct? Yeah, I assumed we were going to have one. Is there something going on that would make us not have a meeting next week? I'm not aware of any events that caused this. I know the OSS summit and Scotland's going on, but I didn't think that was worthy of counseling the meeting. Okay, so I think we will have a meeting next week. I'm not hearing anybody mention some reason not to. Okay, and what kind of things are we going to discuss? I don't know yet. I'm assuming we may talk about the versioning scheme. We'll have the result of the property casing discussion. I'm sorry, I'm asking the teleconference of the Workflow Subgroup. Oh, the Workflow Subgroup. Oh, I'm sorry. So Kathy, would you like to talk about that? Because we haven't had a weekly meeting for the Workflow Subgroup for quite some time. So I don't think there's going to be one next week for the Workflow. Well, that's because I got the kind of update my email today. Oh, that was supposed to be a cancellation notice. Oh, I see. Yeah, because I apologize. I misunderstood what you were saying. I can't remember the person's name. I think the person's name is Taylor, one of the CNCF sort of administrative people. They pinged me yesterday asking whether they should remove the Workflow Subgroup calendar invite. And I said, yes, because we were not doing a regular meeting anymore. So maybe they made a mistake and they sent out a modification rather than a cancellation, but it was supposed to be a cancellation. I see. So could you scroll the screen a little bit here? I put a comment here. Okay. So, Cathy, correct me if I'm wrong here, but no call next week. We are only having calls on an as needed basis. Is that correct? Yes, that's correct. I think for the work group that dropped, I think we still need to go through it. And there are some, I saw some errors there. So maybe after the poop comes from high, I'm going to go through it, then post a new PRs to correct those things. And other people's are welcome to go through it and then pull issues or pull PRs. But just as a point of process, is that being managed in this group or is that a separate body? How's that functioning today? So now it's managed by this group. Yeah. Previously we had a separate subgroup meeting. We have, then we reached some consensus on the first draft and then we decided there is no need for that intensive meetings. So we're going to just discuss it as part of this group. But if needed, we can always have another meeting specifically on the workflow draft. Okay, to answer your question from a broader perspective, if the workflow specification that's being developed becomes mature enough to warrant it being sort of a standalone entity, then I could see a new work group or whatever the proper word is for it being initiated since the cloud events is focused just on the cloud events like itself and the workflow sits on top of it. So it'd probably be a separate entity at some point in the future once it gets mature enough. Cool, yeah. I thought it was something like that. And I think some of this is just the heritage of how this group started up in the first place. Yeah, okay. Yeah, it's actually kind of funny to think about it because you have the workflow subgroup which is under cloud events, which is technically still sort of under the serverless work group, even though they're somewhat separate entities. We have this kind of a weird relationship right now. Okay, thanks. Okay, any other topics we want to bring up? We have five minutes left. Okay, in that case, let's just quickly get those roll call strikers. Jem, I heard you. Renato, are you there? Renato? Okay, what about? He is here with me. Okay, okay, perfect, thank you. And Lee, I thought I saw someone pop in the agenda or the speaker queue with Lee, okay. Mike Place, are you there? Yes, I'm here. And which company are you with, by the way? I work on the Assault Stack Project. I'm the maintainer there. Okay, so I actually represent them or do you just work them? I'm trying to, for attendance purposes, I try to associate people with a particular company for voting rights. I do represent them, yes. Okay, cool, I just want to make sure. All right, is there anybody else for the attendance that I missed? All right, cool. In that case, we are done. Thank you guys very much. And I'll talk to you next week. And don't forget to vote, but please wait until I send out a note or a comment to the issue, which is the article. Okay, thank you guys. Time's up. Good one. Bye. Bye. Bye.