 You hear me? Yes, I can now. Good, thank you. All right, three up to the hour. Why don't we go in and get started? But looking through the AIs, I don't think there's anything worth, oh, wait a minute. No, no, no. I don't think there's anything worth bringing up well through the AIs. Other than if you have one, please get to it when you get a chance. Were you gonna share a screen? Oh, am I not? I thought I was. Yeah, he is. Oh, yeah, yeah. Oh, sorry, my fault. Okay, cool. Can I see that little green box around it? I'm a little worried there for a minute. All right. All right, community time. Is there anybody from the community who isn't part of the normal working group who would like to bring up a topic for discussion, whether it's an issue or question or concern or anything like that? Yeah, this is Tim. I just wanted to raise one thing that I thought might be of interest to the group. So we're doing a big new event driven thing. And one thing we learned is that our basic event structure we're really, really, really wishing we'd put in a time to live field. Having had that there already would have made life a lot easier. Just saying that something to bear in mind. Thank you. Okay, well, obviously you're hinting that maybe we should add one. So obviously, you know, feel free to open up a pull request to define it. Then then we can discuss it. Okay, fair enough. I was talking about MQTT the last time that I could get here. I've had, unfortunately, a lot of things containing for the time. I've got an MQTT sensor set up. I've got a few of them and they're all meeting data in a basic JSON format. So I'm trying to think about how to now get that into a cloud event. And it could just be building up the JSON on the device, sending it over MQTT or similar. I'm hoping to get a blog post together with it as well and show how you can then start ingesting it through a function. Cool. Is this something that you... I'm wondering if cloud events is a bit too heavy weight for two sensor readings. It's a lot of additional framing and context. I guess the way I would answer that is that for those use cases where it makes sense, you can use it that way. And there's always been the concept of taking a different event format and translating that through middleware into a cloud event for later transmission. So if your device is too small, you can still use your existing way of sending events out. You just translate it on another layer. Yeah. What did they say? You can solve any problem in computer science with another layer of direction or something like that. So yeah, maybe they should just send it in a plain format and then something listening as a broker could put forward it on. So Alex, is there something in particular that you're looking for from a spec perspective or is this more of just a brainstorming exercise right now? From the use case and community perspective, this is something that I spoke about, I think a couple of weeks ago and I've got the base work done now. So I'm getting the sensor readings, pulling them off MQT and sending them into a function. The next thing is to understand where to insert the cloud event framing. Okay. So it sounds like you may have some feedback for us once you get the full thing up and running and give us feedback in terms of whether there's something wrong with the spec or it works okay or something like that, right? Yeah, I'm hoping so. Okay. Yeah, because I think it'd be useful then, especially if you do find issues with the spec itself, then I think opening up issues or a pull request to actually make changes to make it better would be the next step. Or if you feel like just providing feedback at overall on one of these phone calls when you feel like it's time, we can just add it to the agenda and you can sort of go through what you did and what you can provide us with whatever feedback or information you think might be relevant. Thank you. That make sense? All right, cool. Anything else from the community? I suppose I could speak briefly. The effort so far has appeared to relate to transitory transmission of events and one of the use cases that we find ourselves very interested in in my team is the kind of event sourced or the commit log as the source of truth. And that, there seems to be, sorry, I didn't prepare these statements. There seems to be an assumption of the context of the transmission as being capable of dealing with things like authentication and validation of the contents. But if the use case involves leaving an event on a log and reprocessing it perhaps years later, the ability to, that context no longer remains. And so things like authentication signing that have been discussed briefly are less of a priority. But maybe this would be a good question to ask is does the community see kind of a permanent retention of an event or semi-permanent if there's gonna be some kind of a translation as part of the use case that is being addressed? Anybody have a comment on that one? No one? So from my point of view, I tend to look at the cloud event spec as more as a, this isn't the right phrase for it, but more of a transport mechanism or transport encoding put it that way. And what happens to it on either side of that transport is sort of out of scope for us. So the question of the persistence of a cloud event beyond it being delivered to a consumer is sort of up to them to decide and that's not really for us to say. Good. But that's just my two cents though. I mean, what other people think? Having been involved in the specification of several data formats over the years, trying to predict what people are gonna do with them is a waste of time. They do surprising things. That's true of every spec, yes. I just wonder if maybe a lot of the authentication authorization are usually at the transport is the event, not more of a payload, which really doesn't expect sort of higher layers to deal with a lot of the security issues? That does seem to be the general assumption. So let me be a provide a concrete use case. The log that's being built up of events written to it would contain something like bounce updates. And it would be appropriate for me to enter an event onto the log that transferred money from my account to another account. However, it would be inappropriate for Doug to enter that same event onto the log. And without the context of the active connection, then there would be without some sort of extra information. And that certainly could go in the kind of payload data section of the event if needed. So bear with me, I'm just trying to bring this up as an interesting thought exercise. But there'd be no way to using the cloud event spec ensure that that event was produced by somebody authorized to do so. It seems like that this might be worth just opening up an issue so people can think about it offline and put comments in there and we can all have discussion in that one spot. I mean, even if you ended up deciding not to do anything with it, I still think it might be useful just to document it someplace to show that we actually thought about it and we decided to do one thing or another with it based upon that discussion and people can sort of see the history of it. All right, thank you Doug, I will do it. Okay, cool, thank you. All right, I think we got one more minute left in this 10 minute time slot. Any other community related issues people wanna bring up? All right, cool, moving on then. Austin, last week we looked at your issue and I just wanna verify one thing because you had a link, excuse me, to your issue but you were pointing to an old comment in there and I wanna make sure that the very last icon or image that you pasted in there is the right one we should be looking at, right? Yeah, that's correct. Okay, cool, that's what I thought if I make sure. Okay, so last week, excuse me, this was on the agenda, asked people to take a look at it. Does anybody have any comments? I could chat about it briefly, Doug. There you go, go ahead. This all got started because I suggested that maybe we could incorporate a better font that might be a little bit more modern and cleaner aesthetically. And I took it upon myself to go do a quick revision to the Cloud of Ed's logo with this updated font and as I did that, a few other people chimed in with other thoughts and we kind of investigated some other icons briefly but it seemed like we were kind of falling back on the old icon here except some people requested that I tried to make the C&E stand out a little bit more because it seemed to get lost in the general way that the icon was flowing. So I made one simple change here. I simply just put a gap between that kind of bottom end of the E and the rest of the Cloud which wasn't there and after going through a few revisions over like an hour I found that this little minor change was the best thing that still kind of kept intact the whole balance of that icon in general. So one minor change, let me know what you all think but otherwise I think it's good enough for now and I think we can proceed to shirts and stickers and all the swag. Yeah, we just, Claire, when we do see the version that has the tagline disconnected just so there's two assets cut and would you have an inverse version as well for darker backgrounds or darker t-shirt? Yep, as soon as we agree on this I could just share the sketch file and it has and I'll quickly generate those alternative versions as well. Sounds good to me. Okay, so I heard a lot of people talk about how they wanted it without the tagline so I guess my one question is when would the tagline appear in what situation? When thinking about open source projects and branding them, the first thing that comes to mind is a graphic on the top of the readme and I always start there because that is where you communicate to developers like first and foremost these days. So that's kind of what I added in mind as I designed this thing and I just threw in a tagline it's not the tagline. I don't know if we really have a set tagline but yeah, that's the context which I imagined while I was designing this. Okay, so that makes some sense. So I guess a few questions here. Do people, let me phrase it differently. Is there any objection then to changing our logo to be the new cloud thing with the cloud events word underneath as depicted here in this last comment? That sounds great. Okay, not hearing any objection. Do we wanna have a discussion at some point about the tagline itself meaning the actual text in there or are people okay with it as is? I think since it's not going to be used for anything right now since it's not gonna be included in assets it's time to like save that for a future discussion. Might be a good GitHub issue. Yeah. There may be something that we can do to jazz it up a bit. Okay, so Austin, can you take an AI to open up an issue, discuss the tagline and then in the meantime, finish up what needs to be done to switch out our icon? Sure thing. Excellent, thank you very much. So let's just document this. All right, cool. Anything else related to logos? Once the new one is ready I can start ordering stickers. I had to get a coupon code from Dan Kahn so I can order a whole bunch of stickers through the store for free but then you should be able to order your own stuff through there. Unfortunately they don't have t-shirts available through the CNCF store so if you wanna do t-shirts have to go someplace else whether we do it at the group or individual companies wanna do it that's up to us to decide I guess what we're on once the icon's ready to go. Let's test that later I guess. Cool. Anything else related to logos? Rather than a t-shirt, maybe a stationery is appropriate. Stationery, what made you think of that one? Like an envelope. Taking multiple letters. An envelope, man, that's old school buddy. No, he's not talking about using it, he's talking about it cause it's funny. I know, I'm getting used to Scott's sense of humor. It takes a while. All right, thank you Scott. I'll be expecting an envelope from you next time I see you. All right, moving forward, Austin, SDK, anything you wanna bring up from the working group call yesterday? Sure, I'll do a quick recap. There are a few of us who are working on cloud events, SDKs for cloud events. We have a few implementations in the works, JavaScript, Go, and Java. And someone was doing a pipeline one but they weren't at the last couple meetings. So anyway, we're cruising along. We have our roadmap laid out in the cloud events design proposal document. And what we did during the last sync meeting is we shared our progress and we shared kind of pain points where we need additional clarity in our learnings. We have a couple of things that we kind of need some, we still need to figure out. The first is how to design the SDK in a way that it can accommodate this spec as it evolves. If we're gonna be building kind of APIs, getters, setters on cloud events in the SDK experience, how is that gonna be affected when the specification evolves? So that's something we're still trying to figure out. And also we realize that there's a bit of a challenge in how we handle all that evolution also with the transport and binding specifications and how those are going to be evolved. Because if the cloud event spec is changing and the transport and the binding specs are also changing and we're trying to build the SDKs around this, it's a bit complicated as of right now. So getting some clarity as to how we're gonna version the cloud event specification and the transport binding specifications would help us figure out how to design the SDKs. And one other big learning we had was that we felt that extensions, in addition to just being custom properties on the cloud events envelope, should be an experience that's kind of carried through into the SDKs. And we kind of pioneered this idea of almost like middleware or hooks, extra modules of code that you could add to the SDK that would kind of extend the ability of the SDK and what you can do with it. So a good couple of examples are, maybe if someone is making a middleware products, they could add in their extension for that middleware product into the SDK. And if the SDK has a published method, it would use that specific middleware to send out the event as well as put custom attributes in the extensions area or as extensions on the cloud events envelope. So we wanted to think about that experience not just as custom data anymore, but also code and logic that you can add into the SDK. And I think if we do that, and we think about that first, when we're just architecting the SDK, that is gonna set this effort up for success because that is a great place for vendors, for the community to add, to build right custom code to extend this and do more with cloud events. It's a great place for companies and teams to bake in, like to write their own extensions to ensure that whoever is doing this event-driven development with cloud events can follow standard kind of organizational policies. It's a great way to put app-specific information, make app-specific extensions. So there's a lot of use cases for that. We realized that we wanna figure out that extension story in the beginning of the SDK. So we're working on that right now. Sounds like I got a question. I have a question. Is this considered a SDK or the SDK? Like, is it expected that, like, if we want to do something different with it, we could create our own SDK that would still conform to cloud events that would do something slightly different somewhere. I don't know if we're in a position to say this. I mean, we've decided we're gonna make SDKs for cloud events. It sounds like we're also gonna put them in the cloud events org on GitHub. And they will be SDKs for cloud events. And I think given that they'll be there, they'll have a lot of community support, but in no way does that prohibit anyone for making their own SDKs and their own custom things. Additionally, the extension's story, if we get this right, it should be a great way for you to really customize it to do all types of things, if that's of interest to you. So I feel free to always write your own code and stuff. We're just kind of working on this stuff together to come out with a similar implementation across different languages so that, you know, developers have an easy experience. I'd also say, you know, be sure to work with the team that's designing SDKs, and if there's changes that you want, work with us to get those put into the cloud event to repose in the first place. Fair enough. Yeah, and one thing, Austin did talk about this. I'll just hammer the point home. One thing we tried to talk about yesterday was, obviously we're gonna have different SDKs for each language, and we wanted to make sure that there was some consistency across the various language SDKs so that even though the exact mechanism by which you may do certain actions within each language could look radically different based upon the language constructs because you wanted to feel natural to that language, the overall feature or semantics of what you're trying to do should be consistent across all the SDKs if possible. That way, no matter what language you're working on, you should be able to do the same type of action and get the same net result on the wire, for example. Having said that, from my point of view, while I agree with what Austin said, anybody's obviously free to write their own SDK. If, as an example, there is already a go SDK sort of that the group is kind of working on, it'd be really great if someone who wanted to do it, who wanted to work on a go SDK tried their best to work with that current one if they could. But for some reason they found that they had to fork it or go their own way, obviously they can choose to. But as a community, it'd be great if we could sort of rally around what we're producing here and have a whole bunch of different versions for the same language. Yep, at the very least, Rachel, there's a cloud events SDK, Google Doc. Feel free to just jump in and add some comments. Just look at the milestones. If there's anything you need or I think we should consider it early on, that would help whatever you're looking for in these cases that you want to accommodate, let us know. And there's a lot of ways you could use this. I mean, either building an extension, a custom extension for the SDK or of course wrapping the SDK with your own SDK or something else. I think over time, this thing will provide a lot of value and it's not just about kind of instantiating events or transporting them, it's also about validating them. It's also about kind of testing them, all that stuff. So, I think this, if we work on this together and we could collaborate as much as possible, we could really create something great that'll facilitate event-driven design, which I think a lot of people need in general. That's it, other than Doug is gonna create a repo and we're gonna start pushing our work in there. It's not final by any means, we're just kind of putting it all in the same place so we could have a centralized discussion. And as we approach the first version here, then we'll figure out, you know, whether to move each implementation as separate repos. What, but look out for that. I haven't gone through this SDK design doc yet, but just a quick question, does it include a section on the functionality of that will be covered by the SDK? What kind of, I mean, features will be covered? Yes, Kathy, absolutely, there are initiatives. We started off with drafting initiatives, all the things that we thought the SDK should do. We stack ranked them, prioritize them, and then we filtered them into basically a little roadmap that's organized around SDK versions. So the initiatives are all the things that we want the SDK to do and the milestones and scope is basically our roadmap and what we're focused on in the initial version and then the next version and the version after that. Okay, is there like, okay, so here this, okay, just a quick question, it define APIs. Is there like API to expose on the, what's that, the metadata defined in the cloud events? Yeah, that's a very loose description of that. So I apologize for that. I think we've kind of converged on a few ideas as to what that looks like. I'd say to get more info about that, let's just look out for the cloud events repo because we're gonna start pushing our implementations there and you'll see kind of some of the APIs that we're focused on initially. Okay. Anything else, Cathy? Yeah, that's it. I'm going to look at the, I guess when the code was put there. Yeah. Okay, cool. Excellent. All right, any other questions for Austin? All right, cool. Thank you very much, Austin. And I'll try to get that repo created today. Fantastic. Yep. All right, Cathy, would you like to update the group on the workflow work group progress? Yes. So we, in last meeting, we went through some existing offerings for the workflow. One is function graph, the other is open-wisk. And yeah, we have a discussion on that. And then we also went through review comments on the workflow proposal document. So I think we agree that we're going to post more comments and post posts at that draft. And in the next meeting, we're going to go through all the review comments and then discuss it at reach consensus. Yeah. All right, any questions for Cathy? Okay. Just a shout-out. The proposal doc that Cathy has, I know there have been some comments made in there, but I think it might be good to have more feedback. So if you guys get a chance, please do take a look at that document and provide feedback that would help the work group. All right, before we move forward, any other, any last questions, comments for Cathy? All right, cool. I don't think there's any issue maintenance issues that we need to work with right now so we can jump into PR stuff. So let's see. Now last week's call, Clemens talked about this qualifying protocols and encoding document. And we talked about how this document was basically going to define the bar that we were going to follow or use to measure whether we adopt a encoding or transport binding sophistication into our work group. And so people were supposed to go off, review this, make sure they're okay with the bar that he was defining here. I believe the only comments in here, I had a couple of words, Smithy kind of things so we can ignore those. The only other comment that was added to the doc was this one. I think Ryan, was this you? I can't remember if that's, yeah, this is Ryan. Ryan, did you want to talk to this one at all? Ryan, are you still there? Okay, maybe Ryan's set the way for a sec. So obviously you can read it yourself, talking about qualitative versus quantitative criteria. Sorry, I just get myself on mute. There you go, hey Ryan, go ahead. Yeah, yeah, just because I remember last time we were talking about Clemens is going to make it a list so that it would be more like subjective. We can go through the list and clearly say if it is meet the bar or not. I'm not, if I remember correctly, that's what he's supposed to do. But I'm not sure, I see clearly a list, one, two, three, four, you meet that bar. Now also the thing is he kind of put it more descriptive way that it could be infamous. For example, the one that I mentioned, I think let me see, it says the bar is it, that implementation should be with my comment. Yes, I'm sorry, I was trying to do, do, do, do, oops. Something like- There it is. Is define a fashion that allows alternative implementations. It seems to me that this is pretty loose, like what is allowed, it's not allowed. When he was talking about, he was a little bit, feels to me like he was a little bit more concrete. Like he says something like it needs to be implemented by two different organizations, something like that. Yeah, I think when he was talking about that, I don't remember for sure what he was saying. He wanted to have a firm number in there or he was talking in general about how some standards bodies of like, I think maybe Oasis or W3C. Something like that. Yeah, they have a firm number that you have to meet. This is just allows. So it can be, no one is doing anything, but still allows. And the allows seems to me is again, pretty subject which one is allowed, which one is not allowed. It's just my two cents. Feels like it kind of turned down a lot then before. Yeah, I mean, you are correct. He does keep it kind of loose there. This is difficult because obviously Clemens is not on the call, he's on vacation. But you're right, he does not have a formal sort of bulleted list of things. I believe these two paragraphs would probably be the closest thing to his bulleted list. Yeah. If you'd like to see a little bit more specificity around what the criteria is. In other words, basically like a bulleted list that says these three things must be met, right? And concrete terms, number of implications, that kind of stuff. Could you add another comment with concrete proposal for text that you'd like to see in there that way we can all look at it and consider it? Sure, yeah. Yeah, I can do that. Okay, I don't know. I mean, obviously we'd like to get this issue resolved at some point, but I don't know if we're necessarily in a hurry, we have to do it immediately other than there are two other PRs that are kind of blocked on this, new specifications. But I know those owners probably want to get it resolved soon, but I don't think as a working group we have to get this resolved today. So I think it's fair for you to take some time to figure out what text you'd like to see in there and then we can consider it next week's call if that's okay with you. Yeah, sure, I'll do that this week. Okay, cool, thank you. Are there any other comments from people's review of this? Are people okay with the general direction assuming we could satisfy Ryan's concern about not having it spelled out in like a bulleted list that's easy to parse? Does everything sort of seem like it's pointing in the right direction here? Hey, Doug, this is Colin. Hey, I just wanted to echo Ryan's concerns as well. I have some of the same concerns. And then also if there are gonna be, let's say, blessed transports, is there gonna be an option for other transports to get in as well, just to allow more people to integrate and perhaps add their own bindings into cloud events? Are you talking about other people being able to add stuff to our repo or just write that in general and host it on their own? Just in general, host it on their own. Almost like guidelines or anything? Am I making sense? Yeah, I mean, I'm trying to think what could we say because obviously anybody can do whatever they want, wherever they want. Right, right. If you could think of some text that might be useful to provide some guidance around that, I think it'd be useful to consider it. I've always opened to stuff like that. It's just a question of whether we can get the right text, right? Sure, sure. Okay. I don't know, what other people think? I mean, we can't stop people, but so should we provide any kind of guidance? Okay, is there any objection to trying to look at, seeing if we can provide some guidance? I'm not hearing any objection to the general idea of at least seeing what you come up with. All right, thanks Doug. Okay. All right. Any other comments, questions on this one? Okay. So let's see what Ryan comes back with and then hopefully, Ryan, if you can get that in there by like Tuesday of next week. Yeah, I do that, definitely. This week, before the end of this week. Yeah, because that way if people like the text, then that should give people enough time to review it and feel comfortable and don't feel too rushed. So I basically just to make sure, we're honestly, I'm going to basically kind of just that bullet, rephrase it and give a proposal in the comments like kind of the bullets. Yeah, basically, if you could do a comment in there that basically rewrites these two paragraphs in a form that makes you feel comfortable that it's clearer in terms of what the criteria is, I think that'd be great. Yeah, yeah. Yeah, I think the idea is just so that we can debate now and in the future with this list, it's no need to debate on any other things like could be relatively clear. We just go through this and say if this meets the bottleneck. Yes. Yeah, because the last thing we want to do is have people think that we're either playing gangs or doing some sort of politics around who we let in and who we don't. I mean, I don't make sure we have consistent rules that we follow. Yeah, exactly. Yep, totally agree. Yeah, so if you could just show the exact text that you want to see in there, that way again, there's no ambiguity on what we're voting on, then I could, if we agree to it, I could always just do a copy and paste and update as PR. Yeah, sure. Because you don't want me to wordsmith this stuff. It'd be better if you did. Yeah, sure, sounds good. Okay. All right, any other comments, questions? All right, cool, thank you much. All right, in that case, we'll skip the next two PRs since they're based or they're gated on Clemens PR. So next up is Kathy. Would you like to discuss your PR that has now been renamed to add a properties or renamed it to properties, or I'm sorry, add properties attribute. Do you like to talk to this one since there have been some changes? Yeah, okay. So basically, so this is about, so we are going to have a properties that for the event producer to put it's true information and then he thinks it's needed to this properties. I mean, the contents of the property will be key value pairs, but it does not have any mandated definition of the keys. For example, a producer could put an event identification label which will be used by the serverless platform or serverless, by the event consumer to correlate the event with other types of events associated with the same serverless application. This is just an example. It could be used for other purpose too. Of course, when the event producer add a new key value pair, he should make sure to use a name that is descriptive enough and also does not overlap with other keys. That's pretty much about it. And there in the extension document, there's some define some attributes. And if the producer like, he can put that as a keys inside this properties. This is optional field. And then there's an example of how to put this key value pair into this properties. If you score that, yeah, these are just some examples. So I think that the net of this PR when compared to the previous versions of this PR is that this is just renaming the extensions bag to be called properties and to make it clear that this isn't just for the things that we've defined in our extensions.md file. This is open for third party people, other vendors, whoever to include it for other things such as the correlation stuff that Kathy's talked about. Yeah. It's for more for the event producer who would like to use the cloud event. And then if they think, there are some key information missing for their categories of use cases, they can put some key value pair there. Any questions? I'm still not clear on how this is different from extensions. It's just a word change. It's just a word change. Okay. Because what do you describe what would be in properties here? It sounded exactly like what was in extensions already. Yeah. I think there was some confusion around how the extensions bag was meant to be used. In particular, I think there was some people in the group who thought that it was only four stuff that we defined in extensions.md because they both shared the same word extension. And so this was, I think this is an attempt to clarify that this really is for other things and not just the stuff that we might define in that document. Okay. I appreciate Kathy's effort here. I'm a fan of the extensions word personally, actually. It's fairly clear. Property seems a bit more confusing to me because it seems like everything is already a property in the envelope there. And we were just kind of rolling out this nice SDK experience around this whole extensions concept and this kind of might confuse the story a little bit. Not sure, haven't really thought it through, but those are just my immediate thoughts. I think that really depends on whether or not extensions move to the top level or not. Given that there's been a lot of talk about that, I think that properties and extensions would we would want to be able to delineate between them in that scenario, and so that we could identify them as two separate concepts. I kind of agree with that. I think this is something that many developers would want to use. Additionally, identifying the source. I mean, it's one thing to say extensions. My take is if we take an extension, it'll be more like most developers are not gonna implement it. Hey, it's when they're dependent. If we make it part of something more, I think this is what developers will use. Hey, it's one thing, an event has come out, but you want to identify more. There are more properties related to that event. This might take. I also think this particular property ends up being extremely useful when, let's say, the data itself ends up being binary and coded or whatever, you're passing some file along, et cetera. This ends up being a great place for the producer or for the application level code to be able to drop additional metadata that can describe or assist with that data block. Would it be worthwhile actually calling it, say, application properties or producer properties? Would that help at all? I think that might try to scope it too much, because one of the things, let me back up, so Austin is right. This is just a name change. What can go in there does not change at all. But I think what you're hearing based upon people's comments is that the word that we choose might imply certain things to certain people. So for example, when you saw the word extension, some people look at that as, well, I'm not defining an extension, I'm just adding a property. So obviously I shouldn't put it in there. Other people look at the word extension as it's just a bag of stuff. So yeah, that's where I put extra properties, right? And so it kind of depends on your history around how you've used these words in the past. And so I think we need to try to find a word that's generic enough to say, other stuff goes here. And we're not necessarily saying it's just for one particular use. And I think that's what Kathy was trying to do here with the word properties, is try to find a generic term that kind of allows for all those uses that we sort of are touching on. Yeah, I kind of like this direction that we're sort of heading right now, which is if we were to refer to extensions as basically extensions to the top level specification or the top level cloud events wrapper, which is new properties at the top level. And then this properties bag is effectively usable for dropping permits, anything into that the application may want to add. I think that helps draw a little bit of a clear delineation there. Well, let's not talk about the other PR that's out there. I think that's a separate topic. Because that may or may not happen. So let's deal with this one on its own first. This one is also limiting what being extension. The old extension is not just a name change. It also limits to only key value pairs. So does the word value imply just a string to you? Because I interpret it as anything. Yeah, I don't consider key value to be to allow any object or a raise. But I might be using the terms wrong. No, I know you're not alone because Scott had a similar comment in the chat. So Kathy, was your intent to have this be only string values or could it be any kind of value? So it's already say it's type map, right? So it could be other values, right? But it's like a key and then the value could be follow the map type. Would that be primitive? Any primitive? But I think the, yeah, so the type is the map. So whatever define the map, right? But I would like to say it's like a key value. So there's a key there, there's a value there. But it's because we cannot predict, you know, how different producers is going to, you know, what kind of is true information an event producer would like to put that in. So I think the key point is we do not have any mandated definition of the keys. So for one producer, they can put, for example, you can put a location information. Another producer, they can put like employee ID and maybe for another event producer, they could put a loan application, you know, ID, something like that. So, but I think to support, you know, a lot of IoT use cases and also other use, you know, just restricted to IoT, I think, you know, as an event producer, we would like to put some, I mean, people would like to put some additional information to help with support of that use case. Just a quick thought, it may be worth in our type definitions up here, just to maybe go the Java direction here and use angle brackets for declaring the types contained inside the map. I think that would help clarify a little bit those sorts of things for people. Okay, but there's a, actually, there's a definition of what type means, you know, because they're, what maps, not what map means. Because when you go up, there are other, there are other attributes that have map, which, yeah, which is defined here. Fair enough. Yeah. Just want to clarify, is this replacing extension or this is another one alongside extension? It's replacing. The extension is deleted. This is like, it's not just a simple replacement, I would say, but, you know, we're going to define the properties, property attribute. And for things that was in the extension MD, they are, where are they going to be? They can still be in there. She talked about that right here. Yeah, so, yeah, this is a, okay, so extension is a separate document. So that's why we do not call extension here because I know some people are confused about, you know, the relation between this extension MD and this extension. There's no hard, you know, how to say, binding there here. Just say, yeah, I know. So that's why I think that's another reason, I think, you know, change to properties. Sorry, what was the confusion with extensions? I think, you know, I think Ryan just raised, you know, is that this is, if we call this properties, we call it extension. It's that the same thing as the extension that MD document was address was defined there. Actually, I think, you know. So does it become kind of like a super set of extension and what other things like the producer want to put in? Is that stuff kind of like that? It's not like a super set, it just, you know, some of these producers would like to put on some attributes defined in extension.md and put it into this property is fine, but not necessarily. So he has to put, you know, anything defined in the extension.md inside this properties. But if this costs confusion, I can remove this, you know, this last, because I myself also feel if putting there, people might just think there's some relationship between this property back and that extension.md. Actually, there's no binding here. Well, I agree with you that there's not the relationship in the sense that extension.md defines the only set of things that can go in there. But I do think it, I do think we need to make it clear that it is one possible set of things that can go in there. Right? Yeah. Yeah, that's how it is written and say, you know, it's some possible. Yeah. But there's no real hard relationship. Say, oh, these two are really related. You can, even producer can put, you know, the key, the information which is, you know, the producers think are key to this event for supporting their use cases. Not necessary, you know, they need to put, you know, some attributes in the extension.md to inside this properties. But if they see some attributes in the extension.md which can serve their purpose, or which they think, you know, yeah, it's useful, they can put it in here. They confuse me a little bit more, actually. So if they see something in extension.md, they do not think it should be in these properties. Where do they put it? There's another. Oh, that's in the extension.md, yeah. I'm not like in the event itself. Ryan, the thing. In the event itself, they do not need to put anything, you know, in here. If they don't think it's important, they do not need to put into their events. No, I think what Ryan is asking, where should the extension.md properties go? And Ryan, the answer is into this properties bag. Oh, okay. Okay, that's what I thought. Okay. Should be here, right? Right. Yeah, so that just seems like, yeah. So they, for the properties that in the extension.md defined should come here. And things that does not defined, and if the producer feels like they want to add something, it also goes there, right? Correct. Yeah, okay. That's what I'm clarifying. Yeah, that's why in my mind, this is just a word change. If I could talk briefly about the history of extensions, the reason why we came up with that title back in, it's like November, last November, was because we wanted this event story to be similar to open API story and open API has this concept of extensions. And they just say it's custom properties. I think that's all it is. And to kind of mirror that experience in the event-driven design world, we thought would be helpful. And I understand that everybody has different, experiences with terminology and interprets things differently. But that was just some context there. If this is just a name change, properties to me is a little bit more confusing, maybe, and I know we're getting into the naming discussion here, but I don't know, something like custom might be a little bit more helpful. I think that the name thing is the only thing I'm getting hung up on. And then of course, we just, we've got to resolve this issue ASAP so that we can start building stuff on top of this. Cause this is, you know, continue to change this stuff is going to block the SDK design and a lot of other stuff, I imagine. Yeah. So we are running a little long time. And so, since this was just put in there yesterday, obviously, I think it's too soon to vote on it plus of all the questions people have. I think it's fair to defer this at least another week or so. But please look at what she wrote here. Think about it. If you'd like to see some changes, please don't wait for next week's phone call. Add a comment in here. That suggests alternative text or alternative name. Maybe there's another name out there that's less confusing for people that encompasses both types of things we're trying to do here. But please review this when you get a chance. We don't want to stay silent on this one. We want to get this one as quick, as quick as possible. So with that, any last minute, 30 second discussions on this before we move on. Now we don't have time to do a deep dive but I do want to draw people's attention to an issue that I opened up last night. And this actually is a result of, excuse me, the SDK workgroup call yesterday that Austin was running. There's a whole question about how are we gonna version our specifications? So for example, does the JSON and HTTP binding spec stay in sync version number wise with the core spec, right? So everything's always at 1.0, everything's at 1.1 or not. So for example, if we end up changing the HTTP binding in some breaking way, but we didn't actually change the core spec, what do we do? Does the HTTP spec become 2.0 but everything else is at 1.0? Do we change everything to be 2.0, right? There's a lot of questions here that need to be thought about and resolved at some point before we make too much more progress going forward or at least before we reach 1.0 status. We need to have a clear rule in place for when we're gonna version these specifications, whether they're linked, whether they're separate. But in all the time that I do a deep dive here, I just wanted to bring up the issue for people to start thinking about it and please comment on the issue because I do think we need to get this one resolved in the not too distant future. But are there any questions about the concept of what this issue is trying to bring up that I can answer very quickly for people? Okay, cool. Thank you guys very much. So please comment on that when you get a chance. And I don't think we have time for any other deep dive discussion. At some point I do wanna talk about what are extensions and what use cases we wanna support relative to extensions. So please, I know some people have been commenting on the doc, thank you for that. I'm a little worried that most people seem to be heading in the same direction, which normally would be a good thing. But based upon previous comments I've heard from people, I'm surprised I haven't had more people saying no to certain things. So that tells me that not everybody is necessarily reviewing the doc. So please review that, especially if you have strong opinions about where should we should allow extensions. And with that, I think we're basically pretty much out of time. Before I go back and do the roll call again one last time, are there any other topics that are short that people wanna bring up for discussion? Okay, in that case, quick final roll call. Farad, are you still there? What about Eric? Eric. Sorry, Farad, I'm still here. Eric, could any join for the first 30 minutes because he had a staff meeting? Okay, I thought, okay. And Stanley, are you there? Hey, Doug, can you hear me? Yeah, who's that? Yeah, that's me. Oh, Stanley, okay, go ahead. All right, Louis, I think I heard you. Neil, are you there? Yep, Neil from Confluent, I'm here. Matt Rukowski, are you still there? I'm here. Excellent, and Dan Rosanova. Dan, did you drop? I may have lost Dan. Okay, I saw him on the chat, so I'll give him credit the same way I'm giving Eric credit because I did see him. All right, anybody that I miss? All right, cool, thank you guys very much. And please do look at those proposals.