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.  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.  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.  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.  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.


We demystify what goes on behind the therapy room door. Join us on this voyage of discovery and co-creative conversations. This is The Therapy Show, behind closed doors podcast with Bob Cook and Jackie Jones. Welcome back to the next episode of The Therapy Show behind closed doors with myself Jackie Jones and the wonderful, I've not referred to you as that for a while, the wonderful Bob Cook. Oh, just sitting down here. Oh, thank you for those kind words. Oh, kiddo. So what we're going to be doing this episode is imposter syndrome within the therapy process, which I'm really interested to know your thoughts on this. This is another one of your topics, Bob. Oh, did I choose this? You did choose this. Yeah, so you must meet people with this syndrome all the time in your practice. Yeah, I think we all have a certain amount of imposter syndrome. Do you have many clients that come in specifically through that process, though? Not. Maybe it shows up partway through. I wouldn't say people contact me with that being the topic of wanting therapy. But it sort of comes up in the therapeutic dialogue. Yes. Yeah. Yes. Yeah, I think so. It's become more and more that case with me, clinic. Can you hear that phrase much more? Yes. Yeah. I mean, I think the, I wouldn't say it's disorder, but the trade has been around a long time. I was listening on the radio to a famous footballer, Terry Butcher, is it? He was playing a long time ago for England. And I can't remember the Ipswich was the club. Yeah. And he was talking about imposter syndrome and that though he didn't know the label for it, that that's what he experienced 30 years ago. And he was talking about how he felt with all those processes. So it's become used more as a syndrome. I mean, I think you can have it at a disorder level and a trait level. So I think a lot of us might feel some imposter syndrome sometimes. However, it gets more fixed and you feel and think it a large amount of the time, it can become incapacitating. And that's when the problem is. So if we see somebody who's got an imposter disorder or even imposter traits, sort of person going to occurs of somebody who's got a tremendous fear of failure. Yeah. Somebody who tries to be Superman. They have a, you know, have a real appetite for being perfect, you know, and they deny, but however they also deny their success. So the sort of people who actually never feel satisfied even though they try to be Superman, even though they try to be perfect, they always feel they never are. So they have a fear of failure. Yeah. Do you think again, when you're saying you've seen a lot of this more recently or, you know, in the recent past, do you think again, that's got something to do with social media and comparing ourselves to others, that there's always somebody doing a better job than us. So therefore we feel like a failure. Well, Tony Butcher was a very successful hip switch player and also a successful international footballer in the 1980s, 1990s, before social media was talking about it. Do I think the advent of social media means that it's more of a common current source used as a term or I think we've always compared ourselves. I think there's always been that competitive investors, always been that sense of having to succeed. Maybe social media like a lot of these other mental illnesses or, you know, maybe it's come more accessibility to the media, but I think it's always been around. Yeah, I suppose, you know, looking at sportspeople or people that are, you know, quite high up in the field, maybe compare themselves to others. I would imagine sportspeople particularly are constantly comparing themselves to others. Yeah, maybe. So maybe there's something in it becoming more of a diagnosis through social media, but those sorts of people are paralyzed with fear. Yeah, people. Poster syndrome are always feeling they're not matching up.  Underneath it, they're always going to be caught out somewhere. Yeah. So I remember a table, I was listening only yesterday. That's why it's in mind. You know, even though he made it to the English international team, he always had a fear that Bobby Robson, who was the manager, would phone up and say, you're not good enough. I found you out and kick him off the team. So it was apparently guilty of success. You know, if you feel, I mean, it's very common, I think, a posture syndrome is that people feel guilty if they're successful because they don't think they are and they discount praise. Yeah.  It's interesting that the title of this episode, being imposter syndrome within the therapy process, do you think that the therapist is open to this as well? I'm thinking in my early days of practicing, I felt like I was going to get caught out. Yeah, I think it's like all these things we've been talking about, there's a continuum of health. Yeah. So I think there's trace and, you know, a lot of people on the neurotic level, I'm sure can identify with what we're talking about, however, if it becomes more fixed and more at a pathological level, where the level of functioning is incapacitated, I think this is far more problematic. Yeah. So, you know, I'm sure I felt, I felt many times the way you're talking about, has it incapacitated me? Has it impaired my level of functioning? Has it been a problem in my life? Probably not. But for many people, with it at a disordered level, they have a fear of being successful, have a fear of failing.  They are guilty of their successful. So when it gets to a level where it stops them functioning or they live in a world of fear or guilt, I think it's much more problematic. Yeah. So what would people come with originally in the therapy room? Because would they come with that? I think, like I said, does it kind of show up? Would they come with anxiety and depression maybe to start off with and then that unfold as the sessions go on? I don't think many clients walk in and say they've got imposter syndrome and that's what they want to work on. It usually comes out of other things as you start working through the layers of the onion. Yeah. So for example, in TA, they've got the concept of drivers, which is they're driven to be perfect. Yeah. So they have a fear of failure. And they also may well have imposter syndrome with that. So it might come out of the work that you're doing. Yeah. It's a phase which is used a lot in mental health nowadays and also in the media and also you're correct on social media and everybody knows what is meant by that term because I think many people can identify with that term in some ways or the other. Yeah. I always find it interesting when I'm having conversations like this with people about why some people are not others. And I think that's what I talk about in the therapy room with people where imposter syndrome comes up is everybody doesn't suffer from this. There's only certain people that suffer from it. Like you said it to be perfect driver or maybe if you've got a be strong or a try hard. Do you know what I mean? If you've got a try hard driver, you never reach the full potential because you're always trying for the next thing. You're always pushing to do more.  Well, our only decisions come from the impact of our parenting. Yeah. So, you know, as a psychotherapist of long standing, I come from the view that the past is played out in the present. Yeah. We are a product of our past. So our, or this syndrome that we're talking about will come from the impact of our parenting or stroke and significant other people. Yeah. Definitely. Yeah. It's carried out into adulthood. So if you're going to work with this type of syndrome then you have to go back to the past because the healing's in the past, not in the present. Yeah. So how would you work with people? Well, obviously besides just listening to their story and thinking, you know, about injunctions and drivers and all the things T.A. Thebes do. People with this syndrome usually have a distorted view of distorted view of reality or at least a distorted view of their self-image. So the first step would be to probably do some normalization work so they can start separating out outdated images of themselves to what is actually reality today. T.A. that might often be called contaminations. Yeah. So I'll probably start off there. I wrote out a treatment plan just before it came on air and that was my first place, normalization, decontamination work. You know, getting to the self-doubt that a person has where that comes from, looking for the critical controlling parent which has been internalized that they're trying to match up to doing some child ego state work in that area. But you know, in the end, this is all about how the pastors have been played out in the present. So you have to go backwards. Yeah. So another part of this work in the child ego state is getting to know the saboteur. In other words, that part that has to, not sorry, not sorry, not something to the imposter, sorry, that part that has to be the imposter. Now they have to be the imposter so that they don't get criticized. They don't get put down. They don't get humiliated. So they have to be someone they are because of the fear of that. So you have to get to know the imposter and make, I would say friends with the imposter, but it's actually come alongside the imposter to see what they're defending against. Okay. And once you can get to what they're defending against, then you'll get to where the healing is because the healing is in the shame, the humiliation, the fear of success, the fear of being themselves, that comes from a very early age usually. Say a bit more about that. The healing comes from... Well, if we get to the original place where the person, which is the younger child usually, is feeling so humiliated by the significant other person or where they feel shamed or put down or they felt they had to match up and be perfect, it's a dynamic. They're doing that because if they are themselves, that will not be good enough.  Okay. Or even if they compare themselves with other people, they're still making a judgment negatively. Yeah, yeah. So the sort of work you would do is you'd probably, you could do some actionistic work, to chair work, to cushion work, where you ask them to put part of themselves which feels so judged and put down and humiliated on one cushion and put the imposter on the other cushion and get them to talk to each other to find out what's the dialogue that's going on between the two parts of the self. It's very interesting. Because if you can do that, you're going to find out, well, hopefully you're going to get to a place where one part can forgive the other part or you're going to get to a place where one part can see that to survive, they have to create a part of themselves which was being an imposter, if you like, to actually protect the other part. Because the creation of this character has to be perfect, try hard, be Superman and everything else that goes along with that is a survival defence mechanism so that the other part is okay. Yeah. So if you can get to a place where they can understand that it's a survival defence mechanism in the service of survival of the other part in a healthy way, then you might get to some compassion. And if you can get to one part being compassionate with the other part, you're going to get to some healing, I believe. Okay.  Well, it's really... Well, no, no, well, let's get it back. It's really fear of failure. Yeah. I didn't say acceptance of failure. I said fear of failure. And the fear of failure is because the person is frightened of failing because of what will happen in their perception of what will happen if they get it wrong or if they don't match up or if they're not as good as Charlie, what will happen or if they don't get it right in terms of what the significant other person wants them to get it right. So it's a fear of failure because what will happen? It's not an acceptance of failure. Now, in that might become... You're correcting one way because part of the therapy might be they have to accept that they're not perfect. Sometimes there will be failure and have some normalization down that road. As important as that road, though, is what are the consequences or the perceived consequences if they're not Superman? Yeah, yeah. So what they could say, well, if I'm not Superman, I remember every time I got home, I got chastisised for not getting things right. How come you're not XXX? So I decided to be XXX. Even though I felt I wasn't. Yeah. So they carry a fear of failure with them. They carry a guilt if they're not successful, or they might even carry guilt for being successful because they know underneath it all, they aren't really. Yeah. Yeah, it's a very... knotted up place to be if you are because it is the fear of failure, but it's also, you know, learning to accept that that is part of... We can't all be successful at everything. We've all got unique skills and traits and... Yeah, but that's what they didn't have. They never had that permission to bring themselves. They never had the way that you were talking. Yeah. What they heard all the time was the opposite. Yes. Yeah. So you need to get to the emotional feelings that I think are underneath that process. Yeah.  Now, working with these types of people, it's just a bit like a knot because they discount praise, for example. Yeah. And they don't find permission as easy to take. So they do need to get the sort of the narrative you've talked about just there, which is the permissions to be and all the things you just talked about. But as in most therapeutic processes, the quality of how you do this is another story. So timing becomes the key. So you need, first of all, I believe to get to the consequences for not matching up. And then you'll do the permissions later. I mean, you can, you can save permissions, but if they're so frightened, they could be so overwhelmed and frightened they can't even hear or take on board. Or it's like being in the alien land, you know, there's only a land on the moon where permissions, it's just you have to go somewhere before you go there. Yeah. You should do a podcast on the use of permissions because I think, you know, permissions are vital in enhancing health. But actually they need to be given in the correct time in terms of healing. So the therapist, sorry, the client can hear what you said in the first place. Otherwise, it's totally counterproductive. So permissions, correct, I agree completely at the right time in the therapeutic process, which isn't at the beginning of therapy. No, no. And I agree completely what you're saying about, you know, it will, the discounted if there are any permissions or, you know, praise or I don't know, conflicting information from what they've got, then yeah, they won't hear it at all. Yeah. No. So these types of people might also, you know, they've had to create an imposter to keep themselves safe. Yeah.  So you get to have to get to that dynamic, I believe in terms of the healing before you go other places. Yeah. And you know, one of the other things that I often talk about is being compassionate, like you said, with that part of yourself, but it's there for a reason. It was there to protect you and it's a survival mechanism. So there's a point to it. It's not, it's not a, you know, a useless part of you. It was there for a reason. Yeah, that's a really, really important place to get. Yeah. That process. And in fact, as with many, many other areas we'd be talking about, if you can help the client be compassionate with themselves, then you're halfway there. Yeah. Do you think compassion comes with understanding and awareness about where these things come from and why they are part of us? I think therapy is one of the few places where you start to build awareness and understandings of how our past impacts on our present. You know, you just think this is just who I am. Well, it's like saying where does empathy come from? I tell you what I think about compassion is that compassion, the development and compassion, which I believe is interesting in the human organism. Will only come, I think, through awareness and understanding of a person's past. Yeah. So it has to come through, I believe, that process of going back to the person being more aware. But also there's nothing about compassion. It's that compassion from the therapist is vital. I think as a model of how to be, as a model of a different emotion. Usually with compassion though, especially with clients who have really toxic histories, it's completely unalien to them because they've never been on the other end of compassion. Yeah. But compassion is the way to the heart. So I think therapists model in compassion is a very good bridge, but it takes a while. Yeah, because again, it can be just discounted or not, not really paid. That's right, or it can be too overwhelming. Yeah, yeah. So the client is overwhelmed by the compassion and they then close up or move away. Yeah. But compassion is vital, I think. Such as empathy is in the working with a healing. Yeah. And again, I completely agree about if things like compassion and permission are too early in the therapy process, it can be overwhelming and the client can shut down. They might disappear, they might not come back. Yeah, well, that's absolutely true. So if you're going to be a therapist and you will be trained, hopefully in all these things, but you know, there's a whole therapy movement around compassion. Compassion focused therapy is a very big movement and the whole psychotherapy training in itself. So we know that compassion and empathy are really important in the therapy process, but the delivery and when you deliver compassion and empathy is another story. Yeah. Now with the imposter syndrome, you know, I am with you here. Once we've done some sort of normalization, help them become aware of, you know, it was in what helps ensure if you'd like, but it's a choice to keep themselves safe by creating another part of themselves, which was, we might want to call imposter, but it was part of themselves that actually was really vital for their well-being. Once they've got that sort of understanding, take down board, so they're not so persecuted themselves and they can move to see this as a sort of more of a compassionate approach, then healing will happen quicker. Yeah. Yeah. Because again, it's a deep rooted part of their self, that imposter. So you have to get to know the imposter, to get to know the other self that has been protected, if you like. Yes. Which is nice. It's quite an endearing thing. That's why I think two chair work is very a good technique here to separate out the two parts of the self. Yeah. So that the person may get to some awareness of one part is protected on the other part and that it was a survival process and something they should be proud of rather than feel so abhorrent. Yeah. Which is interesting because that's the topic for the next episode, Bob, is techniques and one of them being two chair work, which is something I've not done in the therapy room. Wow. I know. I've observed it. I've, you know, been part of it in my therapy training but not actually used it with clients. Well, it's very, very common actionistic technique from Marino onwards. So Marino was the father of psychodrama. Then we go up to Fitzpulse and Gestalt Psychotherapy used to use it in his methodology of top dog. Yeah. And then transaction analysis, which used that actionistic technique a lot in the parent child dynamic and it's been used by many of the therapeutic models. So it's a very well known and I think a very powerful and useful technique for therapists to have. Yeah. In their toolbox. And I think with the imposter syndrome, which is really at its heart a conflict between two parts of the self. It's a really useful tool to use. Yeah. Because you can set up a dialogue between the two parts so that you can get some normalization and work perhaps to what you just talking about earlier. You know, a level of self-awareness that this was a survival process rather than a sort of abhorrent process or a duplicate part of themselves that this, you know, should be compassion oriented. Yeah. I'm all for compassion with ourselves. Yeah. How do you get there? That's the bit. Yeah. And, you know, one of the things I often say to clients is that if we knew a better way of doing it, we would have done it. We do the best that we can with what we've got available at the time. And these decisions are made really early on when we're young, we haven't got the life experience. So we do the best that we can. Yeah. And we started off by saying very rarely to people come in and say, I've got imposter syndrome and that's one to work on. But what they will often come in and say is, you know, I need to find myself because for the last 30 years, I've been playing someone else. And I have got to a stage. I need to be myself and find out about myself. They may say that, for example. Yeah. Yeah. Or I feel like I'm not being authentic in my work or relationships. I'm not being who I really am. Yeah. And the next bit is, a therapist needs to say, and if you were who you really were. Who is that? What really happened next sentence is I don't know. Yeah. Lost all sight of him. And then the work is about helping the person find that part of himself. Yeah. I hear that a lot. I have no idea who I am. The question then, well, who have you been then? Now that would probably lead onto a fragmentation of the self, which we can then might lead to what people call imposter syndrome. Yeah. Which is one part guarding against the other or one part protecting the other. Yeah. That's it. Guarding, protecting whichever way you want to look at it. It's a good thing. Yeah. And what we're talking about here is so common in the therapeutic process that most people, I think, deal with fragmentation and conflicts of the self most of their time in the therapeutic process. Yeah. So I hope that's been of interest to the people that are listening. It's a very tangled thing being a human being. We are very complex creatures. Yeah, we are. Absolutely. Yeah. We'll stop there because I could talk. We are very complex human beings. Yeah. Yeah. That's what I love about human beings. We are very complex. Right. So until the next episode, Bob, we are going to be looking at techniques within the therapy room and particularly to chair work. Okey-dokey. Okey-dokey. Speak to you soon. You've been listening to The Therapy Show behind closed doors podcast. We hope you enjoyed the show. Don't forget to subscribe and leave us a review. We'll be back next week with another episode.