 Hey, Vlad. Hey, Doug. How are you? Good. How you doing? Fine. Fine. I'm preparing to go to a cloud-native meeting Bucharest, where I got to give them cloud event stickers. Ooh, that's exciting. And we need to get more stickers somehow. Got to figure out the process for that. Yeah, I only managed to get stickers at KubeCon when in the last day, they brought a big box full of stickers and there were some cloud events in there. Yeah. Well, that was it. Yep. Hey, Heinz. Hi, Eric. Hello, how are you today? Good. How are you guys doing? Good, good, good. Jane, come on in. Good morning. Hi, Lucas. Hey, Lucas, can you paste into the chat which company you're with? I can't remember for sure if this is your first meeting or not. So I'll make sure I get the attendance right. OK, one of us. Thank you. Tommy, are you there? Is that Mr. Mitchell? Good morning. Good morning. Hey, Tommy. Clemens. Indeed. Yes. I did find it amusing, Clemens, and I know that you sent me your assumption that I knew the other IBMer. It's a pretty large assumption. Well, you both work with standards. That's funny. You should know each other nevertheless. Oh, yes, yes. Because we're such a small little company. Yes, why? Because you work in related things. And York is the industrial IoT champion. You should know him. Probably. All right. Hey, Ginger. Good morning, Doug. Morning, Ann Manuel. You guys don't have a microphone, do you mind? About Kelvin. Kelvin, are you there? Oh, Kelvin, I see you coming off mute. Just if you can, Kelvin, since you may be having trouble with your microphone, do me a favor, I can't remember for sure if this is your first time in the call or not. If it is, can you paste your company affiliation to the chat just so I get it right for the attendance? Assuming you want to be affiliated with the company. Got it. Thank you. For those of you new to the group, we'll get started about three after. We usually give people three minutes to join. And well, are you able to speak now? Yes, I am. Hi. Hey, this isn't your first time in the call, right? Just I apologize. No, I was on one call the last one, December, and I missed the last one. OK, let me just try to check if I have your company affiliation. Let me see. Oh, that's Nokia, or Nokia Phillips. Oh, got it. OK, yep, you're right. Nokia, yep, OK, got it. Ryan, are you there? Yes, hello. Hello. And Lionel. Yep, hi. Hello. Hi. Oh, hey, Kristofs. I don't know why I keep missing you. I apologize. No worries, no worries. You think you would jump out at me because with your full name up there, it's one of the longer ones in the chat or in the list of participants, but I just don't see it for some reason. Yeah, I notice my name is longer. Whenever I have to type up my email address, it's really long. I can imagine, yeah. All right, one more minute, then we'll get started. Actually, I have a fairly light agenda today. Actually, let me ping Mike and see if he's coming. All right, Klaus, hello. Hello. And Javier. Hi. Hello. And Colin. Hey, Doug. Hello. Whoops. OK, did I miss anybody? I don't think so. Oh, William's joining. It's been a while. All right. Hey, William. Hey, how's it going? Good. All right, why don't we go ahead and get started? This is three after. M-m-m-m-m. Usual thing, Mark, Ken, and I are still working on the write up for our potential charter. Don't know yet what we're doing with it. We're still having some discussions. I still have an AI to update the TSC on our plans for the new spec. Haven't done that yet. When I do sync up with them and find out which meeting they want me to present, I'll let you guys know in case for some reason you guys want to join in and listen. OK, community time. Are there any topics for the community that people like to bring up that are not on the agenda? Not hearing any. All right, some Updaters on KubeCon EU. So I don't think anything's changed relative to the serverless working group time slot. I'm going to try to work offline with the workflow guys to see if they're comfortable presenting. I never actually did confirm with them. I assume they wanted to, but I want to make sure that they're OK with it. And down here, I did confirm with Dan Kahn that we will have a booth now that we are an incubator project. So relative to office hours type stuff, we'll have a booth that we can do that at, and we're probably going to have to do some sort of sign up sheet or something. So keeping it out for that at some point, I'll let you guys know when I figure out the actual details of how that works. However, I will need some help, though. Relative to the two sessions we have are cloud events, status and discovery, spec. I can write that up. That's no problem. I would, however, like some help on the abstract for this session, cloud events in the real world. Now, I don't see Scott on the call, but if someone is interested in just helping formulate exactly what that session is going to be like, ping me offline or during the call here at some point. Because I guess I need some help writing up exactly what the abstract's going to say, what we expect the people, and stuff like that. I want to make sure I get it right. So if you have any ideas, please just let me know. And I can use them up there. Thank you. OK, thank you, sir. But let's see. OK, serverless practitioner summit. That's a day zero event at ClabCoucon, March 30. The CFP was just opened up either yesterday or day before. I can't remember exactly when. But it will close on February 4. So if you have a topic you'd like to bring up, just click on the link here. I think it takes you to the CFP. Can you remind me of the scope of that again? Anything having to do with serverless, basically. So products and it doesn't need to be a single person related? Yeah, not product pitches. Those will get rejected pretty easily. But anything that brought interest to the community. One thing that did come up during the program and committee discussions around there is people seem to like the discussions around the challenges that people had in terms of implementing the infrastructure for serverless or functions and how they got around that and stuff like that. That seemed to be a very popular topic last time. Doesn't have to be that, but just let you know that was a popular one. OK. OK. Any other questions on that? Or anything else related to ClabCoucon? OK, one thing I will mention. I'm still working on getting a room for the face to face. I suspect we will be able to get a room. And I'm asking for a two hour time slot for about 20 people or so. When that actually gets confirmed that we will be able to get one. And then I'll send that on notice per governance rules. We only need to do it four weeks in advance. But if you are planning on or if you need more time to get travel approval, then you may want to start the process now because I suspect it will happen. I can't imagine that they can't find a room for us, but we'll see. OK. STK. So we had a call last week. Anybody from the STK subgroup want to mention anything from that call worth mentioning? I can't think of anything offhand. OK. We don't have a call this week, so the next call will be next week. We do it every two weeks. Kathy just pinged me as she won't be able to make the call here. So is there anybody else from the workflow subgroup who wants to give any kind of status? I don't see anybody. OK. We'll skip that. I actually have some minor status update for the C sharp SDK. Oh, sure. I just checked in the Avro encoding. Having implemented it, I'm not sure. I'm 100% happy with how we did that, but that's just what it is. And I'm also working on NAT support and ping direct regarding test interceptor. Cool. Excellent. So the Avro support also has a separate Nougat package now. OK. Any questions for Clemens or anything else related to the SDK work group? All right. Moving forward then. OK, thank you, Scott. All right. For the thought events, PRs, and issues, and stuff, I don't think there's anything here worth mentioning. I don't think anything's really changed there unless someone has something that they'd like to bring up. OK. So let's go ahead and jump over to the discovery spec. Since discovery is first, and I think I saw Mike on the call. Here you go, Mike. I see you. Mike, you want to bring us up to date on where things are or any topic related to that? Sorry, still not used to finding the unmute on Zoom. Not a problem. So I had trouble getting everybody together for a call that volunteered. Hopefully we'll get that done before the next meeting. I put in a link to GitHub issue where we discussed discovery for Knative a while ago. So I don't know that the implementation is exactly applicable here, but I think the use cases are. So I tried to summarize that in that next paragraph in the doc here, thinking about how people are going to actually consume this discovery. I mentioned this briefly last week, but we think about it as a funnel. So I think about like a cloud platform provider that might have multiple tens or dozens of different services they offer. That's a much more tractable thing for them to think about is like I want something from my compute or I want something from this database rather than having a list of the maybe hundreds of event types that that cloud platform provider has. On the flip side, I think it's also equally valid to think about what event types do I have where some event types might come from multiple sources. And I may be able to source those from different ways. So just like a little bit about the use cases, there have been some edits to some of the specifics on the suggested query operations and parameters. Speaking for myself, I know I added some things about filtering languages. So I think it's interesting to think about trying to standardize on a filtering language. At the same time, I think there's always going to be some room for some event providers requiring some kind of domain specific language in particular if you wanted to set up SQL trigger on a database as an event source. It might be hard to express that in a standard Cloud Events filter. Anybody else that has put comments in here wants to speak up? I guess not. If it's helpful, we can talk more about the actual implementation that we used in Knative. Can talk about that a bit now or we can try to organize those docs for offline reading. Yeah. If we have time, maybe it might be useful to talk about the shape of what the query results look like so people get an idea for what the scheme is. I mean, unless it's basically exactly what's shown here, just to see what Knative did. Yeah. We thought about how would we create a registry for sources and we kept budding up against things that looked a lot like custom resource definitions. So we actually just leaned into that and we're actually leveraging custom resource definitions with some conventions. So for instance, we had an annotation that says whether or not that thing is a source. So it's easy to query your custom resource definitions on your Kubernetes cluster and determine which things are sources. The nice thing that that gives us is the open API spec for how to configure that source is just baked right in. We've also got another annotation that describes the event types with a parsable JSON body that can then be used by tooling. So basically we decided not to try to recreate something that already existed and served the purpose we need. Separately, we have an event type registry. So we created another custom resource definition literally called event type that provides that second piece of the registry. So being able to go in. We do have a slightly different use case in Knative and that we are both providing access to external sources and discovery, but we're also providing access to on cluster events, things that one microservice to another that do not come from a provider. And that's where that second bit of the registry becomes a lot more critical being able to guess what event types are lately available in my environment for me to consume. OK. Let's take a look. Actually, does anybody have any questions or comments from Mike? Yeah, I have a comment. So I think one thing we will have to go and figure out is how to balance out the Kubernetes Knative world, which has a fairly well-defined way of how to do resources versus places where none of that exists, where effectively the registry is a standalone REST API. And because there will be many environments where the Knative and Kubernetes are just not playing a role. At least they're not the hosting environment for things. And there may not be Kubernetes cluster where people may not be setting one up just for that purpose. So we'll have to go and figure out how we can go and make an API that works for, effectively works for both, where you can use the Kubernetes cluster and all of the resource model that's in there, effectively as the back end store, but have a very thin veneer that sits on top of that. So it's kind of a need for operability API. So I think we'll need something to that end to cover all the bases. Yeah, one thing to point out is it's totally possible to still implement the semantics of something like a Kubernetes CRD without actually having a Kubernetes cluster. Yeah, but that's a lot of stuff to buy into if you just want to have a registry for events. Sure. I mean, it comes down to a REST API with certain fields and certain semantics. Yeah, and if the data model ends up being with lots of overlap, I think that's good. It's just that I would not force folks in industrial manufacturing necessary to buy into the entire management model of Kubernetes because they have a completely different world. So Scott made a comment and I'll speak for him since he has no mic. He said, can we define the shape of the API results and not the REST API and not a REST API? I think that's half of the interrupt story. But arguably, we're doing that with Cloud Events already, that we define what the results look like. But also, we'll probably also have to go and define how you query. And then you're getting fairly close to what that REST API also looked like. But yeah, in spirit, I agree that the data model is more important than the interactions are. And your comment there about the Clare to Model versus REST API or RPC type model, I think that actually applies to both parts of the spec, right, and for not just discovery, but to the subscription stuff as well, right? What I just said? Yeah. Yeah, I think so. Because there's a, I understand how the world, how that Kubernetes world, to the lesser extent, Knative world looks like and how there's a drive towards declaring everything and then having some mechanics under the covers go and realize all those things. But there is, I think, a need for having fairly explicit here's a network interface, go and use that network interface for everybody. I think we need to have both. And I think the least common denominator is really having some sort of HP API. Any other questions or comments on that? It's going to be an interesting discussion, I think. And Scott said, can you have an API binding? Let's you roll a REST API or host it out of Kubernetes. So something to think about. Yeah, I think that has to be, for the Kubernetes world, in particular, there has to be a mapping that is very straightforward and not complicated at all. But I just think that that interface also needs to accommodate someone who's not in that world. Like, for instance, if I look at Azure and AWS, we have our own resource models for how we represent resources in the system that are not necessarily Kubernetes. There should be some mapping in a similar way to that model as well. We have the Azure Resource Management, which has its own resource graph. And we represent subscriptions to event grids in terms of that model. And there's a layer that we will have to go and implement to go and create compatibility in that API sense. And that's how I look at this. What is the common denominator across all those and how can we create an API that everybody can speak? OK. Anybody else have any other questions or comments on the discovery side of this spec? OK. Let's switch over then to the subscription stuff in Clemens. Maybe you can bring us up a date on what you guys had done so far. Yeah, so we've had an hour-long call just to pick everybody up from where they are and listen to some of the requirements. And so we came up with four distinct areas. The first one is describe what the native subscription capabilities are. So if you have a subscription API, this subscription API should not force you into performing a natural act. So if you have an MQTT broker, it should be possible to do something that is written down in a cloud event spec that doesn't require you to leave the confines of that MQTT broker, because the MQTT broker itself does pops up. So it would be weird to say. But if you want to do subscriptions in the cloud events way, you have to go and pull these four things onto that MQTT broker, because that's a little weird. So the native pops up capabilities of the broker should be permissible. If you are committed to MQTT, then you should be able to do it the MQTT way. If you committed to AMPP, you should be able to do it the MQTT way. If you committed to NATS, you should be able to do it the NATS way. And most of those are effectively pull operations. That's kind of pull subscriptions. You show up to a broker, you set up a subscription, and then you ultimately just pull events down towards you or configure the broker to send that into a queue. So those mechanisms should be described in the specification. And as you say, cloud events, if you use the following transport, we're OK if you're using the following mechanism. Then there's a whole. And this is what we all identified as a pull model. Then there's a push model, and that's something that everybody has a flavor of, where you have a pops up intermediary of some sorts that you can go and configure to push events to a particular destination. So you create a subscription, and that subscription tells the system where to deliver those events. And that's something that Twilio has, and that's something that Klaus and SAP has, and that we have an event grid. And I think Kathy said that she has both cases as well. So that's effectively what the subscription API is, and that's what point B is. And they're not necessarily ranked. A and B are ranked about the same. That is why we need to have a subscription API where we have some kind of endpoints, either at the producer or at a designated destination on behalf of the producer. And that's something that interacts somewhat with the discovery, with the catalog, where you then go and create a subscription and tell that pops up engine where to deliver those events. And that means that that subscription definition needs to tell which protocol is being used and needs to go and tell which credentials are being used, et cetera. So it's a relatively straightforward, out of the thing, REST API, but it also needs to have a common data model that we all can effectively lead on. And so that's one of two options. One is push, configure an event source, or it's a intermediary that is distributing an event for it to deliver events somewhere that is this API. And then there is native capabilities of the respective brokers. They also need to be enumerated. And then obviously, the broader you go in scope, so the further you go away from the source, and the more you have a pool of events, Twilio, for Twilio, that was the use case that's true, where Twilio effectively creates, you have a tenant scope, and all the events from the entire world of Twilio are available in that scope of your tenant. And then you basically just go and reach and create filter conditions for how to get in there. And those might, in the simplest case, go and just be able to filter on source and subject, but they may get more and more complicated, and you may have to have some filter expressions to go into those. I then put up a warning sign by actually sharing the new filter specification for AMQP, which shows how complicated that might get. But we'll have to go and figure out what the filtering model will be, and I think since we also need to have a filtering model for the catalog, I think that's something that we'll have to go and figure out how that will look. I think that the most trivial one is to say, we're only gonna do prefix and suffix filters on source and subject of some sort, and then punt on something that's more complicated for the first release, and then figure out whether we want to do some more complicated expressions down the road. And then Klaus also brought up, and that's D, how subscription propagation might work, and we decided to punt on that initially. And the problem here is that if you are you have a device that's sitting somewhere in a business environment, think of as a restaurant or think of as a medical clinic or just a home entertainment system, and that exposes a bunch of events, and that is going through a gateway at the house and that gateway gets connected up to an IoT gateway in the cloud. And now you have a consumer who's interested in a particular event from that device, which is one hop away. How does that work? How does the cloud gateway know how to ask the IoT gateway to go and ask for that event, and how does that synchronization happen? And then when there is a synchronization of that sort, how does the system deal with the IoT gateway asking for that event twice, but now having two parties interested downstream, if one of them unsubscribes, how do you keep track, et cetera. So that's complicated. The problem exists, we believe, that you need to have this subscribe on behalf model, but that's something that we said it exists, but it's a corner case. So we are gonna write that down as something that we're thinking about this, but we're not gonna tackle that and not try to tackle that in the first run. So that's kind of the overview of where we are. We've assigned some owners to these things. I'm gonna write down the native protocol story and then we're gonna reconvene sometime next week and compare notes and then see where we can get. But ultimately, I think the outcome of this effort is also the core output is a data model and a REST API. Cool. Any questions for Clemens or comments? There's one comment in the chat if you wanna address that one, Clemens. Or Kristoff, you wanna speak out to it? Yeah, I can, well, I have a second point to D, but my comment was, if you're so bought into MQ2TE or NET, why do you still wanna use a cloud event subscription at that point? The simple reason is compliance. So there are a lot of, and I see this now that I'm putting my feed again into this industrial manufacturing domain. There are a lot of customers who will insist on your implementation being 100% compliant with whatever the standard says. And if the standard doesn't mention your path, then the customer's gonna yell at you. So that's the reason is to effectively say, if you use MQ2TE, use the MQ2TE model as described over here and that's okay. So it's not inventing anything. It's effectively just referring to the mechanism and say, and effectively blessing that as a, okay way of doing subscriptions in cloud events. Got it. Okay, my second point is to D. So I think the subscription propagation is actually important in the cloud. So you don't have to look at devices. So I work at commerce tools. We will then software as a service and we try to use cloud events to push stuff, for example, into Event Grid, which we do. And now the extra problem is a customer registers, for example, Event Grid and connects this to our API. And then the question is, which events do we push? So we have, I don't know, millions of events that go out. So, but it, you know, it costs money to send them. It costs money to receive them at Event Grid site. So then what the customer has to do is they've configured one subscription at Event Grid site and then another time at our site. And that's just wasteful. I mean, it gets easier if we have a common filtering model, but it still seems like also very error prone for the customer to do. Yeah, so you can solve this by effectively exposing your own subscription endpoints and then you're being asked to subscribe to something. And then as you are being asked to subscribe to something that is not within your domain, you can then go and look around and see where else you can go and subscribe to that. So that's something that you can do inside of your solution. There's also an interaction that we have to go and investigate and that is with the registry because before you have to, can you subscribe to, before you know that there is an event to subscribe to, right? You sit in the scenario that I explained where there's a device at the edge, there's a gateway, there's a cloud gateway and there's a consumer that sits in the cloud. The consumer in the cloud first needs to be aware that there's an event that they can go and subscribe to which means there has to be some catalog propagation down to that level which comes from, which effectively flows down from the device in some way into a common catalog from where you can go and query that. And once you have that catalog, then you have, in that catalog, I expect it to be a URI where you can walk up to and say for this particular event, from this particular source, you can go to this endpoint and ask for a subscription and that could quite well be the cloud gateway thing which then does effectively with that subscription, does a translation and then walks up to the gateway through some proprietary path initially to go and do this because ultimately there's a synchronization protocol that is needed. Now we're effectively looking in this whole game, we're looking at three APIs or three interfaces. One is the discovery interface, one is the subscription interface and the third one would then be this synchronization, subscription synchronization API and I'm a little afraid of that because of the complexity. I'm not sure we, I would rather want to go and solve the first two first and then take a look at actually what we need. If I can make, yeah, go ahead, sorry. I think the discovery part is not necessarily needed. So if I look at it right now, Event Grid does know what exactly will be sent over the wire or what the event types will be and so on, but it doesn't really matter as long as the one who creates the subscription and the filter knows. So you can add a filter at Event Grid, Event Grid doesn't know what the filter does, but Event Grid can forward this filter to the initial producer and then it's fine. So you don't necessarily need the discovery, you just, the end consumer needs to know what the publisher is actually producing. The middle verb does not necessarily have to, obviously it's nice if you have all that, but I don't think it's required. Yeah, we have a protocol like that for first party event sources. So we can surface that and talk about this, but that's, as I said, that was also part of this discussion and we decided that that's not out, but it's kind of not the first thing we want to go and take a look at as a group. But I'm happy to take a look at it. Okay, I get the point, it's not the first thing. Yeah, exactly, that's all, so it's not scoped out at all. Yeah, I think the problem to maybe make the point a little bit better, the problem for me is that I know there will be, I don't know, 10, 20 developers sitting who consume my events through, let's say, Event Grid. And one of those will have created the initial subscription from my platform to Event Grid and that person has the domain knowledge what goes over this wire or through this connection, but then the nine other guys, they don't know. And so they see, okay, I can subscribe, I don't know, to orders that works, now I'm trying to subscribe to events from products that doesn't work, why does it not work? So for them, that gets very confusing very quickly, you know. And that's where the catalog will help because that will give you certainty that you should be able to query that endpoint and say, what is available here? That's true, yeah, right now with Event Grid, if you have a third party API and you push, Event Grid doesn't know, it just, you have to write a filter that's correct and yeah. I literally answered an email today, to me, that said, you know, how are we gonna go and solve that problem? I said, we're talking about this in the Cloud Events Working Group, but I'll be happy to report back in two or three months. Okay. Two or three months, that was open for weeks. Well, I'm just trying to be realistic here, Doug. Okay, I can look, okay, two or three months, be one, we're all set, okay, good. Okay, sorry for not joining the call, maybe I should have brought the discussion up there. It's all good. Any other questions or comments for comments? I think, Klaus, you came off mute there for a minute, did you wanna say something? Oh, that was actually, well, just to mention that, to Christoph that my motivation for this was also similar. So we have this multi-cloud use case with different eventing infrastructures we wanna maybe integrate somehow. Okay, cool. Any other questions for Clemens or comments? Ginger or Heinz, sorry. That's a big confusion difference. Well, on my screen, it popped up under Ginger for some reason for a split instant. I'm assuming that was a bug in Zoom, sorry, I apologize, Ginger. I didn't mean to scare you like that. We look very similar online. So, Heinz, you're gonna do it. Yeah, just wondering there's, since it doesn't relate a lot to the messaging, there's a lot of discussion where it almost gives me the impression that this is a static kind of subscription. However, in most of the messaging, case in point, it's something like the MQTT, there is a hierarchical kind of definition of what these topics are going to be that the data's traveling around and they are, in some cases, it may be, for example, one of the fields is actual data that's changing constantly. Wouldn't this kind of make it difficult for your subscription model? If one of the fields may be model number or something where there's 100, if not potentially thousands, which is why they've introduced concepts such as wild carding and such, and then you have the other two which will add difficulty, which are temporary subscription topics, which are required for point-to-point, where I would do a request out on a subscription, but the reply back has to be almost like a unicast with a temporary topic, which, again, how do you subscribe to those? And then the issue of the, excuse me, well, I guess those are the big two, is, well, actually there's also temporary subscriptions that are in many of these messaging models as well. So how are we gonna differentiate between like a static catalog and discovery, which is simple versus a lot of these messaging layers where they are hierarchical and many of those fields are potentially different on every message. For example, in the financial world, the actual trade on the financial trade is one of the fields. So how do you know what to subscribe to? That would kind of screw up your discovery in your catalog. Yeah, so that's why I'm, that's actually why I'm looking to describe the native subscription capabilities of the existing transports and what's in standard there. So you can look at what the portfolio is of options that already exist and then have, and then also describe the, deliver into scenarios or the push scenario, so that you have a portfolio of options you can go and take a look at. So what we're doing with the cloud events, mapping, for instance, to MQP is, but also to MQP D5 is that every time you want to promote some data for the middleware to look at, you write an extension. So you can, if you want to go and create an event feed and you want to distribute that event feeds using filters that act on the stock symbol, you can do that by promoting effectively the stock symbol into an extension on the cloud event. And then that gets mapped to an application property in MQP and it gets mapped into a user property in MQTT and it gets mapped to a header in HTTP. And then if you go and take the event stream for the market feed and push that into and you direct that effectively into a, let's say, MQP topic, then there is this particular MQP gesture that you can go and then use to tap into the MQP stream and pull the data out. And that's something that, those combinations, one of the goals that we had initially with cloud events is to combine things and not reinvent the wheel. So what I would try not to do is to create a Uber subscription model that works for all protocols but effectively let the protocols be what they are and let them play their strengths. And MQTT is really good in having hierarchical subscriptions and if that's a model that works for you then go and use those. MQP is really good at at least the implementations that we have and we've been working on making the filtering model standard in MQP so that's currently in draft state. And having more complex rules, JMS is the JMS message selectors is the common denominator there right now. And so I think letting the message broker do what they do best is great and for us to kind of align with that makes more sense. So we just need to have the common infrastructure, we need to effectively define how a cloud event user ought to go and use those. Does that make sense? Hines, go ahead and go back up. I'll get the class in a second. I want you to finish the conversation first. Well again, it sort of makes sense but I think you're opening a can of worms where again to use your MQTT case you have two issues. One is you need to understand the fully qualified hierarchy for the publisher where you can't really divorce that. And on the subscriptions you're back into the use of wild carding on the subscriptions to deal with the fact that fields obviously could be rotating on a per message basis. So it's almost like you need to, because what we've done for example, we take in our cataloging, here's the event where you define that event, you associate a schema, which we're also then looking at the cloud events, but we also then need is the subscription that you need to receive those events, which includes wild cards and some understanding of the canonical format of the producer to be able to figure out when you receive that what are those wild carded fields represented as. So it's actually, you know, your interaction is actually incredibly complex at that point. If you look at it up, it's multiple protocols, right? But we have, so we have protocol bindings today for how cloud events works in general. Like we have mappings of the cloud events to protocols. And so we went through the exercise of making those fits fit. And if we say, if we publish into the, if we publish into the catalog, that a particular kind of event or group of events is available, you know, per entry in the catalog over MQTT, then it's quite possible for there to be two or three fields which are particular to MQTT, which then designate the topic name and then potentially designate some pattern matching for how the selector information is mangled into the topic name. And similarly, I think you can do something similar for AMRP where instead of having a topic name as you have an MQTT, you have an address, a note name, and then you might have some hint on what the filtering is. So I think there's a, if you publish an event source, you also have to indicate what that event source means in terms of like, how do you talk to that event source and talk to that event source is not necessarily always HTTP, but it might quite well be also MQP. And if you have MQP or have MQTT, then there's a custom set of properties that you then go and look at and use, have your client use those to go and attach to that source. So I don't think that's that incredibly complicated. So close your hands up. Yeah, so I think it was the first point Heinz mentioned about how dynamic values can be. During the first part when we were talking about discovery, I wanted for a source if in all cases, it's easy to list the source someone provides or if I don't know, I think in the early days, we had the examples of a source being something like the URL of a pull request or something like this. So it really depends how you define this context of the occurrence, how you define your source or if you would need some kind of pattern to actually list sources in this catalog. Okay, any other questions or comments for Clemens or for anybody on the subscription sub team? Okay. Is there anything else relative to this document at all in either section that people would like to talk about? So otherwise we'll end the call early. Okay, not hearing anything. Thank you, Mike and Clemens for updating us where you're at, I appreciate that. Is there any other business people would like to bring up on the call today? If not, one time, last roll call. I think I got everybody except these three folks. Christian, are you there? Yes, I am. Okay. And Chen, are you there? Oh wait, Chen vanished. What about Falco? Yes, I'm here. Okay. And did I miss anybody else from roll call? Okay, and Clemens, were you just trying to say something in there? Or actually did we drop, we lost Clemens, you vanished. Okay, all right, last chance. Any other topics people wanna bring up before we adjourn? All right, thank you guys. We'll talk again next week. Have a good one. Bye Doug. Bye. Thank you, bye. Bye, thanks. Bye.