Hello. Hello. I think you need to, I think the easiest thing is, as I said in the issue, just go ahead and squash your commits down and sign that last one. Yeah, but there's stuff like. Yeah, I did it. I did a rebase in the middle of that and that was, I did the rebase on that wrong commit. So I, I'm not sure how I'm going to resolve that now. Well, one option it's not pretty is to kill the PR and create a new one. Yeah. I mean, if you want, I could take a stab at it if you want to save your work first. And if you want, I can go in there because I think as an admin, I can do some funky stuff. I can try to squash it and rebase for you or whatever. If you, yeah, if you could try that because I'm, I'm not sure what to do with that one. Okay. I'll take a look at it. I didn't actually look at it yet. I just saw your comment, but yeah, I could take a stab at it.  I mean, I can, I can literally go, I can abandon, I can take the text. I can abandon the, the, the, the PR and then put that text in and basically just kill the history and then, and then pretend it's a new file. That's, that's probably the cleanest way to do this. That I can do. Well, it's up to you. Do you want me to take a try at it first or just go for it? It's up to you. If you, if you, if you need to spend more than 10 minutes on it, I would say. Okay. Okay. Tell you what? I suspect this calls definitely not going to take the full two hours and it may even take less than the one hour. So I'll take a stab at it first and I'll ping you afterwards. All right. Okay. All right. Tommy. Yo. Yo. Yo. Lucas. Hello. Hello. And Simon. Hello Doug. Hello. Hey, Jesse. Hey, Doug. And Chris Hansen either. I am. Hey, I can't remember. Is this your first time here or not? Yeah, I'm subbing in for a. For my colleagues Christian. Ah, Christian. Okay. Cool. Well, welcome. How are you there? Yep. Hello. Hello. And close. Yes. Hello. And Remy. Hi. Hello. David. Oh, no, Mike yet. Oh, ginger, then. Hey, Doug. Hello. Good morning, Doug. David. Hey, David. And Mr. Mitchell. Good morning. Hello. How's everybody doing? Awesome. Fantastic. That's just good. But awesome and fantastic. Oh, that's so exciting. What day is it? They all have the kind of blur, don't they? So wait a minute. I'm confused. Chris, did I miss hear you? Didn't you say you're subbing for Kristoff? Or was it Christian? Christian Christian. Okay. Too many season there. Okay. Yeah. Well, I'm here too. And my colleagues. I heal. We'll also join in a minute. Okay. Good morning, Doug. Hey, Vlad. How's it going? I can use a count on you for something so excited and happy. That's, that's not like you. The pandemic is getting to me. I understand that. All right. Hey, Daniel. Hello. Hey, Jim, you made it. I did. Excellent. That's okay. All right. Another couple of minutes. We'll get started. Hey, Lance. Eric, how are you doing? I'm doing pretty well. Thank you. Yeah. Okay. Well. Hey, someone just joined the name.  If you want. We typically track people for attendance and they can get voting rights by attending stuff if you want to put your name and company into the chat, I can. I could replace it with your real name or your full name, I should say. That's my colleague. He's with. Got it. Okay. Thank you. Let's see if I can spell this right. Perfect. Thank you. Yep. All right. And someone else went flying by who was it? Lou, are you there? Yes. Hi. Good morning. How are you? Good. How about you? I'm pretty good. Thank you. All right. So I think we. We're three out to the hour. Let's go ahead and get started 22. Okay. Cool. I saw a different move one AI care, which one it was. It was slinky with versus QL PR because you already did that one, but there are other. As out there for folks, if you're so remind, if you're so inclined to remember that. Community time anything from the community. People want to bring up. All right. STK calls this week. Just to quickly double check. I doubt we have anything on the agenda. I didn't notice. Let's see. Yeah. So we haven't took the end of this call to add something. We have something.  Otherwise. We may not have a call. I'm moving forward. Discover your. I don't think we really talked about anything last week. Just a reminder. We are planning on doing the interops starting at the end of March. So that's about what two, three weeks away or something like that. Workflow. Two more cities can make it, but they're still preparing for these 0.6 release. And they're hoping to have that done next week. So if you have any questions on that, you may want to reach out to him. And I did sign up for the coupon. For the office hours, which will give us two 45 minutes sessions. Does anybody have any preference on times when they actually do send out the request to sign up. If you want me to help. Like end of the day Europe. End of the day Europe time. Okay. Yeah. When I am it's not really my time. I don't think it's going to be online. Well, these are all Europe time anyway, right? Yeah, yeah, but like seven AM, like a six AM, I can do it. One AM. Okay. I don't think we should take the decision based on me. Okay. Well, I'll keep that in mind though, because you're right. We should try to get people from the, from the States in there. It'd be better if it's later in the day. Okay. So before we jump into issues and PRs anything from the agenda, I forgot to add. All right. In that case, I know last week we talked about. Possibly emerging slinkies SQL expression language PR. But he paid me offline saying he's been working on it. He thinks it pretty much ready to go. And even though I've mentioned that we were probably going to merge it this week, he said, let's hold off another week because it's kind of large and he's in no rush for it to get in. So unless someone really, really wants it in there right now, I'm inclined to give him to his request and say, okay, we'll wait one more week before we merge that. Is that okay with everybody? All right. Cool. Yep. Okay. Yeah. I didn't think anybody was in a big rush other than it would be nice to have a rough draft and official rough draft. Okay. In that case, next one. So this was mine in response to Lance's request for a little. A little bit more formalness around our decision to change how we're going to merge trivial typo type PRs. So basically I'll let you guys read the text here, but here is the text I added to the governance doc. Give you a chance to read that. Okay. So the point here is to make it so that we can merge typo type changes without having to worry about new branches, new releases and stuff like that. There's obvious things that are just typos, but anything pretty much bigger than a typo, like, well, then have to go through the normal release process. And just want to make our life a little bit easier. So hopefully Lance, that satisfies your, your concern and your ask. Yeah, that looks great. Okay. Cool. Any questions or comments on that? Okay. Any objection to approving that? Words, I think natural nature. There. Align them. Nature. Got it. I'll forget if I've got to fix it. Nature. Trial nature. Yes. Okay. Got it. Cool. Thank you, Eric. Okay. And. Proved. Whoops. Good golly. I have major issues here. Okay. Cool. Now that was it in terms of PRs that are ready to go. I did notice a couple of. Commits go flying by this morning. So obviously that's too soon to talk about those or to, to approve those. But did anybody do any of those commits want to talk about their PR? I think I may have seen something from Lance and Clemens. You know, what do you guys want to talk about yours? Yeah, I did work on the schema registry or application to the point that I think if the, the validation of passes. Okay. Except for the CO issue. Is there anything you wanted to specifically bring up and draw people's attention to, or is it a matter of people finding time to review it? Yeah, I think at this point, then people should go and review it because I've made some clarification. There were some, that maybe was some weird. I made, so generally I made some, some, some fixes to links because I had to go and do links throughout the document. So I made some, some headline changes. As you see, there are more changes throughout the document, but really the meat is at the bottom. And those are the, the subscriptions API. Oh, so that should not be there. I think that's the problem I was there. Yeah. So there should only be, I think that's what I pulled in. That's what the DCO issue is. Right. So we're only looking at this. So the ignore the rest. I'll go and fix that. So I have two events that are defined. So I'm defining cloud events and cloud events. And those are for updated and deleted. Updated also covers created. And so whenever there's, there are three modes. If you scroll up a little bit, I can go to the, to the actual definitions of all things. How far, how far up did you want me to go? Where it ends up being great. Where it's still overgreen. I think for section four is what I added completely. Okay. So there. Yes. And some explaining. Effective. Three types of replication models. Let me, let me talk about the motivation for this for, for a moment. And I believe that most of these. Infrastructures will compose. So most of the event brokers will compose in some way. And we will have scenarios where we will have to go and route from one to the other. And we're having one concrete example. Between class, what class does and what we do. Where there is. In cloud system. Over an SAP, they have a event broker inside of their own application where they do a lot of event driven stuff. And now they want to be involved, involve applications that are hosted inside of Azure. So we kind of need to go in and connect all the connect those things up in the way. And so applications will first post to the SAP event broker. They will probably have to go to one or two hops inside of the SAP world. And then the events will hop over to the Microsoft broker. And we'll be distributed from there. So that's these multi hop scenarios is something that I envisioned will be. More and more common. So now the question is, if you're using a model like what you would use what you today use with Kafka where you are effectively writing an app and you have some code. That defines the events. And then you start publishing the events in a in Kafka your, your code effectively starts writing to the schema registry. As soon as it publishes one of these new events. And so the question there is, how does, and those events are no, the payload for those events is not cannot be understood or deciphered by the receiver until they have that event, the schema, the event schema. So the question here is how do we make it possible for the schema registry that sits kind of alongside this event broker to also replicate along those flow paths. So that's the thought behind this. And there's some explaining some to potential topologies in the section. And then I'm landing on there's a pull model and there's a push model and then there's an event driven model. The push model is that a, you have a schema registry and it knows about a target schema registry. It gets it is configured. And whenever it changes being made in the source registry, it goes and just pushes to the target registry. Using the target registries schema API. Right. So it, the, the, the source registry gets is updated and it turns around and just updates the other one through its normal registry API. So that's one possible path. The other path is that you have, and this might all be dependent on, you know, what the firewalls rules are, what the visibility is of these systems. One might be behind a firewall and that might determine whether you're going to do a push or pull. The pull replication is effectively when the target registry, which wants the data calls the, the, the source registry to go and enumerate the, the contents periodically and then goes and adds its data to, to itself. So I'm just also mentioning that. And then the last one is the, the event-driven model for which I have the events at the bottom where every time an event, every time a schema or schema group or schema or schema version changes, or when it's deleted, we're raising an event and then the party which is receiving the event notification through cloud events can then go and turn around and fetch the change. So that would kind of be the, the middle ground between the two and kind of the event-driven reactive way of doing those changes. So I'm defining all of those, all of those three cases. And then there's a, yeah, and I'm effectively, I'm also referring there to our, to the authority model, which we already have in the, in the schema registry. That is it. And then again, the, the, the fact that the subscription API sits in there, that's a, that's an error that it needs to go and fix. So also Doug, so because, because of that error, I'm actually going to go and do a new PR for this. So you don't have to worry about this. Okay. Lots of interesting stuff in here. Okay. Any high level questions for Clemens? Okay. So I think it sounds like people just need to take the time to go off and read the changes. Thank you Clemens for doing all that. Once we get past any issues that people might find from here on out. Is there more work on your side that you're planning on doing on this? Or do you think it's pretty much ready to go and get reviewed and merged? So I think it's a, I mean, there's, I think the core, the core thing I wanted to land in there is all these, literally the two event definitions. But I think, so the rest of it is, is to motivate those two event definitions. Okay. But, but. But you're basically, from your perspective, it's basically ready to go, right? Yeah. Okay. Cool. Okay. Last chance. Any questions for Clemens before we move on? All right. Cool. Thank you, Clemens. Lance, was I wrong? Did you. Did you, did I see a commit go by on you? Anything you want to talk about in this one, or just have people review it when they get a chance. I just, um, after coming back to it, you know, not having looked at it for a long time. It's a, I just, it was way overly complicated. I just simplified it. That took some of the, your suggestion. And, um, I don't remember who made the other comment, but yeah, I just greatly simplified it. Okay. Okay. Some people when you get a chance, um, take a look at this one. It's just for the primary. So it's not normative. But still, you could think I'd review on that one. Any, any comments or questions for the group? We move on. Okay. In that case, ignoring the PR stuff. Oh, wait a minute. Gem on yours. Since you're on the call. You're. Are you waiting for an up thing from Clemens on this one? Or are we waiting an update from you? I can't remember the status of this one. I, whilst I'd love to throw it at Clemens. I feel you're actually waiting for me. And I've been sidetracked on the SDK. I'm afraid. Okay. That's fine. Just wanted to give you a chance to speak to it if you wanted to. Okay. Okay. In that case, let's move forward with some of the open issues in particular. This one I thought might be. Interesting and problematic. So therefore it must be Clemens. So therefore Clemens, you want to talk to this one? Yeah. This is something that Phil Hack brought up on Twitter to me. And this is something that we had already kind of flagged internally a while ago. But for some reason. I. So I had Microsoft. There was something that we stumbled upon. And I then failed to, to, to file the issue. And then someone externally came and said, Hey, there's this thing. And I said, well, wait, sorry, there was something. So now I filed the issue. So the, the, the webhook spec is. I made a mistake. I wrote, I wrote most of it. So therefore it's my mistake and that's the following. The origin header that we are using in the, in this webhook spec has a very, very deceivingly similar function to the origin header of course. So the cross origin resource sharing. And I have, I have. I had used effectively the, the, the, the, the, I only had looked at the course spec. And I had not looked at 6454, which score, which course is referencing. And I had not looked closely enough. The origin header in course. The origin header in cores, which is effectively defining which, which, which site context this request comes, comes from. That is a, that is a URI. The origin that we're using here is the, the push engine from which that request comes from, which is also origin. So I, as I wrote this spec, I kind of conflated those two concepts in my head. That would not be terrible. If the core, if our origin header, which I defined is a simple DNS expression. And the origin header as defined in our, 6454 is a URI. And it is a URI that must be the root of the site. So I can't remember what happened in my head when that was, whether I just ignored the fact that this is a URI because there was only the root address. And then misinterpreted it. So, so we now have a conflict that is entirely my fault. And that we're using in the spec the origin header or a header named origin that is defined as carrying a DNS name, which has a different semantic function than the origin header that is defined in RFC, in that RFC. And also they differ in the rules for how the header value is formed. One is the next DNS expression. And one is a URI. Now we have two choices that I'm, and that's something that I'm pointing out in the, in the, in this issue. That is, we can basically ignore the fact that 6454 exists. And I can say, you know, this is not using course. It's actually not relevant. We can also ignore the existence of that spec. And, and then just say, yeah, okay, we have a name clash. And our origin header is this and the semantics are that and be okay. The problem is that course, the cross origin resource sharing mechanism is by now so commonplace that it's kind of baked into the HTTP stack. So, header kind of all by themselves without you being able to go and sometimes probably without you being able to override it. So, so we can, we could, we could wish it go away, but then it might not go away. The alternative B would be to say, yeah, okay, we're going to go and change, we're going to change the implementations. And we will use our header, which we already use for the handshake. And we're going to go and rename that thing to web hook request origin. And, and let that be, be the DNS expression. So my, my preference would be B, but that would be a fix that would effectively break from the prior definition. Now, that said, it's impossible at this point to implement the, to implement that spec, the spec as we have it really correctly. And that's why my dev team actually didn't. So what they did is they literally did what I did, what I did in B, what I'm proposing in B, that's what they did. They looked at the spec and said, what, sorry, we can't use origin because origin is, is, is an age your eye. We have to use something else. So we're just going to go and reuse that header. That's what that's what they did in our implementation. So now I humbly, I humbly submit this problem to all of you to judge over me because it's my mistake. And we will judge you harshly. All right. Did I say that I'm really sorry. I'm really sorry. Yeah. Okay. So first off, does anybody have any questions about the situation itself, just for clarity's sake first. Everybody understand what's going on. Okay. I have a quick question for you. So the, the, this origin header is related to cores. Do people use cores and cod events together often? I don't think so, but we also can't. So you might be, you might, you might go and have the situation where you have an app on the webpage that's raising an event. And there you would have that. Okay. Fair enough. Okay. Okay, so let's then talk about the options available. So Clemens listed to here. Does anybody have any alternative suggestions for options? Or are these two basically the one only two that people can think of. Okay. Not hearing any. This is, this feels so sleazy to say, but I'm going to say it anyway. Option B. If we looked at our spec and said, clearly whoever wrote this was smoking something and they got it wrong. And it's just a flat out bug in our spec. Granted, it is a breaking normative change, but still it is busted. You cannot implement this as it currently is written in the spec. Therefore, we are going to make a change without bumping the major version number. I'm pretty sure that has been done in the past and other specs, but I was wondering what people thought about that notion. Do any implementations rely on that? That's, that's the other, that's the other question, right? Yes. Because, because it is one where you are allowing a, another party and then as you have allowed that other parties to do this, you need to go on and do some const, you would have to implement some constraint based on this. It's basically just, just valid. It's just allowing you to kind of validate that this is coming from the place that you have allowed. Yeah. Yeah. So, what I'm going to do is you don't actually mention. That R of C in here. No, I do. If you go in search for origin. See, right. See right there. That is there. Oh, there we go. So, so I'm, I'm, see, I'm mentioning the origin through cross-center several times, but I'm not even, I'm not even referring to 6454. Um, I can't even tell you, right? So I can't even tell you that whether I, I didn't really mean the web work request. Well, that, well, that's what I was going to, that's actually the path I was heading down. It's like, if you had actually mentioned the other spec, I think it actually would have been easier to justify and convince people that we just goofed, right? Yeah. Because we knew about the other spec and we didn't mean to do a conflict. We just made a mistake. But someone could look at this and say, where's the mistake you to find a new header. Okay, it overlaps with somebody else or some other spec, but who cares? Yeah, so, so, so I have, I have had a, I have had a, had a, had a, some, not in my head at that point. Where, which made me write the origin header kind of the, in these three places where I'm referring to just origin. So there. And then, and then next, and then the next, the next one. So I have three mentions of origin, but I'm not even referring to the other spec. So that's, that is what I find my, even, even me looking at this thing that I wrote makes me puzzled for how I landed at that point. Yeah. Okay, so need people to speak up here in terms of what their opinion is on this. Even in support. Do we have anyone that's actually implemented the web hook? Because I've done a little bit in the SDK, but I haven't really seen any like in the real world examples of the web hook spec in use. Yeah. So event grid doesn't event grid does ends up, ends up happens to, to actually do what is it be. Event grid. I mean, I think, I think regardless of which direction we choose to go, we probably do need to reach out the community through an email or whatever to get some feedback, or at least to give people the chance to give feedback before you make a decision here. I think that's a given. I don't know what do people think about option B. Yeah, I think we just have to put our hands up, don't we? And just roll with it. Well, Clemens does honestly because he was good. Never going to let it go. Never going to let it go. I understand this is the case of beer kind of bug and Did you just say beer kind of bug? It's a case of beer. I owe a case of beer kind of. Oh, I thought, I thought you were implying you were drinking as you're writing it. No, no, no, no, no, no, this is a case of beer to the group. Okay, got it. That's fine. Okay. Even though you all voted for it. That's true. Yeah, you could, you could blame this the, what's the phrase I'm looking for the, the secure, not the, not the validators, the quality control people in the group. Yes, you can blame us. Yes. So Klaus, since you spoke up on this, what's your take on it? Yeah. Actually, I think we also have an implementation of this and I would have to check with my colleagues. What exactly they did. Yeah, I think it's cleaner. As I said, I mean, to switch to the web of request origin. Okay. I think people need probably a little more time to think about it. Clemens, would you be willing to take an AI to write an email to the mailing list asking for, for the community at large to look at this and ponder it and give feedback either through email or through the issue. Yes, sir. Cool. Thank you very much. Okay. Okay. I'm just barring that. I'm hearing most people who choose to speak up early towards option B. Anybody else want to chime in? Or just people just need time to think about it. Okay. I'm going to assume people just want time to think about it. Okay. Well, cool. Thank you, Clemens for, for writing this up and bring it forward. Gotta get things fixed. So moving on. So last week we talked about these two issues. Let me bring them up here. Okay. So first one was Jim. You were basically asking whether we need to have some sort of life cycle relative to state in the discovery spec for the services. And the second one was, I think that's kind of related to what should a client do when a service disappears. And as a result of a get or in response to a get a service appears to have disappeared. It seemed to have vanished. How's that? And how should the receiver of that interpret it? Should they say it's gone now? Do they need to wait a period of time to realize it's really gone or whatever? Okay. And unfortunately, I don't think I can run the person. I think, I think it was Jennifer. I think that was her name. She said she was initially against the idea of a service life cycle type stuff to it. At least from a deprecation perspective. So I thought a little bit about the conversation we had last week. And what I was going to do, and I apologize, didn't get a chance to write this up formally, was I was wondering whether we can look at two possible stepped solutions here. One is to make it clear that something missing in the get, the receiver has no choice. They have to assume it's been deleted. I think the only weird edge case is, if there was ever only one service in the, in the discovery thing and suddenly that, and then your get was completely empty, you may not know whether, for sure, whether there was a bug someplace or, or really is deleted. But I think in most cases there will probably be more than one. So having one missing at an entire list of things, but you still got a completely valid ESP response just feels like a weird thing for a bug to manifest itself that way. Unless someone actually deleted it by mistake, by that fingering something. But in that case, well, tough, that's the state of the system and we want, we don't want a lot of people. So I think you have no choice to say missing equals deleted from a client perspective. But then a phase two kind of a thing is say, okay, that's fine, but should we look at adding some sort of additional optional property that allows a discovery endpoint to say, this thing is will be deleted at this particular time. I don't particularly like the phrase plan deletion time, but you get my point, right? Where the presence of that time stamp says, the service has been deprecated. It will go away at this particular time. So we're just giving you a warning, but it is optional for them to use, but we would recommend it as a heads up to people if they want to take some action. Anyway, I think that we at least probably need to do one. If we want, if we want to agree that missing equals deleted and then think about possible phase two or a second step. But I wanted to open that up for discussion and see what people thought. And Jim, when you were talking about life cycle, did you want complete multi-step life cycle or is a deprecation kind of thing simple enough to meet what you're thinking of? Well, when certainly, you know, when we look at what we do internally, I mean deprecation and retired means something different. So to us deprecation means you shouldn't, you know, we're still doing it, but you shouldn't add any more dependencies on it. So whether, you know, whether a deprecated state means that you don't accept any new subscriptions. I guess that's an interesting scenario. It's interesting as we see the word retired. I'm not sure obviously that makes sense from an internal or a documentation perspective. If you expect this portal to be used as a sort of data source for documentation as well, I think retired is useful because you can, you know, it's blindingly obvious then that you shouldn't, you can't subscribe to this anymore.  It's not that you're, it's not that you're going mad. It didn't vanish to use your terminology. So I can understand why a consumer side may want to have some sort of retired state for their users to say, yeah, this thing used to be there, but it's not available anymore for you to use. And maybe you're choosing to show it for historical reasons or whatever. But does that mean that in your opinion, the discovery endpoint itself needs to have a retired state or couldn't the fact that it vanished imply it's retired since you can't really do anything with it anyway. Yeah, I mean potentially. And we're not, we're not supporting temporal queries. Are we? We're not saying what was the state of this last Thursday, for instance. Yeah. Okay. I'd buy, I'd buy into that. I maybe just active and deprecated then or whatever. And presumably we deprecated. We should. We should give some indication as to when it's going to retire. Yeah. Yeah. So what's kind of thinking is if we have this sort of time stamp here, that gives you, I think at least those two states is no time stamp means active time stamp being there says it's been deprecated and when it's going to actually vanish. And then when it actually does, when that time passes, then you can actually remove the whole service and lack of being there means it's retired or gone. I guess I'd prefer something explicit rather than inferring. Yeah. I think because you could have multiple. Active versions potentially or one active and one deprecated. It just seems a bit odd for me to have to pay attention to a different field to see, you know, and then infer a status from that. Can you elaborate a little on what you meant by kind of multiple versions? I don't think we have enough versions. So you have more maybe, maybe I've gone completely off track then your events are versioned. Yeah. And as you make breaking changes those events and you move from version one to version two. You might be running both in parallel for a while while people get off your old one and get onto the new one. That's what I was looking to maybe I've misunderstood the discovery side of this thing. So if I say show me, I don't know, think of an example. Show me, you know, give me my the event endpoint for stock tickers. Yeah. And that event follows a schema and then we change it in a breaking way. I'd be then sending both versions for a while and then retiring the old one. So I, God, I apologize. It's been a while since I've looked at the spec where my It is for me as well. I mean, I thought that was where this came from originally that because I remember this came up in a discussion and you said, Oh, could you slap that in an issue? Yeah, it's just, I don't think we have the notion of. So, okay. So first of all, I think we're talking about deprecating the entire service, not one particular event. And I don't think we have the notion of versions between services, right? If you want to have a completely new version of a service, I think from a discovery endpoint perspective, I think it to create a whole new service and the fact that it may have some correlation or similarity to an existing service is interesting. But I don't think that fact is, is manifested itself in the discovery spec itself, right? There's no link between the two. So we're, okay. So maybe I've been confused. So this is, this is really saying your subscription endpoint is moving from location one to location two. What is that on discovery? So, no, I, no, I think, I think what's happening is if you want to have a version two of your eight of your subscription stuff, then you can create another service in your discovery endpoint. And it happens to look very similar to the previous one, but it's a completely different name, completely different ID. And from the discovery endpoints point, it is a completely different service. Okay. Maybe I was confused. I'll go back and double check, but I'm pretty sure we don't have any kind of correlation attributes in our, in our spec today. Okay. Um, and, but then I want to go back to something else you said about having an explicit field that kind of represents the state. I think that's, that's interesting. And definitely an option. My only concern with that is then we basically have. Two fields in. A service definition. That kind of say the same thing. Right. You have states, and then you could potentially have as this. Planned deleted deletion time stamp thing. Right.  If the state is, as you called it, it's what active, but then that time stamp appears. Right. We could, we could put a rule in the spec that says, well, obviously that doesn't make any sense. And therefore they're not conformant and they're just wrong. Right. But my mind immediately jumps to, well, if those two fields go hand in hand all the time, why not make it easier on people and just make it a single field. Okay. So I'm missing my, and again, I apologize. I can't remember that all the context is the original conversation. This note, this notion of one of subscribed ones. Yeah. I'm not going to come back. What would cause me to come back and check it again to see if it's being retired or deprecated. And so if you think about it from a resource change perspective, you know, are we going to admit it? Would you expect an implementation to admit a cloud event saying, you know, this endpoint is going away? That's a good point. I think I know at some point, somebody talked about doing events from discovery and points. I think maybe it might have been Scott. I would imagine that yeah, if any metadata on a service does change, I would think an event should be emitted if someone subscribes to the discovery endpoint itself to get events. Yes, I would think in which case you would expect, you know, would you expect the event to say it's active, but now it's got a, you know, this other date field associated with it? Or would you expect to say this endpoint is now deprecated? So it's a literal state change. Yeah, that's a good point. I don't know. Yeah. I have to think about that. My initial reaction is why treat this one as special. Just say, Hey, this thing's changed and you can go do it yourself. But I could also understand that this thing going away is a pretty important event. And maybe that should have its own special event. Yeah. You could also do the technique of the event doesn't have any context. It just says something changed and it's your responsibility to query what the change was. Yeah. Mark into the first option I mentioned. Yeah, I agree. But that implies, yeah, I get it. And that does imply you've got some sort of history because I mean, presumably there's a number of different things that can change, not just the state of it. Yeah. Anyway, yeah, it's a rabbit hole. I'm afraid. Okay. Well, we definitely don't need to resolve this today. To me, let me ask this one step at a time kind of thing. Does anybody disagree that missing should be interpreted as the service has been deleted? Okay. What I'll probably do then is I'll write up a PR for that one piece. And then I think I personally would like to do a little more thinking about this, given everything that Jim said, but I'd like to think more about all the other things. You mentioned Jim, I think there are some interesting aspects to it that I hadn't considered. That's all I can think more about that before I think we're writing a PR for that. But does anybody disagree with the idea of splitting it into two different discussions or do they, or do these things to, or do these two things you think have to be linked together and we should resolve them all at once. Okay. I'm not going to interpret silence as no objection to me splitting the two. And I'll do a PR for one and then think deep up part two. Does that sound fair to everybody? Okay. I'm going to take silence as consent. Cool. Okay. Thank you. Um, anything else. PR issue related people want to talk about. Okay. Any of the topics that all people want to bring up since we're at the end of the agenda. Oh, Hey, great. I had, uh, with respect to the issues. Um, I'll paste it in. Yeah. So, um, Wait, where'd you paste it? In the doc. Oh, sorry. Um, Yes. So. I was wondering, and maybe this is a good forum. Um, So as the spec evolves. Uh, past 1.0. Um, I was wondering if there's a good. Place for like a change log or. Or some significant updates that. Folks will need to know about. Um, As the spec evolves. Hey, I think I've got an issue somewhere. I'll, I'll find it and paste the link in the chat. Uh, of exactly that. Um, I was trying to chase a while ago the differences between 0.3 and 1.0. Um, So it may well be that we want to elide those two issues, but yes, plus one for the idea of some kind of change log. Um, that's ideally semantic between versions rather than having to read all the different. I don't want to have to read 30 different commits to tell the difference between 1.0 is 0 and 1.01. Yeah. Thanks for bringing this back up. You're right. I stepped off my radar. So basically, I want to make sure and determine what you guys ask for. You're basically saying.  You want something that someone basically calls through the list and says, these are really the things you guys got up. You as a reader need to pay attention to. Right. Because these are the big ones. Is that what you're looking for? Yeah.  Um, that will be a non-breaking change. So what you're looking for is to be able to see like, see those small features. And you'll not have to come through the, the huge list of PRs and descriptions. Okay, I'm going to jump all over this statement. But no, I did get to it six days later. The next comment is this is the community thing. Now, ideally, um, went along. Ideally, in a proper change log, these would be links to the relevant commits, etc. But this is the sort of list that I would find much more useful than just the list of commits. Okay. Grant, with something like this, I assume with links from here to the actual PRs themselves or issues, would this satisfy your concern, Grant? Yeah. Well, I think it'd be nice to see cat's eyes by added fields and change descriptions or something. I'm just thinking over the course of a year, folks will want to know what's changed. I built my cloud service to handle 1.0 events. Are there new fields I need to take care of for 1.3 events? Right. Okay. So it sounds like this is the list. This is good with links, with groupings or categories. Yeah. Okay. John, would you be willing to turn this into a PR? To be honest, no, given that I have two existing action items that I haven't managed to get to in the last week beyond, I was going to say on the HTTP header action item I have from last week, I have made some progress on an internal doc enumerating some options. It's just not ready for public consumption yet. But while I'm already drowning under things I have promised to commit to, I don't want to commit to anything else. But if somebody else wants to take that list and please validate it, because this was half a year ago when I knew less about cloud events than I do now and I'm still a novice, if anyone else wants to take that list and create a PR, I'm certainly not going to feel, hey, that was my work. Right. Okay. Sorry, my brain went frozen there for a second. Grant, would you be willing to do this? Perhaps I can help and bring something up next time. I'm going to come and get up this year at least. Okay. I agree, because I think everybody's swamped. And I don't think there's any disagreement that this obviously would be useful to do. It's just a matter of time and time to do it. What I think would might be useful though is going forward, we may want to consider changing our process such that as we approve PRs to ask ourselves, is this change worthy of adding something to release notes kind of a thing? Because that's typically what people do for open source, right? For this PR, so we change the release notes. I think that's kind of what you're looking for here, Grant. Yeah. Big ticket items, right? Okay, go ahead. Yeah. One comment around that. I think it would be useful if, so just looking at the commits for the spec, maybe it would be useful to have the semantic conventional commits where you say if something's a feature or docs. Looks like, yeah, Lance has some conventional commits. But we don't serve enforces, so maybe you want more emerging PRs in the future. Yeah. Yeah. Basically, I think we're in agreement. I think there are some process changes we can look at doing going forward to make it easier. Oh my gosh, we're doing a release and now someone has to do the legwork of going back and scanning every single PR that we merged. We'll do it as we go along, so it's less painful. Yeah. I think that's a process change that I can look at doing, coming up with the proposal for how to handle that. You just need someone to go through the current list of 1.0 things. Are we in agreement like that adding a new change log file with this, like a new file? Yeah, I think that's fine. Yeah. Okay. So it's like I create a PR for that? Yeah. That's what I was looking for. That'd be great. Yes. Because it doesn't have to be in the, obviously putting something like that into the release notes itself is interesting, but I don't think most people look at the release notes. I agree with that. I think people will look for a change log file. Okay. Yeah, I can create a PR and you can work there. That'd be cool. Thank you very much, Grant. And John, for going through this effort too. I appreciate that. And I apologize if this one just completely dropped off my radar. That's fine. I would say this list of differences was done by taking the 0.3 spec and the 1.0 spec and just diffing them. So it may well not map cleanly to PRs or commits, because the same section may have changed multiple times, for example. That's more to Grant if he were expecting to find corresponding commits than anyone else. And it may well be that maybe this bit of change log from 0.3 to 1.0 0 doesn't end up having links because it would just take too long to work them all out. And I think that that's okay as well. It would be good if we could have links moving forward. Yep. I would agree. Cool. All right. Good discussion. Okay, good. I just wanted to say that we do have some automation around stuff like this in the JavaScript SDK that we might want to look at for some sort of ideas about how to format commits and automate some of the things like the actual release processes and versioning and stuff like that and generating the change logs automatically. Yep. Okay. I'll take a look at that. Thank you, Lance. All right. Anything else on this topic people want to bring up? All right. Any of the topics at all people want to bring up in the whole seven minutes left? All right. In that case, here's the list of people I have that I miss anybody. I think I got everybody. All right. In that case, let me just double check. I'm pretty sure. Yeah, we still have nothing on the agenda for the SDK calls. I think there will be no SDK call today. And last chance, anything people want to bring up for return? All right. In that case, thank you, everybody. Another good call. We'll talk again next week. Bye, everybody. Bye. Bye. Bye.