 Good morning. Let me just get set up here. I have a quick question for you. I'm switching companies. How do I do that with CNCF or lead this group in terms of affiliation? Basically, from my perspective, it just tell me and I'll switch it. I'll just move you in the spreadsheet and it's about it. Okay. Do you just send me an email or is that how? Yeah, email or Slack or just something. Okay. All right. I'll do that afterwards. Cool. Thank you. Yeah. And the interop stuff. We're doing demos at the end of the month. Is that right? We are hoping. Okay. I have next week off. So I'm actually going to take a few days and just try to plug it through and get something set up. I just wanted to double check my timing in terms of where things are going to be set up. Awesome. Let's see. Yeah. End of March. And then hopefully maybe I could come. I'll see how a demo or we're going to start in the March. So yeah, you're right. Okay. Perfect. That works out. Thank you. That'd be exciting. I know everybody has been wanting to find time to do stuff. It just nobody seems to be able to find it. So. Well, I have a week off. So it gives me some time to get caught up again. And it's fun. It's actually kind of fun in a lot of ways. So I missed doing it. Yeah, that'd be good. I apologize, David. I can't remember where do you work right now? I work for Splunk. And where are you going to? Are you allowed to say a company called Sentinel one? What did they do? And I sure have heard of them. Cyber security endpoint. Most of the work, most of the work is actually in serverless space. Oh, cool. But they do endpoint security, mostly cloud focused serverless, all their apps are serverless. So when I go there, one of the things that I don't start for another week and a half or so, that we'll end up doing is trying to roll over into doing the integration with this project. Excellent. That sounds cool. I'm hoping so. I've never actually done it because I've worked for IBM since I came out of college, but I can imagine the prospect of switching companies. It's like, it can actually go in both ways. It could be really, really exciting if you want to get the hell out of there, or it could be really, really scary. It's both. I've been at several different companies and each place I've been at. The culture, how they operate things is completely different. And you experienced both. To be honest, some cases it's like, wow, I love it. This is the best thing I've ever done. In other cases, it's you're like, what? You know, what did I miss? You know, I don't want to see how I missed this beforehand and it really depends. So, you know, it's and IBM, that's a long time, by the way. It is a very long time. Yes. I won't tell you exactly how many, but yes, it's been a while. All right. Let's see who's on. Eric, are you there? Eric. I think you haven't told with your mic. Yo, Tommy. Yo. Uh, Lucas. Here. Hello. And ginger. Sorry. Couldn't get my mute button fast enough. Hey, Eric, is your mic fixed yet? It should be. Yeah, there we go. Okay. Okay. Okay. In case I decided to try to make you a speak up on the call. I tried reading through your latest. Comment on that issue you opened, Eric. Last night. I unfortunately, I couldn't make it through at all. I had to say it for another day. That was a big comment. Maybe we don't have. Today. Well, actually, I didn't add it to the agenda, but if you want me to, I can, you know, No, I think you are a wise man. Well, I was also really, really tired. It was late at night. Don't, don't, don't read too much into that. All right. How are you there? Yep. All right. Hey, John. Thanks for making it. Yeah. The other Lucas. Hey, Lucas. Hey. Hey, Timur. Hello. Oh, hey, Clemens. I saw you pushing the stuff today. That was pretty exciting. Yes, I did. I went and dealt with the, with all of my very, very longstanding AIs. But which means I haven't done anything on the newer AIs, but such as life. Yeah. So I was preparing for the meeting yesterday. I went through and found some issues that I thought were. Worthy of discussion. Obviously, this was just my take on it. If anybody on the call has a different set of issues, they'd like to add the list. Just let me know. We can add them before or after in the middle. It doesn't matter where they go, but I don't want you guys to think that you're stuck talking about the ones that I thought were interesting. I just didn't want to have it be too short of a phone call. Lance, you're there. Yes. Hello, I'm here. Hey. So while we're waiting, I know Clemens felt nagged sufficiently since he was working on his stuff. Lance, any chance of you fixing up that one PR that you have outstanding. No, every week, I think, oh, I need to do that. To do it. So I'm writing it down in my little notebook right now. All right. Oh, in the notebook. Okay. All right. I did my job. I nagged. Okay. Hey, Manuel. Hi. Hey. All right. For a minute, then we'll get started. Somebody came flying in. Who was that? Oh, no. Daniel. Hello. Hello. Come on. Hi. Who's that? Oh, Christoph. Hey. Hey. All right. Three after when we go and get started. Just let you know, I know last week we talked about what to do about the whole branch get up situation. And I didn't hear any objections. To doing Clemens suggestion of just merging everything into 101 branch. As long as they're, you know, strictly typos type stuff. And Lance, I did see your comments and my, I interpreted your comments. Is basically saying. That's fine. Just let's make sure we document it. Did I interpret that correctly? Yeah, I think so. I mean, we just, I think there should just be some guidelines on what is minor and can just go in and what, what is it? Yeah. Okay. Okay. Well, I took from that to give myself another AI to open up a PR to update our. Process docket or whatever it is to make sure we include that. And I'll try to include in there the definition of, you know, what's worthy of being merchant that versus forcing us to go to 102. Okay. And then you guys can review that. The barring that I will later today go ahead and merge the PR that caused me to think about this, which is strictly a typographical type change. Okay. Community time anything from the community people want to bring up. All right. In that case, SDK call will be next week. This week we have interrupt call. I'll double check. I don't think they have anything on the agenda. So I suspect it's more just a nagging reminder to everybody. To work on their code. I guess we don't even have an agenda thing in here, but we will at least have like a one minute phone call after this one to see if there's anybody has any topics they'd like to bring up. So hang on for that if you're interested and just a little reminder of what we're going to do. Okay. And the end of March is when we're planning on starting the interrupt and we are already in March. So. The pressure is on all of us. Okay. And a team were offline reported. He has nothing to report for the workflow stuff. So we can keep going. Unless anybody has any questions on that. Okay. Coupe County EU. I got a note. I believe last week asking what we want to do. At Coupe County EU relative to office hours or booth or both. And I'm inclined to go more for office hours. Cause I'm not sure we have people have the free time to hang out at a booth for extended periods of time, but I wanted to ask the group what you guys thought. Any opinions at all? Okay. Any objection then with me going with just office hours. And then we can figure out the scheduling of that later. Not hearing objection. We'll go for that. Okay. Before we jump into the meat of the agenda, meaning PRs and issues, any other topic people want to bring up in that case? Let's get into it. All right. So this one technically affects the SDK folks more than anybody else. However, I did want to draw it to people's attention. In case somebody else is interested. Somebody ping me offline. And I said they were thinking about offering up code for another SDK. And of course that's great. But then I realized that we didn't really have anything in our governance stock to describe the process for adding new SDKs because it seemed reasonable to me that if the SDK maintainers have the authority to vote on when to archive a project, when to get rid of it or make changes, they should actually have a say in adding new ones as opposed to just blindly accepting everything that comes, comes our way. So I just added a new section here that basically says the maintainers get to vote on it. It's a one week vote. At least two thirds of them have to approve it, which is the same bar as all the other votes they have, and all SDK maintainers get to vote. Basically it's the same pattern as all the other votes they have. Okay. Is there an implication, sorry, that the list of initial maintainers on 918, that they become new maintainers? I have to admit this is something, I should have read this document a lot being an SDK maintainer, but I haven't. So it may be covered from 934 onwards already, but it feels like if a new SDK is typically because you've got some new folks coming in saying, hey, we've done this thing that we would like to contribute, then they should probably become new maintainers at the same time. Yeah, that was what I kind of implied by this. If you think there's a different wording here that makes it more clear, go ahead and suggest it. I don't mind changing that, but that's what I implied. Just checking that I'd interpreted it correctly. Yeah, but if you think it's unclear, I'll think about it offline and see if I can come up with a better wording, but that was my intent, yes. Okay. Now we don't, I mean, obviously you guys, if anybody on this call here has a problem with this, speak up now or comment on the issue. But like I said, this was mainly for the SDK folks to review and vote on, but just wanted to bring it to people's attention. Okay. Any other questions or comments or concerns about this? So Doug, since I brought this up to you, we were intending to not open source the library and then move it, but go direct to cloud events, you know, just for ease of making it open source and just doing it once. There's nothing here that implies that there's a review of the SDK. So I wanted to just beg that question to the group to see whether there is a need for that initial review of it before a vote is taken because you don't explicitly state that. That's true. And just to be clear, you're talking about, they might, you may want to have them review the code itself to see whether it's worthy. Well, again, I'm taking a step back from my selfish wanting to open source this SDK, you know, I have to think about, is that a requirement or is it not a requirement? Yeah. So I'll let others pick up, but my take on it is, I don't think it should be a requirement because technically someone can come here with no code at all and say, hey, I want to do a C1, right? And the SDK maintainers should be able to say yes or no. And if they say yes, it's perfectly acceptable for them to start with a clean slate and they're the only maintainers. So they should be able to add whatever they want at that point. So it seems weird that if you're coming with code, we're going to raise the bar and say, no, we're going to review your code first as opposed to somebody who has no code who gets a low bar of just, hey, that sounds like a good idea. Yeah, that's a good point. But that's just my idea. Anybody else want to chime in on Mark's point? Okay. In that case, obviously, like I said, just going to review it for anybody has a chance. I believe the voting period for this will end. Closes on Monday, 3.30 Eastern. So if you are a maintainer, please vote on this because we need at least two thirds of the people. I said, no, I'm sorry. We don't need two thirds of the maintainers to vote, but we do need at least hopefully more than just one person, which I think is Scott right now. So, okay. There are some questions in chat. Oh, and here we go. Anybody in SDK team want to try to answer those? I can speak, but I'm an SDK maintainer or even developer. So I, like my opinion doesn't matter. Scott. I would be astonished if there were currently any sort of organized release around, you know, lots of languages releasing at the same time. Until we've got something past 1.0, it's going to be hard to know, you know, what would be in a 1.1, what would be in a 2.0, they're going to, that will affect how releases need to happen. Because until we hit 1.0, it sort of didn't matter as much. So I think we'll probably need to define this more as we go along, but I'm unaware of anything organized at the moment. Yeah, I think the answer to the first one is no, we don't have it. Every SDK does their own thing. And dealing with things being behind, it depends on how what the behind means, right? Are they just slow? We don't have anything to talk about that. If they're basically appear to be dead, we do have a process in this SDK governance talk that talks about archiving projects or projects that become stale and shifting maintainers to someone else if someone wants to take it over that kind of stuff. We do have some governance around that, but if they're just slow, we don't have anything for that. Okay. I was going to say they're, you know, it's best effort. It's all open source. It's not like these are products. This is all, you know, on people's own time or managing their company time on open source pieces. So it's best effort. All right. Anything else about the SDK change? All right. Moving forward. Slinky, are you on? No, he's not. I did notice that there's a whole bunch of activity going on there. And in fact, I know there was some discussions even today. So I suspect it's not ready to merge. But without slinking on, I can't know for sure. But does anybody have any comments or questions on here? Um, could I think. If by next Thursday, if the amount of changes that have gone in, I've trick had slowed down to a very slow trickle or even stopped. I'm inclined to merge it and say that's the first rough draft. And then we can iterate on it going forward. Does anybody see any concern with that as a high level plan? That seems reasonable. Okay. Thank you. Yeah, I think that's a good question. Yeah. I think it's fine. I think it's fine. So it's nothing is fine. Since nothing is final until we declare. A version. I think it's okay. Yeah. My bar on this kind of thing is, is it more right than wrong? So. Yeah. And this is just an extension. Well, technically an extension and optional thing. Yeah. Anybody else want to chime in? Okay. In that case. Let's move on then. I don't know what this one was. Oh, yes. Was this Cedric. So here I'll let you, let you read the question. Okay. So there was a little bit of discussion about this. And I believe you don't have time to read all of it here, but I believe most people seem to be leaning towards saying. That the answer is to use the type field. And not the schema field. I wanted, but I wanted to get the opinion of the group here. In terms of whether that's the right solution or not. Because I'm sorry, go ahead. A lot of the comments there are mine. And I'm somewhat nervous that I may have biased the conversation too much. But my thinking is that the schema URL is something that you consume. Whereas the type is something you're likely to use when you're subscribing. So you could say, I want to subscribe to V1 or subscribe to V2. But you, you're unlikely to say, I want to subscribe to this schema. So if you're going to support both V1 and V2 at the same time, it makes sense for that to be in the type so that the consumer can choose which version they get. Whereas if you're just forcing everyone to keep up with you, then maybe schema URL makes more sense. Does that chime with how other people think about things? I think that's actually very much aligned with that comment I made at the bottom there, right? Because I think it's something similar where I said, you know, basically if you want to support V1 and V2, then I agree with you. The person should choose which type they want to get. But that's not to say you couldn't always keep a static type and change your schema because at that, because you're going to force everybody to change over at that exact moment in time. You're not supporting multiple versions. Yeah. I think from a semantics versioning model, I think if you have a breaking change in the data, then you need to have a way to distinguish that at the subscription level. But if you're just evolving, like if you're starting to add more and more information to the payload without breaking the semantics of what you're delivering, then sticking with the existing version of the event type may make sense. So I think if you really have a new payload where you just make changes, then indicating knowledge about wanting that new payload with the type that will make sense. So I think it's both. Yeah. I guess the real question for me is, and this is good, it sounds like we're all kind of heading the same general direction. The question is, does anybody think we need to provide guidance in the primer? Or do you think it's obvious that we don't need to do it? And Cedric is just more of a one-off question kind of a thing. I personally, I would say guidance would be useful. If we provide guidance, we're likely to get roughly consistent behavior across many providers. If we don't, I suspect it will be like rest URLs and things where there are as many different versioning schemes as there are providers. Yeah. Guidance never hurts. Well, and it's not normative. And so therefore everybody can have their own variations of it, but sending most people into a direction who have no concept of what they should do here, that certainly makes sense. Yeah, okay. I agree. I just want to make sure I wasn't alone in that. I think that's the spirit of no good digos on punish. John, I'm wondering since you did speak up on this one a lot, would you be willing to take a pass at trying to create a PR for the primary? I will take an action item to try to do it. Like probably everyone else on the school, I have many, many things on, but not least I've got ECMA C sharp stuff. Standardization is fun. I will see what I can do. Yeah. Thank you very much. I appreciate that. I'm taking some notes here. All right. Cool. Thank you very much for that. All right. Good discussion. Okay. This one. I'll let everybody read the question. And there were two comments here. John, you spoke up on this one as well. Your comment made sense to me, but I did ping Jim offline asking him to double check since he was the main author of the latest version of the proto spec. Does everybody else concur that basically I think you're saying John, no change needed. Yes, indeed. I'm actually hoping to implement a proto buff event formata in the C sharp SDK as a separate package fairly soon, mostly to sort of prove that our event formata abstraction is appropriate. So I have looked at the proto quite recently and thought, yeah, that all makes sense. Okay. Cool. Anybody disagree with John there that everything's okay as is. Okay. In that case, I will go ahead and close that one later. I don't need to do it now. Oops. Can't type. All right. Cool. Thank you. All right, John, would you like to introduce this one? You've been busy. Yes. Sorry. I didn't intend to make this meeting all about me. That's okay. It's all good. So I've been busily at work on a new major version of the C sharp SDK. And so kind of revisiting quite a lot of the decisions and implementation bits. And part of that is HTTP headers. And so I've been looking at the spec and trying to work out if I'm going to be absolutely rigorous. I want to be spot on with the spec. And I found I, I couldn't understand it clearly enough to know what to expect. So I guess the simplest question is about halfway down that comment. If you've got an attribute value of that XYZ colon ABC, what would that look like in an HTTP header? Should the colons and slashes be escaped or not? You know, if they were being deemed as URIs, then maybe the first colon wouldn't be and other ones might be. I'm not entirely sure. We have a mismatch because the URI RFC 3986 talks about this bit of the URI needs encoding. This bit doesn't. We don't have URIs, not always at least. So we need to work out. I would love it if we could work out something that would be backwardly compatible. And that's going to be hard. But also really, really clear with good conformance test testing, if you have an attribute value of X, it should end up in an encoded form of Y. And I'm okay for that to sort of then leave RFC 7230, which I also find hard to understand, but that's the RFC's problem, not ours. So that everyone can hopefully do the same thing, encode the same way, decode the same way. Yeah. Do they have any questions about the issue that he's raising first? Yeah. So what are the attribute values that you're showing here? What attribute would that be in? What is that typed? Well, so this would be presumably a string attribute. Doug, if you follow the HTTP, yeah, follow that link and it'll be a bit clearer because it says the HTTP value is constructed from the respective attribute types, canonical string representation. So you convert to a string first. Yeah. You do encoding. So I would hope that how you encode wouldn't depend on the attribute type. But a URI is, so we have a URI type or URI reference type. And I think we use that specifically for cases where we knew that there would be a URI there and that it needs to have URI treatment. But that doesn't have URI treatment particularly in terms of encoding it as a header. If we can find something that says I will take arbitrary string that doesn't have control characters, bad surrogate pairs, et cetera and encode this appropriately as a header in a way that's reversible and ideally doesn't make URIs look completely weird. It doesn't start encoding slashes and colons. Then we don't need to give special, well, if you're encoding an HTTP header and the original attribute was a string, then you do X. If it used to be a URI, then you do Y. And it would be particularly weird. Suppose you had, is subject to string? I think it is. If you had to, suppose someone decided to make the source and subject the same string. So one is URI, one is just a string. If those came out differently in headers, I would personally think that would be a bit odd. Okay. I was just checking to see which things are strings. I think type is probably the most common string aside from ID. So let's focus on type, since type can basically be anything you want. And extension attributes come here as well. So any questions for us just about the concept of what we're focusing on before we start talking about possible next steps? Okay. I'm going to say Clemens' grunt is no. Okay. So John, are you proposing that we scrap the RFC 3986 encoding rules and create our own? Yes. Which makes me as nervous as it probably makes everyone else on the call. I want to come up with something that is better defined than you, them referring to that, but still backwardly compatible with what people have been doing already, ideally. Okay. Yeah, I mean the grunt, so let's go back to the HTTP protocol binding spec. So the motivation is in the second paragraph there. I completely agree that we need to do encoding and I'm happy enough with percent encoding and thrilled that we've got this string. I'm not sure whether we are specifically saying percent encoding via UTF-8, but let's assume that we are doing that. Then I completely agree with all of that. It's not clear to me when trying to write code for I've got this string that can contain any arbitrary, nearly any arbitrary unicode content, what do I encode? This section three was not obvious to me what the code that I should write should look like and trying to use various built-in library functions such as URL encoding. If I said encode the data, it did one wrong thing. If I said encode the whole thing, it did something else wrong and fundamentally because what we're looking at isn't necessarily a URI. So the URIs are a special case where we care about the URI so being a URI when you have it in the HDP header, arguably. Jennifer made a comment in the chat. You should always feel entitled to speak up. Jennifer, you want to chime in verbally? I was looking for the unmute. I'm not saying just completely create our own but maybe it's just forking and being more clear about it. Does that have the same feels as completely creating our own rules? Yeah. I think that is better than creating completely new rules, certainly. And maybe it is because we do percent encoding but we're not doing that for the URI character set. Is it URI character set or is it the printable U.S. ASCII character set? Yes, maybe that. We know that we do need to encode percent because otherwise we can't. We decided the only things we need to encode are percent and anything non-ASCII. That would be a perfectly good starting point. I wonder how that fits in with existing implementations. If things are expecting other characters to be encoded and this was where my ignorance meant that I wasn't proposing anything specific. That doesn't sound like what you just said sounds unreasonable. It doesn't sound like an earth-shaking new invention. I'm wondering whether anybody has somewhere already invented that before. It might be interesting to go and hunt around in the relevance related to our seas when there's a coding like that. Regardless of that I'm more interested in John's other comment about current implementations and whether if we change something it's going to break something. Did any of you guys notice this paragraph? Who does any encoding at all? Or was John just being incredibly anal? It was when I was fixing things that it came. We do have tests for non-ASCII characters in attributes. It was when I started encoding everything with some URL encoding at which point those tests still passed but the tests that expected URIs to stay unchanged failed. I want to focus on Slinky and Scott's comment in the chat. Can you elaborate on what you mean by it just works or it handles it? Does that mean it does encoding or it doesn't seem to be bothered by non-ASCII characters? We don't care. It just works. When you receive it on the other side you see the same thing you said. Do you know what the library does with non-printable characters? I honestly don't. I don't know the internals of the library but at least with all the SDKs I worked with I never found such a problem because the library handles all of this. Even in Rust strings are the same. I guess this is all already encoded as it should by default. Would somebody we want to check and test out a couple of the SDKs to see what they do if you try to give it a non-printable character and see what it does? Does it skip it? Does it encode it? That sort of thing. Typically if a header has multiple values they are comma separated which means if you want to have a single value that contains a comma you need to put double quotes around it and stuff. That's where I think a conformance test of how does a value of space X space get and does it get correctly decoded? What if you have a comma in there as well as unicode? I did a quick test just for fun, just curl and I gave it a header with the value of comma, comma, comma it just passes it through. That could mean the curl is too low level and it's not going to try to encode it. At least from a curl perspective it doesn't touch it. It's not going to try to decode the values. Just another data point. For the Ruby SDK we actually did have to implement this explicitly and I do remember going through the process of puzzling out what these paragraphs mean and going through several iterations of not understanding that before. I think it's quote-unquote correct or at least reasonable now but it's been a little while since I remember it being confusing. So what did you do with things like colon? So yes, I believe I'm looking at my code right now I believe it was percent and printable ASCII or passing through printable ASCII that's not percent and percent encoding the rest. So you did encode the colon? Yes, colon. What's the ASCII code for colon? I don't know. I don't know. I'm not sure what the ASCII code is for that either. But other differences because of the whole multiple values thing. I I I'm not I don't think we're handling colon or commas any differently from any other type. I think it's also entirely feasible that HTTP libraries may handle commas and quoted strings and things for us but I don't think they will handle the percent encoding because as far as I'm aware that's not part of HTTP. Yeah. So comma I think is 44 decimal that helps you. Okay. So I'm curious about the next steps here. It sounds like we have at least one SDK that actually did try to follow these rules. So I'd be curious to know what the other ones do. However, I think it also may be worthwhile to get a proposal for what this I guess is what Jennifer said is, you know, forking and clarifying a proposal would look like, right? The general idea of encode percent and anything nonusky then reluctant as I am to take on a second action item. I can work with Daniel and we can check the line and our understanding of the RFC and see. It may be that actually an explanatory paragraph explaining how to read RFC 7233 in this case maybe that's all that's required. It might also be worth saying that when decoding HTTP headers implementations should probably percent decode everything and expect that some implementations may encode more than they need to. Yeah. Yeah, I think my headline that way too. Okay, so I think so the actions here are thank you Scott. Talk with Daniel. Hi Daniel. I'm very happy to get together with him and talk this through. So Scott is saying that he can send headers with emojis in Go. That is right, you will send headers that end up being bits on the wire that will then also decode writes if you're lucky on the other side but you're still violating the protocol rules. Unless it is performing some kind of encoding that you see that I'm not aware of or is sort of doing an encoding and assuming that things will do the same thing. Yeah, I mean there's a, it's seven bit ASCII that's what's allowed in the headers and the fact that we are putting eight bit ASCII into those headers practically is still not making it valid. I am mistaken. I was making sure that our UTF-8 encoding for the character set for data encoding for the payload worked out. So we're not putting an emoji in the header. It would be a fun test though, let's see what happens. That's the tragic with that rule. I'm pretty sure that these days you can literally go and send HTTP headers that have emojis and it will work on most stacks because people just don't think about the constraints or at least in some of those stacks. So maybe that seven bit ASCII rule is something that is just loosely enforced and that's why some of that stuff just works. I don't think it's going to work. I don't think it's going to work. I don't think it's going to work out. So anything from the upper section of ASCII then or at the NC strings that will largely just work but it's still illegal. I believe having recently been reading this I believe it's a little weird. I think we've got better at writing RFCs than we were back then. Yeah, that's true. I believe the net of this is John and Daniel go off and talk and hopefully come back with a proposal or something. Does that sound fair? Any other comments about this one then before we move on? Just thank you for indulging me. As long as the data point for the node we don't do any real parsing at all. We'll throw if it's not a string or something that can be converted to JSON. Good to know. Thank you. Any other comments? John, never apologize for doing work. It's all good. Okay, this one I thought was interesting. And Jim's not even here. I'll let everybody read it. So this one and this one I think are related. That's why I put them both in the agenda. What should a client do if an entry vanishes from the discovery get response? Okay. And obviously Jim's question is broader than that. But I think the question I had for the group here is do we want to go beyond saying what happens when something vanishes? But I'm going to actually propose that we interpret a vanish from a get meaning it's been deleted. So there is no notion of deprecation or anything like that. Or do we want to go as far as what Jim is proposing, which is actually have real life cycle type values associated with the things. So is it Boolean or multi steps in terms of removing stuff? I guess it's the question. I want to open that up for discussion. No one has any opinion? Okay, I'll put one out there. I'm inclined to close Jim's while it's an interesting thing. I think it adds complication to the spec. I would rather just have it vanish if it gets deleted. So it's either they are not there. And keep it simple. You came off mute. Oh, okay. Yeah, I agree with you. And to elaborate a little more. I think part of the reason I think that is because I think the many you start getting into this stuff, you're going to get into really complicated things like, okay, well, how long does that be retired for or deprecated for? And then you have to have time stamps and all this other stuff. And it just, it just seems like it's more told than it's worth. And I think actually, you could also add this stuff later, because I think until something actually vanishes, the fact that you may have a state or something like that, that we add later on still implies that it's there. So you could technically use it. It's just, it's just not recommended. I think is the way I would interpret it. So it's that I don't think it'd be backwards compatible to add. Some sort of deprecation state later if you wanted to. But anyway, class your hands up. Yeah, actually, I agree too. I think it's, there will be a lot of variations. What this very abstract concept of a service maps to in the specific environments. And so this life cycle will also most likely be handled differently in those environments that would make it really hard to handle it here. Okay. Anybody else want to chime in? So I, this may be totally weird to think about, but I. What if it doesn't. What if it's an accident that it doesn't exist? So what if you do a follow up get, and then it is there. So what, what is that handled separately? I kind of like that there's a state of the service. So if there's an explicit. Sort of this is going away versus it's. It's like, it just disappeared. Your first question is interesting to me because I think that my phone is the same category as, well, what happens if someone fat fingered, you know, a URL or one of the other values. And maybe an hour later, they realized it until they changed the back. It's me, it's the same kind of thing there. It's just. You sent bad data. You know, and I'm not sure we necessarily need to go out of our way to protect, to babysit people. Right. So if someone accidentally deletes a service and then, oh, realized they made a mistake and resurrects it an hour later. They may have hurt their clients, but that's what they did. Right. They, they changed the data. I don't know. I mean, Jennifer, is that, is that too simplistic? I don't know. I, that might, that might, that might be sufficient to say it, but I feel like I, there's always these cases. There's always these cases that are like on the edges of like, well, it's not supposed to do that. And so then I try to think of like, well, it's less about protecting us from making mistakes, but more like being explicit about. How things should work in the case of. Uncertainty. And so, I mean, I mean, maybe it doesn't matter. So maybe. I don't know. Like I just, I think of it from a QA perspective as well from like just like weird shit happening. And it's just explicit. So I like the idea of there's a life cycle of a service explicitly. So let's, let's poke on that a little. How far would you want to take this? Meaning. I mean, are you proposing that people are not allowed to just make it vanish and delete it immediately? Are they therefore required to go through a deprecation stage? Yeah, I think that's that, that's the, that, that you're right. That is kind of what I'm saying. I think that's a good way to put it. A little bit like, do you just delete a page from the internet or do you put a redirect in place to say, oh, well, I know where you meant to go. I'm going to be helpful. We don't necessarily need to require stuff in order to say, it would be a nice idea and to provide some part of the protocol to be able to say, please don't come here again, or it's gone over there or whatever. Clemens, did you want to say something? You came off mute. Yeah, that was not a completely formed thought when I was unmuted. So I'll shut up. Okay. Jennifer, it's interesting. I'm just obviously just my two cents, but I'm less inclined to force a deprecated state or into enforce a state system, but I can be sold on the idea of including an optional attribute that has something, Samantha's long lines of, by the way, this is going to be removed at this date. And people can optionally set it if they want to give a warning to people, but that's, that's not quite the same thing as an entire life cycle to me. Does that make any sense? I, I like, I have been convinced now having heard John's sort of way of thinking of it of like, oh yeah, like we could make it an optional thing. And then it's more of something that you could, we could have a recommended practice and then it makes it more, like people can be more explicit or not. So I, I feel like that's where I'm at right now in terms of thinking about it. Sounds great. Yeah, but we elaborate a little when you say optional, what's optional, the entire life cycle or just one attribute that says something. So what, what are the, an optional state? Like if you have the ability to have this optional state where you can add sort of the context that then people, you can for your own service that you're defining, you are able to set that and be explicit about it. And if we have some way, like, I keep thinking of like, here's the spec and then here's the implementation and like, or sample implementation and recommendation that, that feels like it's a space where people can leverage different styles, just like not some people just delete pages and so providing redirects. That's why I really like John's way of speaking about it. Okay. I'm so sorry, John. He was shocked that you actually listened to him. Okay. Anybody else want to chime in? Okay. John Mitchell. Yeah. So I guess. With all worries about sucking up to Doug. I actually like where you were headed with your comment, Doug. The fact that it's, you can add extra information into some kind of attribute to give people a heads up that they can look at. Cause the, the, the problem with making this too explicit is. The, the, the failure modes around things vanishing, whether it's a, you know, a transient fluttering of the service coming up and down for whatever reasons, like the fat finger examples or whatever, they, like all of those are still going to happen, even if you somehow mandate an explicit life cycle. Right. So the, the code pass for people who actually care about. The higher quality of service implementations, giving them a heads up and managing, you know, deprecation periods and all those cool things. Like, and, and trying to make that completely. Discoverable automatically, rather than out of band human things. You still have to deal with those cases where it just goes away. Right. So the extra complexity. In band. It doesn't actually buy much in terms of. In practice reality dealing with failure. Or at least all of the failure. That makes sense. Jennifer, any reaction to that? It is the, is the culture of not responding. Verbally. Is that, is that okay to be like, ah, that's interesting. Is that. I just want to give you an opportunity to respond. If you had any feedback or want to get into a dialogue about it. That's it. I appreciate it. There's a lot to think about here. Thank you. I mean, I, I'll tell you my personal bias. When I design protocols like this is like, I. It's all about failure modes to me and life cycles. Like, so all of my systems are based on. You know, some form of finite state machines and those kinds of things. So I totally, I totally agree with the, the, the intent that you're talking about. It's just in practice. If, if the, if the hardest failure modes are the ones where it's, it's fluttering and transient. Like I can give all sorts of great examples at, you know, lower network levels where we're literally people take weeks to try and discover some of these problems because they, they didn't make their system resilient. So I agree. I, it just doesn't. If the states don't cover it anyway, there's not much for us to do. Okay. So say, well, let me do this. So I'm not sensing a, a broad consensus yet. And as Jennifer said, she wants to think about it. I think other people need to think about it as well. So there's no decision on here. We'll save this again for next week. And maybe people will do some more thinking about it. But we did have some interesting options mentioned. So let's just pull off on, on making a decision on either this one or the next one. Cause I think. They're both very much related. I think that's a good idea. I think that's a good idea. I think that's a good decision on either this one or the next one. Cause I think they're both very much related. So let's hold off on that. But think about it during the week. And Jennifer, I just so you know, I just get so excited when people speak up. Cause a lot of times people in the group get very quiet on these calls. So I just get excited at somebody chooses to speak up. So you did. And I jumped on it. So I encourage it. So. I didn't mind to pick on you. No, no, no, I did not, I did not perceive it as picking at all. I was just like, I was like, oh, okay. I'm thinking. But I do want to say it like, I'm relatively new to this particular community of folks. I didn't realize it existed until recently. And I just wanted to say it like, it's so fabulous. I love. I've been here, I guess, like three weeks or something. And like the, the style of how you all run the meeting. And it's so collaborative. I really think it's great. So thank you. We got, we got some good folks here. So it's all been good. All right. In that case, anything else on these two topics? As I said, Thank you, Scott. I even if we come with a different system, Scott, I'm going to keep doing roll call just to another crap out of you. Okay. So anything else on these two topics, we move forward. Okay. Oh, Slinky, since you're on the call now, was there anything you wanted to mention about the SQL query expression? Since you weren't here, we didn't really talk much about it other than to say that. I noticed there was some activity today going on. So I thought I might be premature to try to merge it, but that I'm hoping by next week we might be able to merge it because the amount of traffic will slow down and that it's a, it's probably good enough as a first rough draft to go in, but I wanted to give you an opportunity to speak to it. If you wanted to. No, I'm fine with it. Then we could read some comment from a Lino that I want to fix. But that's it. Okay. Yeah, people please resolve conversations. So I know what that's I need to do. Okay. Okay, hold on a minute. I realize I jumped the gun on these notes. Okay. Cool. All right. Are there any other. Of these PRs that we need to talk about slinky, you may have been doing some changes. I mean, I'm sorry, those Clemens. I think Clemens made some changes recently today. Obviously it's too certain to merge, but please people take a look at that when you get a chance, because I think they're going to make some changes recently. All right. Any other topics people want to bring up? All right. In that case, in the five minutes remaining, we'll do Scott's favorite thing. Clemens already talked. Matt, are you there? Yep. All right. And Vlad. I'm here. Hey, Doug. Hey, Vlad and Grant. I'm here. All right. Cool. All right. Did I miss anybody for a roll call? I think I got everybody. All right. In that case, we are done. Actually, there we go. Does anybody have any topic for the discovery interrupt call? Otherwise we'll just say we're done for the day completely. Anybody want to bring anything up? All right. Not hearing anything. All right. Get back an hour or the other day. All right. Thanks everybody for calling or for joining in. It's been a good, good call. Talk to you next week. Thanks, Doug. Okay. Thanks everybody. Cheers. Thank you.