 All right three up to the hour when I go to get started. We have a really low attendance today only 11 people It's kind of odd for us. Anyway, moving forward Let's see nothing exciting on the AIs actually maybe I should ask the question so Clemens you have two AIs out there do you plan on working on those in the near future Well the first one we can that's that's a very old you can probably strike that okay I can do that This extricate click what that means You can do it there we go Yeah, we can strike that too you sure okay, I don't mind doing that Okay, thank you, sir All right community time Anything any topics from the community that are not an agenda that people like to bring up all right moving forward then SDK working group I don't remember what we talked about last week if it's anything worth mentioning Scott or Cummins or Gaby or anybody who's on the call anything worth mentioning there. I can't remember Just got a business as usual trying to look for people. I have a survey out. I'm still collecting feedback. I've had several responses and Not a lot of people are using the SDKs which is interesting Yeah, I don't know what to make of that but yeah Okay, well is there anything you want to Anything worth else worth mentioning or asking of the group of them to look at your survey That's In so I've been working on the conformance test The the idea is that I'm making a very very lightweight HTTP Sender like basically the goal is it's gonna be a tool that you can point at a Active HTTP server and give it YAML files that are kind of like the conical form of a cloud event and it'll turn it into an HTTP post in the goal is that it will You'll send it back to some sort of active endpoint on the conformance test and you can compare That loop back is working So that's okay. Let's work happening in the conformance test and I have a PR open right now Okay, cool Any questions for the SDK group? Okay move forward I Did ask to get on the TOC schedule so it could put so we could show or I'm sorry so we could ask to go to incubator status and Chris and a check put us on for the September 17th TOC call Still looking for more end users. I know there are a couple of people are still investigating that So please give me that list when you get a chance I have not added our charts yet to the agenda doc But the charts are still linked in this link right here If you have any proposed changes, please let me know. Otherwise, we're going to go with pretty much what's in there and Then moving forward to cloud San Diego. I did put in a proposal for two 90 minute sessions went for serverless over cloud events The I Have not uploaded or created a Google Docs to sort of Start brainstorming on the specific topics and who's going to be saying what and who's going to be talking stuff like that yet I am planning putting that up this week so that we can start Gathering our ideas for what we want to talk about there even though we have a you know sort of a rough outline already But that will then allow us to then you know get people to sign up to That's do the talking so look for that later this week All right before we jump into PRs and stuff any other topics people want to bring up. All right, let's jump into it So this one was from Tim and unfortunately, I do not see him on the call Let's see here All right, he took an action item to modify the definition of a string To limit it or to bed get a bit definition for what it means to be To have the printable character set and this is basically what it came up with I'll give you guys a second to read this in case you haven't had a chance to read it yet. All right Any questions or comments on this does it seem like it's Head of the right direction It looks good to me look good to me when it looks at last. Okay, cool. Thank you comments. Anybody else have any comments on this one? Any concerns? Okay Any objection to adopting this done? Easy. Cool. Okay. Thank you guys Oops All right Evans PR Let me first hide the comments See okay, so I don't think Evan some call. No, he's not Scott Do you do you want to talk to this one of you now follow this one? Did you want me to try to explain what's going on here? Yeah, I think this is basically just trying to use the same technique we're using with Content type for binary encoding for HTTP for the payload for the data content encoding So content encoding is already a valid HTTP header we're We're trying to redefine what that term is but for binary Mappings we should just use the normal HTTP header Right Let's just see so there's this change here It's basically says the two attributes HP version versus the cloud events version map back and forth between each other and then This section down here But this is an HP header values So this is an HP spec. He also talks about percent encoding these to be headers Are you guys a second to read that and then He's talked about decoding there section here I think that's basically it any comments from the crowd on the stuff Nothing at all. I actually wonder whether this is accurate Yes, that is right well, I know that they that they that there is a correlation between the two however It's that is exactly that is exactly what it is. So there's a I'm in parallel In responding to the other issue that's open with data transfer encoding and and that's a misunderstanding Because there's a content encode. So what we map to is and this is what the spec literally says we're mapping to RFC 7231 we're just mapping to we're mapping a cloud event to an HP message. We don't do anything else Data transfer encoding is RFC 7230, which is about how HTTP functions and That and there the data transfer encoding is about whether you compress the content that is completely orthogonal to this So data transfer encode so content transfer encoding is in in so with with what we do here we're mapping to Both HTTP 2 and we will back to HTTP 3 and we met map to HTTP 1 1 because we only really focus on mapping to the message The transfer stuff is all specific to RFC 3230. It's 7230 is all specific to HP 1 1 and looks different in In HTTP 2 and HTTP 3 So this is the right mapping. So I think I was looking at things from a slightly different perspective And correct me if I'm wrong here because I probably am but if data content encoding for the structured format of stuff is Base64 because it's binary data and you can't put binary data into an adjacent string, right? When you then convert that into the binary format for cloud events Correct me if I'm wrong, but wouldn't You just put the raw binary data into the HTTP body So therefore you wouldn't need content encoding Yes, but you might so With content encoding so content encoding is this specifically in HTTP. So you can do base 64 But you need to know how to decode it Doug like on the other side No, no, I get that and I'm not I'm not questioning that there may be times when you have it What I'm wondering what I'm saying is You may not just because you have a data content encoding value for the structured does not necessarily mean that you have to have one For the binary format is what I'm trying to say. Yeah, but that's the that that is what that field is for in In HTTP they have that field Right, okay, let me now in values is Blank and not there or base 64 Yes, right, but I okay the meat phrase I'm thinking differently because I'm not getting the words out right what I'm saying is Between binary and structured formats You may not necessarily have the same value for data content encoding. Is that true? So so what you can do with game? So what you can do with content encoding is we were actually leaving that open the spec We say you must support base 64 Right. Mm-hmm, but it's also possible that you that you in that express other values that you use as extensions so for instance in In in RFC 32 it's 72 31 You can also for the content encoding use gzip I'm not sure that's related to what I'm thinking though, but but that's what this field is for No, no, no Wait, but do you agree that? that you may need data content encoding for the structured Cloud events or you may also you need it for binary. No, I understand you may But just because you need it for structured does not necessarily guarantee that you need it for binary No, it yes, but this mapping is correct Right, and I guess what I'm wondering is whether we need additional sentence here that says Just because you need this for the Jason serialization does not necessarily mean you have to then Base 64 encode all HP messages in particular in the binary format Yes, yeah, okay So so if if the sentence leads you down that path then which then we might go and amend it Okay, that's that's what I was worried about was Just because you have any one format doesn't mean yes I have to have in the other because you don't need to be okay, so that's okay great Okay, because it's it's a legitimate so it's legitimate to use the this field to To basically express how you've encoded the binary the the binary Beyond just stuff stuffing raw bytes in there, right? It's okay. So even though even though the other side may not necessarily understand what you want to express because you know That's extensibility is great. We may want to go and use a fixed future It's okay to say Jesus. We have not specified that yet People should not should not get worked up worked up about it But that's where you would place. That's what where you would place agreements about compression right now We've been we've been using base 64 as the one thing we think is necessary But compression all those things would would go here Yep, I understood. Okay. What do you do is what you do to the binary? Yep, okay So I'll tell you what on that particular point. I'll follow I'll do a follow-on PR I think this might be interesting text for the primer and I say this back. Yes, I'll do a follow-on thing about that. Okay I think these are all data. So what about this section here for? For presenting coding each UP headers you guys okay with that. I'm wondering do we actually need this though? It since we just accepted Tim's PR Um What did Tim you you can't put utf-8 in headers? Yeah, yes, that's right Well You can't and you can so By the so this is this is I think this is where we have the So you can't put H2 you can't utf-8 in headers is correct. You can't actually put anything but seven bit asking headers but Contemporary implementations Let you so And you know and people put strings in there And they don't think about the rule very hard And they stuff is utf-8 stuff in there and then they pull it out as utf-8 and it kind of works Even though it doesn't work at the standards level Um So that's I think that's mostly what the reality of that of that often is is that It kind of works and it doesn't so here I'm okay with introducing. I'm kind of okay with introducing that rule I'm not sure I'm not going to put opposition up. Let's put this one. Do people need more time to think about this? Well, the rule is pretty clear in the hdp and that is you can't have anything but seven bit asking Which means We'll have to have some kind of encoding and a percent encoding is the closest thing But then then the question is, you know, does that actually catch the Does that actually catch the the unicode set like so, how do you how do you encode a Can you encode a unicode character without a utf-8 character character without? Is that clear here? You would do with like a slash you right like like what tim is saying Yeah And I think that's so so I think I think tim has has this So I wonder whether we need this here here too because tim has as I think so Tim has that Although I don't I don't see slashes in this Yeah, exactly. Just I think those two things are Are not aligned this one and tim's one So Okay, sounds like then we may not necessarily be ready to adopt this one if they're not aligned Um, could you clemens at a comment to explain how they're not aligned and into the pr itself? Yes, so since evans, I don't think it on the call yet evans is not on the call So hold on a sec The italic pipe is throwing me off Say that again One of the valid characters is a pipe, but it's italicized. So it kind of looks like a forward slash Okay Uh, let's see if there's anything big on here What about the decoding side of things? Which is the next paragraph? Is that needle alignment as well with clemens? well, that's If you if you if you must encode If the rules that you must present encode then of course you have to go and do presented decoding Yeah, like I thought I was wondering whether there's explain additional text needed there based upon tim's pr or the Yeah, we need I need to go and take a look at that in context. Okay Anybody else have any comments or questions on this? You know what was already said And I'm sorry that I didn't catch that in earlier No, that's okay. Okay. In that case, we'll have to delay this one till next week to continue on I actually think that's it in terms of open prs or version one. So that's good. We only have one right now. However We do have a couple of issues that I wanted to get people's opinions on Um, because I thought if they actually required change to the spec they needed to be in there before 1.0 So there's this one. I'll let you guys read it And you're right There's there's a title in the first section basically wants to extend the data content encoding to have a list of transformations Instead of just a single transformation Is that supported by hgp natively? You know, I actually looked at the spec this morning and I could not figure that out. Um Let me see Because I I didn't when I look at the schema for the header It didn't show a list there But I know in general you can have the same hgp header appear more than once But I couldn't find any text that said the second one overrides the first or whether it appends it to some sort of list I I was only skimming over very very quickly Because would you happen to know? um, there's a rule That says If one or more so hgp says because I just have that right here If one or more encodings have been applied to the to a representation Um, so that's payloads That's the hp lingo for payload The sender that applied the encoding must generate a content encoding header field that lists the content encodings in the order in which they were applied Hmm, so it does support a list Yes, it does support a list Is it this format right here that he expresses in this one? Yes, it is. So, I mean we I think in the spec we literally refer to the hgp spec at least At one point it did. Um, can we go and take it? Yeah, because we do refer to Some section Certainly when I straight See what threw me off was when I looked at this section right here It doesn't imply the mechanism was a list. It applied. It was a singleton Oh god That's actually that's a mistake In a way in a spec or in ours this this this link is wrong Okay, you go back Because that's that's that was that wasn't that was wasn't meant to be that rfc I think I I think this is my I think I wrote that The cat is complaining too That knows all Five minutes to bells Oh Yeah, exactly five minutes of bells you already know it This is the wrong this is the wrong rfc for the hgp is now 72 31 72 31. Yes, that's the that's the message called the message That's what we want So and this is so So that's my this is actually my mistake And now I understand why the confusing confusing confusion exists In this in the pr 477 So that's that's the feel of actually mean to mean to bind to Well, but even this one has this Yeah, I know Which doesn't apply a list to me Um, no, no, no, no, no, you look look at that sentence if one or more encodings have been applied Oh, uh, hey So if one or more encodings have been applied to a representation the sender must generate a content encoding Had our field that lists the content codings in the order in which they were applied. Oh, okay So That has a list So basically you're saying if we change the reference to this section here, are we maybe okay? um Let me There's So we we we have a mix of what hgp does And what smtp does they have So for the case that we have binary This is this is now getting a little weird I may have some I may need some more time to think about the details. So in the case we'll have binary I want to be able to do exactly what's set here That which means I want to be able to declare this is gzipped and go and use gzip Oh, if you go and look at 72 30 And search for what this is the so 72 30 is is the Is effectively the transport the transport thing That has a transport content transfer encoding Don't forget where that thing's defined. I always see two references in it here. I need the one actually defines it Well, that's a transfer encoding No Okay, this is me thinking out loud. Well, you all listening that's It's always scary Which which also which also destroys the myth that I know all they are sees out of Up the top of my head Um, hang on So that is actually an 89 You want to take this offline Do you do you want to take it offline instead? Uh, see while we're while we're a small group and we still have half an hour Sure go for it Okay great So Htp does not use the content transfer encoding field of mime. So the thing that we refer to This here right is Is not in h in in htp but there is a transfer encoding field And the transfer encoding field in in 32 in 70. Okay. Now. Now i'm okay. Now i'm back on but now i'm back on track so Sorry for the confusion So this field This meaning which Okay, so this field is we're using this field in the meaning of of mime which is This is text. This might be this might be seven bit ascii and we need to go and tell you um How specifically we're encoding something that's not seven bit ascii And and we're using this specifically if we want to stuff um Binary's in strings That means that correctly Um the mapping the sentence that we have in the spec is indeed incorrect in the htp spec is indeed incorrect Because that should not map Meaning this this link here is wrong No, no this link is correct. Okay Because that's what we we mean we so So smtp when this comes from right has can only do text And you have to trick it into carrying And you know old versions of Well, it can only do text and so you have to trick it into into carrying something that is more than seven bit ascii So you're effectively telling it a look at this look at this encoding field This is what you find in the in here. There's no seven bit ascii. This is actually something else That's what this this is what this is used for and that's also What we're using that for so we're basically borrowing from the mime spec this notion of encoding and base 64 The and we're explicitly referring to it because base 64 that encoding Is normally normatively defined over in that section. That's where base 64 literally comes from Okay, yeah, so base 64 base 64 is nowhere but here and this is why we why we refer to that spec now the the the transfer The content encoding of htp Is a different thing for which we don't have a field for yet The so this is so our data content encoding is specifically only for this for the case where we put data into in structured mode into a Data where we where we put the string into data But the string really is supposed to be a binary Are you basically saying are you basically saying that this should technically be called data content encoding no, no, no, no, this is We called this well we can call this data content transfer encoding if we want to align with rfc 2045 yes well, because well the reason I say that is because This implies to some people it's the htp header content encoding Which is a list and your rates and I think what you're saying is no no We don't want to list. This is strictly only for the binary case And we're stealing data transfer encoding or content transfer encoding and therefore To avoid any possible confusion if you put the word transfer in here you avoid that Yes, that's right. So that's that that's correct. And then and then you also we also have clarity That because htp explicitly says no, we're not using that field And then we can remove that mapping Remove that So the mapping that you showed earlier In our htp binding Are you talking about the other the other reaction you're talking about this stuff? No, wait Then in that I think we I think we found that there just now actually This actually might be more closely related to Fabio's question Should data content encoding map to transfer or actually because this is related to that. Yeah yeah, and because That's the funny thing so can data That field that he says we should map to it does not exist in htp So Let me ask a totally different question Should we try should we stop trying to reuse words from other specs in this particular field and in particular Turn this into more of a More of a Boolean And say are using base 64 or not Or do you want to or do you want to allow for other types besides base 64? uh In this day and age, I'm not sure there's a Someone is that you you know that next year someone is going to come up with an emoji encoding which is a magic way to go and encode binary in In utf-8 in a super compact way and then we are missing out on it I have it. It's called face 64 Great Well, what what if we okay, what if instead of a Boolean we'd still allow it a single value in there But use a different word or phrase other than content encoding since it's gonna apply something we don't mean to apply Yeah, I think I think that's probably that's that's um Yeah, that makes sense Because that eliminates the confusion I mean we could just drop it to data encoding and I think that's We went through some we went through some Discussions so alan came up with alan conway came up with that field Yeah, I think data encoding is good So let me let me back up just a sec at least from my own understanding is Is the text in this part of the spec that I've highlighted here is all this text Correct and it strictly boils down to the name here is misleading people Um Almost yes, so I would so what I would do is I would do two things. I would strike content Of the word I would I would rename this to data to data encoding And I would I would drop the first reference I mean that so the this reference is exactly okay Um, I would but I would leave the base 64 encoding as defined in I would leave that um Why would you drop this reference just out of curiosity? Because we only we want to constrain the basics for do we Well, I thought we wanted to support face 64 Yeah, but we need to go and point to be able to point to base 64 and that was the That that's the that's the reason why I would still point to that rfc Well, okay, so we do point to it here, right? Yes So, okay, so you okay, so you want to be able to say you can be any string not just Yeah, it could be any string but different space before than the spacey four as defined here got it Okay So we're think I think we're talking about dropping the word content Dropping this section to loosen it to make it even broader set of strings But keep the reference to defining base 64. So we have a little bit of interoperability Yeah, and I suppose Drop this So at least got the reference and then and then and then we still need the String We still need to have a have a sentence that says, you know that base 64 is the string that is like this is not clear yet It's this attribute to support the base 64 encode. Oh, maybe must be supported Yeah, I think that's that's the I think it's sufficient Okay, so let's pause there for a second and get opinions from other people in the group Let's pick on scott first since you've been speaking up a little bit about this What do you think scott? It's getting complicated Well, I think the conversation got complicated. I'm not sure the the net result is necessarily complicated. Is it? I mean, do you think read the rename? Will Complicable will clarify things or make it more complicated I I liked the pr that evan sent But I don't I don't have as much detailed knowledge of all the rfcs as Clements does well, I don't think it's necessarily changes Evan's pr. This is something different. This is Do we this is a question about whether this is meant to map to hgp content transfer encoding? Yeah, or or hgp content encoding You know or any or neither Yeah, it maps to neither. So we we're actually discussing discussing a separate issue now Yeah, I see I see I see We're at anything we're actually discussing this one right here. Oh, no, well did this one in combination with This one, I think it gets tricky because we we might be talking about the rfc For transfer encoding if it's htdp binary, but we're not we're not necessarily talking about that as As part of the spec but part of the binding So like in in structured mode data content encoding does not mean that and it shouldn't be mapped to the header Because we're gonna have a string inside the json payload that is basically c4 encoded Yeah, when that thing gets converted to a binary htdp request We should pop the quotes off the the json base 64 string use content encoding And then provide it but the thing is like you You might lose the intent of the original sender if they want the the data sent as base 64 encoded In the next conversion, we don't we don't necessarily know that The original request was supposed to be base 64 coded. So Version to structure it might be something completely different And you're right and and for that exact and for that exact reason We need to we need to remove the mapping because H so we and we need to we need to disambiguate the field and we need to remove the mapping because What we're doing is we're we're allowing a cloud event to go through htdp Where we leave the choice that you if you want to right you can still have a base 64 body and then this field says Well, this is a base 64 thing you should go and interpret that as binary Or you leave that off completely this field and then you encode it as binary So we're effectively now giving you both choices also for for htp, but That means because that this base 64 encoding thing is it's not a concept that htp supports in its Content encoding field which exists But that's really just for jzip We're now having we're now we now set ourselves up with a with a collision just by choosing that name So if we just call this data encoding Then it gets and we don't map it to htp Then it becomes in htp becomes c e dash No data encoding and it goes from from one side to the next And then there's clarity that this is really cloud events concept Yeah, that sounds good and that that prevents us from needing to try to understand if The content encoding gets of gzip propagates because the transports shows some optimization Yeah, exactly. So in for so for that hop over gzip It's perfectly fine to use the content encoding gzip But that if doesn't affect the cloud event at all Because it will pop out out of the gzip transfer and just look normal I also like the dropping content from data content coding right so So that's a slightly different question. Make sure I'm completely following all this Data if we rename this to be data encoding Am I correcting that we do not need to make it a list it can be a singleton That's correct Okay Okay, so Anybody else on the call? I'm tended to pick on somebody. I'm a little afraid to Anybody else want to speak up on this one? Does anybody else listening? Say what let me pick on somebody just because I want to get them on the attendance list Klaus Are you were you following this one? I'm mentioning the attendance list. I knew you would pick me. That's right It was really hard to follow all the discussion I have to admit I think well and of course it's painful to think of another field renaming But still I think it seems to make sense from what I understood. Okay, fair enough Okay Is there anybody that's wanted to volunteer? I won't pick on anybody else yet. Anybody else want to volunteer to voice an opinion on this? Okay, not hearing anybody I'm going to assume then that this general direction sounds right and Clemens can I ask you to take the action item to To produce a pr that sort of resolves all this in one lump sum? Yeah, of course. Yes, of course I like that of course Okay, so hold on a minute. Well, which one we're talking about Okay, okay. So let's see what we talked about here. So we do data Content encoding to just data encoding Just drop ref to Go away All right, the zoom thing. Well, there's no way to pick the zoom pop up Thank you. Hold on Okay, so drop That there's two of them And there was something else you were going to do. Um, uh remove the mapping and it should be Oh, yes. Okay Anything else Uh, it's to the one right below Fabio's Okay, anything else? Okay In that case, since we're talking about uh this section here, hold on. Um I don't have that one there twice. I shouldn't be there. Okay. Um okay Anything else on that topic related to data content encoding? Okay Let's see if we can move on to Evan's PR about tricky cases Now keep in mind this is all non-normative stuff, but we do need to make sure it's right since these are guiding examples Come on. There we go So back to Clemens. I'm not Clemens at Evan's PR Did people get a chance to look at this one? I think he made some very very minor typographical fixes last night I don't think he made any semantic changes um Actually, Evan uh, Evan Clemens question for you here Will your pr that you're writing up? I assume it's going to modify this not just the type or actually is it just going to be Um Yeah, it's a name change and that's it. Yeah And it so he would still say So in binary format, you still would expect to see base 64 Uh, no, um Uh, yes, yes, if if that yes, if that's if that's what he wants. Yes, okay Yeah, that's the key phrase if that's what he wants. Yes, but it is completely optional If it said if it says that then the expectation is that the content of the the entity body is um It's base 64 string Actually, hold on a minute. Actually, I'm sorry. Well, it's it's a base 64 encoded Of the whatever the content type is yes But and if this doesn't make sense. Well, then, you know Well, would this would would this be the hd would would it be a ce dash or would it be an hdp header? No, it would be it would be c dash. It's a this is now that we now that we made it a data encoding thing It would be it's it's purely a ce metadata. It has no lower anything to do with hdp Okay, actually I take it back Clemens if that's true Uh, I think a lot of parsers will have a problem if you send in just The a non-coded base 64 encoded JSON string as the body but content type is application json I think it's gonna have a bad day. I would think so too then we That's why I'm kind of wondering whether data content encoding only shows up in the structure format. Yeah, possibly Yeah, I should actually that's right Yeah, we're not only do we do we map we remove the mapping we actually just allow it Okay, so I think more thinking might be needed on this one. So Remove mapping hd Yeah, okay. Great. Thank you. And I will see it 477 I'll have something for that soon. Okay. Thank you. But today but tomorrow Hold on. Yeah, 477. Okay. Yeah, so I think there's one pr is going to cover a whole bunch of different cases all in one Should be good Okay Um Uh, I thought there was one of the ones I wanted to talk about I think Christoph is looking at this one. So I don't think we can discuss it I think that's it Aside from possibly the web hook spec was I think is an ai for me to deal with not anybody else yet Okay Uh, I think that's it for the agenda. Are there other? I'm sorry. Come as we're gonna say something Yeah, the web hook spec thing. It's like I don't know what I don't understand what the motivation is for that for moving it from the set because we're apparently all doing hd posts deliveries of hdp, but I have a for long polling Huh, you can long pull a target and get cloud events out of it No, no, of course. No, it's not this is not the only way. This is why the way is a separate one, right? The web so expect is one way we can do these things and this is what so so the hdp spec and the web hook spec are separate specifically because I wanted to make sure that the You can just map the the cloud event onto an hdp message And independent of the direction right the the hdp messages are the same for requesting responses um other than the status line versus the press line and That some headers are allowed to know a lot, but the rest is all the same So that's what the hdp binding does and then for pushing stuff out That's what the web hook spec covers and we don't have anything for solicitation of events. That's right But that's something we could go we could go and add but but for delivering Events via push the reason why this but web hook speak exists because there is no such common spec and that's why some of the web hook people Like from github and elsewhere showed up and said hey, it's great that you have that that you created a spec like this Which is you can go and take a look at the the pr for it now um I have I have talked to some of the folks inside of microsoft because of this this issue um on whether we could go and find a home for that maybe elsewhere and there People have been thinking about what the venues are the biggest issue and that might be that If we wanted to go and you take the spec and then move it into a more appropriate place, maybe w3c Or itf then there remains the issue that this is Now owned by cncf and we can't just you know move it Yeah, I think that's where my initial Thought process was on opening up this issue at all was is this the appropriate home for it because I do see value in the spec There's no question about that. It's just whether the definition of this is out of scope for us So there's a so there's a there's a spec project apparently that I learned about inside of inside of the linux foundation Which is you know all the gran if the grand umbrella which is specifically existing for things of that sort But I have not Done I've not followed up on the investigation to see whether we can go and move it to a different place Ultimately, it's just a question of of whether it should be home So that it gets more Audience but we're doing eventing here and that's kind of the the primary use case for a spec like this So that's why Even though it doesn't have a clear time into the payload Um, that's why it makes sense to have to have here if we remove it then there's a all the things that are in that spec Are all about you know creating a profile of hdp that helps interrupt If we remove it then all those constraints for a drop are gone and We're still having the issue of like how do how do you do off? And how do you do abuse prevention? Like all the things that are specifically addressed here are then again left up left to It was speculation and mutual agreements and that's what I wanted to avoid with this All right So anyway, I think the net of this is I think between the two of us Sometimes we have an ai to figure out what we want to do whether we want to propose to keep it here Opposed and move it and we can take that offline Yeah, okay, okay Okay, any other topics for the agenda since we're almost out of time Okay, in that case, let's just finish up the um Agenda stuff Um Doug are you there? Are you still there? Doug again Mark's on yep, we got your mark Doug you're still there. Here you come off mute Come back down a sec. How about christian? Double muted. Okay. Okay. I got christian. Was that dug in there? Yes here as I thought cool and dan barker Yeah, excellent. Did I miss anybody? Okay, got you dan. Did I miss anybody for the attendance? All right, cool. Um, just since we have a second here, uh Kyle you still on yeah, you are Kyle um If you hope you don't mind and you feel free to to say you can't comment that you can't comment But are you guys actually using cloud events or are you still just sort of investigating it? Just investigating it. Um We're we're trying to move to a more eventive reactive architecture and this was suggested to check out Okay, the reason I'm asking is because I I get the sense that your company would fall into the category of an end user company And we're looking for end users to say yes, we We use cloud events So if at some point you you feel like you can say that without lying Please let me know so we can add your company to the name to the list assuming you're okay with having your name in there Well, then okay, cool. Thank you All right All right, anybody else on the call for the for the attendee list I think I got everybody All right in that case. I believe we're done. Thank you guys. I'm a little bit early today. We'll talk again next week. Bye everybody All right. Bye. Thanks. Bye. Thanks, Doug