 I'm sure no one would eject any early. All right, three after. Let's get started. Let me move the window over for a little so I can see it better. Okay, let's see where are we. Okay, community time. Anything anybody want to bring up from the community that's not on the agenda? Okay, SDK. I think we did have a call last week, but I don't think there was anything worth mentioning from there. Clemens or anybody else that was on the SDK call, can you guys think of anything worth mentioning? Because we all decided that we didn't do our homework or read out Scott's notes. There you go. That was the most. Yep, that's my recollection as well. Okay, so moving on. So when was it? Tuesday, I think it was. We actually did our proposal to go to incubator status for the TOC. Mark was on the call there helping field questions in the chat. I'll let Mark speak for himself, but I think it went really well. We really didn't have that many questions and definitely, I don't think we had any hard questions or it seemed like anybody was questioning our existence or why we're even going for this. I think the next step in the process is for us to formally make the request through a proposal file in the TOC's getup repo, which Mark and I are working on offline, which hopefully will be done either today or tomorrow. And I believe the next step from the TOC's perspective is to actually start the formal vote, which I'm not exactly sure when that starts, but hopefully it'll be very soon. I know that Chris Anicek is very eager for us to not only get to 1.0, but to also have this next status for us to go to incubator so we can do a double announcement both at the same time and get even more press and excitement around our stuff. So that's kind of what happened there. Mark, can you think of anything that I'm forgetting? No. I thought that it went very well. Thank you for putting together all those slides and doing the presentation. You did a great job. I'd say the one area that or the one question that came up that we didn't have an answer to was a protobuf spec that we had explicitly excluded for now. But aside from that, I don't know that there is any questions that didn't make sense and that we couldn't answer. Yep. All right. Any questions from the community on the meeting or proposal that I put forward? All right. Cool. Moving on then. Kukan, nothing worth mentioning there. I don't think anybody's made any changes to the outline for our sessions. Obviously we still have time so that's not an issue. However, I did want to mention that the Surplus Practitioner Summit CFP is now live. I don't know why a note wasn't sent out. I expect one will be sent out soon. But if you actually go to the website for the, I think it's called day zero co-located events or something like that, you will see that listed there. And here is a link to the CFP if you guys do want to submit one. It closes October 4th. So we don't have a whole lot of time if you guys want to do something. If someone thinks that there should be something there from our group, please speak up. We can obviously put something together if we want, but we obviously have our sessions at Kukan itself. So I don't feel a little bit awkward about repeating things, but it's been done before. So think about it. If you guys want to do something, we can always do that. All right. So with that, before we jump into the PRs, are there any other sort of community related topics people want to bring up? All right. Moving forward then. So there was an outstanding issue about, open by Evan, about how to handle extensions in binary format. In particular, when the extension has its own serialization, meaning for example in the HGP case, it won't be prefixed with a CE dash. And I believe on last week's call, I don't remember where we left, actually I don't remember where we left that last week's call, but I believe either through that call or offline, the group has kind of agreed on a around a proposal that basically, let me see if I have this here. Basically, there's a couple things. One, it says that all extensions, in fact all attributes with a couple of minor exceptions, but basically all attributes including extensions must be serialized with a CE dash. That way, receivers know that there's always one particular way or one particular location in which extensions will be serialized. And that's including the binary format and that includes things like the trace extension, which has its own serialization. However, to allow for extensions like trace, we do allow for a secondary extension. So they may have a secondary extension, but they still must also have the CE prefixed ones, if that's what the transport calls for. Okay, so that way we still have the consistency of a single serialization for extensions and a single location, but the data can be replicated someplace else. However, if upon receiving that data in two different locations, if that data differs, then the extension must explain what to do in that particular case. And barring them not saying anything, the assumption is the receiver will just pick up the CE dash version of the stuff. Obviously, if it's an unknown extension, they won't even know about the other stuff to even worry about a conflict. But in the tracing case, I did add some logic there that says both should be passed on to the application, but make it clear that they are two different properties. One is more of a transport level one and one is more of a cloud event level one. And it represents what was originally provided when the cloud event was first created. Okay, so the actual changes that I made basically represent what I just described. Most of the changes in the documents are talk about how things can't have a secondary mapping, serialization, whatever you want to call it. But then they also say they must also include the previously defined primary mapping. That's most of what all these changes are just repeated in each type of serialization or spec. Let me just make sure I'm not missing anything here. Okay, yeah, so here's what I talked about. Here's where I deal with conflicts in the tracing extension. Oops, I'll fix that type a little later. Yeah, so here basically talks about how the CE version one is the one that's supposed to be used as a cloud event attribute when you create this cloud event object as a receiver, but the secondary one may be picked up and offered up to the receiving application as additional metadata. Okay, ACP transport does the same thing. Let's jump down to the spec. That might be the other change worth mentioning. Let's see what is this. I'll add some kitty spec. Okay, so the spec here, what did I change here? Okay, this one makes it clear because I think you might have been Alan who was asking about this that all extensions must use the same must use our type system attributes. They cannot just define some random type. I think that's what we were implying before, but we weren't as clear as we should have been just and this just makes that clear. This here just talks about how they can have that secondary or extensions could have a secondary serialization. Nothing new there, whatever we're talking about there. And I think that's basically it. Oh, down here. Kathy added this text a long time ago when we were talking about extensions. And I was going through there, I noticed that we have the word should here and talks about how the event provider should also add data someplace else. The reason I changed this from a should to a would and remove the normativeness to it is basically because this is an example and having normative text in an example is not appropriate because they're not actually mandating people actually do stuff. This is just an example. So that's the only reason that change was made. If anybody was wondering about that. All right, so let me pause there and ask if there are any questions or concerns, comments, whatever. Really? Nothing? We already spoke about this for two weeks. I know, I'm just checking. That tells me that, you know, people should have at least some thoughts on it. I made comments to you and you addressed it. Okay, yeah, I should mention that. So offline earlier today, Mark did mention that the wording was a little funky when I started talking about secondary serializations and some of the format specs because the word secondary just sort of popped out of nowhere. So I made a change to those documents so that every time or the first time I reference a secondary serialization, I changed that secondary serialization wording to be a pointer to the extension section in the main spec so that people understand what we mean by secondary serialization. No narrative changes in the commits that just went in. It was strictly syntactical just to give people a pointer to reference this notion of secondary. But thank you, Mark, for those comments. That was good. All right. Anybody want to raise their hand? Otherwise, I'll ask the question. This is too lazy. Okay, any objection to approving? All right, cool. That was actually the very last issue for issue NPR for version 1.0. Now, before we jump to Evan's PR, which is or is other PR, which is not required to 1.0, what I'd like to do is jump down to actually I don't have a formal item for it. I guess kind of do what I'd like to do is see if people think we are ready to go to 1.0 release candidate 1. Is there anybody have any concerns? Because that has always been our plan once we resolve all 1.0 PRs. But if you have any concerns about that or lingering doubts, please speak now. Okay, let me ask the formal question. Is there any objection to two different things? Okay, let me do it one at a time. Is there any objection then to cutting into release and calling it v1-rc1? Okay, so I'll make those changes tonight. Yes, exactly. Second question. According to our schedule, we are supposed to start a two week review period for 1.0. That does not mean we can't make changes, even large changes if we want to. And as we make those changes, we may want to reset the timeline if we so choose. But what this meant to do is to basically put nagging pressure on everybody to review the spec because hopefully at the end of the two-week review period, if there aren't any changes left for 1.0, we will shift 1.0 in two weeks or start to vote for 1.0 in two weeks, I should say. And then one more week for that offline vote. Okay, any objection to starting the two-week review period? Should we have it be a little longer than two weeks? I don't know, to be honest. My initial reaction is to start with two weeks, and if we need more, we can always extend it. Okay. The only reason I put it that way, I'm concerned if we make it longer, people will wait until the last two or three days anyway. Then let's make it a week. We could do that if we wanted to. Is that a formal proposal? Yes. One week. What other people think about decreasing it to one week? Everybody okay with that? I've lived in two weeks. Yes. Okay. I heard some definite two weeks or better comments, but I also heard just a yes pop in there. Was the yes to the two weeks or the one week? Yes to the two weeks, if it was my yes. Okay. Okay. Thank you, Koss. Okay. So Scott, you okay with the pushing two weeks? Yeah. I was just trying to follow your line of reasoning. I know. I know. Don't get in my head. It's a scary place. Okay. So start to talk with you two weeks. Any objections to that? All right. So starting two weeks. And that means we start the vote on October 3rd, if all goes well. Okay. Now, let's go back to... So can I assume that there's no action that we need to have for SDKs to support AV 1.0-RC1 and that we should just hold on that until there's a formal 1.0? That's an excellent question. What do SDK people think? I say we hold for 1.0 because having the syndrome thing is likely not a good thing. I would tend to agree. But my plan was to try v1 and then have it be kind of maybe a branch that's kind of breaky until it's fully approved. I already checked in the 1.0 support. Sorry. Okay. Well, it sounds like everybody's in agreement with you basically. But you mean the proposed tentative 1.0 support? There you go. Yes. Yes. I already checked in the proposed tentative 1.0 support. That's correct. You guys are funny. Okay. I think you got your answer, Mark. Okay. So before we go back to looking at the nice to have issues in PRs, anything else about our roadmap or plans? Since those are kind of important topics. Okay. So, Scott, I want to pick on you for a sec, since not only because this came from Evan and he's your compadre, but also because I think you've actually looked at this one. Would you like to talk about what might have changed recently in this one that people should be aware of? I think there's just been a bunch of clarification and trying to keep up with some of the other changes that have come into the spec. Okay. Evan notes that it will be have to, it's probably going to be some updates for the, I think it's like 585 or something. Oh, even 508, the one we just approved earlier today. Yeah, that's right. It'll have to be updated to reflect those changes too. Okay. I guess that implies then we cannot approve it today because he thinks there are changes to be made, right? That's right. Okay. In that case, let me do this. Does anybody have any questions on this PR barring the changes that need to be made for 508? I made a comment to Evan that I would like to see what the user provided data was for each of the examples. When you say user provided data, do you mean extension or something different? No, I mean like, what did the user intend to send and what did it, and this is what it looks like on the wire. Interesting. That might be useful. Yeah. But it sounds like it, okay. So either way though, I don't think it's appropriate to vote on this one and there are no questions that people have. So there's nothing to discuss. I think we just need to wait for Evan to come back with another revision based on 508 and possibly your comment there, Scott. So I think we can move forward. Any disagree with that or move on to the next topic? Okay. Okay. So Alan opened up a, actually I guess I think this is an issue for PR. He opened up a PR just a second ago that I didn't want to necessarily talk about. Yeah. That was just an issue. Okay. I think he opened up this PR as a result of that issue, which is modifying 508. We can't vote on this one right now because he just opened it like an hour or so ago. I believe however he wasn't necessarily planning on this being normative changes. I think these were just clarifications. That's why I marked it as nice to have it for 1.0 but not a requirement for 1.0. But please, when you get a chance, take a look at this and put any comments you have in the PR itself. So I just wanted to bring it to your guys' attention. But since it is related to the extension stuff, we should probably give it a very careful review since that is kind of a tricky area. All right. Any comments on that? Okay. I think the SDK PR is still out there. As Clemens said, we all had some homework that we didn't do. But I think that's actually it relative to open issues. Let me just check one thing here before I even suggest we end the meeting early. That one? Let's see if there's any open issue you want to talk about. Okay. So there are a couple of open issues. Okay. I think there's this one. That one's already done. This one. This one. Okay. I think those are taken. So of these three that I just checked, it would be really nice if somebody looked at those and decided something for version one, whether it's to add some more clarifying text, add an example, or even suggest that we close those for version one. I don't honestly spend time on those on the call here. I don't think that's a great use of our time. It's just a nagging reminder that we have these as things, someone at one point in time, but it would be really nice to have it for one point at all, but I don't think anybody has taken the action item to actually make it a reality. And then that means open a PR or suggest to close it. So please, when you get a chance, somebody take a look at one of those, or I guess all three of those. For example, Clemens, maybe the web hook, one might be of interest to you since that was your spec. Yes. Yep. I don't know who wrote the petition key one. I opened the issue, but I was going to get someone mentioned it during a call and he might lose track of it. So maybe if you're interested in the petition key extension, you can look at maybe doing an example there. So anyway, take a look at those three. If you want to jump on and own one of those, that'd be really nice. So we can close these things out. These try for v one issues. All right. And with that, we actually might be done with the agenda. Okay. Now while I ask, thank you. So any other topics you want to bring up before I do the final roll call and let you guys all have a full 35 minutes back of your day. That is quite amazing. Amazing. Yes. Anybody have any other topics? All right. In that case, let me do final roll call. Kyle, are you there? Yes, I'm here. All right. Klaus, I heard you. Jeff, are you there? Yep. I'm here. All right. Jim, are you there? Yes, I am. Excellent. And Evan, are you there? I wrote in the chat. Oh, okay. Cool. Ginger, are you there? I am. Excellent. Fabio, are you soon here? Fabio, are you there? Yep. Excellent. Did I miss anybody who joined the call late? Oh, yes, Scott. Thank you. How did I possibly forget, Scott? All right. Anybody else that I miss? Okay. In that case, one final note before I get to mention. I'm going to have a vacation for the next two weeks. I'll send an official note to the list asking for an official leave of absence. However, Mark will be running the call on October 3rd, I believe is the date, so in two weeks' time. Next week, depending on who is actually able to make it, the order of potential people running it will either be Clemens, Heinz, or Ginger, depending on whether they're meeting or whatever it is right before this call, runs late. So we do have somebody lined up to cover it. Okay? Yep. So you guys get a break for me for two weeks. Gratum finally taking time off. Only Clemens was taking time off. Yeah. Clemens took a lot of time off, too. I get to explain for that. Clemens has a healthy work-life balance. He does? I think we should cherish. You should all aspire to that. Is that what the outcome of this meeting is? Aspire to be Clemens? No, no, no. You should aspire to Clemens work-life balance. You should not aspire to be me. Ah, okay. Well, on that note. Hey, Doug, one last thing. With respect to in two weeks, that's October 3rd, I believe. Yes. And I believe that's a German holiday. So as we go to a vote for 1.0, which I believe that we would want to do that offline so that people have a week after that to be able to approve or disapprove. Correct. That vote will be an offline vote. Okay. Yes. Just wanted to clarify so that we can take into account people that won't be on the call at that time. Correct. So that means for the German folks or anybody else who may have a reason not to make the call that week, if you have any issues with the spec going to 1.0, obviously raise them offline in some fashion, preferably in PR form so we can just approve the PR. But then, yes, the vote starts and you have a week after that to vote. So even if you can't make the call, you still get to vote. All right. Anything else before that Clemens gets to his soccer match? All right. In that case, we are done. Thank you guys. This is so exciting. We're getting so close. I am super excited. Yep. All right. Cool. Thanks guys. We'll talk next time. Bye everybody. Thank you.