 Hey everybody Hey That Vlad Yep, that's me And I'm gonna join both by phone by phone and by laptop because I'm having some issues Okay I can never tell when I look at it on the screen is the first letter of your last name in L or an I It's an eye. Okay. That's what okay, and Clemens. There's that you I heard in there Okay, you're very faint and Joe you there. Yes, I am Is a You feel like that, okay Okay, um Thomas you there Yeah, I'm here. Okay Is Snidya, is that you Vlad again? Or is that someone different? I doubt that's me. Okay Charlie, are you there? Yes, I'm here and which company are you with Charlie? I'm with a company called fine design group Prime fine like F. I and E. Oh fine design group. Okay Thank you Let's see who else Oh, they are glad to see one of the ones now. So there's someone in there with the name of Sinadia Alberto Riccardo from Sinadia. I got it And this is Collins all of them from Sinadia. Yeah, we're on the Nats team. Oh Okay, cool. You guys can fill in your last names or at least one of you on your last things on the agenda I'd appreciate that so I can get you guys in the attendance John are you actually there? John Mitchell you're there. Okay. We're both Oh, hey, John. Okay, what about Varun? Okay, not wrong. Thank you Everybody's early today. Maybe we're still in dinner time In that case you should be drinking Hey, Dan, which Dan is that the Dan Barker or Rosinova John McCabe you there? Yes, Mike. All right. Hello, Dan Barker you there? Can you hear me? Yep. I can't get you now. Thank you Going through the wrong microphone Barum are you there? Yep here Justin Conway, I got a lot of background noise. It may be coming from you Joe Justin Justin doesn't have a microphone yet. So never mind. I'm connected with Brom. Hey. Oh, okay, Justin. Got it. Okay. Thank you Hey Mark Let's see Bill fine. Oh, I'd already have you. I think they're mine. Or do I? No, I don't find you there. Nope. All right, which company you with Bill? Joints. Joints. Excellent. Thank you Yep. Oh, yeah. Okay. Thank you for the clarification Derek Are you there? Yes, and what's company you with? Senadia we Are the stewards of the Nats CNCF project. Got it. Okay. Maybe you could fill in your last name for me on the agenda. I appreciate that Let's see who else I'm sorry. What was that? Alex. Oh, hi. Thanks. It's Alex. Hey, Alex. Hey Got it. Thank you Let's see we got someone in there where that shows up is hard. Oh Richard gig Yeah All right, which company with Richard? Richard's probably and myself probably from my open fast Okay, are you doing companies projects? Yes. I'll just do the American and Richard's not at the end where oh, he's not. Oh, okay. What's companies in fast project? I would say it's probably more relevant It's not really a company though, is it? No, it's not a company. Yeah Anyway, Richard. Are you actually there? Yeah, me. Yeah, okay. Okay. Please. Okay. Do you want to be associated with a particular company? No, open fast, please. Okay. Don't worry about that one later. All right. It's us. What the people pop in there. Wow Hi, doc. Oh, I see. Got it. Make it easy on me. Appreciate that Charlie Pitkins, I already have you. Yeah, we got you in your mind. Sorry Ginger collision you there It's Collison. I'm sorry. Yeah, you're gonna learn. I am very bad with names. That's no problem. I'm with Sanadia as well Okay Let's see who else went by the list Sean Smith If I am with Oracle Oracle got it. Thank you Steve oh you there All right, thank you Is there anything I'm missing I feel like I miss my Collins. I'm not sparing a Collins Austin Hi, Doug. Hi, everyone. Hello You're Ron is here. Hey, you're on Hi, this is David Lyle. Hey David Oh Is there anybody I'm missing there's Mark Fisher and Juergen in Cambridge got it I could spell right It was Mark and who was the other one Juergen Leshner. I can take it in. Got it. Okay. Yeah, please help me up there It could get real ugly. Oh, thank you Anybody else on the call that we do not have yet, otherwise, I'm gonna begin momentarily And here's the agenda doc again. If you guys want to add your name to the list Just don't put an asterisk there. We'll get you on roll call later All right. Tell you what it's four after why don't we go ahead and get started So what I was thinking I'm sorry, so I'm gonna say something Okay, so today what I want to do is focus a little bit on A process for lack of better phrase now that we've gone through Our first major milestone zero point one and technically we may have actually reached zero point two zero point three And fair amount of zero point four I thought it might be good to revisit our plans for one point. Oh, which we did a little bit at the face to face So that's what I'm going to focus on mainly on the call today if that's okay with you guys And then we'll see how it goes. I don't want to spend too much time on it though But first of all, I wanted to let you guys know that on the toc call. I believe it's next Tuesday We are going to be giving an updated status on what we're doing here And I have a link to that in the agenda as well as our proposal for the cloud event group To become a sandbox project under the cncf We've been kind of very lucy goosey in terms of what we actually are because we're not We are part of the serverless working group, but because we're actually producing a specification It's a little bit fuzzy in terms of you know, what people actually call us and what our role is our classification is within the cncf So we've been asked to make it a little more formal and we decided to try to join as a sandbox project I believe the the biggest stumbling block for us to go the next level up, which is incubator would be at least three different Uses in production, which I don't think we have there yet I think microsoft might be the only one to complain that as of today as an official supported thing But anyway, we'll start with sandbox, but So i'm mentioning this to you guys for two for two purposes one, so you're aware of it But two To please look over the status and proposal itself mainly to make sure that one We don't have anything incorrect in there. We don't want to lie to the group in terms of our status and And what we've been doing But also if you believe that there's more information we can add in terms of Why the cncf should consider us for a sandbox project in particular around the alignment section of the proposal Any additional text you think might be useful in there? Just go ahead and you know either ping me or add a note to the pr And i'll get that added in there But anyway with that i just wanted to bring it up to you guys, you know for as an fyi kind of a thing And ask you guys to do with you when you do get a chance Are there any questions or comments about that? All right in that case next um Excuse me as I was going through the list of issues I came across these four that I thought could technically be closed because of mainly because I thought we covered it With other work that we've done Now I have made comments I believe in all these Saying that I think they're ready to be closed and no one's spoken up and objected and in some cases Some people have you know given a thumbs up to do it But I felt a little uncomfortable just going off and closing them without making you guys aware that i'm going to be doing that At the end of today So please look at these four issues if you believe they should remain open Just add a comment and I won't close it Um, even if for some reason you don't get a chance to do it We can always reopen them later But I just wanted you guys to be aware of what's going on with these four so that way it's not a surprise you guys You can close the two that I have on my list Okay, thank you Clemens Okay, so anyway everybody else please take a look at that if you think for any reason they should remain open Just add a comment and I'll keep it open But at the end of today is the deadline for keeping those or for me to close those just wanted you guys to be aware of that Any questions or comments on that All right, cool. Thank you. All right, so let's talk about Next milestones and as I said we start talking about this at the face to face for you know, what we want to do for 1.0 What I'd like to do is suggest a process where Oh, we obviously use github the way it's meant to be used So I'd like to ask is that everybody who had an idea at the face to face for what they'd like to see included in 1.0 to please open up an issue by default I'm probably going to mark everything that comes in as a 1.0 issue Because I think that's probably the safest thing And then as new issues come in we can discuss them and decide where they want to move them out of the 1.0 bucket And move them into something that's either post 1.0 or not required for 1.0. Whatever the proper term we want to use is But I figured that's the safest way to go right now is to assume it's for 1.0 until we Have a discussion and assume otherwise And so with that what I'd like to do is I last night I did go through And tag everything that I thought was fairly obvious as a 1.0 topic now that doesn't necessarily mean if necessarily going to be Done for 1.0 But I think that we have to have the discussion for 1.0 because if we do decide to do what was being proposed in there It's a semantic change or breaking change to the spec and obviously we need to consider those before 1.0 So I went through and tagged a whole bunch of 1.0 But then there was a set of them that I didn't know what to do with quite yet and I want to have a discussion And so I wanted to narrow down the list for us to talk about today if that's okay with you guys So what I wanted to do was to go through the unlabeled or untargeted issues in prs And then look at the ones that I tagged is not required for 1.0 And see which of those you guys want to pull into the 1.0 release And again, it's not for definite inclusion to say we're going to do this for sure It's just to have the discussion for 1.0 And I believe the total list is maybe about 10 or 12 total issues or prs to discuss That way it shouldn't take the entire phone call. Is that an okay process for you guys? Or for me, okay And I then I figured at some point in a future call We can then try to narrow this list down to see which ones we want to do you know sooner the 1.0 for For a sooner milestone, but that's I'll come later So Collaborate on libraries and spring tools this one while I opened it. I believe I opened this for uran at uran I'm sorry. This was from the From the road map. So on the road map version 0.4. We say collaborate on libraries and supporting tools My initial reaction on this one was That if we do this it's not necessarily a hard requirement for 1.0 It could come after 1.0, but I felt a little uncomfortable tagging it as such without a discussion with you guys first What do you guys think? Does this have to be done before 1.0 or at least does the discussion have to happen before 1.0? Or can we say this can be done after 1.0? I think when we work as a group you're so in one week we can do a lot of work So I I think I don't think it's mandatory, but I don't see any problem for us not to Have it especially if we minimize the scope Now for what I what I suggested just to create like client libraries and then maybe advance to other things Okay, so you want to have the discussion before 1.0. Is there anybody who disagreed with that? What's the scope of the libraries? Are we just talking about Structs and object graphs? Are we talking about something more involved? We haven't decided that yet. That's that way part of the discussion. Yeah, I Think that would be good as a comment from Yaron on on this issue so that people can understand the context of what it means So I have another issue which I opened And yesterday or a couple of days ago and it has a little more details that the client is decay. You see this one Yep So Tewa, let's do this. I'd rather err on the side of having too much in 1.0 right now So Tewa, let me mark this as 1.0 and then you're on let's go to your SDK one and you can briefly Very briefly summarize this one and we'll decide whether we want to for sure talk about this before 1.0 So, you know, let's start with for example, we have HTTP which we sort of in a high level agree to how it looks like So now we can create an SDK for example You have a go or java or node for each one of them You have a class where you're initializing. Let's say the cloud event structure And you're saying, you know publish essentially you need like three methods, you know to initialize something to destroy it and and to submit or publish the The event message and then we can create sort of a pluggable mechanism for transports initially starting with HTTP and then as we starting to define AMQP or Kafka or other transports we just plug them Underneath so we can divide it to you know, sort of the five major languages Everyone can take a peek at one of them and start Structuring it and maybe if we could do it in github then You know, everyone can participate You know, we can take go for example someone else wants to take node Is this a discussion that has to happen before 1.0? Yeah, I don't so I'm I think this is a great effort to do and I'm all for it It's just I just think it's orthogonal to the spec work Yeah, I agree I I also wanted to make that point because like yarn and I had a great discussion in one of the threads where we Basically proposed two different interfaces that had totally different tradeoffs. One is zero copy one is strongly typed And I'm a little bit cautious about saying that we will make the tradeoff as like The standards body or the working group recommends exactly one SDK Yeah, I I at this point. I'm I'm not comfy building, you know cloud events gms And so So I think what I'm hearing is Even if we do decide to do this work, it may be part of a separate work stream outside of the specification itself. Is that true? That's how I look at it So here so if this becomes a sandbox project and Cloud events is called a sandbox and it has a github org or repo and then this code gets inside of it So I don't know who was speaking but somebody was just saying that It could appear like there's an opinionated preference for if we want to do zero copy or strongly typed etc By the implementations that provided by volunteers Yeah, by the way, I think that the client side is simpler because there's less opinion on that one I think the consumer side is the one with all the sort of mark, you know the martianing aspects Okay, so I'm trying to figure out what to do with this one. It sounds like maybe this goes into that bucket of Additional work streams for us to consider in the future Yeah, the only thing I you know, I think we became sort of extremely serialized I like to do things in parallel. I don't think we need to complete 1.0 in order to start this work It doesn't have to necessarily end in the same time, but I don't think we need to work serialized on everything Yeah, I would agree and actually I have a topic later in the agenda about timeline for additional work streams and how we want to do that So if it's okay with you you're on what I'd like to do is to put that. Whoops. That's not right Try this I'd like to add that to the list of additional work streams And then we can discuss that under that section. Is that okay? Sure The question then is what do we do with this issue? Um Is this something Yeah, so um dug uh every time I come out on and off mute, I interrupt inadvertently, but we had put in a An issue and I'll put it in chat. It's kind of just kind of related to the client SDK I think it's labeled right now. It's not being required for 1.0, but it's Similar in that there's really something of a conformance tool to you know to validate a given provider's implementation Against the spec and so the client SDKs certainly facilitate adoption, which is you know Which behooves the the project as we you know as it moves into something like a sandbox or or to that next step um, I wonder I think it's good maybe to reflect on this as we go to decide about Whether client SDKs need to be 1.0 or not as well Yeah, so I think what you're saying is that we have to at least one implementation Which will be our conformance tool. We don't have to for every language, but at least having something Yeah Okay, so Okay, before we get to the to that one itself. We let me back up a sec here So on this one you're on Should I close this one and assume it'll be covered under the additional work stream a topic? You're the boss Well, I like to clean up the list and and if we're not going to cover this under here I'd rather close it out and just keep it as part of the additional work stream list if that's okay Okay, hold on okay, so Tell you what we were going to get to it eventually but Lee since you brought it up here. Let's talk about this one I originally marked this last night is not required for 1.0 because I didn't think it was required for the spec itself to reach one point Though even though I do think it's just obviously a very important piece of work Uh, what do people think is this something that we should pull into the 1.0 timeframe? Is it something that we say? Not part of the spec work itself, but it's a separate work stream. What do people want to do with this one? That seems that seems like something you would build on the tooling you built in the other work stream Okay, honestly, I I do like the idea of the the group that is Trying to define the standards also like contributing an asset test of sorts That's kind of where my mind was that too, um, the asset the asset test would be useful. Um to check compliance like, um Lee was saying but It seemed like there was a risk that this could seem like the opinionated implementation of Of the client library. Well, I think it kind of depends on how it's written, right? So for example, let's say it ends up being just a tool that receives cloud events and just says yes or no Did it adhere to the spec, right? They didn't have all the required fields Are the strings in the right format a completely different thing to that's just a A certifier, right? Right. Yeah, like kubernetes has a certifier. That's completely different thing to what this is proposing It's still useful. They're both they're both useful. They're both should probably be done over time Otherwise we will all write our own client sdk. So I think that's why yaron's raised this but it just needs Some I guess we need some direction on it So lee, what was your intention with this one? You mean with respect to 1.0 or just or just in general? Well, both What kind of tooling were you thinking here? I mean, was it simply checking that a cloud event looks right or was it grander in scope Mostly that it looks right mostly that That yeah, there was a some way of denoting whether or not a given Implementer a given provider You know had conformed to the spec had You know, it had been certified so to speak and I know that that's a that's a big term certified, but And yeah, whether that you know it maybe it's It could be used for those purposes of Of labeling as being conformant That type of a process is You know, would usually involve potentially this working group or the cncf then a hosting And that getting a label and a fixing a label is a lot more involved because you've got to validate the results and the integrity of those Results if it's just a tool to help those that are implementing and make sure and then Then they may be build it into their ci systems to just validate that they've they're continuing to adhere to the spec And that's a lot simpler Yeah, I don't know if we want to get to legalistic aspect of conformance and all that stuff Um, so if we were to scope this down to as you described it a tool that just validates that you're spitting out a valid cloud event Is that something that One would you would keep under this github repo? Or in our organization somewhere not necessarily the same repo, but you know within the cloud events organization Yes, and and two Uh, is this something we need to discuss before 1.0 Uh, I'd say yes to one and then before 1.0 Like so technically that you can 1.0 the spec without having you know this tool um And the same thing goes for client-side SDKs I think in my mind the client-side SDKs help with adoption in general The conformance tool like this, um You know, I guess, you know, I don't I won't I'll withhold opinion because I because I think it You could you know push you the way What other people think is this something we should that we should discuss Before 1.0 Now keep in mind just because we tag something is not required for 1.0. It doesn't mean we don't get to it It just means It's not necessarily our hard requirement for us to do so But if someone takes the it makes the effort to do it it could get added to the agenda Do you have a timeline for it? I think this could yeah, because this could be less I think this could be less opinionated than the client SDK Because it is something that we can use to To check conformance, and I think it will help with people understanding Whether they've adopted it correctly. Yeah, we have a in in mqp. There is a Validator that basically just goes and and looks at the bits on the wire Without building a fancy library and api around it and and then basically just goes and checks that I think that's even written for mqp. That's written in python And so because it doesn't need to have multi language support You don't need to any of those things you basically just need to see whether the bits come fall down the wire in the correct way Yep, and I think if someone Shows up in volunteers to do it then it certainly should be part of 1.0 right So I'm hearing it. I'm hearing it's very very useful, but I'm not hearing anybody say that they think we have to do this before 1.0 I'd rather see this before 1 1 1.0 because this would really help with our client side SDKs And if we could put this for 1.0 and client side SDKs after 1.0 Like having a validator would help people actually building client SDKs and doing tests on that Okay. Well, like I said in my note yesterday if I agree with that Yep, okay So at least if one person as I mentioned my note yesterday if at least one person says they want it for 1.0 We're gonna take the the conservative approach and tag it as such. So, okay So this one's now 1.0 any strong objections to that Because I'd rather play it safe and force the discussion Then then skip it So, okay, we got those those to support work chain and workflow Yaron, I think this was opened by you the other day as well Yeah, I think we had the lightweight discussion of the face-to-face around labels and Workflows and and all that and I don't it's not necessarily a new work item It just maybe we need to clarify within the the standard what happens when you observe a router implementation A workflow is one one form of router You know, I'm getting an event and I'm passing it to To another function and maybe daisy chaining several functions So for example, when I'm daisy chaining an event, you know from one function to another What is the source? Is that the original source? Or am I creating a new source or am I embedding my source in the original source? So I think there needs to be some guidance into How we create workflows because I think cloud events could be An awesome tool for building workflows because essentially you could start labeling, you know, the the event with things like work workflow identifiers, you know And it seems interesting Okay, yeah, so I agree with Yaron that that's it. That is a interesting limitation of the current spec Is that if you if you receive a cloud event And then you yourself want to pass that on to another cloud event handler Then how do you decorate that because with a http proxy? There are ways of doing that for instance That's aren't there that we may be familiar with the um x forwarded buying things like that Yeah, I think we should we should figure out Figure out some scenarios for this and see how we're going to solve those like where the problems where the problems lie So that I think that's something that we should go and address because that's that might have Breaking I'm worried. I'm more mostly worried about any breaking change impact that we might have like like real hard issues And that may be a candidate for one. Okay, so I'm hearing this could this could change the spec So therefore that puts it into the 1.0 category I have a comment on this one. Oh, I think no, you know white paper We have a definition for workflow, which is serverless workflow. So I think I I think you know to avoid confusion I think this is more like a chain of events Not the real serverless workflow, which involves, you know events and the function and an interaction between the events and functions um Yeah, but again, you can generalize it that a function next hop not necessarily a single next hop and could even wait or Depending for a condition. So there's nothing precluding you from doing that But I think this is if you are targeting this as a, you know, like for the router, right? When I say the the real workflow is like a state machine, you know You have different states and then, you know the transition between the states involve Events and then, you know, the action could be, you know, uh one at one function Or multiple functions executed in parallel or in sequence or could be branching I think that concept is different from this one. I just don't want people to be confused They they're a complement each other because even if you look at step functions from from amazon Then you have the ability to control the output of one function and the input to the second function So this is in the context of sort of the cloud event There is an addition which you're you're saying, okay There's a state machine. Am I waiting for a condition? Am I doing several things in parallel, etc? That's not necessarily part of the cloud event So so yarn I think Kathy is just saying that we need to pick a different title because the wording makes it sound like We're going to be defining the workflow mechanism as opposed to just how do we possibly represent Chaining inside of an cloud event or you know, what do we do about that? I think it's I think she just wants a wording change the title. Is that right Kathy? That's right. Yeah, I just want to white confusion. Otherwise, it's me Okay Is not about the function chaining and implementation of that I think that's that is very implementation focused, but how would you frame a cloud event that was Over cloud event, right? Or you'd forwarded a cloud event to another cloud event receiver that Encapsulated it, right? So Kathy can you favor? Can you put a comment on this issue with some alternative text for the title that you think makes it a little clearer? Okay, some use cases would be good on this as well Yeah, I actually I think chaining off, you know, the events probably is a better title Rather than seeing Yeah, just just a few different things before we Before we move on to the next issue So one of my action items for this week was to do some research into distributed tracing or open tracing And whether or not it could solve And though I was of the opinion that no, it is not the PENSE we're looking for there I do think that like, you know, I just surveys at kubecon and any vendor who did any sort of visualizations eyes lit up When I suggested that maybe we could get cloud events to Support visualization across these, you know, the hops through a router Um, I really do think that we should look at supporting at least in the htp spec or you know on a per transfer basis That we do support these tracing frameworks And I'm wondering if that should be its own issue or if it should be something that we fold into this one or Thomas, I think, um, I agree. In fact, I was going to bring that up a moment ago It's kind of the the baggage concept and open tracing is You know is you know one of those ways to potentially Chain things or you know passing along You know span IDs if you will Um, so Thomas, it's kind of up to you whether you want to Add a comment to this one to make it part of this issue or open a separate one that that's up to you However, you want to do it sounds good um, just uh for lee's sake the the concern I had with the Like baggage in various tracing frameworks is that you're allowed to drop them And I want to rely on it. I wonder if we need a different mechanism Yeah, we at the at the face of face. We have discussed this notion of annotations And I think that fits here So we should go and have that have that discussion and then see how we can go and make them work Yeah, so let's not have the discussion now. Just uh, Thomas your your choice whether you add it to this one or Open a separate issue But the other way it does sound like we want to discuss all that under 1.0 Yoran, do you have a preference of whether I uh, work for all this issue or whether you want to Have it the discussion separate Whatever you you feel more comfortable I think if we change this one to be just chaining Then to the extent that your mind is strong to that thomas and mine as well Well, I think there's the question of uh chaining that you can see from within the functions context and chaining that might be only like Supportable at a lower Volume for an actual like operator to see in a visualization tool Now for example, if you use some type of tracing framework, you might need an eventually consistent database that has a very low trace Rate Whereas something that we wanted to depend on is an annotation that happens every time So they are kind of different So can you is this other issue that we have for you thomas? What does this cover that other topic already or? Yeah, this covers why tracing is not is not a great match for the specific case of annotations Uh And so this also links into another case where I tried to explain my thoughts about correlation Um, and how annotations fits into what I'm calling structured correlation versus some people talked about uh follows from Of course something like that and for sequential correlation Okay So it sounds like maybe a bit best if you open up a separate issue Okay, and so then the next issue on the list though is this one. Um Is this something I I suspect that this one we probably should talk about Uh before 1.0 goes out the door given everything we just talked about is that fair? Yeah, I mean it was a research from which I found that my recommendation was to not do something So I didn't know if it was just auto-closable. Um, or if we should just wait for people to see whether they disagree with my lack of action Well, let's let it that's when did you put out there two days ago Let's wait till next week and if no one speaks up then we can do an auto close or close it on the call But let's give people a chance to to review your thoughts That's not fair Sounds great. Okay. And in the meantime, we'll tell you it's 1.0 because we should result one way or the other before that Any objection to that? All right next alignment with itf security event token What if people think about this one is this something we need to discuss before 1.0 Has anyone even looked at this? That's another good question To be honest, I have not um, we we should we should I haven't looked at this yet, but this is something we should look at i'm i'm um For the htp webhook spec. I I mentioned that on the the slack channel yesterday We need to figure out what the right model is for the abuse Protection feature and I have a proposal in there, but i'm happy to not invent anything and take something That exists. Um, so I don't know whether that aligns. So we'll have to go and take a look at that Okay, it sounds like we should at least examine this one before 1.0. I need to screw it with that Okay, this one integrity I'm not sure why I didn't why this wasn't definitely 1.0. Um, but for some reason I thought I'd ask the group Is there any reason that we should not discuss this before 1.0? That's a rat hole Is that reason enough to avoid it? No, um, it does sound like an important rat hole, though Um, so I think we're we're generally using uh, tls And so that kind of helps with with the things not being being messed up on and transport As far as routing is concerned There are 400 different ways of doing these things including existing You know crypto frameworks which can go and take a cloud event that's expressed in in, uh In jason and and wrap that so there's like jason web Web encryption and jason web web signature and all those things and then there's if you look at other so what i'm saying is um, and I there's a quote. I want to quote myself. Just scroll a little bit up A little bit more. Um the memories of w security throw dark cold shadows You know, I actually enjoyed working on soap for a while very soon. Stop picking But it's so i'm i'm worried so i'm i'm really worried about the w security rat hole And this can easily go into that So I would I would literally want to go and scope this out of of v1 And then we can go and and think about message level security In the next version, but I would rather not try to go down that route because that gets very complicated very fast Okay, so i'm hearing one vote for not required to 1.0. What other people think? This was also discussed about when discussing labels annotations and the bag of property properties thing because An event might want to sign itself or encrypt itself with its labels and that would require integrity checking So this might be required for 1.0 because we do want labels and annotations for events And the events might want to be signed or encrypted or whatever. This was brought up at the face-to-face thing Yeah, and I think that the to some extent, uh, it's questionable whether this is even a non goal um beyond things like tls because uh, as I noted in the one of the labels Issues or poor requests Sometimes it got a little creepy and it might actually be in spec that you could have a router that were in dax PII or something like that um, and I think that is an open question or a valid question whether or not Not editing the event is a should or a must sort of behavior and like only a must should be cryptographic designed Okay, so i'm hearing is at least one person thinks it is now. Please have the discussion before 1.0 so We're talking about tls an HTTPS specifically because that's the first implementation that Are all of the event transports? encryptable Can they can all of the ones we're looking at go over tls? Like kafka mq etc um, yeah, so we have so mqtt and mqp and htp all have tls bindings and I would for for the I'm for the webhooks webhook spec. I'm actually leaning towards making it should be as mandatory Okay, so we're gonna have the discussion later. We don't need to have it right now But it sounds like everybody is okay with at least keeping it at 1.0 for right now So next what I'd like to do is look at all the issues that I tag is not required for 1.0 um Now clemens yours are on here first The only reason I mark those is not required is because I didn't think it was a hard requirement from 1.0 Even though we may get to a beforehand um Would you prefer for these to be tagged as 1.0? Yes, I would and that is Only to prove out that we are building a multi platform Or multi transport standard. So I think I think whether we whether we really do yeah, I'm I'm I would like to have both of them 1.0 Okay, turn up This is collin um from the gnats team We we would like to look into adding gnats as a transport, uh, you know and just to see if it'd be a good fit What would you do for that? Look look at look at the so I I wrote the hdp mqp and mqtd specs and um if you just go and let's say take the mqtd spec and And rewrite it so that it fits for naps Oh, okay Yeah, just do a pr basically yeah make a pr. This is we're open. We're open for everything Um, it's just that you do the work All right, great. Thanks. Yep All right, um, we are only have 20 minutes left. I'm a little nervous about clicking into each one of these Given how long it might take. So let me ask this question Looking at the list here Does anybody want to advocate for any of these being moved back into 1.0? And keep in mind just because it's tagged as not required does that mean we won't discuss it It just means if we don't get to it, we're not it won't necessarily hurt the spec We're looking for issues that if we if we address them they may actually make a breaking change to the spec anybody Even to the 30 seconds Uh, I'm surprised that number five is still open if we do need to no, uh, literally issue number five Oh About them. Thank you. Uh, if we have not figured out our non goals It would be probably good to actually figure out what we're not trying to do as early as possible Yeah, the reason I think this one is lingering is because the person who signed up for it has been distracted on other things if someone would like to take Take on the work, I think that's fine The reason I marked it is not required was mainly because I thought given all the stuff we put in the spec about What it is it kind of implied what it's not in particular did things like say Uh, it's not going to include the the destination address in there for example things like that Yeah, so my my devil's advocate argument that we should figure this out is that if we enable a certain situation and give a blessing of 1.0 for compatibility reasons Um, it will be hard to track that. No, no, no, this isn't a use case. We want to support Okay, so to what as I said played on the safe side tag it as 1.0 anything else Last chance actually and it gets not last chance before we move on last chance But we can always revisit any of these later on if you guys uh do some deep soul searching All right in that case we'll keep these as is and like I said you can always change the labels later This is not set in stone. So if you feel like with things are mislabeled just speak up later Is that okay? All right, moving on then Let's see. So what I'd like to then do is as new issues are opened up I would like to Go through a process of assuming we don't get a boatload of issues every call Um, maybe take the first minute or so on each call to classify each issue as it comes in Whether it's 1.0 or or not required to 1.0. Hopefully that won't take too much time We get a lot Then maybe we'll only do a couple of them on the call But I do I my goal is to make sure that every issue is tagged appropriately So that would help or that helps define what we're looking at in terms of goals for next milestones or for the 1.0 milestone now Along those lines we have I believe How many issues do we have total we have 41 issues total um And of those I guess if we have what six or seven on here So somewhere in the mid 30 range of total issues for 1.0 I would like it if people looked at the list and volunteered to Own some of them and that does not mean that you're responsible responsible for necessarily advocating a position one way or the other it's more about Uh poking on people to come to a resolution and help drive those discussions Because without owners for these things they may just linger. So please take a look at the open issues and volunteer for the ones that you'd like to At least help drive I may take a few minutes on each call to pick out what I would consider the heavy hitters Or the the more important ones and try to strong arm people to volunteer to take them Just so we get some forward progress on them Um, but it oh, it's always best to volunteer if you can I appreciate that So I don't want to take time up now just to give you a heads up that I may start nagging people to volunteer All right, so in terms of next milestones and objectives Um, I didn't want to spend all the entire call on it, but I do think on a future call We should start talking about Intermediary minds milestones before 1.0 and what on that list of issues you want to include So please be thinking about that and if you have any suggestions for how to Reduce that list down for the next milestone date. Um, you know, please speak up with proposals Otherwise, I'll try to brainstorm with some other folks and come up with something out of my own Um, and see how the group feels about it Any questions or comments about the milestone discussion? all right so In terms of when 1.0 is ready um In my mind, this is what I sort of came up with is Obviously when we think we're all done with breaking changes or breaking issues I would when those are resolved. Um, obviously typos type stuff, you know, we don't they'd say we're not too much But then there are other issues that came up. I can't remember Uh, someone may have actually opened up an issue related to this. I can't remember for sure But they were questioning actually Thomas may have been you you're saying um, you know, how are we going to determine Uh criteria for 1.0 in terms of implementations Use in production and stuff like that. So I included that in the list here um One of the other things I thought might be interesting is we've gone a certain number of months without any major changes to the spec um but I wanted to sort of brainstorm a little with you guys in terms of What other criteria you could think of that we should consider for when we feel like we're getting close to 1.0 And I did put a proposal here For what I thought might be a good thing to shoot for which was three uses in production and perhaps three months Of a time when the spec doesn't actually go through any breaking changes Meaning it looks fairly stable at being used in production But I wanted to open this up for as I said a brainstorm brainstorming discussion with you guys See what you guys thought and how'd you like to address this Silence Thomas can I pick on you since you opened up an issue related to this? I think sure. Um, I I said I I like being able to Trust that I can rely on the 1.0 label. Uh, it really sucks when you have two point out come out right after your 1.0 One thing I thought was really interesting is the number of implementations might be a really good test just to make sure that we Don't have some blind spot in the use case. We're not handling Um, the challenge is you can measure that in a couple of different ways You can say that we have two implementations due to you know, microsoft and circles framework supporting this Though I don't know it might be better to say that we have a certain number of event providers or a certain number of Customers using this in production for their actual application Um, the last one I think is the most important but maybe the most business sensitive to the various Um people involved right Any other comments questions of people? Is this a topic that's just premature? Is that why people are silent or is this something People don't want to discuss right now Yeah, how serious are the versions like How uh, when could 2.0? Be released at the earliest is this something that's gonna happen every by no three five years Or is it more like okay? We might have a new version every year every six months In my opinion, I think it's too soon to tell Um, I I'm assuming that we're going to follow those, you know the semantic versioning rules where As long as we're making non-breaking changes, we're not going to go up to 2.0 and everything's backwards compatible um And whether we want to introduce a Breaking change it would be completely up to the group to decide I would person prefer to aim at the three-year horizon or longer um Just because we're talking about like creating a A distributed ecosystem of a lot of partners and it's going to be very hard to move any of them Yeah, I mean I would agree with the sentiment The one reason I couldn't put a date on it was because You know if if two months after release 1.0, we find a major flaw in the spec I don't think it'd be any of anybody's best interest to wait three years then to put out a 2.0 Yeah, I mean I I'm not going to stick to the guns and see we need to have schedule different developments. Uh, I'm just saying the Uh, the gravity that I think 1.0 should carry is that we believe it can last for years I definitely agree with that So this is alex again, um What why is there such a focus on hitting 1.0? Which is actually the point at which you cannot make breaking changes And and we want to make breaking changes on a very low cadence Do we not need a lot more validation from people using this and adopting it before we We go to 1.0 is what's pushing that I I'd say that's the basis of the question Which is what amount of validation do we need in order to declare this 1.0? Right, this is super early. I mean it was zero zero point one Last week or declared that A couple of people are using it, but really Do we need more feedback before we we say right? This is a finished work I would say so Yeah, I I'm okay with saying this is a premature discussion I just I think maybe thomas's issue is the one that sparked the the idea for having a discussion on today's call And if people want to wait and see how things go before we even have the discussion further, that's fine Um, and if someone was to ask us for example in the toc call next week, you know What is our criteria for 1.0? How do we know we're there? I could I could dance around that and say we don't have a firm line in the sand yet It's still up for discussion and you know, that's fine But if we did have something a little more concrete that I could say Then I was hoping to have that you know As a as a thing to say but if it's if it's premature, that's fine as well And I think the I think the tension there is also that people want to get to a 1.0 in order to ensure the stability Of the interface of the spec Okay, I would agree That yeah, that is the reason for going to a major version clearly, but if we going to major version before it has widespread adoption, it's And then you you get that adoption. That's the risk isn't it that Maybe didn't build it build the right thing Right, I think I think all of us need to think hard about what what would we want to see in a 1.0 in order to call it a 1.0 So it's to me this is another discussion. You're right So I think what I'm hearing so far is this may be a little premature But it may be a good thing for us to start thinking about in the back of our minds and maybe what I should do is wait A couple months or a couple more milestones and then re-raise the question to see if if they have any more of a solid answer What statistics are you guys Recording at the moment in terms of adoption or usage I don't think we have anything official other than we have a web page. I'm sorry a A markdown document with a list of people who are the implantations okay So to to the previous discussion about zero dot two dot three dot four that was in the milestones I think I think if everyone Could take a look at those and come next week Thinking about, you know, what are the next major milestones that we would like to see Some of that could be adoption based in terms of providers consumers open source, etc So you would want people to think about what they should what they want to see in the next milestone basically, right? right Or the next set of milestones Okay That's not fair to everybody. I'm not doing any objections Okay, so say what I'll assume that this was a premature discussion. Which is fine But at least so we'd have an ai out of it. So thank you mark Anything relative to this discussion people want to bring up Okay Next with only about seven minutes left So we have a whole bunch of topics that people wanted to discuss for sort of additional workflows And you're on I believe earlier in the call you said we don't need to serialize everything and I definitely agree with that So then the question then becomes at what point in time do we want to have a discussion around Kicking off one of one of these additional work streams because I do think there will be a little bit of process involved there So for example, if nothing else I do think we need to get agreement from the toc on starting another work stream The same way we did on getting agreement to start cloud events at all Because I don't think it'd be appropriate for us to do something out of Out of flakabitter phrase charter or bounds of what we what the toc agreed for us to look at So how do you guys want to approach this? Do you want to wait until it feels like the cloud event thing spec is Is sort of calming down and we're not going through so much churn Otherwise we may get our time split up too much or do you want to start it? You know basically right now and start picking out the next work item. How do you guys want to approach this? So I think we've got the cloud event agreement after we started talking about it in the in the working group and then got to You know name it, you know and so we we do need to start discussion. What's the next item and only then go to the You know to see I I agree if I if I phrase it backwards. I apologize I definitely think we should come up with the idea But before we start doing it's like actually writing down a spec I think it would be best to get an agreement from the toc because the toc comes back and says no then that may change How we process it going forward You have a slightly more than maybe incubating the concept, you know, you know talking Let's say we we talk about security for you know Starting to define what do we really need etc and then going to the toc when you know what you want to talk about Okay, and kathy you're trying to speak up in there right I would like to propose that we know we start work on the The serverless function workflows, which is you know about you know how to What kind of language primitives we can use to define the To specify the or to compose the function workflow and also the interaction between the event and functions Because I'm seeing you know some companies already started doing this for example amazon step function Platform nine is doing it Huawei is doing it that and IBM I think is doing that so I think we need to if we can discuss have a consistent way of you know the For the user to specify the function workflow that would be good. Otherwise will be all different You know versions of variety is how to do that Right. Okay. So we're ignoring for a moment. Which particular work item we want to address Do people want to start having those discussions immediately or do you want to wait for some event to happen in the future? I think we do have to talk about this now because at least what Was said about the begging and labels and stuff like that needed Inputs from users like you need a workflow to know what labels you want to add and having a spec for that We decided it was not in the scope of cloud events But it would be in the scope of something else being done by the surplus group And we can't properly do the spec if we don't have Workflows and chaining and stuff like that and we need a spec for that to be able to do this in cloud events Okay. Yeah, I support that. I think you know when we discuss a lot of correlation things Or what information we should add to the events or how we should add it That's all related to relate to the you know the workflow on how we should do that So I think you know working on the workflow Well, you know, we can come back to see what's missing in the event cloud events back Okay, so I'm hearing people want to at least start having the discussion now Is this something that you'd like to spend time on next week's call? Or should we set up a secondary call to have that discussion and bring back your recommendation for the group Is is this about all of the topics or about function chaining over function signatures? It's about looking at the list of Possible work streams and figuring out which one or ones we'd like to tackle first That would be a good thing to make movement on Yeah So is this Let's do it in this call and then branch out if we want to have specific topics Okay, so then what would do Okay, so what we'll do is we'll take as much time as we needed on next week's call to figure out which of This list or others if you want to add to the list we want to tackle next as a work stream Okay, so please be thinking about it. If you have additional items you'd like to add to the list Please get them in before the phone call so people have a chance to think about it in advance we actually technically have a future work item document and Unfortunately, it's very very slim I will take the action item Of adding this list that we have down here To that documents You look at this prs or issues of Say that you can join Do you want us to add issues or prs for them? Uh, this this is a markdown talk. So if you want to add things to this list go ahead and do a pr Okay, and I'll I'll do don't you don't have to a pr for anything in this list here I'll make sure that everything in this list is in the documents. So you think of other things if you want to add them Sure, and then we can discuss it on next week's call Doc, I think do we need to clarify a little bit more on each work item so that people know What it is about That's fine, too If you I was going to add the exact text I see here for the most part If you'd like to add additional text go ahead and do a pr To add more text. That's fine as well Okay, thanks Okay Anything else related to additional work stream item? All right, so I guess we may mark down here. We agreed to so Let's kiss go. All right So come prepare to talk All right with that we only have two minutes left. Let me go back and do the roll call then So I don't think we have time to dive anything if anything needy Um, Louie, are you there? Yeah, I'm here. All right, and ihore. Are you there? Ihore, I said we're here, right? Yeah, and Yep, Dan con you there Dan Okay, what about Alex? I see you typing. Yep. I'm here. Okay. Is there anybody else on the call that is not on the list of attendees? Do I have a star next to everybody? I think I do What is the star for oh, it's just an indication that you I thought you've actually been heard on the call We keep attendance for voting rights I guess I should say that for those of you who are new to the call Because we don't have formal maintainers like a you know traditional code github project What we do is if we ever get to the point where there's a contentious decision to be made and we just have to Take a vote because we can't decide if you can sense this which way to go We actually people earn voting rights by attending three out of the last four meetings And that's why I make sure that I actually hear you on the call And you didn't just add your name without actually joining the call and then I keep track of everybody's attendance here And then everybody with a green fox Has voting rights and it is based upon company and that's why I was asking for the company affiliation earlier in the call Would that help elix? it doesn't help when it's an independent software project And actually representation is by the by the project the community and not by a corporate sponsor if you like Yeah, we we haven't had that problem yet until today and up in town. Yeah, we don't know so what we're gonna probably have to do is just Let open fads have a vote at the table is what I just the way I'd like to go with it. That's okay And but I think I think from a representative perspective, I think you'd have to be counted under vmware so That doesn't make sense because open fads is not a vmware project No, but you work for vmware We can take that offline. Let's talk. I mean, I was engaging with this work group for Since like the whole the whole last year small gap recently. That's right But as as an open as the founder of open fads So let's talk about that offline. I think um You make your company may need to decide who you're representing in this work group And that's up to you to decide is my opinion So, but yeah, I mean my opinion hasn't changed but I can get I can get back to you I think your company might have an opinion so that's I'll let you figure that one out Okay, with that, I apologize for slightly over time. Um, thank you guys very much and we'll talk again next week Okay, thank you. Okay. Bye guys. Thank you