 Hey, everybody. Sorry. Oh, wait a minute. I did not create the next section. Wait a minute. I Could have sworn this is really weird. Oh, yeah, Simon. Yeah Hello, you know what I did I modified. Hold on. I put today's After last week's so hold on a minute. I Pause as I'm just coming off another meeting That I was presenting and that's why I didn't get a chance to do this beforehand That was Simon. What is your last name again? I apologize Simon Hyler from SAP. Okay I'm gonna try to get that give me a favor. Can you edit that? For me when you get a chance if not, I'll figure it out later. I'll write it in the chat. Thank you very much I tell me are you there? Yo, Daniel Hello, hello Ginger Good morning afternoon, whatever whatever Good, whatever. Yes. I like that. All right. Hey, Jim. Hey All right in middle. Well, hi. Hello Scott Timur Christoph And who was it Lance gonna make it Hello Clemens Hello, sorry for being three minutes late or so. You're good. Thank you Simon We have a I really struggled to find topics for today's call. In fact, we have no PRs to review Wasn't sure what you just discussed so I'm looking for you guys to help fill it out or we can end really early one of the two I like free time. Yeah, I'm not telling about it. I'm so angry Oh my gosh All right, I see I need to go to create more work. Yes, I think we all need to create more work for us Matthew either Matthew Matthew Matthew What a class Yeah, hi, Doug. Yeah, though So Clemens or Klaus picking on you for being German here, how would you pronounce his name? Matthew Matthew. Okay. Thank you Matthew Matthew It's hitting in Clemens, which is French, but okay. Okay. Oh Thank you so he doesn't have sound. Oh, you're thank you. I didn't even look at the chat. Thank you. There we go Okay, we got him. All right, it's three after did I get everybody but I'm bump bump bump bump bump. Oh slinky you there Yep. All right, let's go then See how quickly we can end this thing Just reminder if you have an AI Please look at it when you get a chance Anything from the community that people want to bring up? No, okay. Cool We do have an SDK call this week. I last time I checked there wasn't anything on the agenda. Let's just quickly check Yeah, we have nothing there so if you want to do something go ahead and add another section for today's agenda Otherwise, we may not have a call Or is it going next? Oh, yeah, okay discovery interrupt next week call I don't think there's anything been updated in the discovery doc So please if you are planning on doing something there help fill this out. It's on my to do this as well I think the more important thing at this point in time is for everybody to actually start coding more than anything else The way I kind of look at it is Once you get the base infrastructure in place the rest of it should be easy Hopefully, but please start coding that we can find errors in the spec and try to get those ironed out before the proposed interop On November 2nd, which is only a couple weeks away all right and Tim or anything from the workflow side of things you want to mention Yeah, we from the specification side. We had an agreement that we added The use of open API for service invocation definitions. We also create a couple of training type of videos that Mostly for just a community, but also what we're using for KubeCon and just overall KubeCon this year We have a project booth and that doing that this intro in Trato. Is that what it's called? Thing is just it's a pain. So putting a lot of ours into that So that's it Okay, any questions about the workflow stuff? Okay, just let you guys know since he mentioned it. We did not sign up for a booth However, I did sign us up for I think it's called office hours. I have unless I missed it I have not seen the sign-up sheet for when the office hours might be When I get that I'll look for some message on the slack channel because I suspect we probably I'm sorry go ahead Sorry, I can for you to use that email. Oh, did I miss it? Yeah, you should have gotten it. You know, I actually had a problem with this. I haven't said anything to see NCF, but Last time we had to express interest and then once the deadline was over then they open the calendar It seems like this time as soon as you responded they open the calendar to you So there are a lot of times that were gone already by the time. Oh, I responded on Monday and A lot of Wednesday was completely gone already Hmm. Okay. So one of you guys can for I yeah, if you can for me the email, obviously I missed it I've been getting so many emails from them. I just I'm trying to phase it out So if you can send me the email, I'll look for some times and maybe just grab one and if it doesn't work We can always adjust but I Don't anticipate it being difficult last time we had very few people show up So we just need somebody to you know warm bodies in there is probably all we need I think most questions should be easy. So All right All right with that, let's keep moving forward as I said, I couldn't we had no PRs to look at Issues I picked out just a couple. I thought might be interesting Let's pick on this one first since that ain't got a little bit of traction or last couple of days So just to refresh everybody's memory. This one is really about The spec says basically You know property exists it has to have a value Leave out a leave out extensions for a minute because there's a hole there but for all the Spec properties you can assume that if the property exists, there will be a value there It will not be no at least that's what the spec kind of Leans towards but this issue is really about is that really what we want? and so let me pick on Gem and Klaus since you guys commented the most recently on this to get your opinion on what we might do with the situation If anything so gem you want to go first and click give your opinion on this Not really, but I will I guess Yeah, I mean Where as I read the spec it doesn't It doesn't to me read like we support nulls and I wouldn't expect to receive an attribute with no value I think my bigger concern is if you do How do you? Are we meant to propagate that through all the different transports? Yeah, so if we were You know gonna send a null attribute over HTTP. What would we put in the header for that? Yeah, does it then make everything more complex? You know because it might expect The word null in in a header attribute that was only expected to be I don't know a number so I think it is sort of It's a bit of a deeper issue than than it might appear But I would lean to not allowing or or explicitly saying that if if an attributes defined it should have a value Okay Klaus, did you want to chime in here since you commented? Yeah, so Basically, I agree to what Jim said So it just would like to emphasize that it's not about the empty value. It's about the null value of the discussion So I realized that most of the standard context attributes also state that they shouldn't be an empty value, but that's I think a different topic so And I agree that that transporting null Explicitly would be then a challenge for each and every protocol binding and in format. So that's also what I wrote here I Propose that we treat null as the same as not present but I guess we would then have to make that more clear in the Type system and then in some of the formats like for JSON where you can then distinguish null and not present but I Mean undefined and null That this would mean the same for us Okay, so just before I get to I just want to ask a clarifying question because Jim correct me wrong But you seem to indicate you wanted the spec to be more clear to say we do not support null But Klaus you start off saying you agree with Gem, but then you ended with we should allow both But be clear that null is the same thing is not present Well, I say that either we allow it and treat it as the same or we don't allow it at all and Yeah, okay, got it pretty much the same. It's just a subtlety of what would be easier for the SDKs and and for handling of JSON in detail and here would also rely on feedback from the SDK implementers Okay, okay. Thank you for the clarification. Hey, Clemens your hand is up. I Would like to support what Klaus just said Which or what he writes there because I No values, I don't think we allow them anywhere, but if null appears then that's Some especially for Jason some serializer serialize out null if the object is not present and if you have a strongly type structure Which you might have for stuff for for cloud events then You know, you fill all the values that you want to go and fill in and you emit the ones that you don't want to set and Those that end up being null right in Java or in C sharp or other languages And if you happen to have happened to use a serializer that Wants to go and serialize all those values with null values really on the wire then Then that's what it is right, so so I That's so I think that means then that there is no value because nobody said it Okay, thank you Scott your hands up next What if folks think about trying to limit this to just the JSON binding Because I think trying to figure out what this means for the HTTP structured encoding. It's kind of weird That's fine with me. I mean, this is something that I think this makes sense to define in the in the encodings I was gonna say does that mean are you gonna plan Scott that this isn't a core spec change but rather a transport change? Yeah, it's a it's a change to the HTTP binding for only structured events It's a gene. It's a JSON format change. I wouldn't even argue. Oh, yes. Sorry. It's it's JSON only Yeah, because it's absolutely sure. Yeah, if the value is not set then we would not map ahead or But there's no expectation that the that the shape of that is lossy or sorry lossless if it goes from Say HTTP structured to binary to structured again. You don't you lose that information that there was a mill Yeah, because the field wasn't there in the beginning. So the case I just want to want to make not too complicated for for the for the innocent is If I mean literally if you code up a poco type Right, and you grab just grab a grab the serializer and the serializer is that its default is to not emit the values But to to write them out onto onto the wire. That's now then Then that's what you should that's that's the situation you're in and I'm So I'm not sure we should make it really difficult for Those folks who want to go and express a cloud event as a strongly poke with strongly type poco type in there in their app It should not be hard for them to write compliant Cloud events either way. Yeah, this this seems like IOT might care about this. I I'm currently Having a side job helping a soccer professional soccer club their IT stuff and Then so I'm dealing with developers who are just doing dynamics every day and that is calibrating my perspective I would say For how complicated it can be to deal with Jason. So I'm I'm I'm a little Disillusioned I would say Okay, well Jim, I know your hands up, but I think mine was a person just asked my question It's kind of what I tried to say here in my chat pipe I'm wondering while I understand from a straight geeky spec perspective It probably would be good to add some clarifying text here And I think Scott your suggestion of trying to limit those to just the the Jason stuff probably makes sense and just the heads up I will be looking for a volunteer in a sec, but the reason to raise my hand was I'd like to better understand Why this matters at all in the sense that as the receiver of this What would someone do differently whether it's present in the CE or not present in the CE with Present in the CE with the null versus not present at all What would they what would the receiver do differently between those two cases? Well the goal like one would not blow up Is the change? Because right now if you send a nil value, no quoted. He's just nil onto a string It doesn't know how to decode that that's custom Way to back up little I'm confused. What do you talk about an optional property in that? Java would the goal line job. I'm sorry. Yeah, the goal line Jason person will blow up with a no with a no Yep, it doesn't it doesn't work you can't turn a Struct that has a string and you say inside the Jason version that I'm marshaling into the struct But it doesn't know how to turn a the value null into a string. It just blows up Okay So you need this on the goal line side because you need to know whether you need to add specialized logic or Treat this as an error condition or eject the cloud event, right? That's right And so because of this some of the test grid pieces don't work with the goaling SDK Interesting, okay that helps. Thank you Scott Okay, Jim. I think your hand was up next So for me, I guess it's you know, what's the expected behavior of a of an SDK I mean if If an SDK receives a Jason format with a nil And I say to it is this attribute present? Is it gonna say yes or is it gonna say no? I mean, I'm gonna get a different answer if that was Subsequently, I don't know marshalled, you know as a binary through HTTP because that header wouldn't be there. So It just I think it's just gonna lead to when you're gonna have to provide guidance to SDK writers as to how they're expected to handle this situation To get a consistent application Semantic of sort of dealing with stuff Okay, Scott your hands up hopefully to answer that Yeah, so I think from my side Integrators never are asking questions about the original payload. They're asking questions about the the converted nominal form of the event And so in that case, I think it ends up being the same if if something was set to nil The parser understands that that should just ignore it and not set that value So I think you end up with the result the resulting Exact same object after on Marshall Slinky your hands up Yeah, I'm just thinking that in the case of The SDKs I'm working on so both SDK Rust and SDK Java This requires changing the main APIs Because then we because now the assumption is only there is something There isn't anything and if anything is null or not present It doesn't make any difference for So this this will require changing the stuff Okay class, I think your hand was up next oh Wait, I'm sorry. Were you done slinky? No, no, no, if I can add something to bonus. I'm not even sure how Should I for example model this in the rust like I'm saying I'm saying one language, but I Have I have no real idea how should I model this in Rust? I mean What happens when it's not present and what should I say when it's not present what should I say when it's not so The language doesn't give me the ability to model them now In fact, it just gives me the ability to or to say there's something or there isn't anything So I think Clemens point is that the the marshaler Sees no difference between something that was not present and something that was null, right? Yeah, that's that's right if you so In the case in the marshaler and also someone who's looking at at us as a strongly typed object in In Java or in C sharp or any strong any type language that they see no difference between whether you sent null or Or or and meant to sent null or whether the object is absent. It's just it's semantically identical Okay, I'm not sure who I Guess Slinky that doesn't answer directed towards you. Does that help or do you need more clarification? No, no, I'm fine with that I'm just saying that I Think it we shouldn't add this difference at the EPA level Fund is to correctly. What's the discussion? What discussion is going? Okay? class I think your hand was up next yes, so a remark if it's just about the Jason format or Also the main spec. I think the main spec has this CE type system and also mentions that there are canonical string representations So maybe some clarification there that there is no representation of null in the type system could also help Simon I think your hand was up next Yeah, thanks, so I just wanted to point out one use case where null is actually different than being undefined or And that's for example, if you send patch requests or use the chase and merge patch Semantics and there and I basically says if you know this property and you have a value for that you need to remove it So it's But we don't have that use case Yeah, yeah, and it might be a mime type anyway. Yeah This is only for the the envelope properties As body and so you could still do that same patch semantics inside the body payload Okay, sorry, then I missed this. Yeah, you're right. Okay. I Can't remember why I raised my hands all over it Um For everybody's hand that up to your did you guys already talk or was there something else? I just want to know those hands are old basically Okay, I'm gonna assume they're old Okay, so I think What I'm hearing is add language to The Jason only spec. Well, I actually okay two things add language to the Jason spec to make it clear that Null and absent are the same Klaus you were thinking that we may need to add something to the main specs type system section But I think those are the scope of the possible changes we've talked about so far What do people think about those two? possible changes in particular, I wanted to pick on Jim To get your reaction Repeat what I'm having a reaction to What would you be okay with us changing the Jason spec to make it clear that absent is the same as no So would somebody then change the Jason schema definition we have to reflect that I'm not sure if that would be needed as well. I don't know Let's see what the Jason scheme. It looks like Let's find what's empty or here So at the bottom you need to go down to the action definitions so I can't see Data-deaf is the only thing that we currently have to find that is allowed technically to be null all the other Attributes don't allow null as it's currently Schemaed if people are using this and schema Jenning code Jenning off it so Would it be Horrible incorrect for us to say that this was just an oversight and this is more like a typo change by Because we need to add null to all these up here. I think it's yeah, I mean, that's what it would be. It's just a mission But we would you be okay with that direction because you Concerns I mean, it's just if we want to allow stuff to be null then we should define that it's allowed to be no I guess that's what I'm saying. Okay. Okay. I got it Okay Simon your hands up. Yeah, so Yeah, I'm just getting into this but I don't see so if we say Null providing null or is the same as not providing it the same then we could just Disallow null at all and we would get the same behavior and don't have to change Our contract basically it's just adding That it's already defined in the chase schema that null is not allowed. So basically it's just not worded out Okay, Scott, I think you raise your hand for this Yeah, I think the issue that we've run into is that if you if you write a database that's cloud events enabled The database has no ability to omit null value because it'll send them out as the attribute Okay, this this is intended for dumb producers And smart consumers, I think Okay, so if the producer is dumb as and there's no mapping being done, it's directly exposed Yeah, it just direct serial serializes the structure that it has and if it sees no value it it literally writes the null value Okay, thanks for the context Okay, I remember now what I raised my hand and I think it was because of what Jim said earlier is there's no way to for a consumer then to distinguish between not present and present with null and It gave me flashbacks to To looking at query parameters in Golang right because you can use the methods I'm not think it's the query object to actually just you know say give me the value and there's no way to distinguish between empty string versus The the the property wasn't there at all, you know probably not there at all is always going to return to be string If you want to actually find out where the query parameter is there but with no value you have to actually go look at the The map itself to do that and it just got me wondering And I know Scott you said that most people don't never really need to look at the original cloud event itself They're looking at more with the semantic meaning is later on that line I wanted to poke on that a little not to say that I think that's wrong but more to make sure we've thought about this because I am worried about somebody coming along and saying you know what I my my SDK does not shield the user from anything They basically show them what it was basically on the wire for the most part and I want to make sure that we're not going to close off use cases where someone says you know what I really do need to know whether the Whether the thing was present with null versus not present at all for some reason I just so I'm sure we're not missing some use case here Anyway, think of any reason why someone actually might give a crap as to whether the property was there with null versus not at all Given that the guidance is that these attributes are meant for routing and Maybe a tagging of some sort of event and it's not the payload itself It's a I think you're probably doing it wrong if you you're expecting the existence of some nil value, especially because the specs says it must be Min length one We're doing a special case here for serialization between wire format and conical form Okay, I'm okay with that answer. I just get nervous, but okay I would prefer it if we kept them it would made them the same. I'm aligning with you guys just want to make sure we're not missing something Okay I don't see any other hands up any other points on this before I ask a very painful question Okay, I want to do it Doug. I want to do it the answer my question. Thank you Scott. Are you serious? Thank you. All right. Excellent. Thank you Let's see if I can get back to the issue Unless someone wants to fight me for it. All right, cool. Thank you, sir. I appreciate that. Okay Hold on I can't type Okay These were there mainly because they were there last week The only reason I kind of kept this one on whether epoch should be global or not is because Of the conversation you and I had Scott during last week's call where we were talking about this and I was then we got into the discussion point about how If we made this change, it's going to really, really make it hard when you start syncing up between discovery and points And we then kind of landed I think in a position of well, maybe we shouldn't talk about that And leave that as the other exercise for later or someone else's problem But our initial job should be to focus on how to make a single individual discovery and point work well Okay, and so what I wanted to do is to bring back up this issue to say two things. One is is that where everybody's head everybody else's head is at And that for now we should focus on just a second Discovery on point. And if so, what do people think about this issue within that scope and just refresh everybody's memory. This issue is talking about how today in the spec the epoch value is basically Localized to each individual service. There's no correlation whatsoever between epoch values across services. This is proposing to make that to change that to make it so that every single time a new epoch value needs to get assigned to a service. It's globally incremented or it's globally made a larger value with that and what that enables is for us to query the system and say give me also a Services that have been updated since a particular epoch value. Okay, and in order to do that you have to have something that spans all services. Okay, so I guess the question for the group that I have is two things. One is Are we okay with right now focusing just on single discovery and point making that as good as possible. And to what do people think about this feature. Is it worth it. Anybody want to hear. I think you're asking for an atomic incrementer. Yes, I don't think we can do this. I don't think you can make that. That is kind of what I'm asking. Yes. But you but if you think about it, you, you almost have to do the same thing anyway on a per service level, don't you. Yes, on a per service level you do. But only for the produce the services that you produce. That's the key difference. I think you're asking for an atomic incrementer. Yes, I don't think we can do this. I don't think you can mandate this. That is kind of what I'm asking. Yes. But if you think about it, you, you almost have to do the same thing anyway on a per service level, don't you. That's the key difference. Elaborate on what you mean by produce. So if you are in charge of reporting X, Y and Z services, those are yours, but you also accept an aggregation from some other downstreams or upstreams. You don't control those epochs. You control only X, Y and Z. It's interesting you say it that way because the spec doesn't make a distinction between who owns a service. The discovery endpoint just has a list of services and my assumption has always been, I may get a put request for any of the services in there. And then this discovery endpoint increments the epoch for whatever service you targeted. We have no notion of ownership is what I'm trying to say. Is that something we need to add. Or roll back the put until we actually need it. Interesting. I mean, as you came off me, did you want to say something? No. Okay. If we roll back the put, how do we standardize uploading? I don't think you do it because a pole model only. But even a, but then we need to go through the, the interop event to actually see if these are problems or not. Okay, because, okay, I mean, we could, I don't, we don't have to resolve this today. We definitely can wait. I am kind of confused though by your statement of a pole model only. So even, even bootstrapping a discovery endpoint should not be done via something like a put to you. No, I think you do it out of band from the API. Right. It's like, it's, it'd be like the zookeeper config that you're in charge of these downstreams. Or upstreams, right? I always get the up and downstreams part wrong. I like that we don't have to define the API for the mechanics of all of how this works. It could be up to the implementers discretion here. That is true. Sorry, go ahead. So what about some sort of poor首 condition traveling processes, you know pulling from some central config or a database or some other like service discovery end point or an API endpoint. So in the, but it, but you did mentioned earlier that the case of a discovery and point being sort of some sort of aggregator. And to me, whether that's a pusher or Mis But it, that's another one I want to go back to be very detailed that it does not seem still useful for somebody who's quering that discovery endpoint to for somebody who's querying that discovery endpoint to say, has anything changed since a particular time? To me, the discovery endpoints that push data to their downstreams kind of breaks the eventing model because now the discovery endpoints understand the topology of this wacky system instead of each node knowing where it wants to pull data from. No, I'm sorry, it wasn't clear. I wasn't thinking about what's changed from a syncing of discovery endpoint perspective. I was actually thinking more about from a client perspective, right? I have an application that presents some services to a user so they can maybe choose one, right? But periodically, I need to query the discovery endpoint that I'm hooked up to to know whether I need to update my UI with a new list or call the list down because things vanished. It would seem valuable to me as the author of that UI to be able to query the backend system, meaning the discovery endpoint to say, what's changed since the last time I talked to you? Yes, you could do that, but I don't think that the, I think that's a different value than this epoch. That's probably a single other epoch value for the shape of your catalog. And then that could be global for that service, but it's just journaled entries that come from other places. Okay, and so if we had that other epoch value, you're saying that it would be an internal implementation choice to figure out how to map that global epoch value to which services have been updated since some value of that global epoch value. Yeah, somebody else chime in here, but I think we do this, we could do this with the cache key that is a standard header for like CDNs. Interesting. Anybody else have an opinion on this? Does anybody else see value in being able to say, what's changed since a particular point in time? I do, I just don't think it should be that epoch value we're talking about for the service property. Okay, fair enough. Okay, Simon, your hands up. Yeah, I agree with Scott. So I'm also at a similar problem implementing discovery and we decided to go with the cache, basically an ETech as a solution for finding out if content changed and versioning if you need to have the details on it, but we weren't considering having epochs and logical clocks for this because eventual consistency would be okay for basically getting a synchronized state. Okay. All right, I'll tell you what, that helps. So thanks for the discussion, Scott and Simon. Let me go back and rework this because you made some good arguments there, Scott. And I think you convinced me that, yeah, a separate value would be probably better and easier to implement and maybe even safer. It's okay, let me go back and rework that. So thank you. Anybody else have any comments on this before we move away? Okay. The only other thing on the list I thought might be interesting was this one because I don't know whether or I don't remember where we landed on this one. Does anybody remember what if anything we want to do with this one? Here's the original thing because I had this vague recollection that we may have said it's out of scope for us. I can help you refresh that, yeah. Okay, yeah, please. Yeah, that's correct. So we thought that it's probably not the best fit right now and we basically said that we'll revisit this concept in future, but not for now for sure. Okay, would you be willing to add a comment to the issue stating that? Yeah, sure, I could. Cool, thank you very much. Scott, your hands up. I thought we also said that we would consider it as an extension, like an official extension. Yeah, yep, I agree with that as well. But I think we need to address the concept of extensions in general before we think or we classify anything as extension, right? So that entire topic is open right now. Or is it not, I don't know. Well, when you say, can you elaborate a little on what you mean by deal with extensions? So the extension fields, we still have to discuss on how do we want to handle the concept of extension fields within the specification right now? Or do we already know that? We already do. Okay, that's something that I was not aware of. Yeah, basically, extensions appear as top-level attributes. Oh, okay, cool. And they have their own specifications. Yes, that is true too. Hold on, let me press everybody's memory. Extensions. Those are the extensions that we have. There's extensions section in the main spec. Yes, yeah. The extensions in the main spec is the mechanism that we use to allow those, like, well, those extensions are the official sanctioned ones by the cloud events providers. And the intention is that those are interoperable. You can also add your own, but make no exception, expectation that anyone's gonna understand them. That's right, gotcha. But just specifically on this one, sorry, I wasn't paying attention for two minutes. The webbook spec is effectively mandating the same, it is building on the same mechanism that HTTP itself builds on, which is the authorization header and is not trying to invent anything new. So the authorization header is defined in what, 72, 34 or 35. And that's the exact mechanism that we're building on. And then what the spec says is that it's assuming some token-based scheme, even OAuth2, which is the most widely used framework that we all use for web authorization, makes no firm, has no firm mandate for using Jots or not. But it leaves open which format the token has, because the token is really an agreement between the issuer of the token and the consumer of the token. None of the parties which are sitting in the middle should care about the token because the token is really opaque. It doesn't matter whether it's a Jot or not. So if you look at OAuth2, OAuth2 will have has extensions that tell you that it's a JWT, but it doesn't, ultimately for the relationship between the issuer of the token and the consumer of the token, the party that's actually putting the token into the message doesn't need to know what format that token has. So how many are there, Clemens? Are you suggesting that we don't need to make a change? I think the spec, as it stands, is we're not inventing anything beyond what HDP prescribes. And I don't think we should invent anything beyond what HDP prescribes. It's 32, it's 72.35 RFC. So you're suggesting that we don't even need an extension? No, because the WebExpec is an extension of our HDP binding and really defines how you deliver a cloud event via post to a particular endpoint. So it basically is a constraint on the HDP binding. HDP binding allows you to bind the cloud event to any HDP message, whether that's a response and doesn't care about what the method is. For WebExpec, we need to have something that's a bit more specific for delivering events out in a push fashion. The WebExpec is kind of sitting on top of that. So that spec is specific about using post and also referring to a security mechanism, but it's referring to the security mechanism that is defined in RFC 72.35 and then also points to R2 as the framework of it. But I don't think we need to have anything special because that authorization header is not expressed in the cloud event, it's out of band. Okay, Scott, your hands up. I think the thing that I'm considering is it would be nice to have this go through of some other queue of some other protocol and then land still with a proof of origin to some target webhook. So how do we make this lossless through protocol transformations? So you're asking for something else. You're asking for a signature for the cloud event. Right, like the same concept and it gets projected into HTTP as the standard mechanism, but it also can become part of the conical form of the cloud event so that we can convert it to something else. So we have discussed this. So we generally have discussed the problem of both encryption and signature for cloud events and several of us here have been around for a while and have seen the ship of SOAP sync over W security and the brutally complexity that it has. And so we have decided to scope out in basically message level security, both signature and encryption from cloud events 1.0. That was a very conscious decision because we exactly W star evolve into CD star because it turns out that SOAP probably wasn't a terrible idea until all the security stuff came around where people then started building TLS on top of W star and all it was terrible. It was not the XML Scott. So we've decided to ponder on this but you're already kind of hinting at something that is probably a good path. And that is SMINE where I can see that we would create something that allows cloud events to be encoded with SMINE and that SMINE packets can then be routed. So that's ultimately I think where that might land but we have decided not to tackle that problem. Okay, Manuel your hands up. Yeah, I think pretty much some of us where we got to last week but I just wanted to raise that this was about really the signature or it has evolved into this. Originally it was based really on the authorization header but I think the use case would have been to authenticate with somebody further down the line. So if you communicate through a webhook with an event gateway and that event is propagated to a consumer then the consumer has no means to check whether the message, the event, the content had been messed with. So this is I think where it came from. And I don't think that the authorization header here helps SMINE, yes, message signature maybe also but SMINE would that work across all transports of cloud events? If we decided that we wanted to create an SMINE binding for cloud events and if we then made effectively a binary pass through of the cloud events through the infrastructure, I can see that working but it's something that we have to go and spec out. So as SMINE stand right now the cloud event would probably not translate. Okay, and use your hands up. I don't know, it's probably kicking my OCDs into action but somehow it just feel wrong to have something as sensitive as authorization part of the standard spec. I mean, even as an extension. Yeah, I don't know, it might be just me though. But that was the point, that was the point. It's like we're referring to it. We're referring to RFC 7235 effectively and say, that's HDP's problem. And then we're referring to OAuth and saying yep, how you acquire a token, go look here. We don't wanna go and define anything related to security here but we want to go and effectively just refer to the existing mechanisms. And then on the point of authenticating against a downstream entity I hear that a lot. Like amongst plumbers, I have to say. I never hear this from customers but I hear this a lot from amongst plumbers as a alleged scenario that needs to be supported. I'm not sure it's real because most of the messaging systems that I'm seeing are effectively surrounded by gatekeepers and if you're allowed to put a message into the system then and the system supports routing then the system will effectively route the message to whatever the destination is. And having a system which kind of routes you four hops and then the message kind of stops at one gate where it says the message can't pass here. I agree that that's a theoretical scenario. I'm just missing the real scenario for it. Yeah, but I do also see the point of what Scott brought in. Like for example, what if you really want to propagate it feels like there's down the protocols. Like this is a very HTTP specific thing but what if it's some AMQP client is, you know, it needs this particular value. So do we really need to think into that direction that how do we propagate such sensitive fields across protocol? Is it really part of our business? Yeah, do that. What you can't do is you can't give an intermediary the keys to the castle to a downstream entity because nothing prevents that intermediary from then reusing your credentials. Okay, so I'm trying to figure out what's the next steps here? I mean, nothing or guidance or what? I think Clemens you're suggesting nothing and close the issue, right? Yeah, I believe this is solved. Well, Clemens, how do you deal with, so you have these guards and the pipes and stuff but if you use cloud events to act as a router and you don't use the gate keeps keys anymore and there's a bunch of mixed messages on a single pipe you don't, you lose the ability to gate keep. What do you mean? Really? So maybe there's a particular consumer that would like to verify that only the bank database sent you data. But it can always do that. So it's not clear to me that that's a problem that we need to solve in the general case. So if you want to do that since cloud events carries the data is always binary or can always be binary. Nothing stops you from making the event data such that it's SMIME side. So if you have the particular case that you really want to make sure that you have that the data is can be authenticated then nothing stops you from crafting the payload of the event such that you can go and verify it on the other side. Okay, I think that's what the advice should be then is we say the cloud event envelope is not gonna support this directly but the guidance is stick it in the data payload. Yeah, because I think that's the reason why we the reason why we create the cloud events metadata or what we have it is that because we want to make it possible for arbitrary, well not arbitrary but cloud events supporting infrastructure using arbitrary protocols the ones that we support to have a shared understanding of what to do with those events and how to dispatch them. But it's so it's more a spec that is helping you to help foster interoperability than having the originator of the event, the producer of the event and the consumer of the event deal with their end-to-end relationship because the end-to-end relationship is ultimately about what's in that event in terms of payload and they can do whatever they want. One of the principles that you'll find in most messaging systems is that end-to-end security is generally only happening at the endpoints with the broker having no business in dealing with it at all. It's end-to-end security is often something that's only being done by the clients but the only server piece may be some shared key store but that's it. So I would follow the same principle here and say, if you really want to have end-to-end security including validation of who sent that event that's something that should be handled end-to-end which means it's handled based on the payload. Okay, so we're almost out of time. I probably, Anish, it was you that was suggesting you maybe will respond, right? Yeah, I can do that. Do you feel like you understand which way to respond? Because I kind of got the sense that maybe there's a PR in here someplace to add additional guidance someplace maybe in the primer or maybe one of our specs, I don't know. Yeah. Do you feel like you have a, I'm sorry, go ahead, Collins. I think the primer is a good place for us. Anish, do you have a good sense of where the group might be wanting to go with this, that you could take the next steps with it? Yeah, I can raise a PR for the primer, Emily. That'd be great. Thank you very much. Okay, so with that, where's my cursor? There it is. Okay, so Anish would do that. Cool, thank you very much. Okay, that was, I think that's it for the agenda. I don't think I have time to really discuss anything else. One last thing, Erica, you have you. Michael, are you still on the call? I am, yes. Excellent, okay. Is there anybody else that did not get for the attendee list? Okay, in the meantime, does anybody have any topics for the SDK subgroup? Because I believe that the spec or the agenda is still empty. So I'm suggesting that we cancel the SDK call immediately following this one. Is there any objection to that? Or does anybody have any topics? Okay, anything else people want to bring up for today's call for the main call? Okay, in that case, I believe we are done. Thank you, everybody. We'll talk again next week. I'm just wondering, there is no SDK call right after this. We just canceled it. All right, so talk again next week. Bye, everybody. Bye-bye. Bye.