 Let's go ahead and get started. AIs, nothing going on there that someone has that they want to mention. I do want to talk about the SDK calls coming up. I have that as a future agenda item, so we can skip that for now. The first thing I want to discuss was actually upcoming phone calls. Here's the list of phone calls we have for the next two months or so. I crossed off, I'm assuming people are going to want to cancel during KubeCon Seattle and Shanghai. I was also assuming people might want to cancel during Thanksgiving and Christmas and New Year's. That would give us, if we do that, one, two, three calls before KubeCon Seattle, and then resume back up on January 10th. What do people think about the schedule with respect to canceling calls? You know, holidays and vacations and stuff. Yeah, I think that makes sense. I mean, it's the practical thing, right? We're not going to go and set up a call in Thanksgiving and nobody's showing up. Right, I agree. I just don't want to make the executive decision without you guys checking or you guys verifying it. It's just the end of the year, that's what it looks like. Yeah, now the interesting thing is, we'll talk a little bit more about this later, but we talked about doing or trying to get out 0.2 for Seattle, which basically leaves us three phone calls to resolve any 0.2 issues. So keep that in mind as we go forward. Okay, but any further questions, any objection then to this being our schedule for canceling calls? And if not, I'll make the appropriate actions to get cancellation notices sent out and send out a note and stuff like that. But any objection to this schedule? No objection. All right, cool. Thank you guys. All right, community time. All right, is there anybody on the call? New to the community who'd like to bring up a topic that they would like to discuss this is typically for time, a time for people who aren't. We're not normally part of the working group and there is not an agenda item for the topic they'd like to discuss. All right, cool. We're not hearing any. We'll keep moving forward then. All right. Moving forward. Okay, SDK work group. So Austin, you're on the call here, but let me just say what happened offline. So I did, I'm down Austin. Apparently he decided to take some vacation. Shocking. But because of his work schedule, Craig from wrong here, Austin, you want me to at least set up the meetings for the SDK calls going forward. And what I was thinking about doing was rather than setting up a doodle poll and wasting time going through that process. I looked at the last time we had a meeting, which was a Tuesdays at 1pm Eastern. And what I was going to do was propose that we have weekly calls on Tuesdays at 1pm, at least until KubeCon North America to try to force some forward moving action here. What do you guys think? That sounds good to me. Sounds good to me. Okay, anybody else mark given opinion. I know you're on there as well. I'm trying to remember who else was on the calls. Sorry, I got interrupted. What was the question Tuesdays 1pm Eastern for SDK calls. Yeah, I think that should be fine. Okay, any objection then to going forward with that. Okay, we'll do that. Thank you guys. So I'll send out meeting notices to the whole group instead of just myself and look for those. So in terms of SDK work, honestly, I'm a little worried. I know that the Golang guys are the Golang one from VMware looks fairly complete. At least there's code out there. I haven't seen anybody asking for access to any of the repos. So please be thinking about that because on next Tuesday's call we really need to decide what we're going to do there. Zero activities not very good. So be thinking about that. And a lot of people did sign up. So it's a little distressing that no one is doing any work there. Hey Doug, on that note, this is Austin here. Our company has been doing a lot of work on this and we've baked it all into the next version of our serverless framework product. And there's some great stuff that we've done and we've definitely invested a lot in this direction. We just have to put that into an SDK and submit that to the repo. But just want to put that out there in case anyone else is working on any JavaScript flavors of the SDK. But we've done some pretty good work here. We just got to put it into a cloud events SDK format and contribute it. So hopefully we'll get that done in a couple of weeks. So Austin, well, let me first state, I don't want to go too deep in terms of SDKs since we have other meetings for this. But it would be great if we started to think about what are the feature sets at a high level that each of the SDKs is providing around versioning or ways in which it deals with the data payloads, etc. We should understand what those feature sets look like so that we can rationalize what are the features of each of the SDKs independent of the language. Yes, so we've already had a few SDK calls where we discussed the design goals of the SDK and aligned on which features we'd like in each individual version of the SDK. All that information is put in an SDK design doc, which I believe is in this Google document somewhere. But as the SDK calls become a recurring thing, I recommend at least using that as a starting point because we established some pretty good alignment there. And I think that the Go version was actually following that. Now, of course, on our side, we've been trying to follow that as well while also trying to focus on features that help meet our company's priorities at the same time. And I think that's kind of where we left off on those SDK calls. It was, hey, look, we have a loose alignment on the things that we want to focus on. We agree that there's still some outstanding issues here. And if anyone wants to jump ahead and focus on anything else, then just kind of go for it and let's get some implementations on the table and see where we end up. Great. Thanks. Okay. Anything else related to the SDK work people want to bring up? There is a gentleman who I haven't been able to get back to. I'm not sure if he's on this call. It's Matt from Red Hat. Is he on this call? I know that his team has done some work on the Java SDK. Yeah, I don't see them or I'm sorry, I don't see him on the call. Okay. Doug, if you want to schedule this, if you can make sure to ping him and let him know that the SDK calls are recurring SDK calls are happening and he or his team should join. Okay, cool. Since I nominated us for the AC Sharp flavor of this, I had a conversation with our engineering team last week when I was in Redmond and it's just for us, just a schedule, I mean thing, not willingness to do the work. So I'm going to try to make that happen within relatively short time. Cool. Sounds good. Thank you. Excellent. Cool. Thank you guys. All right. Moving forward then. Kathy, I don't see, okay, I don't see Kathy on the call, but I don't think anything's happened with the workflow subgroup. So I don't think there's anything to update there. So actually, I think I could probably delete this link. The slides are out there. Clemens, Kathy and myself have been working on it. The slide link right here. Please take a look at you if you're interested. There's an intro and a deep dive session we're presenting at. If you have any feedback commentary on the slides, please let us know relatively soon. I believe officially we're supposed to submit the charts by tomorrow. So that date is, is kind of important for the Shanghai one in particular because they're going to be doing translation on the slides in advance into Chinese. So if we miss that date by there to be not be a big deal but we definitely can't wait until like the day of like we can for normal promises. So please review that when you get a chance if you're interested in providing feedback. And actually, I'm sorry, go ahead. The deep dive section I made a little bit wordier than I usually make a slide for that purpose, so that the folks who are doing the Chinese translation have a bit more meat to look at. Yep, that's good. I wasn't sure whether they were going to translate speaker notes or not. So I figured it's probably safest to just stick it inside the slides like you did. So that's good. Now, since Kathy isn't on the call. And Clemens you're technically on vacation. We're supposed to phone call right after this one to continue discussions about it. But come and I assume you're not going to make it if Kathy does not join. Then there will be no phone call for anybody else that was thinking about joining that call so it all depends whether Kathy makes it or not. So just give you guys a heads up. All right. I have a feeling most of us are probably going to be really, really busy but I thought I'd ask the question anyway, do we want to try to have a formal working group meeting during coup con Seattle, we will have an intro and a deep dive session there. But do you guys want to have a real working group meeting. Anybody have any desired to try to set one up. Okay I'm not hearing any. I don't think we have any really large issues to discuss so I don't think it warrants a face to face for that purpose. I'm not hearing anybody really jumping up and down for it I'm going to assume that we will not have one is that okay everybody works for me. I think having those other sessions is good and can preclude the use of needing to have a formal working group meeting. Okay, sounds good. All right, moving forward then the interop work. So we did a meeting yesterday and again I apologize for it being on short notice but between travels and stuff I didn't get a chance to do another doodle poll. But we are going forward with the notion of a mad libs type of scenario. And if you scroll down in the document that's linked in the agenda, you'll see under demo flow, the exact flow it's going to that's going to take. And basically a sentence is going to be picked at random with some missing words like nouns verbs adverbs, send that an event to all the nodes saying, basically what kind of words are missing. Those guys respond back with the words that they randomly chose. And then the, the controllers I'm calling it will sort of display the sentence with all the words filled in and hopefully it'll be funny. So from a, from a technical perspective, all we're really looking at is for the nodes or each company wants to participate. All they really need to do is create a function that just picks a random word. We do have a list of words available. It's easily downloadable. And it has, you know, nouns adverbs everything in there so really all you guys need to do is generate a random number and index into the array for that type of word. It should be really, really easy for just about anybody to join and participate. I do have an intern working on the actual UI piece of this itself. I could show you guys that if you're interested it's as of right now it's, this is two or three, I think it's three. It's something similar to this for not he needs to work on it. But it's basically going to be a little bit graphical things moving back and forth so it's not as boring as just showing a sentence and stuff. But that's the current thought process. More work needs to go on. It needs to be done on the UI, but everything's dynamic so people can easily join at the last minute how we need is their icon to display their bubble or their circle. But that's the current plan going forward. If you have any suggestions or comments you want to do or you want to make just mention it on the cloud interrupt slack slack channel. That's where mostly discussions will be happening. Any questions or comments on that. We were originally we were talking about doing this in time for coupon Seattle, but given the how easy or lightweight it should be for people to create a function to just basically generate a random number. It would be really nice if we could actually get this going in time for Shanghai, I would love to download this there as well. And in particular, it'd be really cool if people could support other transports besides HTTP or HTTPS. So Clemens I'm kind of looking at you for AMQP. If you guys can support something else in time or support this in general time for Shanghai and other transports just let me know and we'll do our best to try to get this in there so we can develop there. I am going to review all the notes that were there for the interrupt meeting tomorrow and then I'll see what that should be possible because it's I mean it's not that hard. As long as there's a go live client library for any transport we want to support we should be able to add it to the to the guy that's sending out events. So that's that's the only constraint that we have. Yeah, we have a we have a go MQP library now so that's something that we can go and put together. Okay, cool. I'm personally fluent in it so that it might look a little out of place but we'll see. Yeah, that's fine. Yeah, so anybody else if you have any other transports. You know, obviously one of the transfers that we have a document for that be really handy. All right, any other questions or comments about the interrupt stuff. All right cool moving forward. So, I sent that a note earlier in the week with a list of issues that I believe we can close. I put a comment in each one asking for someone to speak up if they thought I was mistaken and it should be kept open I don't believe anybody spoken up. Do people need more time to analyze these issues or could I ask for a bulk closure at this time. If the room might want to discuss a little bit more about the correlation use cases. So the correlation use cases was basically just an issue that we opened up to sort of gather ideas about how people might want to do correlation. And that was it I don't think this was necessarily meant to result in a change in the spec it was more just to gather ideas. But if someone thinks I'm not correctly let me know. Okay, okay. Anybody else have any questions or comments on this I definitely don't want to rush it but the same time, if no one thinks that they're worthy of keeping open, and we always can reopen them if we really want to. But if you need more time or want more time to speak up otherwise I'm going to ask if we can close them all. Okay, not hearing any objection. Is there any objection then to closing all these PR are these issues I think it's about 10 or so of them. Okay, cool. Thank you guys I'll clean up our list greatly. Alright, now onto PR review so last week, we resolved to adopt the direction of Clemens PR for restricting the character set. Since then, Clemens did a rebase, and I don't think there's anything semantically different about his original PR versus what's in there right now. But because the changes were made over the within the last day or so, I did want to give people a chance just to do a quick review of it, and raise any concerns if they have just just before I merged it. So, has anybody taken a look at this and have any concerns about the merging just want to give people one last chance. Okay, in that case, let me ask the question is there any objection then to adopting this PR. Alright, not hearing any cool. Thank you guys. Yep. I don't believe Fabio is on the call. But this PR has been out there for a little bit. I think he made a very minor changes the other day but I don't think it was really significant hide some of this stuff here. So, he made a minor change to our examples. What we want to do is to show real you are eyes in there because I don't think our example is actually using a real your eye. And then the source he actually put a real your eye because this is not a real one. It's a relative your eye which we technically don't support yet which actually that mistake but has a different issue. Anyway, relatively small PR. Any comments or questions on this one. I agree with this I the source as a relative URL confused me when I when we're implementing this. Yeah, it's good to get it. I figured this is actually kind of important if nothing else to make sure examples are correct and mislead people. All right, any then any objection to adopting this PR. Here. Yep. All right, cool. Thank you guys. Next, versioning scheme for our specs this one's been out there for a little while I think people wanted a little bit more time to think about it. Are there any new questions or comments about it. I don't think I've changed it for at least two weeks or so I think looks good to me. Okay, thank you, Roberto. It's together in one group. Basically everything except the primary will you lump together with same version number. Okay, any questions comments from anybody else. Okay, any objection them to adopting this. Cool, you guys are really easy today. All right. Okay, zero two milestones so what I did make close some of these windows here. What I ended up doing was going through all open issues and pull requests, or actually issues I should say all the pull requests are going to get in whenever they get in for the issues I went through and tried to take a guess as to whether I thought that they were significant design decisions that need to be made for that particular issue or whether they're minor, minor type of clarification kind of things. And so I went through all open issues. And if I thought we needed to be, I thought if it was a major design decision, then they would give good candidate for 0.2 because our roadmap for 0.2 basically says all major design decisions, except for security related ones. And this is basically the list that I came up with. Right here. So what I wanted to do was first, ask if anybody had a chance to look through the issues themselves or to look at my analysis to see if they thought I either added something I shouldn't have or missed something along the way. Basically, does anybody want to make any changes to this list. Okay, not hearing any. In that case, I'm going to assume that this list is at least a good starting point we can obviously change it as we keep moving forward for the next couple weeks. And what I did is that before the call is I actually classify these or group them a little the first two actually are PRs that are already out there which have now basically both been approved so we can skip those. These next three are kind of interesting. Clemens, these are the ways Clemens, you are okay. So Clemens these next three are about our data model, and in particular, they're very, very focused on the data attribute itself. I'm wondering if you could take a look at these three in bulk when you get a chance because I think that's kind of important thing to get right to make sure there isn't any confusion around what's allowable inside the data. Okay. Okay. Yeah, let me let me take a look at this tomorrow. Okay, cool. Thank you very much. Yeah, not a problem. Thank you. Now these the next ones, what I'm kind of looking for here is somebody willing to own it not necessarily come up the solution themselves but sort of help drive the discussion to come to some kind of resolution whether they come up with it themselves or not. So let's walk through this one at a time Jim I believe you're on the call. This is one that you opened up. I was wondering if you'd be willing to drive this one forward perhaps maybe generate a PR to force the discussion and just pick a direction based upon your preference or comments in there. Sure I can do that. I mean, I think one reason I didn't go down the PR road originally was this is really two PRs, one for each proposal. So I was hoping to try and get the group to go one way or the other and then I would do a PR to sort of solidify that. So given how quickly flew through the agenda and we have 35 minutes left. Let's let's do this. Why don't you talk to the repulsor very quickly and let's just see what the sense of the group is at least for the people on the call and that may give you a sense of which direction your PR should go. Sure. Okay. So my original drive for this was a comment that I believe somebody from AWS made quite a few calls ago. And that caused me to look at the current definition and we seem to just not be very consistent in the way that some of the context items were named. So, you know, a more AWS style approach would be to sort of drop the word event from everything because we know we're talking about an event. We're actually in an event. So it's already contextualized. Alternatively, we should sort of, you know, prefix everything with the word event and just follow some common themes. So that was really my drive, you know, just to get a consistent feel. The first one sits a bit better with me, but I've no real preference one way or the other. Okay. Anybody have any comments or thoughts on this one? Plus one on option one. Okay. Thank you, Matt. I was thinking option two, I prefer the one. Compacting events I think is the key, you know, it's already contextualized as pointed out. Plus we're talking about consuming and storing millions of events per minute or even you need to really condense. Yeah, I mean, there's definitely an efficiency play somewhere. You know, if you're talking about Jason transport certainly or formats. Yeah. So what about just abbreviating to e so e type e source e data. I'm plus one for option one. The version though, because we have a couple versions here right we have the version of the actual event type and the version of the cloud event specification. So that's the one thing that's a little. Actually, believe it or not, I just realized this the other day we actually dropped event type version. Yeah, we did. I looked it up also. Yes. I mean, but it's a good thing. Yeah. That's a good thing. Well, yeah, because you I think we decided to encode the version into the event type string itself. Correct. Okay. Yeah, we dropped that along the way a few months ago. Yeah. I missed that one. Okay. Do we have, we have some examples in the repo of how the version is put into the event type string. I don't believe we have at this point in time. No, that might be a good thing to have. So, okay, I'll raise my hand speaking not as moderate of the group. I definitely agree with everybody's idea that shorter is better and that these things are already contextualized and from that perspective I do like option one. However, what concerns me is that when we start talking about extensions, we ask people to give a descriptive name for their extension to avoid the risk of it being overlapping with something else going forward. And when I start thinking about some of our things or some of our properties like say ID, right, or even version or type or whatever. I think we should have, we should be forced to follow the same rule as extension authors because I don't think we should necessarily treat ourselves as special. So when I see something like ID, it's like, well, what is it the ID of and that's when I get a little worried. Right. So for example, if someone else decides to have an extension with their own ID, they're going to call it foo ID. Or something like that. Right. So they're going to see your two things in the message foo and I'm sorry foo ID and ID. That doesn't seem as descriptive to me and useful as event ID versus foo ID. And so from that perspective, I tend to prefer adding the word event in front of everything just with a little bit more descriptive. I can go technically either way but I have a slight preference for adding the word event in front of everything. I just put that out there. But anyway, anyway, anybody else have any comments. So my only other observation is recently we decided to adopt, did we all vote for lower lower case only or lower case. Yeah, we just approve that today lower case. Right. So again, you know, this is a very personal thing, you know, so presumably, you know, this event type would all be in lower case. So that's really what we're what the proposal would be in that situation. Right. Lower case T on this one. Yes. This is Vladimir. I have one comment regarding the naming. In the past I have been forced to use a scheme that followed the pattern like where we add event in front of everything. And sometimes one emerges the definition from several things. So then becomes a pattern A plus pattern B plus pattern C and then the actual name of the thing. And it becomes very tedious to use some kind of in a favor of the shorter version like type version ID and time. Thank you. Sorry about late joining. I guess it's a bit of a contextual argument because not to overload the context too much but if we are in the context of a cloud event we know that it's type version etc. If we're flattening then we want to push that context down into the name of the field. And then in other specs you see that kind of reserved reserved field sometimes start with an underscore or something like that to imply that they have some kind of namespace separation. I'm in favor of shortening. But at the same time Doug I can also see your argument we should be we should be following the standard that we're advocating as well. So I'm in support of the first one and as a spec the things called out explicitly in the spec not inherently special in some way. I'm sure you're cutting out a little there Dan can you repeat that. In a spec are we not the things explicitly called out in this fact that was not inherently special in some way where they could avoid having the event. I'm in favor of the first one. I acknowledge that that's not what we're asking other people develop extensions to do the underscore might be an option. But I feel like what's called out in a spec is inherently special. That's one way to look at it. Okay, anybody else have any comments they want to bring up or opinion. I'm still in favor of the first one the shorter. If I'm a developer looking looking for the tool that I'm going to use simplicity always appeals to be, you know, above all. And also I think is the emphasis should could. I think should probably be on documentation and just you know, I don't think we need to establish. We need strong patterns here or to kind of over engineer some patterns to how we do the key names as long as we have great documentation that just says exactly exactly which each one of these is. Except for the one. One thing I feel is if I'm a developer and I'm just stumbling across this I just look at the word version. I'm going to think that that's the event type version and not. And not the cloud events version. So you so you would want like a spec version or something like that. Spec version would name makes such a difficult thing but spec version would make it very clear to me that that's, that's something that's not the event type version. Okay. Plus $1 was just said, and thanks for the analysis as well. Yep. Okay, so Jim I think there's discussions down there it sounds like there while there is a little bit of a split decision there's definitely I think more people leaning towards number one. It's kind of up to you and how you want to move forward. You could choose to open two PR so you can look at both options or you could just choose one of the options and open a PR for that it's kind of up to you. I have a feeling that one PR with a choice might be better just from a process perspective but it is completely up to you. From a personal workload perspective I would prefer that option. Yeah, I'll do I'll do one PR for option one and you know if we decide to change direction. That's fine I'll do it again. Yeah, that's not okay with everybody from a directional perspective. Sounds good. Okay. Cool. So thank you, Jim. One other comment on this. Well it's actually on versioning and I've been doing so much context switching and I'm in the car right now heading to a meeting so I can't actually look at the spec. But when we settled on versioning on how to do event type versioning, do we settle on a specific format are we forcing like a specific versioning format there or are we letting it letting the user decide what that is. I believe it's producer defined. Yeah, I believe it's I believe it's producer defined the entire string is producer defined. Okay, well I'll throw out this suggestion we may have discussed in the past. I can't remember. But is there a possibility that if we settled on like a strict way of versioning event types, we could actually have a space in that version number for the cloud event specification. So like, you know, like thinking of semantic versioning or where there's just like three different spaces for versions we can have the initial space always indicate the version of the cloud event spec. And then everything that perhaps follows that could be the version of the event type to consolidate these things into one single version. It seems like the version of the event type, as well as the cloud event specification version are should be considered together. And along with the actual event type together that's what that's what the total schema actually looks like at the end of the day. So just throwing that out there haven't haven't thought it through but curious what you what y'all think. So that other version represents essentially the schema of the data payload. Is that the intention there? Correct. You know, in the event driven design, you want to think about data evolution as you modify the actual event schema. And so having a clear place for for the version of the schema for the event that you're using is pretty important. So but we have two versions of course we have the cloud event specification version, which is all about the metadata that we have the version of the actual event type schema. And I think these things perhaps could be designed with a clever single versioning implementation, but we have to get strict and kind of force people to use that, which might might be good. That's sure. Any other comments on that. So Austin, would you be willing to write up a PR or issue to get your idea out there and a more formal form so we can review it. Yep. And I'll try and do it fast because I know this is kind of a bigger thing at the last minute when we're trying to stabilize this. Yeah. I wanted to comment comment on that, but I think the reasoning for dropping the event type version was very solid. A few months back, talking about how yes evolution or data evolution would be is a big thing. But the only situation where you would actually change that version number is if you make breaking changes. And then you might as well change the event type anyway. That was a very good point in my opinion for why the edit type version is not needed. Well, it sounds like we we through what I gathered it doesn't sound like we said it wasn't needed. It sounds like we're just going to add it into the event type string. If people think they need that, is that correct? Well, yes. The point was that if you are making a breaking change, the event type version field doesn't serve any purpose as you might as well. You have a type string. But I think that precludes making a complex versioning scheme that includes an event type version because it's already there. And the discussion that was also feeling that there was a redundancy with the schema URL. Yeah. And I know that I think I think we also looked at the schema URL. Excuse me, as an example of why you could put it both into one because many times the schema URL expresses not just the type of data you're looking at but the version of that type of data. It's usually the version strings encoded in there as a date or something like that. So I thought that was a good pattern to follow, I believe. Yeah, we we dug into this for a long time. How about I just put out a PR quickly. If it's interesting, we could discuss it, consider it. You know, if not, let's just let's just move forward to get this thing stable so we can start building the ecosystem around it. I think is the ultimate bigger priority. Yep. That'd be great. Thank you. Yeah, I like looking at concrete things. Yeah, I agree. Also, and if Jim, I don't know pressure or anything, but the sooner we can get this done because definitely changing attribute names at this point is a little disruptive. So the sooner we can get this over, it would be helpful. I agree with that 110% totally aware of that. Try and make this as, you know, as simple as straightforward as possible. We could discuss it for five minutes. It was not like, yes, we should do this. Let's just kill it. Yeah, cool. Okay. Message received. Thank you. All right, cool. All right, moving forward then. Klaus immutability of event. What was an event context? You do want to quickly talk to this one. I think it was at KubeCon and Copenhagen, and we had an idea of having multiple property bags. So one for annotations being added while routing an event and one for the initial extensions. So that was just what we discussed back in May. And so I was, when we were discussing now extensions being top level attributes, I was wondering what happens now to those annotations. So being added later on. So I was wondering if, yeah, attributes can just be added by middleware just as normal attributes or if there will be some reserved space or property bag or how we handle this. Anybody have any opinion on this one before I give my opinion? Give yours first. Oh, sure. Okay, I tend to think of middleware as nothing more than another event source in the sense or an event producer. So whether a piece of middleware adds another attribute that's perfectly fine, it can add it, but we don't need to necessarily put them into special buckets. They're just additional properties regardless of who added them. To me, the producer, I'm sorry, the receiver of this doesn't really matter or doesn't really care who added any particular property. All it cares about is what properties are there and what their values are, where they came from is kind of irrelevant to the most part. Especially when you start talking about adding proxies in the middle, you know, are they allowed to add at the top level because that's what they're supposed to do is proxies, or, you know, are they middleware where no, you have to call out their special. It just seems like it's adding extra layer of complexity that things like ACP don't have this problem with special buckets for proxies. So why should we, but that's my question. It has it has rules about those things like what you can you do and what can you touch and what can't you touch. So the question is what rules should should apply here so the, the, the put the place of or the way how they're encoded it's not as important as having some rules about what you can modify and what you can't. Like a proxy in HTTP can't just modify everything. There's rules written down in in in HTTP and what you can do. And there's also like if you are acting as a proxy, there's stuff that you must do like you must add a via header but can't overwrite the via via header so that's stuff that's worth considering doing. Yeah, I kind of view those as a secondary type of discussion or as a different type of discussion than whether we should have bags for students. Yeah, I agree. And I think ultimately we'll have to go and figure out what how we think about routing. And whether we want to make routing a first level concept we want to go and tie into, but that's also discussion to have with relationship to some context I in the in the slack channel I put something a link in to a blog post I kind of discusses some of those things. Hi, this is John I think one of the angles that I mean I don't have a particular opinion about the bags or not but the the angle we're talking about is is meetability and and there's issues around that in terms of security. So I don't know you know how people are thinking around security issues, authentication, validation of the payloads as well as tampering. That's right. And that and I think that's that's actually where it really matters. When you want to make sure that you got the message as it was as it was emitted by the center. Then you first need to have a rule about the immutability means you can't touch this. And second, you then need to have a way to ensure that and that's by putting a signature somewhere. That's about security and that kind of stuff. Yeah, that's probably the discussion we need to have at some point. Yeah, we're going to even touch that topic. Yeah, I was curious about security when I was looking at the Kafka transport binding spec earlier because when we we see a lot of people asking about headers and passing security context so it'd be good to to map that into the cloud event. It's back when we get up to it. Yeah, I think signing signature is the minimal thing we have to go and take a stance on. It's not clear that we, we need to go and like, I think we should stay away from inventing something because that smells like W security and I don't want to go there. I think I mentioned that earlier. But we need to take a stance on how we think about a cloud that's relative to existing security mechanisms. Okay, anybody else have any comments on this one. Okay, so I'm not sure where this left us close. Me neither. So, okay. It sounds like there's almost two different discussions here there's one about whether middleware should be forced or required to put properties into special locations or whether they can just put them in there just like any other attribute. And then there's a second discussion about, do we need to find rules for certain types of middleware say like proxies and stuff like that. I'm wondering whether we could split the discussion into two. I think, I think, I didn't hear any disagreement about specifying rules for middleware or proxy middleware kind of things. But the specialized bucket thing that that seemed less clear to me. So, I think there's maybe also more formal aspects so what exactly is an event ID identifying so when I add or change something when do I have to create a new event ID for this. I think we had this event ID discussion several times also over the past weeks. Interesting question. So, let me ask you this. How do you want to move forward on here would you like to leave the issue open for a while and try to solicit more feedback or would you like to force the discussion by putting some poor requests out there. Because that poor request to the force most discussions right because it's actual proposal to change the spec. How would you like to come to resolution on this. I don't know what made up my mind completely so I would have a hard time putting together pull requests I don't know what exactly to propose. Okay. So then sounds like a little bit like you'd like to wait to get more feedback either from other people or until you've resolved the issue in your mind itself. So let me ask me to change the question then. Do you think this has to be resolved in time for 0.2. Do you consider this to be a large design decision. So far I haven't ran into any implementation question where I would have to add something when routing an event. So maybe then I have a better opinion. So. Okay. So let me ask the broader group then does anybody have any opinion on whether this is a 0.2 line item or not. I think this is a 1.0 line item that we need to go into. Figure out what you think it's blocking. Okay. What other people think I agree not an unblocking. Okay. In that case, class would you be okay with me. Removing the 0.2 label would definitely resolve it for 1.0. Yeah, it's fine. Okay. Any objection then to doing that. Okay, so we'll do that then. Okay. Okay. Let's see if we can just quickly talk about this next one. Thank you guys. Hey, Doug, can I squeeze in a quick comment and a quick question. Sure, of course. Okay. First off, I'm not going to submit that PR for a proposed version change. Sorry about that. I think right now we just got to stabilize this thing and focus on reaching that stability. So we could focus on building the ecosystem around it. The tools, the SDKs that make it accessible and usable. So that developers can put their hands on and start building it into their applications. And we can get that real world feedback that helps drive the specification forward. So I don't want to introduce anything else that's going to cause kind of shocking jarring changes at this time. So I'm going to withdraw my suggestion to consider that proposal. And then additionally, one other question for everyone would love a great idea for this. We have done a lot of work to transform popular AWS events to cloud events format for an experimental thing we're doing in our new version of the serverless framework. And we've written these manually just in JavaScript. But it would be great to figure out a way where we can basically create transformation and mapings, store it in some format that's language agnostic that all the SDKs could basically optionally load and do transformations based on those mappings. And I think I asked this, if anyone in the group had suggestions for how we could do that, what we could use for that a little while ago. I just want to ask it one more time just to hear if there are any other new suggestions for that. Anybody have any comments on that one? No suggestion, but I think it's a great idea. Agreed. Yeah, right now we're looking at velocity templates, which is heavily used by AWS API gateway for transformations. Okay, but if anyone has any other thoughts or ideas, please let me know. I think if we, given all the great people who are in this group, all the resources we have here, if we could start collaborating, if we could figure out how to start mapping out these transformations for very popular events in the ecosystem and put them in this language agnostic format, which a whole bunch of tools could optionally load as they deemed necessary. I think we can make a lot of progress getting people on the cloud events pretty quickly. There are examples that you could share with us that would illustrate how you're transforming between AWS and JavaScript today. Oh, it's pretty raw. It's just, you know, where we've just written code that looks, you know, that basically understands the existing AWS formats and transforms them into out of its format. There's really nothing special going on there. Are there any that are trickier than others, or is it just a pretty rote transformation? That's a good question. I didn't write that code, and I wasn't, I was the one who did that. So I'm not, I can't answer that. But from my experience, a lot of those AWS formats are consistent, and they're not changing. So it's, it should be relatively easy, but again, I didn't dig into that side. I can't give an informed answer here. I think it's a great idea because it helps us accelerate our understanding as to how, you know, we shape cloud events going forwards. It'll also accelerate adoption, you know, people building tooling around this as well. So yeah, great idea. All right. Any other comments or questions for Austin? Yeah. If you, if you have any suggestions, if you think of anything or see anything around the ecosystem, just ping me on Slack. But yeah, I think that would be a great way to add some fuel to this fire. All right, cool. Thank you. Thank you. Awesome. All right. Next. So this person I'm lending, I believe his name is not on the call. He's basically wondering how we send multiple events in HP binding. Now I believe Clemens, you may have made a comment and a previous issue or pull request, I think, basically saying that we're going to let the fall on the HP transport decide how to do that. And it's outside the scope of us. I believe that's what you said. So the binary, so the binary world can't do that because we're mapping that to HP headers. And so therefore there's no independent way of doing that. So that said, for the structured mode, where it's all in the payload, we could do that. And actually in our Azure event grid with the current proprietary format that we have, we are doing that. So effectively, we deliver, we currently deliver Jason only in our product. And so we have an outer array, which means we can do. So that's our standard format is not a standard encoding is an outer array in the Jason, and then we can go and basically send one event or we can send X events. And that doesn't make a difference. If you want to, so batching is something we can go and add, but the complex that makes things more complex. So that then, you know, puts up the question, if we want to go and add batching, which is not terrible. And then the mapping to the header thing becomes a little bit harder. And then the question there is, you know, how many, how many complexities we need. So basically I would, from a complexity perspective, I would say either we do batching, or we throw away the binary mode. So what other people think. Yeah, I agree with everything the plan has just said, we're having the same issue. We're also putting an array at the top so we can actually batch multiple messages into the same thing. But we're also only doing Jason in the structure format, not the binary thing. So I don't see much use for binary in my use case of this. Can we do something with multi part responses. Multi part is super hard. Yes, people do it, but it's, you need to have a library to go and do the multi part thing because you need to go in parts of the boundaries and multi part is terrible in my view. The extreme example of wanting to support something like this would be open connection that streams out individual events, like a continuous stream like a Twitter feed or something like that right. Yeah, but you can, you can do that with with protocols that support that like you can do that with a MQP, you can arguably do that NATS and you can do that with MQP as well. Like HTTP HTTP is a terrible asynchronous for asynchronous protocol that's just that's just the issue with that one. Potentially is also Jason P. Yes. Yeah, but that's kind of a bit of a hack that existed before people came up with things like WebSockets and you know the HB2 back channel. So let me ask this question since we're running a little low on time here. Let's say we decide to do some sort of batching thing obviously well turn this around. If we decide not to do batching then obviously no change to the specs are needed. But if we decide to do some sort of batching thing. Do you guys think that is strictly additive to what we have now or do you think that's going to potentially fundamentally change what we have, because it was not going to fundamentally change what we have that I'm thinking maybe this isn't a version 0.2 item, a 1.0 item. Yes, but maybe not a 0.2 because it's additive, but I want to know what you guys thought. I think batching is a substantial addition and batching changes the way how we think about, you know, mapping the events to the infrastructure. And because if you now carry multiple events in the payload, then you're effectively hiding the details of those events to the intermediaries. You can assume that intermediaries can go and crack open a bag of events. So I'm and batching is useful for HTTP because of its request response nature. It's less useful for protocols that are effectively delivering events in sequence. So I don't think it's actually don't think it's critical 0.2 but it's something that we need to go in and and look at but that discussion might be a little bit longer. This is a question that Knative has around, you know, an event processor takes an event and then returns back in the same HTTP response, multiple events. We're going to have to wrap it in a way like Clemens was talking about. Yeah, so so I'm leaning I'm really kind of from I've been thinking about this for a while because I, you know, making binary part of the story was something that I did based on feedback that was given early. And I think that might be a middle path here where we will preserve some aspects of the binary, which means your promotion of properties into header so that middle where could see it. But also introduced batching, but I don't have a clear picture of that just yet that I'm certainly not in two minutes so we should go and have that debate. In one of the next calls, but I don't think it holds. I don't think it pulls up 0.2 and something that we have to go and deal with but not it's I don't think it's urgent. Okay, well, since we have one minute left I'm not going to force a decision that whether it's 0.2 that everybody think about it and next week's call will decide whether we want it for 0.2 or not. But in the last 30 seconds, there is one other issue is type was 0.2 it's another transport. Please take a look at this one. When you get a chance so we can decide whether we want to pursue that or not. I don't think we necessarily have to have the transport in place for 0.2 but I think we promote per our roadmap we have to decide where they want to put it in 0. Sorry, for 0.2 we have to decide if we want to do it or not. We don't necessarily do it for 0.2, but we just need to decide if we're going to do it so look at that one and get a chance when you get a chance. So, so this one just just just one sentence on that. For this one the HTTP binding that we have would apply, but we need to have a different stack like the WebExpect that defines how that's actually happening over that particular channel but it's just an HTTP message. Okay. And so with that 30 seconds I just want to do the roll call quick to make sure I get people on there Scott I heard you. Erica you're still there. Yeah, I'm here. Okay, excellent. Thank you. Hold on. Ling Lee, are you there? Ying Lee. What about Victor? Yeah, here is me. Okay, Luciano. Luciano, are you there? Yes, I'm here. Excellent. Okay, Christine. Me too. Okay, Fabio. I'm here. Excellent. Victor Matos is here. Yep, I got you Victor. Okay, thank you. Adriano. Adriano Gomez. What about Diego? Oh, I got you Adriano. Okay, what about Thiago? I'm here. Okay, and Steve are you there? Yes. And you go to Ying Lee instead of Victor first. Wait, I'm sorry, is Ying Lee on the call? No. Okay, there's an AW. There was an AW in the attendee list. Or employee. Kind of funny name. Okay, is there anybody on the roll call that I missed? All right, cool. Thank you guys very much. I apologize for running over one minute, but this was a good call. We made a lot of really good decisions today. Thank you guys very much. And we'll talk next week. And I've Clemens. I just remember Kathy said she wasn't going to be here today. So that's why she's not on the call. Actually Clemens dropped. So anyway, we were not going to have the phone call after this one to discuss the slides for Shanghai. If you guys were thinking about doing that, since Kathy's not going to be here and Clemens has gone to. So the call will end here. We're not going to have to follow on call. All right. Thanks guys. Okay. Thank you. Bye guys. Okay.