 Dug, dug, dug, dug, dug, morning. Hello. Hey, sir. Hey, sorry, I was on mute, taking a different call, just to get this one set up. How's it going, guys? It is going well. Well, that is good. Yes. It's hard to get back in the swing of things after the nice break between KubeCon and Thanksgiving and everything. Obviously, I'm watching the AWS keynote at the same time. Oh. Anything exciting going on there? Not for me. OK. We're talking about VMs and virtualization stuff, all things that I'm not too, I can't get too excited about this other people problem. Hey, Tommy. Christian. Hey. Good morning. Morning. And hello, Ginger. Yes, I am. Not to back. Yeah, everybody, yes. Roland, are you there? I think I barely heard you in that ground there. Hello, yes, I'm here. There you go. Is this your first time on the call? It doesn't need. OK, do me a favor. Let me paste a link to the minutes. If you can just put your company name next to your name and the agenda just so I can give your company credit for joining, I'd appreciate that. All right. Thank you. And hey, Christoph. Hey. Hey. And John, are you there yet? Morning. If I don't remember, somebody please remind me. I was going to ask if people actually wanted to have a phone call on the 19th. Because I don't know about you guys, but at least within IBM, a lot of people start taking vacation right around the 15th or so, so I don't know how many people are going to have a phone call on the 19th. Because I don't know about you guys, but I don't know how many people are actually going to want to take a phone call on the 19th. I will certainly be on vacation. Yeah, I'm supposed to be, but for you guys, I'd join a call. Wow, that is so nice of you. Yes, yes. I don't know whether it's dedication or insanity or something, but it's something. I know how my wife feels about it, so I'm going to call you out. Well, you guys are all early today. Morning, Eric. And Manuel, are you there? Yes, I know I'm here. Hey, is this your first time on the call? Yes, it is. Okay, great. You know your favor. I'm going to paste a link to the agenda doc into the chat. If you could just add your company name next to your name, just that way you guys can get credit for joining. I'd appreciate that. Sure, thanks. Thank you. And Ryan, are you there? I am, yes. Hey, I know this isn't your first time on the call. I can't remember if I have your company name so say it with your name. I am with Twilio. Okay, that sounds familiar. Okay, got it. I'll break that just in case I forgot. Just one L. Holy cow, my mouse is nowhere to be found. Jeez. Okay, thank you. And let's see, Jim, are you there? Yes, sir. Hello. All right, one more minute until we get started. Mohamed, are you there? Hey, yep, good morning. Good morning. Colin's on a plane too, Doug, so he won't have anything. Okay. Thank you. All right. Klaus, are you there yet? Oh, maybe he got dropped, okay. Anyway, we'll catch him up later. All right, 16 and let's go ahead and get started. Okay, community time. So for those of you who are new to the call, excuse me, it's a time for anybody who's normally not on the call to have a topic that they might want to bring up for discussion for the community to ponder. Is there anything people want to bring up? All right, moving forward then. Just a reminder, we don't have a call December 26 or the second. Does anybody want to have a call December, what is that, 19th? I know a lot of people are going to be on vacation starting around the 15th or so. Do people have a preference for a call or not on the 19th? I'll side with your wife and say no. Thank you. Okay. I'll be off as well. Okay. So is there any objection then to cancel in the 19th? Okay. I'll make a note about that. Thank you guys. And Klaus, I think you're there now. Yes, I'm there. Okay. Can you hear me? Yes, I can. Thank you. Okay. Cool. All right. Moving forward then. I don't have anything to mention other than we do have a call schedule for today. So if you're interested in that part of the discussion, just stick on the call after this one. We'll start basically immediately after this one ends, even if it ends early. Let's see. I don't see Kathy on the call or anybody else from that work group to mention anything. So I don't think there's anything to talk about where that is the workflow. Other than still the work is still going on over there. So if you're interested in that, please join. They are ramping up. What I want to do now is give an opportunity for people to talk a little bit about what happened to coupon. I do have a whole section down here talking about what we're going to work on next. So save those discussions for later. But does anybody want to bring up anything relative to the practitioner summit or the cloud event session that they think might be of interest to the group in general? Nothing. Okay. I'll tell you what I just let you guys know at coupon itself, I was hit up for quite a few press interviews around cloud events. Well, mainly about cloud events, obviously because it reached 1.0, but a lot of them also did then ask about, you know, what's going to happen next with the service working group. And they all seem really generally interested in, and excited by the cloud events. So that was all good. And they're also very much interested in what we're going to work on next with the service working group. And I did let them know what the current thinking was in terms of some of the ideas that we've talked about. But I definitely did not tell them what we're going to work on next because obviously we haven't decided yet, but I just thought I'd let you guys know that there is interest out there, at least from the PR type of people that I talked to, not only in terms of what we've done so far, but in terms of what we're going to work on next, because a lot of them seem to really like what we've done, not just from a straight technical perspective, but in terms of the community aspect, in terms of bringing everybody together. So they seem to think that this was a little bit of a unique occurrence, because while there have been standards work done in the past, or the things, they didn't see it being quite as collaborative and, and non political as this one has been. And hopefully I wasn't lying. You guys feel the same way when I expressed that to them. So they do seem to really like what we're doing here. And they're very eager to see what we work on next and to see if we can keep the good feelings going with all this. I thought that was all kind of nice. But again, one last chance. Anybody else want to bring up anything relative to Kukan, they might, they might give interest. All right, cool. In that case, moving forward. What I wanted to do in the future calls is to make sure that we don't ignore some of the stuff that's going on in cloud events as we work on something new. Is I want to do a little bit of things like issue triage or PR triage if needed. But I'm not obviously going to spend the entire time on it. So I did it. I just picked out three of the newer issues and just to make sure we at least have some owners are going to take a look at it. Clemens, I thought maybe you could take a quick look at this one to talk about AMQ pay since that's in your. Real house. Yeah, so I have an opinion about this. Well, we don't have to enter it now. Just what could you just reply back to him on the call? I will take a look and then we'll voice my opinion in that PR. Okay, because this expired draft has become the proprietary protocol of one particular product. And as such, I think. The similar rules apply as they do for other products of that sort and that we link to spec. That's myself. Okay, cool. And the next one. The person who opened it, he basically said a whole bunch of questions about, about how to use cloud events. And I did my best to try to answer his questions, but there was one outstanding thing that I wanted to get clear for confirmation on from Scott in particular. So Scott, I was wondering if you could at least take a look at the, at the mention of your name in there to see if I got the answer right about K native. If you get a chance. Thank you. And then the last one was somebody wanted to talk about open API for our stuff. And Scott, I know you said you had some experience with the opening API stuff. I was wondering if you could take a look at that one as well. Unless there's someone else on the call who feels like they have enough knowledge in that space to take a look at that one. Can you, can you clarify what the question there is? Which one? The open API one. Oh, I think you just want to know how to write a swagger doc for it, but I'm not 100% sure. I'm going to refresh my memory here. The thing that's funny about that is that it's not going to work for HTTP for both encodings. You're going to have to choose upfront which encoding you're swaggering for. Yeah, I'm not quite sure what you write. I'll see if we actually did that, whether we bothered to or not because it doesn't. It's questionable whether I actually make sense. Okay. Well, if you guys could take a look at that, I'd appreciate it just so you don't feel like this. So this guy doesn't feel like we're ignoring him. Okay. Yeah, I'll have a look and see what we did. Cool. Thank you. And did you raise your hand for a different question or was that it? No, I just forgot to lower it. Okay, that's fine. Cool. Okay. Luckily, we have no PRs review, so that's all good. So now I could jump into the fun stuff. What to work on next. Let's see. I wanted to show something here. So a couple of things. First of all, in terms of the face-to-face meeting and the serverless working group session that we had a coupon, we did take notes and the link to it is in the meeting minutes. It's this link right here. We did take notes in terms of people who are there, brainstorming sessions. To me, the most important thing was once we're ready, we already was done with their sort of brainstorming ideas of what we could possibly work on. We then asked the group, okay, after all these ideas, let's narrow it down to what we actually think is doable and possible to work on, and people could actually get behind. And it basically came down to this list right here, which is, where's it? I don't have it there. Okay. Which is basically this list right here. Now, and this is in the meeting minutes as well. The other thing is, though, at the birds of a feather working group session we had, and here's basically a summary of the notes that I took there. What was interesting to me was a couple of things. First, there seemed to be a split in the room about how important portability and lock-in was. We had some people who thought it was very, very important, and we had some people who thought it wasn't important at all. And people just managed to work around it. So I thought that was kind of interesting because in the past, most people seem to think that interop was actually a really big concern. So it kind of took me back a little to hear that for some reason, but it was not an issue whatsoever. So I thought that was kind of interesting. But the other interesting thing is that in terms of what to work on next, there definitely seemed to be a lot of people leaning towards the discovery and catalog side of things, which was interesting. And in terms of adoption of serverless and functions itself, the general consensus I got from the room was, for newer things, people don't necessarily seem to be having a concern with this. The bigger concern to be seeing the more round things like, you know, how do they get there from where they are today? For example, how would they break up the monolith, not just in containers, but then all the way down to functions? Or they're a little bit nervous about the technology. So they may start with tooling type of stuff or utilities, and not necessarily jump full head, you know, head on into using it for product level code quite yet. So it's a slow progression kind of thing, which makes sense from all perspectives in terms of, you know, slow learning curve. So that was kind of nice to hear. But the biggest thing I think for us is to actually talk about what to work on next. And as I said, I think discovery and catalog was probably the top thing that kept coming up. And a very close second was function signatures. So I think those were sort of the two top things, but let me pause there and see if other people who are cooped on had a different take than my view of it. Nothing. Scott Clemens Klaus, I'm trying to remember who else was there. You guys, I don't know when you want to add anything to that. Oh my God, I didn't pay attention. To what? My question or the entire coupon? Here's the question. I was wondering if you had anything to add to my commentary or summary of what happened to coupon. You are summarizing things well as always. Okay. Okay. In that case, what I'd like to do is this. Okay, I'm not quite sure how to proceed here. I'm sorry. So I'm going to speak up there. Yeah. Can you tell me in one sentence what catalog discovery means? Is that for cloud events or is that for function as a service in general? So I'm going to hand it. I'm going to force someone else to talk here. Scott, I'm going to have you answer that one since this was more your idea than anybody else's at the group on itself anyway. Yeah. So clot catalog. What would we call it? Catalog for producers and consumers. So basically, like think open API, but open API is tied to usually HTTP. So it dictates a certain protocol. You need to speak to that, that producer or that consumer. But what we've done with cloud events is. Kind of reduce the, that dependency on the protocol you choose. So I would like to explore some sort of concept where you can, you can get a catalog of events from a, let's, let's take a producer and says I produce the following conical versions of cloud events. Possibly also says, I can speak on these protocols. So an agnostic way to ask about what, what the shape of the event and what, what does it mean to you to use the extension foo. Where foo is not defined in the cloud event spec, but, but maybe used in your organization. And you're trying to negotiate which foo you actually mean. It's that help Christoph. Yes. Got it. Thank you. I think, I think we had, so we had clustered a few things in the discussion and the three things we cluster together were the idea of, of this catalog. And it is, you know, ask a, and ask a publisher or it's, it's a delegate in form of middleware, what events are available. And then a schema registry, which tells you what the payloads are in those events. I think those things work very well together. And then the subscription API to, now you have discovered how you're going to get at those. Yep. Yeah. And the subscription API kind of requires what, what the shape of the event will be because we would like to filter on only things that are inside the envelope of the cloud event. And so you need to know what the envelope looks like. Yeah. And I think even if you didn't want to be intelligent inside of the inside of the middleware for schema bound encodings, like, I mean, we keep, we keep those out now, but I think Proto is going to be back for schema bounds encodings where you can't even decode the body without having a schema at hand. I think a schema registry will be important, even if the middleware doesn't reason about the payloads. Yeah. And what I like about this direction is that I know in the past, we've talked about subscription API is something possible to work on next. And I think as Scott has pointed out a couple of times that that's all well and good, but without the discovery side of it, it's going to be hard to automate it and write tooling around that stuff. So I think what's really cool about this is, as Clement said, if you can link the discovery of what events are being generated, what their schema is, that goes very nicely with the subscription API definition as well. They all kind of fit together into this sort of attack in the same general problem of how do you get, how do you start asking for the events and what types of events are you going to receive? And it all just seems to fit nicely. And of course, it's also a nice next step for the evolution of cloud events in terms of using the cloud of a metadata that we already find in the next step of your tooling exploration kind of stuff. So I thought it was kind of a nice. Oh, yeah, sorry. I would like to invite people that are involved in that topic to maybe have a sidebar discussion. The reason I bring that up is we have actually got a beta product that is the catalog automatically generates the events. We've actually pushed that into async API, which is a parallel thing to open API except for non-http. And we have code generators that have actually demonstrated internally just this week to our executive branch to generate spring cloud streams applications based on cloud events in the catalog and for some self-discovery. So I'd be interested in some opinions and what we've generated that might help us on the product direction as well. Cool. I don't suppose you have a link to something you could point us to. Do you? Well, I could, but then you'd have to be an employee. Yeah, there you go. But I could actually sometime in the future, if people are interested, post a little demo or a little video if you're interested as well. Okay. That's cool. All right. Any other questions or comments just around the idea of catalog discovery subscription API type stuff? We're looking at basically these two things here. Hey, this is a target. Okay. Yeah, if I can make one comment on the subscription API. So what I, so I basically write a software service API and we would push our events into a middleware. And if they're hosted like, for example, Azure event grid, then our DN consumer would subscribe, should subscribe at the event grid API. And then our API would push the events to the event grid and event grid would route them further. But there's a problem in that if we push all of our events into the event grid, this can be a lot of them. And the end consumer maybe only wants a few of them. So what we end up with is maybe us pushing hundreds or thousands of events and the end consumer only one or two of them. So that's like a huge waste of money. So we could get like a standardized subscription API so that it can be forwarded along multiple hops. Then the first event producer can already know what events to send on. So I would be very interested in this one. Cool. That sounds interesting. I like that. And we have the same problem in Knative. We call the technique upstream filter propagation. It's a very nice name. Yeah, I like that. Who else raised their hand in there? Kimmer, who was trying to speak as well. That was me. This is Ryan. Yeah, I'll just echo that. So we are working on some things that were, we basically need to invent all of these art on our own. So I think that's good validation to focus on these next from, from our side. Cool. Good to hear that. Yeah. So I'm hearing lots of people jumping on board with the idea of the catalog discovery subscription API, that kind of stuff. However, I don't want to assume it. Too much of an answer here. But so let me, let's take a step back for a second and see, are there other ideas that people have either on the list from, you know, the minutes that I'm highlighting here, or just other ideas in general that people think, no, we're missing the boat. This is the next best thing we should be working on instead. And Jim, you're up. So I, I guess the only one that I would add to this list, I mean, I, I think this list is good. Um, is sort of end to end, um, security. So, you know, how you prove non tampering of payloads and, and all that sort of stuff. Yeah. I think that actually did come up during our brainstorm session at the, at the, um, at the face to face. Um, I, I know, I think it's something that we need probably an opinion on, um, whether it needs to be spec to the level of a subscription API or anything like that. I'm not sure. Um, it's more of a pattern, I think initially. So on that one, I'm trying to figure out what you'd like me to, or what you'd like us to do with that. Is that something that you would like to ponder a little bit more to see what that actually means? Or do you want this to actually put, you know, put that on par with the other one and say, you know, we need to choose between the two because this one's just as important. I don't want to railroad it. I mean, I'm, I'm interested if other people think there's a need for that because, you know, if I'm in a extreme minority, which isn't uncommon, by the way, then I'm not going to push it. No. And I apologize. I kind of, I kind of inverted the discussion here. So let me ask anybody else on the call, for example, Clements, I think you made a brought up security at one point as well, but you didn't seem to think it was, it was at the same level of that's what we should work on next. It was just something that was sort of, it was in the hopper of something to consider. So what are the people think on the call it about the insecurity idea? Is it just an interesting idea? Or is it something that no, we actually should consider working on that next. So I think the registries, if we call them that are a bit more important. And so insecurity is something that we can, we can probably tackle next. Now there is a, I think that the pieces that are up to us to pick or to standardize, even if we think about creating an ecosystem, which is backed by interoperable software, that is not so much about the end to end encryption per se. That's an aspect of it, but there we have to go and pick, pick up something that we all can understand, like SMIME or something like this. But then the question is, from an interoperaspective is how do we store the, the crypto material and how do we, how do we share it? So if you go and publish, start publishing events, and you use asymmetric encryption, how do you share your public key? And if you, and because it's asymmetric and because it's, it's pops up, but your keys will be great quicker than they usually would, because you can't negotiate session keys, which means you don't need to be able to roll them, which gets you to the point that you have to have a schedule of keys. So there's, I think there's lots of stuff that is required for, and uniquely required for Reddit flows that calls for having, you know, a common interface to a key vault. And I think that's something that we should go and take a look at more than, than really, you know, figuring out what a new crypto model will be, because ultimately I think SMIME or something like this is, is, is ready to go. But I think having, having, you know, a unified view of a key vault that would be more interesting. I think that's something that we should eventually tackle. But from a priority perspective, I think of the, the subscription and discovery and schema registry as higher priority. Okay. Thank you, Clemens. Eric, your hands up. Yeah, I actually have to say that I effectively agree with everything that Clemens has just said. I was also surprised along with Jim, or he didn't state this, I was surprised that, and then security concerns, signatures, encryption, that kind of stuff hadn't been on the list as something to discuss. So I want to second that as, as something valuable to, to keep up there. I do think that the, I think there's a delivery API that perhaps is separate from a discovery or subscription API that also is, is higher priority than some of the security concerns for this group. Interesting. Okay, hold on a minute. Okay. Oh, just from my own understanding, when you say delivery API, what, what does that encapsulate? Is it, is something like the, the web hook spec that we've already produced falls that category or are you thinking something different? I mean, it would be similar to the web hook spec. I, I, yeah, I mean, if you squinted the subscription API, when you asked to be delivered something inherently, you should then probably also talk about how that will be delivered. But there was a, there was a bit of a, I was, I was envisioning the discovery and subscription as, as kind of developer experience or, you know, although there would be other things. And then the, the delivery API is going to be far more productionized and far more performant. It's going to have a different kind of an environment. So the concerns it's going to need to fit into, in order to be fit for purpose. So I, I, there seemed to maybe not be enough separation in how that was being discussed. And so that's why I bring that up. Okay. Okay. Thank you for the clarification. And I think John, your hand is up next. Howdy. Yeah, I wanted to echo stuff that Clemens was talking about, but also the fact that the discovery work and catalog work, we're going to have to deal with authentication of those things. So it kind of leads into the, the start of a bunch of the security work anyway. Okay. Good God. Okay. Thank you. And Scott, your hands up next. I think I want to add to what Eric was saying. We did talk a little bit about function signature, like function signatures and making that more common, but I don't think that's what you're saying. One thing we didn't really talk about, I'd like to have a super briefly was protocol and negotiation where you could upgrade some, like if you wanted to talk over a Kafka queue directly, maybe that is that we were talking about with being able to negotiate or to talk about how to get things delivered in the subscription API. Yeah, I think that's a really, that's a good sophistication of what I was saying. Yeah. So, you know, what are the rules and expectations? Kind of what are the guarantees that each side should make to the other? If it's a, you know, Kafka queue, was there a set of delivery requirements? You know, do I just say, Hey, did you, did I successfully open and transmit that data or, Hey, are you going to act that it was actually written to the disk? Some of these nuances really matter for how you design a system. So Eric, do you look at the delivery API as something that's actually distinct from subscription API, or do you look at it as a sort of a subcategory of subscription API because you have to do, as Scott called it, protocol and negotiation? Yeah, I kind of, I was, that's what I was saying. If you squint at subscription API, it includes a delivery API, but I think there are fairly different requirements for the delivery of data through a specific protocol. And using maybe even within a protocol specific rules about what that means. It might be nice to have some amount of standardization across protocols, but that gets us into some pretty difficult waters. Yeah. Okay. Okay. Cool. Thank you. Okay. So John and Sky, your hands are still up. I assume those are old, right? Okay. Cool. Anybody else want to jump in here and comment on this and just want to point out there were other things that were mentioned. I've seen function signatures popped up there. The refresh of the white paper and that's some education stuff as well. But is anybody else want to mention something that they think that they're just flat out missing? It should be added to the list. Hines. Sorry, we're still on mute. Having done quite a bit of work with the API's in the last couple of weeks. And the fact that as I mentioned, we are doing a lot of code generation based on the schemas. Some more expansion on the actual cloud event schema where right now it's quite elegant with all definitions. However, I don't know if this is the best practice or something that should be defined farther. So for example, I ran into, if I had to add a JSON schema that represented the data in the cloud event schema, how do I merge those? Should I make it another definition? Should I make it, you know, so there's quite a few ways to do these things and there might be a better way or a worse way that might be recommended. And possibly, for example, we found some of the libraries for some validations and things really don't like everything using definitions. They expect a more common definition less schema. That might be something that is produced as well. So just a little bit more work around the actual schema because there is one example only and there's multiple ways to do JSON schemas. So make sure I understand there. So when you talk about the schema, are you talking about the schema of say the structured cloud event payload or are you talking about the schema of the business logic? The schema in the structured, so we have the schema for the structured message, which is all definitions. There's one example. However, for the data part, right, that in itself may be another complete JSON schema. So what is the best way to reference it? Do I do it with definitions? Do I inject it directly in the definition? Like what do we recommend for people that are doing JSON within JSON, which becomes very important for things like code generators, which we're using where I can actually extrapolate that into then the, rather than having an SDK, I actually generate a full object setters and getters. Or maybe, and we also ran into some of the validation libraries using a schema that is there now which is purely based on definition. It does not work correctly all the time. So having one example where it's not definitions, but a regular, you know, structured attributes with all the properties and everything kind of manually defined might be of value as well. But just more work around the actual, I mean, all of this is based if you're doing the structured is, you know, the cloud event schema, which right now there's one example where there's really no discussion or, and again, even though it's nice, it should be cleaned up where some of the definitions where they define the event and the event is then referencing other definitions. They're kind of some at the top, some below, you know, just clean it up a little bit. It might not be a bad idea either. Okay, so it's interesting because this, doesn't this sound like a whole new work stream as much as it's just additional tweaks to the spec, to the spec or the primer itself. And I think at least from my point of view, that's always been a sort of on the table is, as people raise issues or concerns with the spec. Right? Do I have that right in terms of classification? It's not, the spec is fine. It's kind of like when you're doing the SDK, it's great to have the libraries, but without examples, it's not going to be adopted and people get frustrated. So again, the spec is not affected. It's purely the samples of the JSON schemas provided, which to your point, I think might be referenced more towards the primer than the spec itself. Okay. Okay. Thanks for the clarification. All right. Manuel, take your hands up. Yeah. Post V dot one. I don't know if it's, if it fits, but I'm sort of missing the packaging contract that was discussed in face to face. It's clusters with the function signatures. Right. So as Clemens was earlier pointing at, we had the discovery cataloging delivery API, subscription API, sort of all fitting in one cluster. And I think we had more about how the functions would be described and function signature. Right. Yep, right. I did forget about that. The only reason I didn't include it was because while it was mentioned during the face to face, it was my impression that it didn't get as many votes as the other ones, but you are definitely right. It was mentioned. Okay. Anybody else want to jump in there? Okay. So I'm trying to think in terms of next steps here, my natural inclination is to believe that while it would be wonderful to work on multiple of these things at the same time, given our history, I tend to think we have to be kind of single threaded. Is there anybody that thinks we can actually do more than one next new thing, meaning not just tweaks to the current cloud events, spec or anything around that, but in terms of a new project or new specification, does anybody think we could do more than one at a time? Okay. Because that to me says we're going to have to come down to a vote and we're going to have to pick what that next one thing is. And I'm sorry, there's somebody in the kitchen, I think maybe we can go on mute. I'm not sure what that noise was. It seems to me that it might be good for people to go back to their respective companies and do some thinking about what they think they'd like to work on next. Ultimately though, I do think as of right now, I'm hearing more people leaning towards the subscription API type stuff more than anything else. Whether number two is things like function signatures or packaging contract or any security. I'm not sure yet, but I'm not sure it matters because we're ultimately going to pick one. But what I'd like to do is come back on to next week's call and basically take a vote in essence and say, you know, is it going to be subscription API? Is it going to be in security? Or any other ones that are mentioned? Does that sound fair to people? Can you give you guys one week to think about it and come back and basically vote next week and see which one gets the highest number of votes? Or is there a different process you'd like to follow? That's good to me. Okay. Thank you, Clemens. I don't like silence. Anybody else want to chime in? Otherwise I will assume silence is an agreement. Okay. So in terms of thinking about what we're actually going to vote on, just to reduce the number of choices, I do think subscription API discovery is on the list. I think many people have said yes to that one. Is there anybody who thinks that function signatures should be on the list for people to consider? I'll go first with voicing opinion on this one. Personally, I love the idea of function signatures. I think that's a wonderful thing to tackle. However, I think that is a, it is a non-trivial problem to solve because of the differences between the various platforms that are out there today, which also tells me it probably might be very, very political. And so I would love to work on this thing at some point in the future. I think it may require a little bit more discussions offline first to see that about the feasibility of it. So I'd like to sort of keep that in the back burner, but in terms of as a top order vote possibility, I'd like to not include that in the list just because I think it's not, it doesn't fall into that category in my mind of small next baby step. I think it's a biggie to think about. And maybe a rattle for us to think about. Anybody else want to advocate function signatures being on the list of considerations? Okay. These two things I think can be done anytime. We don't say have to take a vote on it. There's just people to volunteer to do that kind of stuff. And security. I'm assuming that will be on the list just because Jim, you mentioned it and you thought it was important enough. Is there anybody who disagrees with keeping it on the list in terms of on the vote for next week? Okay. Delivery API. Eric, since you mentioned it, I assume you'd like that on the list or not. However it works. We need to, that may be under subscription API. I don't have a strong opinion. Okay. Anybody else have an opinion as to whether it should be a standalone entity or we should consider it under the subscription API model or the project? Brian. I think that they are interrelated. And I don't think that they can be just having thought about this a bit in the context of what we're working on at Twilio. I don't know that they can be developed independently. So I would advocate for even if they are, you know, conceptually separate things, I think they need to be thought about together. Okay. My experience. Okay. I should mention, offline, just because of all the discussions that have been going on. I started the process of putting together. Just something a little more concrete about what the discovery and the subscription API would. Concepts would be do not interpret this document as, as a, as anything other than just my rambling is just try to get something a little more concrete. So I can have a conversation with people about what we're thinking about doing. And I think that, as I said, you know, the link is here in the notes. Eric, what if we did this? What if we start off with delivery API being considered a subset of the subscription API discussion. And as we make progress on there, if it turns out, it's either too big or, or something causes the thing, you know, is really needs to be pulled out. We can pull it out later. Does that make any sense to you? Totally reasonable. Okay. Cool. Thank you. I'll move it into there. Okay. All right. Heinz, is it okay with you if I consider this to be just a normal part of maintenance work on the cloud event specification? So it's not necessarily considered as a top level, potential new project? Well, absolutely. Now it's how I had envisioned it. Anyway, so we're on the same page. Okay, cool. And Manuel. Do you think there was enough support for packaging contracts to be considered a top level vote possibility for next week? Ooh, I'm in the balance. If it was just the container OCI's, then it might be low hanging food. If it was functions delivered wrapped up, then it might be similar to function signatures, a bigger one. So I'm going to try any comments. Yeah, I was going to ask anybody else on the call have an opinion on this one, or they think it should be part of the vote for next week? Because as of right now, we have two items discovery and end delivery. So this would be the third one. Anybody have an opinion? Just trying to reduce the amount of thinking you guys have to do for next week. It's a pretty crowded space. What's interesting is when I think about packaging contract, well I think it actually kind of falls in the same category of function signatures as G's. It would be really nice if there was commonality. It feels like it's going to get very political very fast. But that's just my gut feel. Yep. So let's leave it undefined. Okay. So it sounds like we have end-end security and the discovery subscription API slash delivery API as the two topics to consider for next week. Does that sound right to people? Okay, not doing any objection. Clemens, are you going to say something? I was just nodding. Nothing. Okay. All right. So what I'll do is I'll send out a note saying that we're going to vote next week on these two items for next big work item to work on and people should come prepared to vote either next week or if they can't make the call then they just vote through email or however means whatever means they want then I'll record their vote. All right. Anything else relative to post 1.0 or future work item discussion? Any other topics? All right. In that case, any other topics for the agenda at all you want to bring up? All right. In that case, let's just do the final roll call and then you guys are free to go except for the SDK folks. Doug, are you there? The other Doug? Here. All right. And Vladimir, are you there? I'm here. Thank you. Anybody else that I missed from the roll call? All right. Cool. In that case, everybody but SDK folks are free to leave. Thank you guys very much. And we'll get started in just a minute or so as people leave the call. I have a first thing to skip the SDK call. OK. Thanks, Clemens. I suspect it'll be short anyway, but we'll see. Yeah. Sorry about that. I'm triple booked this slot. Not a problem. OK. Thanks, Clemens. Thank you. Goodbye. Bye. Thank you. Thanks for everything. Scott, do you have anything to talk about on the SDK call? Not really. And I want to go to the Kata call in 15 minutes. There's a Kata call? Yeah. Really? Where is that? Or who's hosting that? It's a Kata community. Oh, I see. OK. OK. Well, in that case, is there anybody who has any topics at all for the SDK side of the house? Because if not, we will just adjourn very early. Actually, I had a quick question. Go ahead. I was trying to work with the Java SDK and had some good success, except I could not get the vertex, virtual vertex thing working. I wonder if there's like a working sample that somebody might have? Anybody in the call use the Java SDK? You may try asking in the SDK Slack channel or open an issue because I think Fabio, well, he doesn't typically join these calls anymore. He does want to get a repo fairly well. And he does respond to my Slack messages. So he is in both of those places. OK. He may be able to help you. OK. Thank you. OK. Anything else or anything at all for the SDK meeting? All right. In that case, we're probably done then. OK. Thanks, guys. And we'll talk again from SDK perspective in, I guess, in two weeks. So back in January then, because in two weeks we'll be on vacation. I'm not sure when the first meeting is in January. We'll figure that out. All right. OK. Bye, guys. Have a good one. Thanks. OK. Bye-bye. Thank you. Bye. Bye.