 place to face on his comments, we'll see how that goes. Klaus will not join today as well. Oh, that's too bad. Okay, thank you. Is the other occasion? I assume. We'll ask him. Yes. I would have a quick question on timeline. So 1.0, do we anticipate to have something like a version for 1.0? The tough questions. So we talked about this in the past, and everybody basically agreed we want to get there as quickly as possible. I think we have two main issues in front of us. One is how to represent the binary data, the binary property, and that's sort of going back and forth between James Roper and Clemens. Unfortunately, James is in Australia, Clemens is on vacation. It makes it very difficult to make progress, but I'm trying my best through back channels to see what we can do there. The other big issue is how to handle maps. I think if we can get those two issues behind us, I think we could then go for a release candidate, to be honest. So something we could anticipate to have in Q3? I'm hoping so, yes. I really, really hope so. But it's kind of up to you guys, in terms of how quickly you guys want to move. Just because people keep asking. Yeah. No, I totally understand it. Like I said, though, it kind of depends on this group, because if everybody waits until the phone call to have a discussion on something, we're never going to make progress. So we need people to come in to review people's proposals and stuff outside of this phone call as best we can. But I know it's a challenge, because everybody's busy. So with that, I think Eric, you joined? Good morning. Good morning. And I think that's it right now. It is three after. So a lot of, actually it's four after. I'm going to get started. So go back around later. All right. Community time. Are there any topics people would like to bring up? They're not on the agenda. All right. Moving forward. We have not an SDK. We have not had an SDK call. I don't even think we have one scheduled for today. So I think next week might be the next time we have one. So nothing new to bring up there. Still looking for three end users. Ping some people offline. I apologize that I was traveling recently, so I didn't get a chance to deny people like I meant to. But please send me your three end users if you have any. Also, if you want to be included in the list of adopters, let me know. Kucan, San Diego. I don't know for sure when that is. It may be November or November, exactly when. But I did get the official notes just this week asking whether we would like to have a intro and deep dive for both serverless and cloud events. So ping me offline if you are interested in being part of that presentation, whether it's part, actually, mainly for the presentation side of things. If we're going to do a demo, I'm assuming we're going to use the airport one again since that's already out there. And I don't think people necessarily have time to do another one. But if you want to be part of any presentation at either serverless or cloud events stuff, let me know. And based upon the feedback I get, we can then decide whether we have one session or two per working group. Okay. With that, we can jump into PRs. Oh, man, Fabio's not on the call. Hold on a minute. Let me just quickly ping him because I was just talking to him. I was hoping he'd be able to join and discuss his thing. Just a sec. Okay. So let's see. Fabio made updates based upon Jem's comments. And I believe he actually addressed all of them. In particular, Jem, about an hour ago, asked for a name change on a file. And I believe he made that change. Okay. Or he's in the process of making that change right now. And I don't believe, I think he addressed Jem's comment here about whether we can file the same convention as Protobuf. So with that, I'm wondering whether people are okay with approving this PR, assuming Fabio actually did that name change. I think that's actually a relatively minor change, even if he does make it. So let me ask the question. Are people okay in general with this PR moving forward? Because I feel like it's been there a long time. We can always make updates to this and any other of the transport specs that we have. Approving it now does not mean it's perfect. It just means it's better than there, but better than what's there before, which was nothing. Anybody have any comments or concerns moving forward? Once I find out what happened to the name change, because I don't see another commit from him. Okay. Any objections to approving then with that condition of the name change? I'm good with approving. Okay. Thank you. Anybody else? I can't type today. All right. Cool. Thank you, guys. There we go. Okay. And I got you, Tim. I'll add you to the attendee list. Tim, sorry. Okay. Maps. Unfortunately, Jem ping me earlier and said if he makes it, he's going to be late. So this may be interesting having conversation without him. And Evan, obviously. So did people get a chance to look over Evan's sort of pros and cons list? Oops. Here we go. Pros and cons list about having maps there. I was wondering what people thought about that. Is this so anybody wouldn't wear the other? You guys cannot remain quiet the whole time. I don't want to talk for a full hour. Okay. Let me do this. There's one in particular. Where is it? Okay. This one right here. This comment right here I thought was the most interesting one or the hardest to deal with. So I'm interpreting this as if you get an extension and you don't know what it is because it's unknown to you, how do you return it to the user? Do you return it as a string or as a map? And on this one, let me pick on Scott for a second. What do you do when you go SDK? Because part of me looked at this and initially thought, okay, that sounds like a problem. However, in formats like JSON, just to pick on JSON, if a property comes in, sorry, if an extension is included and it's unknown, people need to deal with that anyway. SDK writers or JSON parsers or something, they have to figure out some way to return it. And in Go, probably the most logical way is just to return it as an interface, basically an unknown type. And I'm curious to know how the Go SDK handles that and whether this is a major problem or it's just kind of an annoyance. So Scott, let me pick on you for a second. So the Go SDK doesn't quite support this because it's very complicated, but the intent is that you ask for a known extension with a known type and it populates it for you. So you pass in a struct and it comes back or you pass in a string and it comes back as a string. But also to note, the SDK in Go does not support multi-level extensions. So the map can only be one map deep. Okay, let's ignore that second one just for a sec. Let's just focus on map versus string for unknown extensions. What do people think about that? Is, for example, the way the Go SDK handle it and acceptable way that people will think that's how they're going to do it? And hold on, Tim, I'm going to make you speak up instead of just putting a comment in the chat so that other people can hear it from the recording. You want to say what you said in chat, Tim? Yeah, I haven't, you know, read all this. I'm leaning to the notion that for extensions, just make them scalar. And probably you come out ahead. You know, I just haven't seen, you know, they're definitely, you know, having maps and potentially infinitely deeply nested stuff there clearly creates problems in certain situations. And I look for the countervailing advantages that you win by doing it. I don't see that. Okay. And so keep picking on you for a second there, Tim. So when people talk about maps, I think one of the biggest use cases for having them is the human aspect of it in terms of being able to group things together. Does that sway you at all or is it simply, yeah, that's nice to have, but it's not worth it? It's nice to have. And they gave perfectly compelling examples of how I can just do some prefixing and get what I want anyhow. Okay. Okay. I'm going to pick on somebody else. But before I do that, I'm going to see, does anybody want to volunteer to raise their hand to voice an opinion on this? Okay, I'm going to pick on somebody then. Christof, let me pick on you because you've had an opinion on this. What's your take on it? My main take is I want to get to 1.0 and doing those big changes doesn't really help because if we remove map, then we have follow on problems. Like then we have to look again at how do we do namespacing, what are our recommendations there? So then we have to revisit, do we have a separator and so on. So we can have all these discussions again. If we have to, it's just going to delay things further. That's my main concern. Otherwise, it's a trade-off decision. I'm kind of okay either way. Okay. Mark, you want to say what you said in the chat since I made Tim speak up? Yeah. I mean, I think that where we are today is that we we're coming up with a lot of complicated examples of why things need to be a certain way. And we should likely look for more simplicity in delivering the 1.0 spec. And so I like, removing the complication of having to deal with the map construct and dealing with the scalars. Okay. Thank you. Hines, thank you for raising your hand. Yeah, no worries. I tend to agree that as much as it is elegant and it would be very cool, I think it's going to potentially add issues, especially on the multiple transports and the inter process going through how you're going to represent that. So as much as that intellectually and program-wise would be cool, I think it might cause more grief than benefit. Okay, cool. Thank you. Anybody else want to speak up there? Yeah, I'm coming to the same conclusion that we're probably better off just with simple scalar types and not have maps. Okay. Anybody else? I would make SDK a lot easier to write. Yeah, I kind of figured that one. I figured that's where your position was. Okay. Let me turn this around. Is there anybody on the call who thinks we should keep maps, even if it's just an inkling? I want to hear from you. So you could still keep maps as an extension, as a detailed processing the keys. Say that again, you lost me. Okay. So right now we explode the keys down to some known key format. Right now we add dashes between the prefixes. You could write an extension that does that to a map, but it flattens it. But it's part of that extension that does the flattening for your map directly. So it's a little bit of processing that happens. So in an SDK, you could say, I support this map object, and I know how it flattens into the namespace of the attributes of binary mode. And you could unflatten it and then hydrate that original map and then return it. It's transparent to the user, but for the SDK, or sorry, for the cloud events spec, it's always just a single string. We remove the details of how that happens. Right. But that would be sort of an SDK specific type of solution, and both sides would have to sort of understand it. Yes. Yeah. Gotcha. Okay. True. Anybody else? Okay. From my point of view, I tend to agree with everything you guys were saying with the addition that we could always add maps back in later, especially if we don't change the character set that's allowed for names. Right. So that's another way to go, or another way to look at it. Okay. So, of course, Jim is not on the call to try to strong arm him. So what we could do is this. If we did head that direction of dropping maps, has anybody actually looked at this PR well enough to know whether it generally is going in the right direction or whether there are major changes to it? Okay. I don't want to say approve right now because I don't think anybody's looked at it enough yet. But I want to know if anybody has looked at it to know whether it seems like it's headed in the right direction or whether we need to ask them to go back and revisit it based upon conversations we've had. Okay. Not hearing any. What I'd like to do then is this. Have everybody look at the PR, give your feedback in terms of whether you think it's sufficient for this decision of dropping maps. I would like to have a conversation with Jim either later in this phone call if he manages to join because he did talk about possibly joining halfway through or I'll talk to him offline and see if he can live with this decision. But I'm not hearing anybody necessarily go against it. So consensus seems to be heading in that direction, but I don't want to necessarily make Jim feel like we voted without him here. Mark, did you want to say something or come up mute? Yeah, I was going to say that we also have a mailing list if we need more discussion before the next meeting. True. That's a good point though. Let me, I will send out a note with that. Here's it. So I'll send out a note to the mailing list making people very aware of this because we definitely don't want to hide or make the decision hidden. Thank you very much for reminding me. Considering the fact that we want to get this into the hands of users as fast as possible and that we want to get feedback, it wouldn't be that much of a change. It would be like 1.1 if we choose to revert the decision we're taking here, right? Like we would not allow maps and then we actually get some usage. We see that we actually do want to allow maps, even though all the drawbacks of it, that wouldn't be that much of a change with it. I'm hoping not, but the problem I'm trying to run into or the problem I'm running into in my head is right now a 1.0 receiver, if they assume everything they're getting is a scalar, if they start getting non-scalar things in 1.1, like a map, will that break them or will they just treat it as a string? I don't really answer that question because if they, if it breaks them, then we have a problem, right? I just haven't worked through that mentally in my head. But it is definitely something for us to think about, but at least to address Christoph's concern about the character set, right? If we don't change the character set rules we have right now so that you still can't use dash, but reserve it so that later on we could use it for maps, you know, again, is that going to break people? Because a 1.0 receiver is never going to expect to see a dash in there and now suddenly it appears that might break them, right? Yeah, I think the implication is that you need to choose a different character to reintroduce maps. Well, an item is a different character. You have to, I'm not sure, can you introduce maps without breaking somebody, breaking an existing receiver? I don't know. I think you can. Well, let's continue the discussion in the issue because I think that's a very important point. So Scott, maybe you could make a comment in there and how a 1.1 could add a map without breaking a 1.0 receiver because my initial gut reaction is it may not be possible, but I don't want to rattle on experimentation thoughts right here. Okay, anything else on this one before we move forward? Okay. Okay. Now, as I said, James and Clemens are both unavailable for this call. Has anybody actually had a chance to look at both PRs and want to comment on them? Because I don't think anybody but Clemens has made a comment on James's and no one's made a comment on Clemens, I don't think. I'm trying to interpret the silence as to whether you guys don't think this is a problem, you haven't had a chance to review it. The problem is so abstract, complicated, it hurts your head to read them, that's where I tend to be on this one. So does anybody have any comments on these at all? Because I'm trying to figure out whether this is a serious problem or it's an edge case in the spec that isn't necessarily worthy of too much concern. Okay, thank you, Tim. Anybody else? Okay, I don't want to have a discussion here on the call if no one has any opinions or read it, but we have to resolve it one way or the other, even if it's to just close both of them and keep it spec as it is, but we need to get back from you guys. I don't think this kind of decision should be left up to just James and Clemens. I think we need input from more people in that. So please, please go read both PRs and in particular the history behind them. The only feedback I've gotten offline, I can't remember who it was from, was they want things as simple as possible. And I'm not 100% convinced either PR actually keeps things as simple as possible, but at the same time, I don't know what a simpler solution is if this is a real problem. So please go off and read those. Okay, anybody else want to think about speaking up? Okay. In that case, let's talk about this one for a sec. Okay. So just to refresh everybody's memory, a little bit of stuff out of my way here, let's hide the comment for a sec. So just to refresh everybody's memory, this PR tries to talk about transfer air handling in general. And this is just for the primer. It basically punts on it and says, we're not doing anything about it. Normal transport air handling sort of applies. Now, Scott, what's your thing? Scott had a comment in here. And basically, Scott, you want to talk to your comment? Yeah, I'm looking for more advice on the how to handle air cases and how to translate those air cases between transports. Okay. Did you get a chance to read my comment back to you? No, I was eating pancakes. I hope it was good. So in my opinion, what you're concerned about is probably a valid concern. However, I view it at a scope for our specification, because if you look at what our spec says, at least in the read me, we're here for describing event data and comment formats. We're not here about message transport. We're about just tweaking the format. In a sense, in the most basic case, just add forward new properties. That's it. How the message is getting transported back and forth between two endpoints across multiple protocols for the most part isn't really in scope for us. Aside from, we talked about maybe how to serialize our properties on particular transports or formats. So I feel like what you're asking for may be valid, but it's out of scope for what we're trying to do. But Tim, I noticed your hand is up. Tim? Yep. So I'd be supportive of this, Pierre. I think it speaks truth. I mean, it's intrinsic to the whole notion of eventing with PubSub semantics that, you emit the data into the cloud and, sorry, you don't control or really influence much what happens thereafter. I think it would, I was all sympathetic to the point that we could say more. I'd certainly be sympathetic to something saying that if you receive an event and it's deeply broken, you shouldn't simply silently ignore this. You should raise an alarm by whatever alarm-raising channels are available to you because this is a symptom of something bad happening. I mean, we sort of imply here, saying normal transport level airport recordings will be used. You know, maybe will and should be used would be enough to say. Yeah. Unfortunately, using the word, yeah, I could make, I could add a should in there. It just wouldn't be normative because it's the primer, but I could definitely do that. That's a minor change to me. Scott, what's, what do you think? I'm sorry, let me add on one more. I mean, if you, if you emit an event and it's, it's broken, you can't reasonably expect anybody to tell you. Sorry, that's just a fact of life. But the receiver should tell, you know, should raise flags in the hope that something can be done. Yeah. If Clemens was here, I think he'd be going back to his messaging versus eventing thing. And I think his take is, eventing is a one-way protocol. Yeah, except it's not though, because there is a response that goes back to the persistence piece. So there's a queue somewhere in here potentially. And then if you have multi-hop and both connections are open because the middle, the middleware doesn't take control over the, the persistence of the event, the end consumer can still air and then you want to enact the upstream. So now you're, you have no idea how to actually translate the responses between transports. Like what does a 400 mean to AMQP, for example? Like I think that kind of advice. So we have the request turned into a conical form for cloud events, but we don't have the response turning into a conical form. We don't know the semantic meaning of what it, what it means to throw an error for all the transports. Hold on. Are we allowed to have middleware that doesn't fully process the event like it keeps open both the connection to the producer and to somebody else downstream? Sure. Why not? But I would assume the middleware would have something like a dead letter drop that if there was an error, and it didn't want to drop the event, they would deliver it to someplace to be able to handle that error, or at least alert on that error. So take PubSub, right? Like you, let's say you have an invoker and then two function chains. That second function could throw an error and you're, you still have the PubSub connection open on the first function. And so you need to translate errors from upstream to the either a NAC or an AC on the PubSub channel that initiated the request. But I saw, so I keep going back to this idea of the problems that you're describing, Scott, are there even without cloud events. And therefore, because I don't think this cloud events, in essence, charter, even if we have a charter, is really about how to get an event from A to B, you know, reliably across whatever transports and stuff like that. That's not our charter. Our charter is to help in describing an event, not delivering an event. And therefore, I can't help but think that this is out of scope for us. Even though I agree, these may be real issues you're describing, it's just for someone else to answer, not us. I'm confused how you say the request is in scope, but the response is out of scope. It's not that the request is in scope to me. I view it more as what's in scope for us is to how to decorate the request to turn it into a cloud event, right? We don't tell people necessarily how to use HTTP. We just say, if you happen to be using HTTP, here's how you decorate it with the cloud event stuff. And that's the difference to me. Because one of the things I keep telling people when I describe to them what cloud events is, I always drop back to the most basic example, which is today you're sending an event between A and B. If you happen to be using HTTP, add four new HTTP headers and boom, you know how a cloud event. That's all that we're doing. And people look at me and at first they're shocked because they think we're defining another cloud event format. I'm trying to get clear to them we're not. We're just adding a little bit of extra metadata. And when they hear about how simple it is to turn basically any event into a cloud event by just adding four new HTTP headers. And that's all we're trying to do. The more often than not, the reaction I get is, holy crap, that's simple and holy crap, that's brilliant for being so simple. And that's really, really useful, even though it's so simple. And that I think is the point here is we're not over, we're not trying to oversell or over try to solve problems that are beyond, you know, what we said we're going to do, all we're looking at doing is making it easier for receivers to be able to do some common processing on it, you know, routing, filtering, that kind of stuff by saying here's what, here's some common attributes you could look for. That's it. We're not going beyond that scope. You know, we're not defining an event that all events should look like, like there's been in the past and failed. We're not trying to tell you how to semantically process these things. We're not telling you how to transport these things even. It's just here's a couple of a bit of extra metadata that's going to go along with your message. That's it. So sorry, this is John. Yeah. So if you, because I think, I think we may be talking about a few things. I mean, if I take what you just said, right, this goes along with this notion of events being very distinct from messages, right, that they really are, in essence, fire and forget from the spec perspective. Does that make sense? Right. And if that's the case, then there is no, like if there's an error, that's a, that's a, either a transport thing in terms of its own mechanism, which is, as you say, out of scope, or it's a much higher level, whatever you want to call it, business protocol issue, somewhere higher up the stack to be rectified higher up the stack, right, which may be a quote unquote return cloud event, right, being published explicitly to some kind of topic, if you will, right, that says, Hey, this was a problem. So they're, they're disjointedly disconnected. That seems to be, I mean, that's at least how I'm interpreting how you're framing it from a cloud event philosophy perspective. Is that, is that what you mean by that? Possibly. I think what you're basically saying is there's eventing and there's messaging. And my mind is more the eventing side, right? Yes. Yeah. And maybe to be honest, I have a feeling you've probably read more into what I was saying. Maybe not be wrong. My mind wasn't that deep. Because, because, for example, you know, Clemens goes back and forth on this whole eventing versus messaging thing. And my simple mind breaks it down to it's, it's, you know, eventing is one way messaging is potentially two way kind of thing, right, or higher level processing event. And, and, and that, and so when I look at the cloud event spec, I don't even look at it necessarily as eventing versus messaging. I look at it more as I'm sending a chunk of data across the wire, I want to add some extra common metadata to it, whether you're sending it as a quote eventing thing, or you're sending it as a quote messaging thing. In my mind, I don't actually care. That's why perfect. Yeah. Yeah, this is what I want to tease apart. Because I think, I think where you're going, yes, if I can put more words into your mouth, is, is, is this simpler, is this very simple philosophy, right? And I think part of the conundrum, right, is we're all coming to this from our own perspectives and experiences and all of those things. So we're all kind of projecting our own assumptions and biases into that. And so I think one of the things that, that may be missing, and whether it's from the spec itself or from things like the primer, is we need to be very articulate and clear, sort of about the, I mean, if we're going to talk about it technically, about the scope of cloud events, right? But we have to be much clear about it, because if, if, if I interpret other people's position in the conversation, if we don't actually provide them with some kind of, you know, I don't know a better word to use at this point, philosophical model about our assumptions, or at least what we think people are going to have to deal with and make it clear, hey, if you think about it like a, a messaging system that has dead letter cues and things like that, you're going to have to translate those pieces yourself, because we don't have that model, right? So if we don't give some guidance or some, you know, whether it's example code or whatever, that works with at least some of the common tooling and infrastructure out there, then people are going to be just all over the place. And, and I think that's a disservice, right? Even if it's just, hey, we're just giving whatever clues or best practices or saying, hey, here's an example, the code that works, this is what we think is part of cloud events itself. And these are externalized, but obviously issues you have to take care of, right? And failure modes and being able to manage those obviously is very critical to a lot of processes. Sorry for being long with it. No, no. So I think Mark pasted something into the chat and then I highlighted something from the primer itself. And I think, I think those are consistent with the idea of we're just doing metadata. But I'd like to hear from other people because if other people don't think of it in that simplistic term, in the simplistic terms that we're talking about here, which is basically all we're doing is defining metadata. If they think our scope is bigger than that, I'd like to hear from people because I know Scott, you may be in that camp that our scope is bigger than that. But I'd like to hear from other people in the group because if so, then we probably do have a disconnect and we probably need to tighten up the language in the primer and the spec itself to make it more clear. Assuming that is the right way to go. Tim, is your hand up from before Tim? Or is that a new hand? Oops, sorry. Is that old? Old. Okay. Okay. Kristoff. I generally do agree that we should not cross into that territory. But the problem is that we actually do it for the HTTP transport and the webhook spec and so on. So maybe to clarify that, it would be better to make that its own thing and move it a bit outside of it. Because I think that's where a lot of Scott's confusion comes from. He just takes only that, tries to implement it and then he runs into all these problems and I see them coming up. But this is like taking part of what is not in our main spec, what is in the other bindings we define. So then we do have to take some stance on how to handle these things, at least for those things we define like the webhooks. Okay. Is that makes sense? I think so. And to be honest, it's been a while since I've looked at those specs to know how far outside of that limited scope they go and to see whether it is a concern. But Scott, let me pick on you again for a sec. If we were to ensure that the HTTP specs did not leave that limited scope, that I think we're hearing from most people, that it's basically just about defining extra metadata and did not get into a processing model. Would that change your opinion at all about this? Were you misled by what's in the HTTP spec, you think? I don't know. Because my gut reaction is you probably were not misled by that. You're probably looking at this from, damn it, I just want to write code. You want the code to work, be interoperable, and you're looking for clarity on how to handle situations. And because you're in the Cloud Events group, that's where you thought the interest should come from. Yeah. I mean, I think I've talked about this with a couple of people, but what I really want is the ability to make a function framework that can operate on any transport and not care about the details of that transport. Just write some code, make it work. And Cloud Events is close, but not quite there. Right. Okay. Mark your hands up. Oh, I was just going to add that if we want something that's more prescriptive or in more detail around error handling, I don't know that that should go into this specification, into this file, but could be more of a primer or a subsequent document that could go into various strategies for handling errors. Would we, if you, when you think about that, do you think about that as that text being normative or non-normative? Because you mentioned primer, but I wasn't sure whether you were just saying that or whether you actually thought it's definitely non-normative. Non-normative. I don't know that you could define a one size fits all for error handling across multiple transports across multiple systems. So, sorry, here's John again. Yeah. So, let me ask Scott, then, is you see a, is there a simple, the equivalent of what we're talking about is, hey, just add these four fields going back, right, for a request. You see a mechanism that's the equivalent that would be the foundation for, hey, here's errors. Maybe the transport can do something useful with it. Maybe it can't, but at least from the normative spec perspective, we're providing the hooks upon which you can build your framework. Yeah, absolutely. I think cloud events, if you think about it as becoming the conical form of an event payload, like it defines the envelope and a bunch of data inside, and it allows me to process it, that envelope gets a receipt and it gets delivered, right? It'd be interesting for us to think about the conical form of what's that receipt look like. For most cases, it's as simple as a MAC or an ACK, because we're dealing, underline, there's cues, and they have to either give up or retry. Yep, yeah. So, I will agree with you based on my own personal experience, and I think that's where I would come down, is can we define that same, hey, here's four fields or whatever it's going to take, the absolute minimum to be able to provide that mechanism as part of the normative specs. And then in the non-normative places, we can provide whatever examples or guidance for, hey, here's how other people are doing this. Absolutely. And then you allow each binding specification to be able to say, this is how my responses for my transport relate to the conical form of what a receipt looks like. Right, and then we articulate that in essence a quality of service, escape hatch, right? So then different implementations are open to, hey, I ignore them completely or I just log them or whatever, but it's not otherwise specified. Yeah, this is what I'm looking for. I see it as the other half of cloud events. So, Mark, is your hand up? New or old? Okay. So, I may be wrong, but I think we just ruined Clement's vacation because I can sort of hear his head exploding off in the distance where he is, because I can't help but feel like that if we head down this path, aren't we heading down into defining messaging? No, we're just defining a conical response to a cloud event payload. Yes, I totally agree. And that's where I was trying to make the distinction of just as you were talking about, hey, all you have to do is add these four headers. And that's all, that's where we stop, right? I think what Scott's asking, and I think what I am saying myself as well, is we're just talking about the equivalent of exactly that and nothing else, right? Because it provides the mechanistic hook in a normative way. And then everything else is punted to the implementations, right? So that's exactly the mirror of what you're talking about from a request side. Would someone be willing to write up that PR then? Because ultimately, without a PR, we can't go anywhere with it. But my initial reaction is I don't see how you do that without getting into processing model. Because we started off this conversation with at least some people saying, eventing is kind of one way messaging, which in my mind says, okay, you get a 202 back, which is pretty indeterminate. 202 doesn't even mean you're going to process it. And now we're talking about response, response metadata. So now we're saying 202 isn't actually valid. There should be something you should always do a 200, you know, with some extra HTTP headers, right? I kind of worry that there's going to be a rattle. Hi, this is Tim. You don't even get a 202 back. You get a 200 back saying, yeah, you successfully posted your event by. The relationship is now over. That's fine. The difference is that invoker needs to understand the difference between 200 and 500. Should the producer try again? Should it try once and maybe the service is not up or not found? So, sorry, I can speak only from my own experience here, but most eventing systems have some sort of an API to inject an event saying, oh, here's something that happened. And you either get a 200 meaning, yeah, there's your event. It's in the system now by or, you know, you know, if you could say you might get a 500 if you sent or 400 if you sent like malformed JSON or something like that. But if there's like a semantic problem with the payload that breaks downstream software, I'm sorry, there's just not a mechanism to feedback directly to the producer and we shouldn't pretend there is. I'm not saying that at all. I'm saying there needs to be, so when that downstream system delivers the event, it needs to know if it's done its job or it needs to try again. So, do you have a dug your hands up? Doug, are you still there? Do you have a commute? Okay, you're having trouble. If you can come up mute, go ahead. Christoph, your hand, your hands up. I think it kind of makes sense. Or the question is where does processing model start? If it's just like I delivered the event, that's it. I don't know what happens afterwards, or I did not deliver it, which could be my network timed out, or the other server return 500. Does that already count as a processing model for you? Who's that question for? To you. Honestly, I don't know because I think it's out of scope for cloud events, even worry about that. However, the event was sent without cloud events and whatever decisions it made based upon whatever error codes it may see, does not change because we've now added four new attributes. And so, like I said, in my opinion, these may be valid concerns, but they're not our problem to solve. Yeah, I think that goes back to my previous comment that yes, at the level of the spec it does not, at the level of the HTTP and then the batching and so on, there it becomes a problem, unfortunately. Yeah, and I think it's incumbent upon all of us, myself especially, because I want to go back and understand this, is to go back and look at the HTTP specs to see whether we've left our scope incorrectly, and maybe we should rip those things out. But there are other hands up. Doug, you able to come off mute yet? Okay, Colin, your hands up? Yeah, yeah. I mean, in my opinion, this is delving into quality of service, which is clearly, in my opinion, clearly a transport level thing. And, you know, perhaps instead of enforcing this in the spec, you can provide guidance through a priority. And then it's up to the user, it's up to the implementer whether or not this priority warrants QoS of zero, just if I lose it, it's gone or QoS of two, deliver at least once or three exactly once. But I really don't think that should be in the spec. Okay. Doug, if you could come into the chat, I'll let you guys read it. Can you hear me? Oh, there we go. Hey, Doug. Hey. Yeah, I share Scott's concern. I think Scott had mentioned that, especially a concern when you're doing batching, I think having some type of attribute that could be at the event level, you know, that granular rather than at the header is going to be kind of important. And even if it's an extension. Okay. Thank you. So we are running a little low on time here. Um, so what I'd like to do is two things. One is Scott. It sounds to me that relative to this poor request, you, you don't necessarily have a problem with this poor request itself because the text almost says nothing other than we're punting. However, you would like to see us go further. And so what I'd like to do is to split. Oh, sorry. Go ahead. This says it's not our problem. Right. And I kind of wanted to be our problem. Okay. Tell you what that, okay. Since you're phrasing it that way, let me not suggest what I was going to suggest then, which was to do it in steps. Um, I'm not hearing a consensus about whether this is our problem or not. So what I'd like to do is this, and like I said earlier, nothing goes into the spec without a PR. So what we're going to have to do is get someone to write a PR to, to show people what your guys are thinking you want to see added to the spec relative to these error conditions. So is someone going to volunteer to, to write that PR? Because if no one's going to write the PR, then it's not going in the spec. I don't think we have enough agreement if it's even something the community wants to be, to be in there. Well, that I agree, we don't have consensus yet. However, um, just, just my opinion, but I tend to find that having a PR helps solidify things because sometimes people think about an idea and think, Oh my gosh, that's so big in scope. I didn't want to touch that. When in reality, the PR actually might be relatively small. And that may be the case here. I don't know. Of course, the exact opposite could happen. So I think someone could say it's trivial and then when people look at the PR, they think this is way too big and go screaming from it. Right. But if no one's willing to do the work to, to write up the PR for it, then I'm not sure where we go forward or how we move forward on this to, to get what you're looking for, Scott. Hey Doug. Yeah. I dropped a suggested onto the issue. I dropped a PR. I dropped a comment suggesting a wording change to, to, to be a little bit more proactive and actually say, um, uh, please do use the, please do report them using the, where did you put that refresh? Oh, there we go. Okay. I think that's a minor change, but that's fine with me. But I suspect that wouldn't address Scott's issue. Right, Scott? Yeah, what I'm really looking for is that conical form of what you mean by the, the error, like turn it into the cloud event response. So, okay, Scott, let me ask you this question since you're the main instigator of this thing. It seems to me that there are two different ways we can go with the spec. We could say it's not our problem, which is what this PR is trying to say, or we can, we could then change our minds and say, yes, it is our problem. And here's how we're going to solve it. Would you object strongly if we started off with the position of it's not our problem and letting this PR go in with, say, Tim's wording change, but with the assumption that we could change our mind and say it is our problem, if a PR comes along that we can agree to. Yeah, that's fine. What other people think? What if people think about Tim's wording change? What I'd like to do is suggest we go with what I just proposed, and that's going to make it more formal. My formal proposal is to adopt the PR with Tim's wording change, with the assumption that if a PR comes along that changes our mind about whether we're going to touch a reporting or not, we will examine that PR. Any, any objections to doing that? Okay, thank you guys. With that though, the burden now is on Scott or whoever wants to take the action to write up something. Even though I kept using the PR, I guess an issue is fine too. As long as I think it has to be descriptive enough for people to get a sense of the scope of what's going to happen here in terms of spec changes. One or two sentences kind of thing. I don't think it's going to cover it. I think we need to be very explicit about what's going to happen because my general sense is this will be a non-trivial change, and I think you'll need to understand that going in. But I do understand, Scott, you're concerned about writing a PR that may go nowhere. That's a lot of work for nothing. So, okay. Oops, hold on. Yeah, I can file that issue. Okay, that's fine. I mean, obviously, people can do eight issues whenever they want. That's fine. Tim's wording. Okay. So, Doug, one of the things that we've always wanted with this group is always making forward progress. And the text that is proposed in this poll request is good text to add, and people can augment it in the future, like you said. So, I don't see a problem with us accepting this or adding in Tim's additions as well. Yep. Thank you. That's a better way to say it than I did this. Thank you. Okay. I don't think we have time to jump into another deep issue, especially something like Evans. Oh, yeah. One thing I did want to bring up, since I don't want to necessarily dive into a discussion about it, but I did want to draw people's attention. And it was, Scott, you want to quickly just, you know, like one minute mention this comment you made here, because I think it's kind of important. Yeah, it's basically the same conversation we just had, where in H2DP there was added this concept of batching events, but it looks, the payload looks like this. That's, you know, it's a square bracket and then a common delimited event in structured form. And I just don't understand the processing model for this thing, because there's no way to reply back to the deliverer. I got, can you scroll down a little bit, Doug? So like I got A and C, but like B had a problem. So I propose something like this. And funny enough, like it requires a conical form of an error or sorry, the delivery receipt. Okay. I just want to bring this to those attention, because even aside from the entire discussion we just had about whether we should do error processing or not, I have heard a couple of comments from people that they did not like this, the current format we have, which is just top level square bracket array thing. They would much prefer a curly braced object thingy, even though technically it's both valid JSON. I've heard people prefer this other way, even for, even aside from Scott's issue about error reporting. So I just wanted to bring this people's attention to get some feedback on it, at least in the issue itself. Okay. With that. Just for, I prefer the top level array myself. Do you? Okay. Okay. How do you do act snacks? Sorry, what was the question? How do you perform the act and act of the delivery? We don't, we don't, we don't do that. We just get it one single 200 or, or not for the whole batch. Okay. Okay. With that, we have one minute left. I think I have everybody from an attendance perspective. I haven't seen anybody join. Is there anybody who's not on this list with a star next to your name? Okay, cool. Hey Doug, this is Colin, information. Oh, did I miss you, Colin? I'm sorry. No worries. Thank you. I joined a little late. Okay, cool. Thank you. I'm sorry. Scott, were you saying something that the SDK calls next week? I believe so. Let me hold on. Everybody else could, everybody else could go, but let me just double check. Yes, SDK calls next week. Okay, great. Yep. Okay. With that, I believe we are done. Thank you guys very much. And please go review those issues in particular, the James and Clemens back and forth issues of PRs. All right. Thank you guys very much. Have a good one. Thanks Doug.