 So I know in the past we talked about doing some sort of SDK demo kind of a thing at KubeCon. To be honest, given the workload or given the activity I've seen, I'm inclined to think that that probably is not going to happen. Now, that doesn't mean that we couldn't showcase some of the SDKs. For example, Scott, I know you guys have done a lot of great work on the Go SDK. So we could showcase that someplace in one of the presentations that we wanted to. But in terms of some sort of global SDK interop thing that we once talked about, I'm not sure it's going to happen just from people's workloads, but I wanted to get your guys' take on it. Yeah, I think that's probably right. I think we'll get there. Yeah, I just don't think it's going to happen this time. Yeah, maybe KubeCon ENA. Yeah. Although my plan is to show the writing ace, a cloud event consumer producer using the Go SDK for the intro. Yeah, and I think that makes perfect sense. But it's not necessarily really about the SDK. It's more about like what it looks like to produce events. I'm assuming though you will highlight about how the SDK made their life easier. Yeah, yeah. For sure. Yeah. Okay. Cool. I think the point about showing the SDK is that you try to decouple the idea of consuming the transport away and instead focus on the payload. Yep. Oh, speaking of payload, just a question for you. As I mentioned to you a while ago, I think someone I know was using it because they were getting base 64 or all the data was base 64 encoded. As opposed to just raw JSON. Has that been fixed? That was, that was a bug in the K native SDK. Oh, okay. Never mind that. I don't think it, I don't think mine does that. Okay. Excellent. Cool. And K native now does use your, the, the go, the SDK from here. Right. Yeah. Yeah. So in 05, we, it'll, it'll all be the, this SDK. I actually found an interesting bug that I introduced. Adding headers and stuff, but there's a new release now that fixes that. Cool. Oh, speaking of headers, we still. Really need to figure out the. Extra quotes thing. Yeah. I'm just looking at the agenda here. That's not on the agenda for today's call, but we should probably definitely talk about that. I know Clemens, you had an opinion on that, but your opinion was to keep the quotes. Which is. Keep the quotes. And that upset some people. I think we should also add extra time zones. Just for you. Like a Tuesday time zone. We'll just shift it back by like 35. Are you trying to be funny? Yes. I'm just, I'm just, so the opinion is just based on us allowing maps in. As types in. In attributes. And if we do so, then we need to be able to go and encode the full range of Jason in that field. And then. You know, a quarter straight. Right, right. So that's, I'm not arguing against that. I'm saying for the known types that are core to the SDK, the things that are always going to be sent over the wire. I think they should be special cased. Because we understand their types. And those are your extensions and unknown. Yes. But then, then, then now you're in. Tractors territory when you have a unknown type. That becomes porn extension that becomes promoted into the spec. And all of a sudden that's incompatible because prior to that, it had to be cured from Jason role. And now it becomes to the elite circle of things that have Yeah, I was going to suggest something slightly different, which is for a well-known set of types like String, URI, they just don't get quoted. But for other types, they can follow the JSON encoding or whatever you want to call it. Yeah, but now you get into the funny, you know, it gets it's a weird, then you kind of have weird edge cases where the customer is now choosing just to put numbers in there and yeah, yeah. The trouble is that the current spec on the wire for binary mode HTTP looks really strange. What do you mean? It has a bunch of double quotes in it. It looks really strange. Like to compose that, you have to do a bunch of weird stuff. So can I, let me interject here just for a sec. I definitely won't have this discussion, however. Let's make sure we cover any SDK topics first. Are there any? That's what I was going to ask. Is there anything related to SDK since that is the point of this call that people want to talk about? Yeah, I don't have much. I don't have anything else. Maybe, hey, Clemens, do you want to make our SDKs talk to each other? Yes, I would if you just speak to the spec, it's all good. Oh my gosh. So hold on a sec here. That's the whole point of that document. But specs are allowed to have typos and bad ideas. So hold on. Wait a minute. As long as they're there. Wait a minute. Wait a minute. Okay. Before we get back to this, Mark, you said something interesting there. You said you don't have much. Does that mean you don't have any? Does that say much? Yeah. No, I'm good. I'm good. Okay. Okay. Hind, is there anything you'd like to bring up? Maybe Hind, step the way for a sec. Okay. Well, let's go back to the attribute. So regardless of the correctness of the quotes, I would like an official from on high ruling because I can change the SDK to be compliant and that's no problem. Or I can leave it the way it's currently doing and it'll only talk with my SDK and people that didn't read the spec as well as the C-sharp SDK did. So Scott, I have a really hard time. Like I've looked at this and I've thought about this for a while and it's kind of hard to prove because I have nothing written down about it about the thinking, but as it is, if you decide to not change anything, I want to see the rule, like write down the rule, write down what you think works because I don't find a future-proof way to make this work and still allow the rest of the type system in those fields. But it works because of versioning, like as things get promoted into versions, then they can- Yeah, but I want to have an- I want to have an- I want to have a normative explanation of the exception that you want the formulae, like I want to see it writing. So Clemens, I think I can come up with a rule, but I want to make sure I understand what you said earlier before I actually put out a proposal, which is when I said we know how to serialize the types that we know about, like strings don't have code and stuff like that. You said there are some edge cases that cause concerns in particular that someone can just put a number there. Explain to me why that's a problem, because even if they put just a number, if we define it as string, it gets read as a string. All the- so the reason for that is that it's effective for all extensions. Anything that's data that's just being added as extensions is defined well-known or unknown to the envelope. Anything that's there. We basically rely on type inference, or we rely on, you know, type information in the the- sorry, for AKP friends, we rely on the AKP type system because that's there, right? And there you say this is a string, and this is a map, and this is an ins, and blah, blah, blah. So that has that. For HTTP, since HTTP, the header is a string, you rely then necessarily on type inference of the encoding we've chosen to use, and that's JSON. And so for- to figure out that something is a string for an unknown attribute, you'll have to rely on, you know, a string being coded because otherwise you can't identify the string where at least you can't tell it apart from a string that contains only numbers, and you probably don't- you don't necessarily know what to do with curly braces or with square brackets, et cetera. So you have to rely on- you have to rely on type inference. If the case happens, if then the case happens that a unknown type becomes promoted to a well-known extension or becomes even more so, becomes a part of the core spec, then all of a sudden the encoding changes. And that's a little strange. But Clemens though, when an extension gets defined or when an extension is used, there are two options in front of them, in front of people, right? The extension has been well-defined so you know exactly what type it is. Yes. So there's no ambiguity there. Well, there is because you can choose to completely ignore an extension. No, no, well, but then, well, that gets into the second case though, which is even if it's defined, someone may not know about the specification and therefore it's unknown and what does someone do with it when they receive it, right? Now, in those particular cases though, I would say that that almost falls into the category of is an implementation detail, meaning the receiver is going to decide how to take this particular string in essence and decide how they're going to store it. It may look like a number, but they could choose to store it as a string and pass that on to their function or their code, the application, in whatever format they want. That doesn't affect our specification. That doesn't work because if two receivers that are trying to consume a binary HTTP encoding attempt to consume the same string, they need to use the same rules. And so they do need type inference. Now that I think about it a little more, I think the rule that could be future proof is that for everything that's in the core envelope, they don't need quotes because they have strict types defined by the specification. For every extension and unknown or unknown, they use the quoted JSON mentality. Yeah, but now you've bolted down the extent of the core spec for eternity. Well, I'm sorry, bolted down. So if you use that rule, then an extension property, let's say the thing we've discussed with the partition key, right? If that's something that becomes so important that we think it needs to become part of the core envelope, then it will be quoted as an extension. But then as soon as it marches into the core envelope, it will be no longer quoted, which means that all code that is using it will now have to be effectively rewritten, adapted for it to be not encoded with quotes. I'd like to understand what you said earlier, though, Scott, when you said two different receivers are going to have to think about my proposal that wasn't going to work. Can you elaborate again or say it again? I was saying the two different consumers need to understand type inference as things come in. But don't they only need to understand how this particular attribute is going to be handed to them from their SDK? No, no, no. It's independent of SDK. Okay, so let's say two SDKs are going to consume the same event and invoke some function. The inner representation of that, the envelope, the context data, and the payload may be exactly the same, right? Yeah, but my point is anybody who is actually going to use that attribute has to know two different things. One is how the attribute is defined, right? It may look like a number, but it's actually a string, that kind of stuff. And that's part of the specification of that attribute. And they just have to know that by understanding it. Otherwise, they can't really use that data for anything meaningful anyway. And two, they have to understand how the SDK is going to hand it to them. And they may be handing something that is technically per the spec of the extension a number, but the SDK may hand it to them as a string because SDK doesn't know about it. I think the difference between Clemens and I's perspective and Doug's perspective is that Clemens and I are thinking about middleware and not the end consumer, and Doug is thinking about the end consumer. Right, so Doug, in that case, so I have a case, I don't know what's making that noise. There are some Microsoft software I really want to kill. So the, here, the case I'm thinking about is Event Grid, where the incoming request is a binary HTTP request. And then there is a route to a service plus queue, which then runs over AQP. And for that, I need to be able to take the properties that were set and map them effectively into AQP properties which are appropriately typed, and then flow them over to the other side. Where there may be, there may be actually be on that route, there may be message selector rules, which are dependent on what that type is. So I need type inference basically to keep the types right as they flow from HTTP into AQP. I can't ignore that and simply say, well, you just deal with it as a string. I agree that it might be okay with that, sorry, for the core properties. But as soon as it gets to extensions, then the middleware will, generally the middleware will not know about extensions except the ones that it cares about handling. And then, and so for that we definitely need inference. And then for me the question, for me then the compatibility question is, is one of, when I go and promote something that is currently in extension into the core spec, that changes everything. And so, and then that becomes inconsistent, for me that's just a bug source. Hines, were you going to say something? No, I'm just wondering that on the selectors aren't most messaging protocols. Selectors are against the headers and the headers are usually, and there might be exception where there are always string based name value pairs, so it'll always be a string, won't it? No, in JMS they're typed and they're, so JMS, JMS where brokers need to know the data types and MQP is completely as a full type system. JMS headers are all Java strings, there is no typing in JMS headers. It's implicit, they have math functions, some brokers do. Oh yes, but it's a string that's passed to you. Yeah, but then you're effectively inferring that from function, but in MQP, in MQP, so my perspective on this is effectively the MQP mapping of JMS. In MQP, the underlying type system of MQP allows for properties to be typed. They can't be complex types, but they can be any of the valid MQP types. Go ahead. No, so they're just the primitive types, that's it? Yeah, so it can be numbers and you can even have dates and you have constraints, but that's permitted. What's constrained in MQP is that the property names need to be symbols, but the rest, the value space is unconstrained. You can't have lists, you can't have maps, but they can be any of the other types, so that is type safe. Does the cloud of inspect actually have to understand the types? Or can the cloud of inspect treat everything as a string? We have a few things that are not just strings, right? Well, we don't have very many, I know that. We have an integer. What's it used for though? We have time stamp. Which is basically a string. Yes, everything is just a string. Well, that's how I'm kind of wondering, can we punk on this? Because HTTP doesn't have this problem, right? Everything's basically a string to them without actually saying it's a string, it's just a bunch of characters. I'm wondering whether at the cloud event level, we actually need to worry about this. Or we just say, nope, everything's a string and if you understand the types, then fine, you can convert it, but that's outside the scope of the spec because that's outside of cloud events processing. Yeah, I've done a lot of work to take like, for example, dates and turn them into strings because Go will serialize out a full date structure if you're not careful. Yeah, we have strings. So what we started with, so what we started with in the type system is that the integer, the integer was the thing that started that started throwing out a string, meaning that a little bit more complicated than it needed to be. The goal was basically with the type system to distinguish between strings. And then, which was most of what we had, and timestamp as a special case of that, because that is a string expression. It's just a specially formatted string expression. So timestamp is effectively derived from string. And then we only, we effectively had the binary as a special case because that might be expressed as string, but then in the cases where you have the binary encodings, that is effectively bit by bit being put into the binary body. And then the rest of the constructs like the map is for complex types. And then any is either of the two. And I think with the integer, we broke into jail and actually having to think about different encodings for these primitive types. Yeah, but if you look at the current types that we define our spec, not look at the extensions, but everything in our core spec is basically a string. Yeah, that's, yes, it's a string or is a derivative of the string. That's right. We could basically say, yep, we're going to kill the integer again. For the data, the fact that the reason why we have, why we have binary is really to just accommodate binary in data in the any type. Like binary is never used directly. But just for attributes per se, which we're now debating, we're not talking about data, we're just talking about the attributes. For those string and string rise types would be sufficient. And so we could go and pump, basically pump on that problem. If we get rid of the, get rid of the integer. Yeah, this is the only use of integer I could find. And that's in sampling extension. Yes, yeah, we introduced it specifically in that case. But it seems to me if we, if we change the spec to be just everything's a string period, we don't have this problem anymore. You could, and you could subset string like timestamp is that it has to be in a particular format, but ultimately it is a string therefore we don't have to do JSON encoding on it. Well, even for that one for that extension you were just showing. It's still encoded as a string and header. Yes. Are you saying you want quotes from it? I'm saying we say it's encoded as a string that should be parsed as an integer. Yeah, that's fine. So, but yeah, then it solves the problem. The issue that remains them though is that if you put a map into an attribute. Then we have, I think we have a few extensions, or do we? Then, then, then the question is, can we can we represent that accurately? Like, can we encode that because the map is effectively like we need, we would have to go this thing is between the strain and a map. If we say, okay, maps are legal for attributes, then that gets gets us out of that out of that as well. Well, what if we did this? What if we said if you're going to define an extension that is a different type and map is a good example, then you need to define the proper serialization for that particular attribute as long as it can be serialized as a string in the end. And if that means for this particular extension you want to be serialized in JSON format, then that's the rule for that particular attribute. Yeah, then everything has two representations. There's the structured way and then there's the binary way. What do you mean by binary way? Oh, I'll always say what you mean, binary. It's something we can, like I'm not opposed to that. So I'm just, I just, we just need clarity, I think. Yes. And if we limit the choices, that's fine. So as it stands, I think we need type inference. Because we need to distinguish between principally between strings and integers and maps. And if we say we're not allowing maps, but like if you want, if you need five fields in your extension, well, bring five fields, don't bring a map. And then so that's a thing that's that that's the thing we can say. And then we can strike the integer and say, well, if you need to have a number, but ultimately the only way you can go and encode that is straight. And then in that case, then it's easy because then everything is a string or is at least something that is encoded. It encoded as a string that interpreted in a certain way, like in timestamp. And we're okay. Yeah, I would let the quotes go. I would much rather head down that path. I think it's a much easier model. Well, and then that's, then let's, let's go do that. Yeah. I have cash over to the, to the customer call and I will hopefully be able to rejoin the call at some point. Okay. So much to talk. Okay. You want me to try to, to draft that proposal. Sir, if you would, that would be fantastic. Okay, that sounds great. That sounds perfect. Thank you guys very much. Non SDK discussion, but very important discussion. Very important discussion. Okay. Okay. All right. So people trying to, but I will try. Yep. Okay. Scott, you're still there. You're still there. Eric, you're there. Good morning. Good morning. All right. I should just mention I couldn't get off mute there when you asked me if I had any other issues. The only issue I had is that I did offer to referee a discussion out in the parking lot. If necessary. Are we going to get into a fist fight? Is that what this is about? Well, it started like it to me. I thought it actually went really, really well. Good. Hey, I don't have any spare tables. So it wouldn't be a very fair fight. Hold on. I'm sorry. I'm sorry. I got distracted. Somebody's paying me. What? Can you make an action item for me to stop volunteering for things? Can do. Yes. I said, maybe one thing we can't write down. Good morning, Adam. I assume you're in the West Coast. Yeah. I just just making conversation. I assume you're on the West Coast, right? Yeah, about 50 feet from Scott right now. Oh, in that case, I apologize. Okay. Ginger, you there. Good morning. Fabio, are you there? Yes, I'm here. Hello. John M. Is that John Mitchell? Oh, no microphone yet. We'll get back to him. Hello. Yes, Robert. This year. Hello. Is that Vladimir? That's right. Good morning. Good morning. Is that John Mitchell on the phone? That is me. Good morning. Good morning. Are you also in the Zoom under John M? Yes. Okay. That's weird. You come into two different ways. Okay. Oh, it's because I dial in for better connectivity via my phone. Ah, okay. That makes sense. Cool. Thank you. Yep. Christian, are you there? Hello. Hello. Tam, are you there? Good morning. Good morning. Javier. Javier, are you there? Hopefully I'm pronouncing that right. Yeah, thanks. Good morning. This isn't your first time, right? I already have you in the attendee list. Yes. Or is this your first time? Okay. Thanks. I don't think I have you. Hold on a minute. What company are you with? Code it. Code it. Code it as in code. It's like that. Oh. Yeah. Without the E. Oh, interesting. Okay. Cool. Thank you. Thank you. Thank you. Thanks, Sarah. When you get a chance. Let me paste a link to this in the chat. Can you just add your last name? Just so I have that proper attendance list. Yes. Excellent. Thank you. All right. Mr. Curtis. Are you there? Yes, I am. Hello. And Mr. Mark. Are you back? I'm back. Oh, I'm sorry. Go ahead and have you. Okay. Yes. I can spell it is H. U. A. Thank you very much. Uh, Christoph. Are you there? Yes, I am. Hello. Um, Jim, are you there? Yes, fine. Okay. And Jude. Are you there? Yeah. Okay. Rachel. Yeah, I'm here. To Peany. Yeah, I'm here. Yeah. Yeah. Yeah. Yeah. Whatever. Okay. Hey, I'm here. Hello. And William. Yep. I'm here. Okay. I'm missing somebody. Oh, yes. Oh, that's who it was. Yes. Thank you. And then Justin Johnson. Are you there? Justin, are you able to come off mute? Yeah. Okay. Just say if you're trying to talk, it's really hard. I'll take that as you'd be in there, but it's really bad connection. And Justin just made, oh, we lost him. Oh, he's back. So Justin, I think this may be your first time in. If so, can you do me a favor and, um, add your company affiliation if you want to have one into the gender next to your name. Just for the attendance tracker. I put a link to the document that I'm editing into the chat. If you can see that. All right. Let me do one like look, and then we'll get started. Okay. Okay. Kathy, are you there? Yes. Okay. I think I got everybody else. Oh, Doug, are you there? Like Mallory. Oh, no microphone yet. Let's take it back around with him. All right. Let's go and get started three after the hour. Um, AIs. I don't think there's anything here. Um, As I should mention, we had a discussion during the SDK call, which was right before this one about the header of value issue that I believe Adam opened up a little while ago. Um, I think we had a really good discussion and Scott took the actually had to write up a proposal. So expect to see something there soon. We don't need to go in that now, but just let you guys know we did. I think made some good progress there. So hopefully we'll see how that turns out. Um, community time. Okay. For newer members of the group, this is the time for you to bring up any topics that are not normally on the agenda. So do we have any issues or discussion points people would like to bring up from a community perspective. All right, moving forward then. Uh, SDK call, as I mentioned, we just had one 30 minutes ago. Um, There probably isn't anything worth mentioning there other than, um, I know in the past we talked about potentially having some sort of SDK interrupt type of thing go on at a coupon EU. Given everybody's workload and stuff, we don't actually see that happening. Things could change if people get some free time. But as of right now, we are not planning on doing a interrupt demo for the SDKs that it could kind of you basically just do to people's workloads and stuff. Um, but I think that was the only thing noteworthy to mention from the previous call. Scott, can you think of anything else that might be missing? Uh, no, not so. Okay. There was that one fight that we had. But other than that is fine. Yeah. We don't need to talk about the fight. Um, let's see. Okay. Demo. Do a phone call after this one to continue our discussions on the demo that we're going to be doing for coupon EU. Um, Doug, I see you have a microphone now. Do you want to bring us up to speed on where we are on that just to summarize for everybody? Uh, can you hear me? Yes, we can. Uh, well, I think, uh, what we were trying to do with the, the call after this was to just, um, figure out a good way where, um, the demo could be extensible to accommodate multiple, uh, CE participants. Um, so I think we're still focusing on, um, a simple supply chain within an airport setting, which involves a retail, multiple retailers, multiple carriers, and multiple suppliers and how, um, they can all participate and replenishment of, um, cups that are being used to, um, fulfill drink orders to passengers. Yep. And, um, I apologize as we would have been, as we've been having these phone calls. Um, Doug has been doing a really good job of producing documents to sort of explain the current thought process and ideas we have. We probably should start sharing that with a broader community because I know this Google doc right here doesn't have the very latest. So we'll take the action item after the call, after this one to start making sure that the documents are in a place that everybody can actually see it, even if you can't join the phone calls. But I think Doug did summarize where we are. Uh, does anybody have any questions about the demo work? Okay. Moving forward then. Um, I don't think anything happened relative to the planning, planning for the actual coupon sessions themselves. I didn't realize that, um, I have one question. What is, what do we think of the idea of having a demo that we reuse so we don't have to reinvent the demo for every coupon. So if I remember correctly, I think we were actually kind of hoping to use this airport one to do that as we go forward because I think Doug has talked about being able to extend it in the future. Okay. That's what I think. Yeah. I don't think anything foremost comes from those discussions other than it has come up as part of that. But I think it is a good idea though. Okay. Thanks. Yep. All right. Um, yeah, I don't think there's anything planning wise. I don't even think we've even really gone forward in terms of, uh, uh, starting the presentations yet. The one thing I will mention is that, uh, the CFP for the service practitioner summit is tomorrow. And I did put a proposal for a very generic, you know, what is the service working group type of session for that? Um, and we're going to talk about that offline, I guess, or maybe we could talk about that. If we have time in this call, basically it's just a very high level thing. We just need to figure out if the text is okay. Um, but we can discuss that later. Um, nothing relative to cook on China. So I believe we're into the PR review. Let me just do one quick check here or something. Okay. No new votes to come in. Okay. So into the PR review stuff. Uh, so last week we started a vote on the men's size type of PRs that are out there. And if unless I mistaken, I believe this is the current status of the votes. Is there anybody on the call who thinks I may have entered their vote incorrectly? I believe we had commerce tools, PayPal and Vlad voting for option one. And the other people who voted voted for option two. Does anybody think I got that incorrect? Okay. In that case, I think it's clear. I don't know the numbers, but the two definitely wins over one for that. So this is the one that we're going to go with. Um, I'll, I'll enter in the vote results into the PRs themselves. Um, but is it before we move on though? I think the next steps here is for Clemens to potentially do some wording changes on this one. I think some people had some comments last time, but aside from that, are there any other discussion points people want to bring up related to this? Okay. In that case, just Christoph, thank you very much for helping push this one forward. Um, I know that. It didn't go the way you necessarily wanted, but I do appreciate you guys. You driving this so hard. And I know it painful because it took so long. Uh, sorry. Can I button again? Just to, um, make sure that like if did anyone, does anyone, is anyone not able to do what they need to do? If we go with option two. I still don't quite understand, to be honest. I think we have concerns about end to end reliability. That that's really what the drive of all this was about. So I'm holding comment until I see what the next proposal is. Okay. I'm really sympathetic with that. And I honestly, um, sorry, I'm sick and I shouldn't talk this much, but, um, I think that we have interoperability constraints in either one of these. And so like just speaking for myself, I would have rather had more conversation. Um, and, and I'm really open if someone else wants to keep the conversation going about like how interoper's supposed to work. With either of these constraints. Okay. Sorry for that. Sorry for just dropping that there. I, I used suggesting that we should have a separate statement in the spec around interoperability. And then these become implementation patterns rather than the other way around. Um, okay. I guess for me, I was thinking that like, like I have, I can read the text, right? I can read the text and understand what it means, but then it still seems like there's some unsolved, like there's some outstanding questions for me about how this solve, like it seems like we have an interoperability problem either way, because it's a should instead of a must, like we'll still have problems. And, uh, like if middleware modifies things, like how do we, like how do we make sure that an event can get all the way through that is like, maybe everyone else understands this. And I'm the only one that doesn't understand it, but it's still undefined in my mind. So I'm trying to figure out the best way forward here than Rachel is this. I don't, I don't want it at all block, like going with Clemens proposal. I just want to say like, it seems like the start of a conversation instead of the end of it. Well, that's what I'm trying to figure out is, cause I, uh, I'm not sure that this phone calls the best place to say, have that conversation. Cause I feel like we've kind of gone around in circles for a while. But if people do feel like we may have made the incorrect decision, then maybe we should have a separate discussion. I don't think that, I don't think that it's incorrect. I feel like it's not complete. Like either one of these would have been like, okay, and then this one seems easier to implement to me. But there are a lot of outstanding questions and like there, and we had, we were starting to ask those questions at the end of the call, like in chat, there was like a very lively chat going on. And all of those questions are still outstanding in my mind. So would you be willing to take the action item to set up a call with interested parties who would like to continue this discussion? Um, how about, okay. So I, in general, don't feel like I have a lot of time to like jump on a lot of calls, but maybe a doc that people can like chime in on as like, like at their leisure. Would that be something that people could work with? Does present, I'll give that, but do people want to continue this discussion in an offline fashion? Yeah. The problem for me here is that as far as I am concerned, last time it was me and Kristoff in chat and how that conversation ended. As you said, these, these proposals end up with different constraints. Um, and I don't think there were any questions open bit with me and Kristoff in that matter. It was just, we are looking for the, for different things. Okay. Um, I might have different outstanding questions. How about as a action item? I, uh, tried, how about I write up either like a doc or I think it's, I think a doc's a better idea than like, uh, something in GitHub because like, we probably don't want the artifact of this conversation. Um, to like live in the repo. And try to describe the problems and like a potential solution. As with the idea that it would only be a scare crow, right? That I'm not attached to solution. I just like, I want to be able to describe from end to end how the size, like how the size definition, um, prevents interoperability and how we can solve that problem. Okay. So, uh, so normally I think once we have a vote on something that says behind us, however, because I'm hearing that there may be some people on the call who feel like maybe we ended the discussions prematurely. Let's, let's sort of bend the rules a little here and say, okay, Rachel, go off and create that doc and let's see where that discussion leads. And we won't necessarily rush through merging any PR at this point in time. Sorry. I didn't mean to say don't murder. I think you should totally merge it. I just think like, it opens up a lot of questions for me. Well, yeah, but I also, so let me put it this way. And the reason I'm okay with not merging it is, and this is just my opinion. You know, you guys can say I'm wrong and that's fine. Um, the reason I'm not, I'm inclined not to merge it yet is because I don't want people to necessarily code it up if we decided to go a different direction and I don't get the sense that while it is a very important issue, I don't think it's necessarily a blocker for somebody to implement the spec to test out the rest of it. You know, it's not like we're going to change our encoding kind of thing. It's going to radically change all SDKs kind of stuff. Yeah, for sure. And I, and I think, um, it's a should. And so people can take or leave this one. It's, I guess, like the ultimate get off jail free card here. It is. Yes. So I, okay, Jim, you have your hand up. Um, only to say that, uh, maybe I misread the instructions. I thought we've, we weren't voting to merge the PR. We were voting on a, uh, on the manner in which you might measure the size of a payload. Yes, we're in that direction. Yes. Yeah. So I just got a bit nervous when we talked about merging PRs. No, no, no. Yeah. And I just say this earlier. I think Clemens had some work to do to tweak the PR a little and now people can go review it for more stringent, uh, wordsmithing kind of stuff. But my point was, let's say that's all done by next week. Um, I don't want to necessarily try to force a merge in next week of a rewrite of that PR. If Rachel's document has had some good discussions in there, that was my own point. Okay. I didn't want people to have an expectation says, oh, Doug, we took a vote. Why don't we just merge in this thing? You know, kind of stuff. I want to, I want to be a little bit looser with the rules here because, you know, I don't think it is as critical as it has to get solved today kind of stuff. Is that okay with people? Yes. Okay. Okay. So Rachel put together the doc and I assume you'll send out a note or slack or something to let everybody know where the doc is to have the discussions. Yeah, dropping in slack seems great. Okay, cool. Okay. Anything related to these PRs people want to discuss? Okay. Um, next, Scott, hopefully this is a fairly easy one. I apologize if you guys can hear someone blowing their nose behind me. Um, this is just a prettier.io's linter tool. It does a very opinionated version of markdown formatting. And I made no content changes except for in the, the, I think the contributor dot MD file was implemented in a way that was not marked down compatible. So I had to reformat it a little bit. What's that? I can't. It's a different file. Oh. I mean, it's in the PR here. I made it in governments. Here it is. Oh, governance. Okay. So this, this section. If you scroll down a bit, I had to change the member format. Like this list with a numbered space dash space. That's not markdown. Got it. So strictly syntactical change. Yep. I just added a dot and then I bolded the member voting member admin. Okay. Mark had a comment in there about maybe modifying the makefile, but then you said something in response. I don't think we should do that. Because it changes like this are, you don't know if it's done it right or not. So they're a human has to look at it. What's other repositories do is they have a robot that will make a PR that you can go and review and check in or. My, my, my comment wasn't to, you know, completely automate and check this in, in one fell swoop. What I wanted was just to document, what was the command to purify it so that if someone were to review it, they, we'd all be using the same command. Right. That, that command is in this PR and we could add that to the, some sort of document somewhere that says how you make a PR. Yeah, sure. Yeah, but we could definitely do that as a follow up PR to this. I assume. Okay. I love automation stuff like this. Anybody have any questions or concerns with this? No, thank you, Scott. Every time I make a change to the pros, I have to like do the like thing where you add bits of the file. So it seems great. So I, I'll, I'll pimp my tool a little bit. My personal GitHub, there's the repository called. Get tools. And I made a command called, so I extended get so I can run a command. So I can do get and it's lint and it'll auto based on file type run linters for you. So it's a, it's kind of cool. Just to be clear, you saw this at the get level. So I have a workflow that's like local to me, but I use prettier and it does this command that you see here. This is the one that just runs everywhere, but I used a version of this that only looks at your diff for your current commit and it runs lint on that. So I always check in stuff that's linted. Very cool. Yep. All right. Any questions, comments, concerns on this one. Hopefully Scott then sneak in something. I did not. There you go. Thank you. Thank you. Thank you. Thank you. Thank you. All right. I did remove Doug from the admin. That's wonderful to me. Thank you. All right. Any objection now has free time. Exactly. All right. Any objection to this one? All right. Approved. Thank you, Mr. Scott. Whoops. All right. Next one is mine. I don't think they've had really many comments on this one. This one is mine. It just added some text to the primer. I think. Yeah. Okay. This is the bulk of it right here. Basically, I just wanted to add some text to the primer, explaining some of the rationale or ideas behind the ID itself or the ID attribute itself. Basically pointing out the biggest thing here is that the ID is meant to be unique per cloud event within the scope of a single event. So that, for example, if a single occurrence generated to separate cloud events, those two cloud events get separate IDs. They do not share the same ID. If you want to do some sort of correlation and stuff like that, look at some other attribute to do it. But that's not what ID is for. The ID is strictly meant for uniqueness across cloud events from a single provider. What I did is down here, I replaced database commit ID with just a UUID because my concern was that someone can interpret this as one commit ID may actually generate more than one cloud event. Therefore it's okay to use that commit ID and more than one cloud event. And I didn't want to be able to make that mistake. And I don't want to get into that kind of pros in the spec itself. I'd rather leave that for up here, which is what I did. That's why I just changed it to ID or UUID. I'll leave that there for a second for you guys who may not have had a chance to read it. Okay. Okay. So what in the case of. You are doing transaction IDs. And you would like your, your middleware to provide you at least once delivery. Basically this change prevents. Using functionality that is at least once delivery mechanisms. Or at most once delivery mechanisms. Because there's no way to know what. What is the way to deliver it to a destination or not. You elaborate on why you think it would block something like that. Because if you replay the transaction commit history for a database and you don't have a way to know what. What the cloud. Cloud event ID should be. You can no longer guarantee you've not delivered that event before. So this doesn't say you can't use a database commit ID as the ID. What I'm saying is. If you have semantic rules that are trying to use this ID for some sort of correlation across cloud events. That's would be inappropriate. But it's not preventing you from using database ID. If it fits the, if it fits the rules of how we define this ID, meaning it's unique for all cloud events. From this producer. But you can do replays with this. It's not, it doesn't block that. Because it's replaying the exact same cloud event. It's not, it doesn't block it. Does that make sense? Yeah. Maybe I need to clarify that. We still have the trouble of if there are two producers that are reading from a non cloud event supported. Entity. No conflict. If the tuple is not there. Say that one more time. So above you're talking about uniqueness, right? And I still think that you need event. Type in the uniqueness check. So, so the reason I don't think we need type as of right now is because the spec specifically says ID must be unique from a producer from a producer. But if there are two producers producing events from the same source, right? You still don't know where that thing is coming from. You don't know if it's a replay or not. But if you have to, if you have two things generating cloud events from the same source, then each of those two things are responsible to make sure that their IDs are unique, right? No, because their IDs are informed by that, the entity they're reading from. So things are really replaying database commit transaction. And they're using the ID from the commit in the cloud event ID. Right. But I think, I think that's an implementation detail in the sense that if, if whatever mechanism they choose to use to generate the cloud event ID. That the entity needs to satisfy our requirements of it being unique. If they choose to use a field that's not going to be unique because there's another guy doing the exact same thing from the, you know, and, and going to spit out something with the exact same source, and they need to do some, some coordination to figure out what's, what's going on and how to resolve that. Right. I think that coordination is vent type. But that, but, but then you're talking about changing the definition of what ID is, right? So that particular source is always using the same ID, but sorry, the, that producer. Cause it's contained. It just happens that another producer is also using that same pool of data to pull IDs from. What if Christoph join in? He raised his hand for a sec. Yeah. I think I would try to discuss the issue before. So that it is, if the source is not really guaranteed to be unique, you can clash on the source. So for example, I have the same user handle on Twitter and on GitHub. So if both go and say there is a slash user slash Christoph, they may publish sort of events for the same source. And if you only look at the ID and you're really unlucky, they could also clash. So because they like Twitter and GitHub, do not know how the other generates their ID, but they would be different in the event type because one would become Twitter or something and the other would be come get up something. So in, in that scenario, looking at the type would then allow you to understand these are different events. But the other way to go is to say, okay, the source should also contain the UI and then you also don't run into this problem. So then we would explicitly have to make sure that people try to make the source are unique. Okay, so maybe I need to clarify something here. My purpose behind this PR was not to change the semantics of ID. It was to clarify what is currently in the spec. And I believe what's in here is accurate within what we currently have ID defined as in the spec, meaning we define ID to be unique for all cloud events from a single producer. If we want to change the definition of ID so that it's not unique and that the uniqueness spans multiple attributes, for example, type, then I think a different PR should address that. My PR is just trying to provide clarity for what is currently defined in the spec. Yeah, sorry, I may blow up the scope. Yeah, you're right. But I think it goes back to what Scott's talking about, because Scott, I'm not saying I think you're wrong in your concern, but I think what you're proposing to do is to change how we've currently defined ID. And I'm not saying whether I agree or disagree with that, but I think it's a different PR. Well, I read this as trying to clarify the conversation that's happening in the different PR around how to understand the uniqueness. Or maybe that's this one. No, I think they are definitely related. And this was just trying to provide clarity for what's currently there in the spec and based upon that other PR, this entire text may go away or change. So if you want, we can hold off on this PR until that one's resolved. That would make it feel better. I think they're linked and I think we should roll them into one or something because it's a bigger problem and I think we've been talking about it. Okay. I'm perfectly okay with that. I've no desire to rush this through. So in that case then, let me go back here for a sec. It's Alan's PR. I believe it's this one. In that case, that I think we may need to do is to go back and look at Alan's PR because I think. I don't think he necessarily took it upon himself to change the definition of ID. He was more looking at it in terms of given what's currently in the spec. How does someone establish uniqueness? Right. And I think what you're suggesting is maybe we need to revisit the definition of ID. Do I have that right? No, I'm not saying that the definition of ID is invalid. I think a single producer that produces an ID should be unique for its own scope. But the trouble is you can't guarantee the scope of every, every producer on a system. But that's what I, maybe I'm misunderstanding my interpretation. Let's get to the spec itself. It's actually looking at it. Where is, okay. So yeah, source and ID. Okay. So. Okay. So ID talks about. It must be unique within the scope of the producer. Right. And that, and while we don't actually, I'm not sure we actually come around and say this, but I think most people are assuming producer equates to source, which is why Alan's PR talks about linking these two for uniqueness. Oh, I guess it does right here. Describe the producer. Now this document, this in right here doesn't actually say that source has to unique across the entire world. Maybe that's something like that is missing from here. Or maybe. So I guess this bubbles up to the, sorry, totally clear. I work on K native. I write source adapters. I take things that are not cloud event native. And I bring them to a Kubernetes cluster. We've been using ID source and event type to understand the, the adapter that's read from a ultimate source, the source of truth, and then converted it into a cloud event in some scheme. We're making the choice to add. K native to the event type so that we understand which, which exact producer produced this version of the cloud event. And therefore if we look at all three fields, we can understand if there's multiple producers reading from say Twitter. And let's say you have a, for whatever reason, URL encodes everything. And another one uppercases all the events. It's modified, right? But they still have the same ID. And they still have the same source. So does Clemens subject PR playing this as well? It seems like it has to. If Clemens subject PR comes in, it'd be a four pole. As a result of that, I'm kind of wondering whether we need to take this offline and have a discussion about ID source, subject and type. Because it seems to me that we would probably make a mistake if we tried to modify or, or tweak the definition of just one of these without talking about all four in combination to see what we really want for the end game. I agree. Okay. Does anybody disagree with that? Because my next suggestion is going to be that we take it offline and set up a separate document or phone call or something to have some additional discussion. So we don't kill off the entire hour with this. Does anybody disagree with that direction or are we misreading the tea leaves here? Okay. Let's do that then. It is a very good discussion. And I don't want to do a partial job. Okay. I will take that one offline. All right. Next one is might as well. Okay. This one. Hold on. You're coming for a second Scott. Okay. I'm trying to remember why I wrote this. You are leading the witness. I'm trying to remember what the heck I wrote. It was a big one too. Okay. Tell you what, I don't want to waste your guys time. Let's take this one off. Let's save this for next time because I need to refresh my memory and page everything back in. It needs to get grouped into that doc that you have an action item for. Oh, we see. Are there previous discussions as well? That's right. Okay. That makes it even easier than for me. Okay. Cool. Oh, Clintons, you just joined the call. Excellent timing. Amins, would you like to talk about your subject one? I'm not sure if you introduced this in a previous call or not. I introduced as well ago, but then we saw it. We ended up introducing source in that discussion. Oh, yeah. You're going way far back. Yeah, of course I do. Because I also linked that. I think I linked that old, the old issue into this. So. In addition to what's written here. In addition to what's written here, there's also some supporting material that I'm pointing to that you might want to read. There's. I would say a little book available on, on that. The subject, but we have, we have already seen this in also in the demo discussion that we're having for, for the next coming up event in the EU is that in the demo scenario, this suddenly there was an object field or subject field that appeared. So basically the reason for the subject field is that in source, the source identifies where the data comes from, but the source itself may have some further substructure that you want to go and express in that events and sources typically a way for you to identify where an event comes from. In, in a scenario where you have, you're subscribing to multiple different sources of events and you want to land in a single function. And then you want to further, further understand what is that that in that source changed. So example. And that's the most popular one is you're subscribing to events raised by storage container. The directory. And you want to know when new files show up. So this is the block created event where we're generally talking about. You then want to know exactly which file was created. And you want to be able to generically filter on this, which means you want to probably put a suffix filter on that file name, which is dot JPEG. And you don't want to do this by cracking the payload, but you really want to have this in metadata. So now the way that how we've solved that problem for ourselves and Microsoft is where we have it. We have two fields, but for cloud events is to go and put the source to construct the source from the place where we subscribe, which we call the topic. And then we put the pound, the pound sign, the anchor effectively at the end of that. And then we append the file name. And then basically to go and do some reasonable filtering on just the filing with prefix suffix, we basically have to know that we can break apart that your eye at the pound sign and then kind of come out without two fields. And that is the left part being the container and the right part being the file name. But that seems to be, so that turns out to be for several people who have been, who have been starting to implement cloud events or also middleware for cloud events. And that duality where you need to have information about where does that event come from and then further information about what aspect of that source has been, has that event been raised about is something that is, is in fact interesting to people. So that's why I'm effectively reintroducing this, even though we've had been discussing this for about a year ago, I think, and then ended up having just one field. I think we're now having started to have some evidence that having source as the subscription scope, if you will, and then subject as the additional identifier for the sub object that the event is really about makes sense. Thank you. Any questions on this one? This is a rather large chain. So I'm hoping to get at least a little discussion going here. I like it. Scott was, Scott was saying, give me, give me, give me. So some, some support, some more words to that would be nice. Yeah, we're, so in Knative, we're trying to work on, well, on the eventing side, we're coming to the need of some sort of registry. And they're, if you, if you're going to ask all of the consumers to send to a central place and then ask that central place, give me all events that match the following criteria. And you probably want to do something like give me the bucket that events are coming from and give me all the bucket events. But I want to only know for a very specific bucket at the moment, we have no way to do that because we don't control the format of what a source is. And we don't know that we can always split on a hashtag or a pound sign. So we need some, something that means the, the parent object and the, the subject, which this, this fulfills. So we've actually started working on implementing this as an extension because we need it. And I also want to comment on this one. I also think this is quite, quite needed for every single example I've now given for other PRs and features I've had to somehow work around this issue. And I think that shows that. Well, it's an issue. Okay. Sorry, I have one more point. If this comes in, does source change? Well, I was going to get to that in a minute because I think Clemens missed the previous conversation. I was going to say was if we actually liked this PR, then we can't merge it today. We need to pull this into the previous conversation of how does this relate to ID and then as you said, Scott has this impact source. I think we need to take out all those together first before we go about merging this one. So I don't think it changes source because source is, I can imagine that what sort of discussions you might have had about uniqueness of, of, of messages or of events, but source is really the place, the place that you, where you, for which you register interest, right in the pop-up substance that raised those events. And then subject is really a thing that is, that is relative to that source. That's, that's how I look at it. But source per se, I don't think source as a definition of how we look at it. It's the thing that raises the events. It's just that the source itself has some internal structure and you're interested in, in what, what is that inside of that source that just, that this event is about? And that's something that the source itself can't explain really because the source is, well, the thing that's raising the events, it's the outer container, if you will. Can you show comments and look at the comments that I made at the very bottom, I think? Yeah, I'll do that. Just, yeah, let me just point out, Clemens, but if nothing else, when we need to do things like change the examples so we don't include pull request number one, two, three anymore in there? Yeah. I think that's a, that was, there were some brilliant examples in the, actually in here, in that the, if you subscribe to pull requests, so you're interested in pull requests, let's just look at the highlighted piece, right? What you will subscribe on is on the cloud events repositories pull request source, right? That's what, that's what you will subscribe on. And, and when you get events, that's how you will discriminate them from other events, because you're going to look at this and say, so you're going to have your, your pull request notification service. The first half is, I want to know, I want to identify which repository they are associated with. That's the left side of this. That's the thing you subscribe to. That's that, exactly. So you can tell from this which bucket they belong to, but the last part of that, the one, two, three is not what you subscribed to, but that's effectively what this event, this event is specifically about one, two, three, that new thing that you didn't know about when you subscribed, because it didn't exist yet, but that now comes into being. That's the subject of, that's the subject of this event, which has a certain type, which has a certain idea, et cetera. But about that subject of the event, you can obviously raise two, three, four, five different types. So why this is not the type and it's not the source. But yeah, we're going to have to go and change those. Okay, Scott, what do you want me to scroll to? I think there's an example of that. Maybe the last comment here. Yeah, that's exactly here. And the wonderful thing is the last, the last example that Scott mentioned is the email to with the subject help. That's exactly what that is. Right. This is, this is why the messaging system, including SMTP have a subject because in addition to the address, where that stuff comes from, you still need to have some, some sorting criteria, how someone can go and figure out whether it's worth reading and often that's the subject. Should that, well, I'm just wondering for SMTP, should that be subject or should that be something like a thread ID or something like that? Well, so, so SMTP lands effectively in your inbox is a thing that you look at. Because that's for human consumption. The subject is exactly what you typically look at. And that's also how your threads are being sorted by. I can have two threads with the same subject. They get threaded separately because they were actually sent independently and, you know, health is a great example. If 10 people send help over the next two weeks, they may not be replying to each other. They may actually be asking, you know, for help on separate topics. I would argue that's a tangent of correlation. But effectively, this is, this is about how you tell it's a subdivision of, so the source here, which is the serverless working for mailing list is sending you events because you're subscribed to those. And now you want to be able to tell those apart and the way that you tell those apart, if you look at it in your mail, in your mail application, is using the subject. And yes, there might be a further criterion with the thread ID, which then allows the client to go and, and, and figure, and figure that out. But that's a, that's an additional correlation picture. I have a question. How does this. So I am concerned about making something like the pub sub channel or the Kafka topic or something like that, like baking that in, in a way that like seems like not like people will be using not Kafka or not pub sub. And I want to make sure that this is like something that works for everybody. And it reminds me a lot of the conversation we had about topic, which was an attribute proposed. I don't know, like a year and a half ago or something. What is the different, like, how is this different than the conversation we had around topic? And I think, I think what, I think the thing that got in the topic discussion. The, the, what, what caused most confusion is that the topic is necessarily a thing that is a middleware construct. At least, at least in the way how it's usually perceived. And now I'm already need deep into messaging philosophy. The source. But I think that, I think that like we're already into messaging philosophy is like the important point here. Right? Like we are, we're baking in like a messaging paradigm. So I'm, I'm, I think we're matter of what we're doing here is which we're, we're baking in a, a dispatch, a dispatch network. When you just assume, forget the, forget who is, forget whether there's middleware in play. Right? You're simply, you have a function and you are asking 10 parties to send you something and they, they sent you something about, let's stick with the, they created files example. Right? So you have 10 parties who all manage files and they tell you about it. So now they show up with cognitive events. The first thing you will look at to figure out what to do with that event is you're going to look at source because you want to know who just sent you something. And then now the second thing is you want to know what is that file that was created and whether you're interested in that file that has been created. Now, so you now need to go and be able to apply a filter on some metadata of, of whether you are interested in that file. Is that file, if that is about a JPEG, you might be interested. If that's about something else, you might not be interested. So you need to have a, have a, have a screen that carries that information. And that is distinct from the, the information about who sent you that, who sent you that data. That's the decision I'm trying to draw here. So it's not necessarily something that's important for middleware, but it's important for, for someone who's, who wants to distinguish between who sent me this, that's the source. And what is this about? And that's the subject. Okay. Like I understand the need for this, like for, for having something that describes the content. And I would love for the content, for like the description of this attribute to have more of what we've talked about in here. Like to, to make that, like that distinction clear. Do you think that it does? Well, it does me. I wrote it. Okay. How about I take an action item to leave some comments on this PR and say, like, like I am like, bringing it back into the, on everything, like, everything. My, my main concern, and I know I sound like a broken record is that I want this to not just work for like the example use cases that we are thinking of, but work for like more general use cases. And I worry that we are baking in, you must be using Pub sub or something like that for like, in this one. So maybe I can go through and add comments. Or maybe just like propose an additional. Like paragraph at the end that says that it's not It doesn't correlate exactly to a PubSub channel. It doesn't have to. It can be used for other things. So would that be okay? But one thing you could also look at that is potentially adding something to the primer, right? Cause typically the spec is relatively short and even when you start talking about pros, that's perfect material for primary. But I think it's about this attribute specifically, that like, that this, that subject is not meant to be used as a, like only as a PubSub channel. Yeah, but that's, yeah, that's not what, yes. Okay, I understand, like I'm too deep in this. Like this is my, I'm probably 20 years too far into this whole PubSub stuff. The thing that I don't see the thing that you're missing. And I would like to see the thing that you're missing in writing. So that would be fantastic if you would do that. Okay. And one, if you do me one favor, as you, as you think about this, there's in the comments, basically in the PR itself, I've leaked the old issue, which is prior, basically I created an issue back in the day, which was subjects, I think topics and subjects and, or just subject prior art. And that's leaked from this issue. And then if you scroll further down, kind of five pages down, it's the issue text. I have a list of like, Doug, if you could, if you could It's in the conversation. If you go in conversation and go, go for, go up, I put that into the right, into the, up, up, up, up, up, into my original text. One 12, then I'll above that, that's linked that one. Yes. And then scroll down, there's a whole prior art section on where actually linked the various different kinds of products and definitions of, of, of subject. This is one of your, this is one of your shorter comments, I see. Yeah, I did. Sorry. Basically just show it, this basically just, live with further, no, because there's actually a table. Eric, there we go. So this is basically that subject field and how that subject field is, looks in various different kinds of infrastructures. So that's kind of the summary of, of that, that's not something that we're introducing here, but that, that's something that is, is very common in the, in the infrastructures. So I have a, for me, that's, for me, it's that, that field for me is basically given as something that in my head must exist in a message. And I understand that if you come from a different, from a different angle that it might not have to. So, so, but I, in my head, I have a hard time closing that gap. Rachel, if you would help me closing that gap with some additional text, it would be fantastic. Okay. I'll read through this and add comments and I'll also read through this topic, subject, prior. Thank you. Okay. So, hold on, where are we? Anybody's hand up? I don't think so. Okay. I got a question for Clemens. I think the answer is no, but I want to double check. Are there any other constraints we need to put on this around uniqueness or anything like that? No. This can be literally anything. This is, whatever the source things is the right thing to say here is fair game. Okay. Anybody have any questions, comments? Evan, you've been putting some stuff in the chat. Do you want to vocalize those or let those go? Oh, just that I was slightly concerned about saying that subject or that source was related to how the message was published specifically because if we're ending up forwarding these messages, it seems like needing knowledge of what the original publisher was doesn't have a good decoupling between producer and consumer. And so I'd rather have source be some indication of the source system. Now, it may be the in Clemens system, the source system is the PubSubbus, you know, is PubSubbus, but I'm not sure if that's universal. So I just wanted to clarify the difference between the first place it got published and where the event originated. Yeah. And this is, that's the place where it goes into this. This is where the philosophical piece comes in. And that's actually where, I think where we landed on source and where I'm actually happy with that being source. Because topic is something, because topic is an overloaded term. So let me back up one. The way how, the way how topic is being described as an abstract term, which means is, this is the general, this is the channel, the logical channel for which I deliver events and where subscribe events is as an identifier is something that is, I think that's still true, that that's a good concept. However, since topic is also used and largely mostly used as a concept that is a thing in a PubSub infrastructure, then you get to the point of, okay, so the topic is where I send that message and then I pull that out of the message and now I do multi hop routing and I now put that onto a different topic, different topic, how much is that worth that I put the initial topic where I publish that thing into that event? And that's something where even in our team, in the event group team, we're now actually explicitly into the native schema adding source because we have now realized that using the topic because of that overloaded notion is probably not too smart. So yeah, so the topic will not be useful but source really designates who ultimately put that event out and that is a channel. So looking at the description of source right now and the examples, a couple of things that I think based on the chat may have caused some confusion is the optimist will include things like the process to produce the event and some unique identifiers. And then in our examples, we show specific like pull requests for example or a specific resource in an API. If instead that we said this was a representation of the source system and then it shouldn't include unique identifiers and those should go in subject, I think that the confusion would be substantially reduced in the spec. I agree with you. Okay. Yeah, I can agree. Yeah, because so what I've been, since this is something that I've been reintroducing and we've been having long discussions about this prior, I wanted to make the PR theory scope and not edit the rest of the spec completely but I agree with you. So with if we introduce this then that needs to go with some edits throughout the rest of the spec to basically make clear what the relationship needs sort of the subject is. Okay, so since we're having a long time and since Clement, you missed the previous conversation because of your other phone call. I will listen to the recording about that. Well, the key point is we've realized that we probably need to have a separate discussion that sort of combines ID, source, subject and type because based upon all of the various PRs and issues that are out there right now it seems like we maybe get converging on this idea of we need to modify some or all of those four different attributes in terms of definitions or in the case of subject, add it to the list and when you add this one it's gonna impact the other. So I took the action item to create a separate discussion to sort of have that broader discussion to resolve those four attributes in combination so we don't do one PR that's in conflict with another. We're gonna do it all in one gigantic blob basically. Yay! Yeah, so. Okay, so let me ask this though since we're all set of time does anybody have a fundamental objection to even considering something like subject? No, I think we absolutely need something like subject. Okay. Cool, thank you, Rachel. I have a fundamental objection to not considering subject. Thank you, Tafini, I appreciate that. I just wanna make sure that we head down this path and someone doesn't wanna raise their hand and say, wait, wait, you guys are going the wrong direction. Okay, cool. Let's circle back to the ever popular attendee list. Just to make sure everybody, Matt, are you still there? Yes, I am. All right, Victor, are you there? Victor, Victor? What about David Lyle? Yes, I'm here. Barron? Barron, are you there? What about Klaus? Yeah, yes, I'm here, sorry. Okay, that was Barron. Yes, I'm here and this is Klaus. Okay, and Victor. Okay, did I miss anybody? Yeah, I think you missed me. Oh, darn it, okay. Anybody else? Okay, in that case, I believe we're done right at the top of the hour. Thank you guys very much. If you'd like to hang on, for those of you who wanna talk about what's going on at the demo prep call that we have basically starting right now, you're free to join. Otherwise, everybody else, we'll talk next week. Thank you guys very much. I have, okay. Okay, Rachel, go ahead. Everyone can go. I just wanna say like there's