 Good morning. Hey John, how's it going? You know, let's, let's talk More autumn joy. All right. Um, hey Mattis. Matt, yes, you there. Maybe you stepped away. Good morning. Oh, there you go. Hello. How many good buttons? All right, we actually have a very short agenda today. Hey, Doug, how are you? Good. How you doing? All right. That's not very sure. Pretty good. Oops. Hey, Clemens. Doug. How free is that? All right, let's see. Tommy. Hello. Yo. Yo. And Nick. Hey Doug. Hello. Well, let's try to do this right. Uh, Grant, are you there? Oh, he has no mic yet. Hey, Grant. Hey, Doug. This is Grant T, right? Yeah. Yeah, okay. There's another Grant out there. Just want to make sure. Yeah, Grant Rodgers. Yep. And Minwell. Yes, hi. Hello. While we're waiting, just let you guys know, um, Gem did indicate to me that he thinks the protobuf one is ready to go. So if you're bored, you can take a look at that one in case you haven't looked at it recently. Yes, I'm sure that's everybody's problem these days. Absolutely. Hey, Colin. Hey, good morning. Morning. I was, I was too busy shipping the cloud event schema registry interface. Yes, like, you're obviously excited by that one. Hey, Brian. Hello. Hey, Ray. Hey, Lance. Hello. This is Ray. Hello. Hello. Okay. I was talking to you. Hey, David. Yeah, I thought it was me. We've had new problems all morning where my audio is not working. Yeah, I had this whole conversation. No one could hear me. Actually, we, uh, NIVM, we've been using WebEx and, uh, WebEx just does not like me over the last week or so. It's had this wonderful little habit where it would disconnect my audio. Not, I'd still be in this conference. I get to see people do stuff, but I could not hear them. But sometimes they could hear me. And it was just like, just randomly happening. It wasn't like at the beginning of a meeting, like maybe just that connection issue, just like I was connected perfectly fine. And all of a sudden halfway through the meeting, just couldn't hear anybody. So very annoying. Um, we have someone named Tom. Which Tom is this? Are you new? Oh, that's probably me. Thomas Langartner. I'm on a different computer. So, okay. I guess. Okay. Cool. Someone else went flying by. Are the other, oh, Matthew? I'm not sure how to pronounce that. I apologize. Matthew, are you there? Oh, there you go. Gotcha. Thank you. That's an excellent question, Lance. Yeah, I think convinced they hate their users. Although I had to admit, I give them a lot of crap on Twitter. Because I love to pick on Webex. But the last update they did in terms of the UI, I do think it was actually an improvement. It's still not where it should be, but it was better than it was. So small victories, I guess. All right. Three after, we can switch over to something more exciting than Webex. Hold on a minute. A 16. All right. Let's see if I missed anybody. All right. I think I got everybody. All right. Let's jump on to this stuff. Okay. So Jem did his AI. So there's nowhere he has left. That's good. Community time. Anything from the community people would like to bring up. That's not on the agenda. All right. SDK. I don't believe in SDK call last week, because we had no agenda items. And this week we are planning on having the discovery interrupt call immediately following this one. Of course, I don't know if we have any topics. That may be quick as well. So be thinking about the possible topics for that. And Timmer, anything you'd like to mention relative to the workflow subgroup? Yeah. Thanks. Just just overall improvements of the specification. That's what we've been doing for the last couple of weeks. And I'm sorry. I missed the last meeting. And we also got a new logo finally. So we're waiting on CNCF design team to actually create us the SVG images so we can post it all over the place. So we're excited about that. And the only other thing I kind of wanted to ask this group is, have you guys heard anything about project office hours for KubeCon.na or not? I did get a note from them asking me to take a survey to ask whether it was useful or not. But I haven't seen an actual sign up sheet or anything like that yet. Okay. Thanks. Yeah, that's all I have to say. Okay. Any questions for the workflow team from anybody else? All right. Moving forward then. Okay. Before we jump into the PRs, is there anything on the agenda I should have added? Okay. In that case, let's jump into PRs. Okay. So this one is updates to our REST APIs, just filling out some details. Been out there. I think I made some minor updates late last week or maybe earlier this week, but it was definitely before Tuesday. I did split the APIs into, I think I call them, I think I call them discovery APIs, which is basically just the get stuff. And then I created management APIs per Scott's suggestion, where this does things like imports and puts and stuff like that. So this is the right side of the house. I think for the most part though, that was pretty much most of the changes. I can't remember for sure though, whether async processing section was separate or merged in like before, but if not, I did pull out asynchronous processing into its own section this time. But I think I might have had that last time too. But I think that's about it in terms of changes since last week. Now there was a question asked by somebody, it may have been the other grants, asking whether we should look at the log stuff that Eric mentioned last time as a way to handle some of the importing type stuff or epoch processing. And I asked if we can defer that that I didn't hear back from. So I'm assuming we can deal with his issue later because we don't have the log stuff even really thought about yet. But I think that was the only open question. So let me go ahead and pause there and see if you guys have any questions, comments, thoughts? Nothing? Okay, obviously this is not the final end game. I'm assuming we're going to make a lot of changes going forward. This is just put a stake in the ground for us to have something to work on for the interrupt stuff. So if there are no comments, any objections then to merging? All right, you know I love silence, thank you. All right, next one then, version timestamp. All right, so this one we decided to go with the ever cool word epoch. And here's the text which you guys read it in case you haven't had a chance to read it. Okay, any questions, comments, concerns? You guys can't hear me, right? It's not pulling a Webex on me? No. Okay, just joking. Nice try though. Yeah, well if you're going to find it sexy on mute somebody would have said something at some point. But of course if I couldn't hear you then it wouldn't do any good. So okay, so silence means everybody's okay? All right, you guys are killing me. I don't like this rambling all the time myself. All right, website protocol. Now Slinky said he wasn't going to make it but he also didn't see any comments made in there. So I guess my job on this one is to nag, I think Clemens, you were the one that had some possible concerns against this. Do you still have those concerns? Because I think he did make some wording changes. If not, did you want to eventually add some comments or maybe we can talk about it next week? Yeah, that was the, let me think what it was. I had, that was this negotiation thing with a different with a different sub-protocols I think that he had. Yeah, you don't need to, you don't need to review it right now. I just was wondering whether there's something, whether you just, whether you're, I just was curious whether all your comments were addressed or you just have any chance to review it? I have not, I've been to, unfortunately, I've been kind of backed up. Okay, that's fine. I just don't want to slow things down too much but that's just, I'm just not on top of it. That's fine. I mean, Slinky's not on the call anyway, so we, I was going to defer a vote. But yeah, if you can get, if you can get those in there before next week, that'd be appreciated. Okay, let me look at them parallel. Okay, thank you, sir. Oh, does anybody else have anything they want to bring up that I can put in the notes to ask Slinky to think about? Okay, in that case, we shall keep moving forward. Darn it, I was really hoping Jim would join. He didn't specifically say he wasn't going to join but he did ping me saying he thought this one was ready. Okay, well, it's loading. So according to Jim, he does believe this one's ready to go. Now, I know nothing about this. I don't know anything about protobuf so I wasn't going to even say too much with it personally. But for the folks on the call, do people want to vote on this today? We don't honestly have to wait for Jim but if you guys think we should, we can. Do people want time to review it? Is there anybody on the call who's a protobuf pseudo-expert who says, hey, I need more time to look it over? What do you guys want to do with this? Because I'm okay voting or waiting. It's up to you. I wish we could get this in and then we should patch it if we need to. Okay, definitely one way to go. Anybody else want to voice an opinion? Okay. Yeah, I'm going to vote for that as well. Let's get it in and we can tweak as necessary. Okay. All right, just to double check and please that people on the call do not feel like you're being pressured. If you want more time, don't hesitate to speak up. For the last chance, anybody want more time to review? Okay, any objections to approving then? Done. Jim, I'm sure we'll be thrilled. Thank you, everybody. All right. In that case, Scott said it was going to be late but I don't see him on yet. So let's see if we can talk about this without him. So on last week's call, he suggested that we try to set up some goals for timelines on things, which seemed like you were generally in favor of that. Has anybody given any thought to what kind of timelines they may have in mind for any of the specifications or even the interop work? Nothing, huh? What if we did this? Just put a date out there. What if we shoot for two weeks? I don't know, actually no two weeks. Let me do three weeks. What about we shoot for three weeks to hold an interop around discovery? To do the interop session on discovery. Interop session on discovery, which means we need to completely fill out all the details of what's expected of each implementation, which means we've got to beef up our documentation or the interop doc, and then code. Three weeks. So maybe one week to beef up the interop doc and then two weeks to finish up coding. Is that too soon? Yeah. October 15th, so a little less. Okay, October 15th, that's, I think, that'd be three weeks or four. That's probably still three weeks then. Yeah. You don't hesitate to say, I'm insane, but you push it out and just putting a date out there. Because I like forcing functions, but that might be too aggressive. That's a little, that's very close though. Sure, reality hits us in the face. Well, let's see. We could look at a week later, October 22nd. That makes it slightly better, but no. Okay, Clemens, since you're brave enough to come off mute, I'm going to force you. Pick a date. Um, I would say, oh my God, well, end of October, like beginning of, what is that? Beginning of November is the second. That's kind of where, I think it's more realistic for us. Like I need more buffer because I can already tell you what we're going to do each day in the next three weeks. Okay, what other people think? November 2nd? I know, see, I signed up to do some coding. Obviously, Clemens, since you're hemming and hawing, you're probably going to do some coding. I think Sanjay, you're on the call, you were planning on doing some coding. I can't remember who else, pseudo volunteered. Is there anybody on the call who was thinking about doing, or who wanted to participate? And if so, what do you think about October 2nd? Sanjay, go ahead. October 2nd to say October. I'm sorry, not October, November 2nd. If I said October, I apologize. Oh, November 2nd. November 2nd. In November 2nd, sorry. Yeah, that is good. Okay. I probably misspoke, yes. I was not sleeping, okay. You're okay with that? Because I know you signed up to do some stuff, right? Yeah, I would. So you're okay with that date? Yeah. Okay. Okay, let's go with that. And go ahead, Grant. Yeah. So I was looking at the PR for reintroducing a part of off. Looks like there's, I definitely don't want to block on anything, but it looks like there's some unaddressed comments. For example, at the bottom, we don't have comments per all the fields. And that's pretty knit. But there's one of, like the data fields, instead of data one of, John Skeed recommended just data. So I'm imagining like maybe someone should look at the comments before getting all approved. Okay. Tell you what, let me reach out to Jim offline and ask him if he thinks he's addressed these or not. And if he thinks he has, maybe I'll reach out to John then. That is John, right? That's his name, John? Yeah. Yeah. I'll reach out to John to see whether he agrees or not. If John disagrees and wants to block the merge, then I'll block it because of that. I mean, hopefully things aren't two blocks, but... Yeah. No, no, it's a good point. And I apologize. You're right. I should have double checked to make sure. Hold on. But yeah, just checking before just pressing the merge button sounds good. No, that's all good. Okay. Thank you, sir. Appreciate that. Okay. So back to number second, double checking. People okay with that? Oh, Scott, you just joined. So the current plan, Scott, is to shoot for November 2nd for Interop on Discovery. That will be a forcing function to make us clean up or finish up the writing of the Interop doc and then code for the next couple of weeks. You okay with that, Scott? Okay, sounds great. Were there other dates you wanted to shoot for or was that the main one? I was just asking for a date. We could go and polish this forever, but if we set a timeline to stamp it and then iterate, it makes more sense. Yeah, I was just actually I was more wondering whether there were other dates you wanted besides for the Interop. For example, were you hoping for a date for the actual Discovery spec itself or one of the other specs or was this good enough for now? That works for me. Okay. Cool. I am pretty keen on getting the subscription API up and out at some point, but I think it needs more work than the Discovery EPI. Okay, cool. All right. Oh, before I forget, Scott, I think you had an action item and I'm going to try this down to create the Discovery metadata for a Discovery endpoint. Yeah, I do. I have that action item. I also release Captain for Knative right now. So yeah, it wasn't to actually put pressure on you to do it as much as just a reminder, because I need to add it to the AI list so that I don't forget to nag you occasionally. So okay. Cool. All right. With that, we are technically at the end of the agenda. Are there any other topics people would like to bring up? Was that what were you saying some of their comments? I was just saying, wow, I was after looking at my watch. Well, that's your agenda. What do you expect? Yes. Okay. Maybe if possible while we're here, a question came up while I was reviewing the VEPOC specification. And we do have 201 created if an event has been accepted and processed from the HTTP semantics. I believe the created could also apply if it has only been accepted and the event has not yet been processed. Is that correct? A created is 201. Yeah. 202 would be accepted, right? 202 is accepted, yes. All right. Right. So accepted is for the not yet been processed. We could have 201 for a not yet processed, couldn't we? No, because 201 says that you have created an object and that will then usually come with a location header, which tells you where you can find that object. There's some implied handshake that happens with the 201. Effectively, to be nitpicky on the HTTP, if you're taking an event and you're hacking it, which means I have understood this and I have processed the event, which means you've put it on disk, like you have it safe, then you return it to 100. If you take the event, but you haven't done anything with it, but you want to basically return control to the HTTP clients, then you send a 202. Okay, because it's purely about the delivery and acknowledging it is just having it stored, not having actually done something. Well, it is whatever you think of as processing, right? But 200 means the work is done, and 202 means I have taken this message, and that's all you say, but you don't make any statement about having done the work. Okay, thanks. It's a small, minute detail, of course, but it can occasionally be useful. Any other topics people would like to bring up? I have a question. Sanjay, I was not there when you guys might have discussed this, but so we are trying to use the cloud events for both webhook as well as internal events. And one of the questions which came was that, what about the reliable messaging QoS related semantics? So for example, if you are trying to retry how often or how many retries are left, you know, that should be stored with the event. Did you guys discuss those kinds of use cases when the cloud event structure was defined? And if you did, then if you can point me to the discussion, what should be done in that case, that would be great, because I think the question is, should we have whatever you want to call like reliability context or retry context or whatever, should it be part of the event state, which so typically, you know, the event is dispatched, let's say you are trying to send it to a remote destination, it failed and you want to retry, but you want to put that retry, when to retry, how many retries are left, that data inside the event, wherever you are storing the event. So if you are taking it from a queue and sending it out and it failed, you want to change that state, which is part of the event and put the event back in the queue. Yeah, let me try the rest of this. Doug, just put a little quip into the chat and I actually want to go and pick up on that quip. Yeah, WSRM, yes, I know. Exactly. So I did this in EVXML messaging, which we actually was used for WSRM. But I think, so this question came recently now also. So let me give you, since you're coming from that corner, let me give you an answer that is tailored for that corner of the world. I think SOAP made a terrible mistake by trying to do everything from TLS to reliable messaging to messaging of security and everything completely ignorant of the capabilities of the underlying transport. It basically ended up treating everything like it was a naked TCP socket, but then was happy to kind of bind to fairly sophisticated protocols on top and then layering another layer of brutal complexity on top of it. And I think that was also, its downfall was the extra complexity. What we've done here, since you were now here as we started this, I think one of the principles we have here is to not try to but really make something that is super compact and have something where we can agree on what an event is. Okay, Clevence, I get it. You know, I know I have gone through this before SOAP came. I was doing HTTP when it finished, right? I was at BA, we were doing a lot of things like that. But I think the question here is that what is the suggestion for this question? Look, do you want me to answer or don't you? Yes. Okay, so the principle is that we're going to have a small compact standard here, which is just expressing what the event is. Cloud events explicitly scopes out transport concerns, such as redelivery, such as, you know, redelivery count. We don't have that in the message because you are mapping a cloud event onto a transfer message or containing it in a transfer message. So that's the difference between the binary mode and the structured modes. Of a protocol, which then is suitable for whatever the transfer path is that you have. And if you need to have reliable delivery, we have three options for you. We have NCP, which is a super reliable point-to-point transfer protocol, which is an ISO-ISC standard. We have NQTT, which is also a reliable transfer protocol for PubSup, which is an ISO-ISC standard. And we also have Kafka, which also gives you reliable semantics. So basically you have the choice of three protocols, which are implemented by a broad variety of popular brokers that you can use cloud events with through the transport spending that we have. And that's how we do with reliability. Yeah. So I was not expecting, I think I'm more asking about how you would advise someone who is asking this question what to do. Let's say, for example, in the context of webhooks. If there is a situation that you want to offer retries and you are using HTTP, what would be the suggestion that someone asked that, you know, where this information should be stored? Because it appears that it should be some other state than the event itself. Is that right? Absolutely. Yeah, that would be my recommendation. I would take the event, because if you're going to retry the event, the way I'm looking and thinking of it is you're going to store the event someplace you can retry again later. Well, when you stick that event into something, whether it's a database record or something, right? I would assume you probably have other metadata about that record or inside that record. And the cloud event itself is just one of those bits of metadata. And so that other metadata is where I would stick like the retry count or whatever other metadata you want to store. But I wouldn't necessarily put it in the event itself, because it's not really a metadata about the event. Okay. That's what I was looking for. Because, you know, Doug, I asked you the question about the extension. And this is one question, which I was struggling with that. Should I put the extension for the retry there? But now I'm clear that, okay, it should be some, so for example, if you're sending an HTTP message, then if you're storing that message somewhere to retry at some of the time, that state should include the retry specific data, not the event itself, right? Right. Yeah. Okay. I get it. And thanks, Clemens. Over time, as you know, we know we have looked at the whole thing. All the time. I was actually part of this transaction and coordination. I gave my input to it because, you know, one of the protocols I developed was business transaction protocol. Okay. And I knew it didn't work because it was very complex. So it's done. But thank you. Just to augment your knowledge on this, we have Event Grid, which is our cloud event-based eventing platform and their side delivery metadata, where we keep kind of delivery count and the backoff and when the next retry is and everything that's kept effectively in a metadata bucket that sits kind of on the side of the event. Okay. So that's exactly how you understood that. So that's how we're doing that in the product. Can you put a pointer on the chat or, you know, I can look something more there? Yeah, I can point you. I'll put a part of the Event Grid on the chat. I don't think we have a discussion of exactly how we do this, but yeah, you can go and look at the product. Okay. Thanks. I'm still bothered by the old-timer comment, personally. I mean, it's one thing when I make fun of Clemens' age, but now you're including me in that bucket. I don't like that. Okay. Any other topics, even old-timer topics? Yeah, let's talk about XMLRPC for a moment. Yeah. I went to talk, I missed WS addressing. That was, that was, anyway. Okay. Okay. Last chance. Any other topics? Okay. Before we let people go, whether we may or may not talk about discovery interrupt, let me just do the attendee list. So, Nacho, are you there? Yes. Excellent. And Eric? Hello. Hello. Ginger? I am. Sorry, I was super late. Not a problem. Mr. Mark, are you there? I am. Excellent. I miss anybody. I just joined. I was hoping the call would last for an hour. You're lucky it lasted this long. Oh, let's see. Okay. Did I miss anybody else? Okay. In that case, before people decide to drop off, do we actually have any topics for the interrupt discovery part of the discussion? I mean, I guess obviously you can go if you don't care about that stuff, but interrupt discovery, do we have any topics there? If not, we'll let everybody go. I have nothing. Okay. Yeah. I don't have anything either. Although I did, I will admit, I actually started doing some more coding this week, but I only got like half an hour worth, but at least started. So that's progress. So, okay. And Sanjay, Clemens did pay some links into the Zoom chat. You might want to grab that before you exit. Yeah. Thank you. Okay. Thank you. All right. Not hearing anybody with any topics for discovery, we may be done with both calls then. All right. Okay. The roll call, Doug, I don't see my name here. Oh, I meant to stop you. Thank you. I did ask if I missed anybody. Okay. Anybody else? All right. We are done. Thank you, everybody, and have a good rest of your day. And we'll talk again next week. Bye. Okay. Bye. Bye. Bye.