 Hey Clemens. Good morning. How's it going? It is going well. Good. I'm about to after this meeting I'm about to head back home to Germany. So now I get to go home. Cool. This is a good day. Yes All right, hello Eric. What are you doing? Yeah, it's gonna be a challenge for me I don't have my usual second monitor that puts these things off to the side. So Oh, are you traveling to? Yeah, I'm actually at a Microsoft office in New York. Oh, nice. Yeah. Actually, let me do this. Let me share my screen. Let me do that eventually anyway. I need to figure out how to build how to run this Travis build thing on my own machine. Actually just run make. Oh, really? Yeah, I think I'm pretty sure there's a make file in there. So if you just do make or run all the same text. Oh, yes, I tried to make it as easy as magic. Yes. Yes. So I probably have to go and run this in bash then. Yes, it definitely is that yes. Yeah, this is the magic of window services for Linux that I now have a button right in windows, which is awesome. Yes, I have for a very short period of time I had a very small little windows laptop. And one of the first things I did was to enable whatever it's called, I guess, you know, you have it with some Ubuntu service thingy and start playing out Ubuntu and I was oh so excited. Yeah, it's awesome. Yeah. Yes. Oh, okay. I'm not sure how to interpret that. Since I'm now using this, the repo has been checked out on windows, which has carriage return line feed at line endings. And if I'm not trying to use it from bash, then it starts the tool circle. So you have to go in a different way. Interesting. Yeah. That's that's one of the warts that's currently existing still with this with this windows thing. Okay. Vishal? Vishal? Vishal? Yeah, I'm Vishal. That's it. Okay. Are you giving me to the group? I'm sorry if I don't recognize the name. Have you been here? No, I'm planning the first time. I've been planning to join for a few weeks, but yeah, for the first time. Which company are you from? I work for a company called InfoCloud. We are based in India. Cool. Can you do me a favor? Can you in the attendee list or I'm sorry in the agenda doc, which I'll paste into the chat right now in case you don't have it? Thanks. I put your name in there, but add your company name just so we can keep track of you. I appreciate that. Hi, Louie. Louie, you there? Oh, hello. All right. And Rachel, are you there? I am. And Joe Sherman? Yes, I'm here. Good morning. Morning. Here's a bit of background noise from somebody. I'm not quite sure who. It might be me. Yeah, maybe you. Everybody else is on mute. Sorry. Not a problem. Vioam, are you there? Vioam? Hey, this is Vioam here. Excellent. Thank you. I'm going to make this window smaller. Sarah, are you there too? Yeah. Excellent. Thank you. And if you heard that, Sarah has to get out for you to the meeting. Oh, okay. Yeah. Sorry. Thank you. I missed that. Thank you. David, are you there? Yes, sir. All right. Thank you. Very good. How about you? All right. I'm like most people. All right. Varun, are you there? Yeah, I'm here. Morning. Morning. Jim Curtis, are you there? Jim, are you there? Uh-oh. Yeah. Oh, there you are. Hey, Jim. Hi. Austin, how you doing? Austin, are you there? Steve, are you there? I'm here. Excellent. Thank you. Let's see who else can I pick off? Thomas, are you there? Yeah, I'm here. Cool. Thank you. Austin, are you off mute yet? Klaus, are you there? Yeah, I'm here. Cool. Thank you. Hey, Doug. I'm here. Sorry about that. I cannot find my Zoom window. I've got too many tabs open. Not a problem. Ryan, are you there? Yes, I'm there. Excellent. Thank you. Mark is on. Hey, Mark. How's it going? Doing good. Cool. And Mr. David Lyle. Present. Excellent. Thank you. Varun, are you there? Yes, sir. All right. Thank you. Hmm. I think that's everybody so far. I keep seeing these email notices go flying by on my screen. Clemens, you're just too active right now. I apologize. We'll never do that again. I just had to do make, had to do two fixes in something that we're not going to talk about today, so. Yes, I understand. Oh, Rick, are you there? I'm here. Okay, excellent. Thank you. Is Yoran with you? No, no, Yoran is a giving lecture. Ah, okay. Ganesh, are you there? Ganesh? I don't think he's going to be joining today, Doug. Oh, because I see him in the chat. Oh, it's weird. Maybe he is. Yeah, just no microphone. I don't know what that means. I guess they, they haven't registered the microphone yet with the software. That's kind of weird. Okay, well, it's on the list. We'll get a star if I hear from him later. They probably haven't dialed in yet, which is why no microphone. Ah, that could be it. Okay, we had another Dan show up. Is that Dan Rosanoba? Parker. Ah, sorry. So close. Let's see who else. Chris, are you there? Yeah, it's gone on. Hello. Hello. Ganesh, are you there? Yep, I'm here. Excellent. Thank you. Okay, is there anybody on the call who I don't have an attendee list? I think I might have everybody. Hi, this is John. I just, I just joined it. And you said that's John Mitchell? Yeah. Good morning. Morning. Got it. Thank you. Thank you for that. I'm here, Doug. I'm sorry, who's that? Matt's here. Oh, hey, Matt. Okay, give me just a sec. All right. All right. One last chance before we get started. Is there anybody on the call who's not in the attendee list? All right, cool. I think we have everybody. So I want to go ahead and get started. I don't think there's anything worth mentioning on the AIs, unless someone can think of something terribly exciting to mention there, other than just three months. We'll take a look at their AIs. So yeah, I did my AI. So there's a PR on the process for highlighting code experiments. So that's just, I'm going to review it. It just came in this morning. Excellent. Thank you very much. I like crossing things off. Yeah. So take a look at 159. You guys get a chance. And Doug, real quick on one of my AIs in there below the ones that you just crossed out, find a way for companies to indicate what they're comfortable with people saying about their participation in the working group. How about we just ask, as we get close to CloudNativeCon in early May, you know, the meeting right before that? Maybe we could just ask them on the call and see if they'd like to at least be in the presentation I'm going to give about this at CloudNativeCon. What do people think about that? That sounds fine. Yeah, actually, you could also just start an issue so that people could chime in if they're like, hey, here's some stuff. I mean, you should also ask at the call, but we could like pre-flight that a bit if people aren't have stuff ready. Even better ideas, Sarah. Thank you. I'm going to make the issue right here. Yeah, there might be some people who are like, don't announce it till such date, and then we'll do it at the call, but we're already in a degree. Perfect. I'll do that. Cool. So you still can't excuse your, you still have an AI from that. You can't get rid of it yet. That's good. Yes. All right. Excellent. Thank you guys very much. Moving on then, let's talk a little bit more about KubeCon. So just a reminder, we do have two meetings. We have the BOF and the official face-to-face meeting for the times here listed in the agenda. I do have a doc for a list of proposed topics. I haven't taken a look at it recently, but as soon as we get closer to the date, we will try to finalize that list and put forward an agenda. Chris Anacheck said that people who are not paying for the conference can get in, but they need to send them a note in advance to make sure they can get an exception or add a special list or something like that. But it is possible to do, just to make it happen. And in preparation for the events, Mark or Austin, you guys want to talk about the meetings we had earlier this week about the inter-op events? I think Mark should take that one. As I scrambled to find my unmute. Yes. We had an interoperability conference called earlier in the week, and I think it was very productive. We have minutes that are below the current minutes being edited, where we discuss some of the go-forwards. Clements and Sara are looking at how they can provide some APIs to provide events from both Microsoft and Google, and that would be very useful for interoperability. And we're looking for other vendors, such as VMware, Huawei, etc., to have their tooling in place as well. I know Austin wasn't able to make the call, but I know that he is working on things aligned with this as well. And we also have another meeting coming up on Monday, April 16th, this Monday, at 7 a.m. Pacific, using this same Zoom meeting. Hey, Mark. Yes. This is Rob Dolan, now from Oracle. Yes. I want to suggest that you guys may want to make sure that Oracle is part of that conversation. And if you need help with contacts, please don't hesitate to reach out to me. Yes. Sorry. Sorry. I should have mentioned that Chad was on the call as well. Oh, perfect. Then you guys are already in touch. Great. Yeah. So I didn't mean to exclude anyone in the comments I made, but there was a attendee list down below that you can take a look at. I think somebody from Oracle was on the call. Yeah, Chad. I think all of those calls are whoever shows up shows up. Yes. So thanks, everyone. Any questions or comments on the interrupt? So I also just wanted to clarify, we are aligning on some example formats that we're going to try to have a couple of different providers, say like image upload is this object created format that I haven't proposed yet, but I was going to sort of align what Google does and what Microsoft does and propose something. And then the actual setup of how the source and destiny or whatever we're calling it, the producer and consumer are connected. Like it's outside of the scope of the demo. That might require some things that are different or will require some things that are different. We're not going to try to align on that, right? People want to hook these things up. They're going to have to do things that are specific to the different people doing the demo. And we're just going to do 2Z needed to get the demo. But the main thing is to show, look, we're all using the same format. And that's a huge step forward. And then there are some combinations of providers that work together. That sounds great, Sarah. All right. Any other questions or comments on that? All right. So just a reminder, next Monday, 7 a.m. Pacific is the next phone call for that. All right. Let's talk about PRs. First one, this one was technically open last night, but only because it's a duplicate of one that Austin could not quite get the DCO signed on. So we just created a new PR for it. So Austin, want to quickly talk to this one? Yes. This is a pretty simple update to our roadmap, specifically the 0.1 milestone, which is what we want to announce at Cloud Native Con. This adds in a few things that Clemens has been working on, specifically including a spec for mapping the cloud events to HTTP as well as some spec that shows how to format cloud events as JSON and also defining a type system for cloud events values. So those are a few things that are in progress, but just wanted to make them clear on the roadmap. So what I would like is to have a label on the core spec first. And then, so what I would really prefer if we would go and get to a very quick resolution preferably, preferably, preferably even today, but likely next week, we're going to say, hey, we're going to tag the core spec with 0.1. So we have a baseline because I think the I'm pretty comfortable, obviously, with the HTTP and the JSON status, but I don't think that has seen a lot of review. And so I would prefer us doing a basic locking down the 0.1 for the core spec. I mean, from there on, we're going to do 0.2, et cetera. But basically put a tag on it, put a label on it, and then do the HTTP and JSON mapping subsequently because we're going to do some interop work. And that interop work will shape these initial drafts. And so I would rather want to have those in the 0.2 phase, I would say, and focus on 0.1 kind of the core spec locking that first. So just to be clear, I think what you're also suggesting there is what we actually take to KubeCon would actually probably be closer to 0.2 instead of 0.1. Yes, but I want to, so I'm interested in having a tag in the repo that says 0.1 so that you can go and point to a spec that isn't changing, but you say, this is 0.1, that's what I rely on for my stuff. I love that idea. I love that idea. If you have the protocol specification in 0.2, so we could be like, I support the 0.1 attributes and then we have something that is stable even if we know it's going to change. Exactly. So that's my point. My point is to do the transport mappings, I need to have a stable reference point and not something that moves around. And eventually they will all snap into under one roof. But I think I want to have the core spec lock and then the core spec will move smaller hopefully than all the other stuff that we do for the real wiring. So Clemens, on this list of what Austin has shown here of these four things he put in there, I assume you want the middle two to be moved to 0.2. And what about the first and fourth? Do they stay or do they move as well? The first and fourth I would keep because the confidence values type system is something that we have implicitly right now kind of in the finish and then wish you wash your way. And so the PR that we also have on the list is just a clarification of that. Austin, what are your thoughts on that? Sounds good to me. My interest was in making the deliverables explicit. So they were all kind of working towards getting these things done. I love the idea of tagging the initial spec at 0.1 and moving these to 0.2. So I'll move the second and third to 0.2 and keep the first and fourth in 0.1. So hold on just a sec. Is there anybody on the phone who objects to heading that direction? I don't object but I will mention that I think this conflicts with Rachel's renumbering. It does. That's okay. I can renumber them and honestly the point of renumbering is to make us those like to encourage us to stick to our roadmap and this is us sticking to our roadmap. So yeah and I think that yeah so this is in Austin's roadmap. This is our working group's roadmap. I think Austin did a great job of driving it. And so I think we're actually following the morning. Yeah I'm just commenting that I think Austin and Rachel could get together and have a combined PR that would address that. And I can I will read you mine after this if this gets affected. And so just ready to can we just accept Rachel's? No because there's a formatting problem. But I mean we can accept it based on like we could accept it and say that the formatting is administrative and doesn't need a working group if we wanted to. And that might strain more in this process. So let's focus on this issue right here. So I'm going to be clear. So everybody's agreeing to moving points two and three of the current PR to 0.2 milestone. Yes. And we're going to try our best to try to tag 0.1 as soon as possible once the stated milestones for 0.1 are in place. Which at least for us I now include the two extra items, points one and four. So I'm sorry I missed the last week's meet. I didn't want to have been tracking the website. Is that done? In 0.1 or should we move the last two items to 0.2 as well? Create and deploy a website that features a simple overview, email lists, and direct visitors to get it out. Is that not already completed? I don't know. I'm close. Dan Dan actually provisioned the website. It's up and running. I'm not sure if it meets all that criteria yet. But I don't really have a strong preference as to where we... Well, let's move it to 0.2. I would say leave it in 0.1 for now and hopefully we can achieve it. Okay. Oh yeah, because we're not at 0.1 quite yet, right? Right. So Dan has a couple of days to get it done. Or we can move it later. Yeah. All right. So is that the agreement? Yeah. Yes. All right. Cool. I haven't seen Rachel's PR. I'm not sure what it contains. But if there's anything we could do to merge them or just move faster on that. It needs little points to be enumerated to have numbers on a letter. I'm going to move hers up because I think we're proposing that it is ready and that the formatting could potentially be outside of independent of this decision. Okay. Okay. Anything else on this PR? So Austin, you have some AI to do some twiddling, right? Yep. Okay. Cool. Thank you much. This one, we briefly talked about last week. Everybody's going to go looking through. This is about removing the additional topics and questions section from the spec, which are basically a list of two dos. If there's anything missing from the list, we were supposed to open up an issue or PR or something. I don't believe anybody did. So is there any objection to removing this section from the spec since I think we would have it covered in issues or someplace else? I'm not going to object to moving it, but basically I didn't open issues because I think that the current way we're managing issues is really hard to parse, but we can just always dig this up later if we need to refer to it. Okay. Any other comments or questions? Any objections to approving the PR? All right. Cool. Next one. Camel casing are property names. Barely easy. Camel cases things. Can we cross out the action item about the engines? Can I just cover it? I believe that probably does. You're correct. Somebody accept this. Yes. Yes. I talked to Doug about this. I like this came out of my my HTTP actually out of the JSON mapping because I would have to have it. So I wrote a rule for how to go and do the mapping to JSON and I found that little weird. So I and this it gets it just gets difficult in all kinds of language bindings if you have the dash in there. So it's easier to go and just make the naming convention difference rather than doing special mapping for all kinds of different languages. Yeah. At least from my perspective, like I'm not I'm a life now stick on exactly what it is, whether it's camel case or under bars or whatever. But but we certainly haven't had consistency there. So I appreciate. Yeah. I'm just I went back with camel case for the what I find the majority of of easy closed by language bindings Java and and the Node.js, etc. and go and and C sharp for C sharp. We're probably the ones that have a different but I'm I'm I'm being ahead of ahead of myself and I'm bound to the majority. All right. Hey, Clemens. This is Stan. I have a question when I'm just generally for the group, I guess in some of these things we see event prepended. What are your feelings on removing event just having like type versus event type? It seems like beyond the scope of this PR to me. It does. Fair enough. It's just a point like I think same for ID, right? Like every one of these is an event ID. I think event is a little bit like yeah. There are some things like version, right? Like some things require prepending. So I think if you have specific examples of ones where you're like it's clear without the event prefix, we could look at those independently as separate PRs. Yeah. Think about it in the context of the other attributes in order to say for sure. All right. Fair enough. I can open a separate issue or PR. Yeah. I'm I'm I think I otherwise is is fine if we keep if we remove or if we eliminate any potential for confusion. Like so we could keep we could keep cloud events version as it is and then just make version for the event per se or type version for the event per se. Not necessarily opposed to it. Let's let's let's look at it. You need to think through how some of them would flow as you're talking about them. If you take event time, if you just change that to time, I don't know that it has as much meaning as it should. You don't have to say that it's a date stamp then and I don't know if you're buying yourself anything. But I think you have to do it on a one by one basis. I agree. All right. We don't need to discuss that right here. He's going to open up a separate issue or PR for that so we can talk about that then. So back to this PR. Is there any other questions on it? Is there any objection to approving it? Hold on. I lost myself in my notes. Here we go. All right. No objection heard. All right. Clemens, would you like to talk about your HTTP transport and JSON mapping PR? Well, since we just pushed that out into 0.2, I would probably not want to. I think I would want the interop group. So that subgroup of folks who show up for the interop meetings to take a good deep look at it and see how realistic they think this is for implementation. I think I made an OK effort to not invent anything new but rather lean on the existing artifacts that we have in HTTP and in JSON and do just more or less straight mapping. One thing I should add as a kind of a reading guide is that there are two related PRs. One is this one, so HTTP transport and JSON mapping. Then there's another one, which is the HTTP webhook specification. And let me give a quick reasoning for those because to eliminate any confusion. What I'm doing with the HTTP transport mapping is I'm mapping a cloud event onto the HTTP message per se. So this works for a request as well as for a response because I anticipate that people will want to build systems where you can go and solicit a cloud event from another system, which means you can do a get, pick it up. An event has been delivered to someone like an HTTP-based queue and he wants to go and pick up that event. That event should then also map to the HTTP message in clear way as a response. So what I'm doing in the main PR that you've just been referencing earlier, that is that message mapping. Like how does that generally work? This one here is an effect formalization of webhooks per se. This will work for cloud events, which means it composes with the transport mapping that I'm proposing, but this also works for the generic case. So like if you have a current format that you're delivering events on and you're pushing that out to a webhook, like for instance GitHub does here, right? There is currently no good formalization of how that ought to work. Like everybody does it in their own way. And so what I'm trying to capture with this spec is a common way of how to do this, which operates on, again, on common HTTP mechanisms. One thing I'm adding here, and that's something that I'm lifting in a way, like conceptually from WP, origin resource sharing, is a abuse protection that you probably will need to read through to grasp. But the point of it is that if you have a system that pushes to a third-party website, then it's actually fairly easy to go and take that system and make that a distributed denial of service machine if you're just registering someone else's website. And so this here is effectively protecting in a way that the target websites or the target web service must expect those pushes to happen and that's what I'm adding here. So this is something that I would propose that we eventually take to IATF because it's a generic mechanism that's not strictly tied to cloud events but that is an interoperability foundation for what we do for cloud events. I might not have a discussion right now about this one. I like the introductions. Thank you very much. But I don't want to have a deep dive in this one. So I don't want to talk about either. Right. So let's move on to the next one, which actually is targeted for 0.1, which is your type system one. So maybe we could talk about that one instead. Yeah. Okay. I'll make it to the spot. And let me hide the comments. Okay. Go ahead. I'll scroll through it before you. So this one was motivated by the JSON type mapping because I need to have a way to map types and defines the types that we're using right now. We have a string. We have a binary. We have a map. So these are all lifted from the attribute section. We have an object. The object is something that I'm introducing here because we have for the data section, we have a arbitrary content. I think what it said. So I'm just making this an object and that's effectively a variant type, which can be either a string or a binary or not. Then the URI becomes its own type. We are actually using that already as its own type. And I'm just clarifying that it is a string expression, as defined in obviously 3986. And then timestamp is also we are using that already. And I'm just lifting that up and say it's a string expression, as defined in RFC 3339. I'm clarifying that we're not defining numerical or logical types here, even though we could be tempted to. I think it's fine to not have them unless we have a really hard need for them. And so then I have the, and I'm basically making the clarification down for the object type. So I'm not inventing anything. I'm just basically just clarifying what we're using already. I guess the rest is just conversion of, almost looks like there's backticks around everything for the most part, right? Yeah, and then taking the redundancy out of the timestamp, redundancy out of the URI. In the content type, I keep it because it's a string, but the string needs to conform to RFC 2046. It's arguable that this might, might, should, could be its own type. I just find that a little strange if it were, because it's really a string. And then I have map and object. All right, any questions or comments? I think the big six, I'll just show this. Go ahead. Sorry, was there a question in there? Yeah, I apologize for not reviewing this in advance. I just added a comment. I think object is a problematic term because of its very specific meaning in JavaScript. And I kind of prefer if something was left untyped rather than introducing a term that can create confusion. Well, so I've been using this, this came out of the JSON mapping, which means this comes out of the lingo form of JavaScript, where I'm, so I'm using the variant nature effectively of JavaScript here in the sense. So object is really meant to be a variant type. I understand that. Exactly, that's my job. All right, in common parlance, object is a hash, is a map. Right, like objects in JavaScript have properties. They aren't exactly what is defined here. I understand the need for a definition. And so in general, I think that this is a great direction for the PR, but I think exactly it's, I think that it would be great to have more review on it before finalizing it. And, you know, where this is sort of a point to anyhow. So I think leaving it open for a little more time for comment. Maybe somebody has a better name or construct for this. Well, so what is, what's the concrete objection? Object. Yeah, I, one of my concerns, and I apologize I didn't click submit, it seems to my comments. I know I'm going to run into problems with a PR that's already out with map being explicitly defined as a map of, from key to effectively anything. Because for example, labels was specifically a map that's only a key value pair. The values must all be strings. So I don't know, I mean, this can be a follow up if necessary, but it would be nice to be able to, to give a narrower type of the map. Well, it's, if it's, if the values are objects, are objects and they can also be strings, you can go and constrain that in your PR. It's, it's like we do this, we do this here, we have a string and then we go for content type, we go constrain content type down to a particular format. So I think what I heard was Sarah was asking for a little bit more time for review. Clemens, would you be okay with that? If we don't get consensus on merging it, then obviously we have to give time for a review. It's, I would just have to have that merged next week because we need to have a tax system. Okay, so is the group okay then with the, with, it sounds like everybody's okay with the general direction. It's just, there may be one or two questions about, about in particular the map and object. So let me try something. Let me try something. If I call the object variance, would you be happy? Variance, that's interesting. Can we, can we think about that? So yeah, why don't we just give it a little time? I don't think we're changing the actual, this is a semantic representation about something we all agree on. So it shouldn't actually change any implementation and having a little more time for people to name thing, like come brainstorm good names for things so this doesn't add confusion, which could potentially slow down everything. You know, I think would be good. But we will, we'll respond to this soon. Right, so, so what if we do this? What do we, we, the assumption going forward is people are okay with the general direction. There's some minor changes in particular on map and object. People may want to suggest alternatives. How about we, we push to get those alternatives proposed by say like Tuesday, with the assumption that Clemens will be able to finalize it Tuesday evening, Wednesday kind of thing. And then we'll vote next Thursday. Correct. So that's not fair to everybody? Yeah, we should vote next Thursday on that. That's the key issue, yes, voting next Thursday. Any objection? Anybody object to heading on the path? Austin, are you going to say something? I was just going to clarify that this is a 0.1 agenda item. Yes, actually. Yes. Since you mentioned that, let me do, let me make it more official. Well, this is a clarifier, okay. So this is a clarification of what is currently in the spec, right? That doesn't change any definitions in the spec. So this is a normative, this is a normative part of the specification that I'm referencing in, in the, in the binding. So I need to have, I really need to have that. So let me back up though. Is there any objection, because I thought we already agreed to this, but let's just double check. Is there any objection to this PR being part of 0.1 milestone? If we can have another few days to just make it more clear, in my opinion, and propose some alternate wording, I don't have an objection to that. Yeah, yeah, that, that agreeing to putting the milestone does not change the agreement we had before, which is we're not going to vote till next Thursday. Yes, that seems fine. Yeah. Okay, cool. Okay. So with that, what do we have left for 0.1 in the core spec then? I think we have some additional PRs to go through. Right? Yeah, well, I'm just, I'm just, for, for the, since they're doing a photo of this one next Thursday, I'm just wondering where we are then. The very next, the very next thing on the agenda is also 0.1. I, I have a change that I did not push because it's, I can immediately push if we want to take the feedback that's open there. This one? Yep. So I can push that exact wording if you'd like. I just want to make sure I did it clearly with everyone's consent here instead of just trying to slip it under the radar. Yeah, why don't you talk about the PR in general in case people haven't had a chance to fully digest it, and then you could talk about the specific change that you're thinking about making. Sure, yep. So basically, as I've drilled in a number of times, a document create event means very different things, whether it is, you know, a Microsoft Word document create or a Mongo document create. And so for systems that might want to aggregate or group by event type, it would dramatically help people to be able to actually have a semantic namespace. Similarly, you might have software that wants to be in compatibility mode with another software. And so being able to say that I'm subscribing in cloud storage using the Amazon Semantics, I might want to say AWS Object Create. And so that was the intent is to say that we recommend, there's a should suggestion that it should be using a reverse DNS style namespace. I chose reverse DNS because it tends to group things hierarchically very well for listing. And just as an FYI, both Microsoft and Google own the Microsoft and Google TLDS respectively. So we kind of benefit from being backwards compatible already with what we do. Just want to make sure that that's clear so no one thinks that we're being sneaky. And then the change you're proposing is, I believe this, right? Yeah. So Doug had brought up a very good point that I'm that trying to be very clear about the software compatibility mode that basically we're not saying it's disallowed that somebody else implements another software vendors contract. But that com.github, they own the right to define what these event types mean. So if Google Cloud Storage ever implemented Amazon's namespace stuff and there was incompatibility, it's a bug with Google, not with Amazon. And for me, the key was, talks about the semantic of the event as opposed to the source of the event. Yeah. Clement, are you trying to talk there? Yeah, I'm wondering. So as an organization that defines a lot of these things, I'm okay with being the dictator of them. But I'm wondering in how far that is enforceable clause. You know, which part of it? The prefix domain dictates the organization, dictates the organization which defines the semantics of this event type. Well, I mean, anybody can make up, I think the key thing is that people can diverge from the spec. Like anybody can write any code they want, right? But we need to define a specification that allows for it to be clear what the heck this thing is. And by not having any scoping of the namespacing of the event, that's not clear. Anybody can make up a domain and scope it themselves, right? Yeah. I don't understand the concern really. Yeah, no, so I'm wondering whether this is the path towards the giant UDDI event registry. But I'm like, I don't have any substantial objections to it, but I'm feeling this is a little, it's a little, very, it's a little too dictatorial. Thank you for the question. I appreciate that. I mentioned UDDI, that was pretty good. I'm sneaky that way. I'm sorry, Rachel, were you going to say something? Yeah, I'm wondering like comments, but can we, like what would, what would make you feel better about this? Well, maybe since he's not actually objecting, maybe we could hear from other members of the working group to see how other people find the other. Anybody else have any comments on this or any part of the PR? Can someone hook me up with a great person to get a, a custom top level domain? It doesn't have to be a top level domain. Oh, you would just want a cool top level domain like the big company do. Yeah, it, it, yeah, if we go with event types in this manner, then it looks great to have Microsoft dot, whatever, Google dot, or even Amazon has, has dot AWS. And then other people have to be comm dot, blah, blah, blah, blah, blah. Mm-hmm. Yeah, I didn't realize that was a thing until just actually earlier today, someone else came across it. They were giving us a DNS names and I don't know. Yeah, I didn't know. There was dot Cisco dot Microsoft dot IBM. I didn't realize that. That's pretty cool. That's cool for your IBM or Cisco. Yeah, I think it's for that. Yeah. Those things are super expensive. So it's, it's good for us and from all the big companies, but then, you know, for all the small cool companies, it's, we're basically forcing them. This, this will force them into something that's aligned necessarily with their domain name as a should clause. So that's also why I'm a little hesitant because I know how little company all this. When I was a little company, I really appreciated being able to make up my own name space, even if it was net dot blazing cloud dot whatever. Right? Like it was, it's, this is like a very like only exposed to developers thing. Yeah, I understand. So as I said, I'm little, I'm okay with it. Okay. So let's, let's run with that. Okay. Is there any then objection to taking the PR with this change? I'm moving forward with it. Okay. So Thomas, you can make that change. I'll push it right now. Thank you. Okay. So approved with the suggested edit. All right. So I apologize. I should have done this before, but this has been a really busy week for me. I haven't gone through the list of PRs to remember which ones are actually tagged with 0.1. I think we actually may have hit them all. I'm not 100% sure, but I suspect Rachel's might be the next one that would come closest to it if it's not officially tagged with 1.0. I'm sorry. Mine has changes that needs to be made for formatting. And after Austin pushes, or like after that PR merges, I will... Well, I think actually what I would propose is that we accept what it is, and then we allow for the formatting changes to happen independent of the working group meeting that Rachel could fix it up today, and then Austin could immediately follow this. Right. That's what I was going to suggest. It's relatively straightforward PR. Does anybody object to removing or replacing the bullets with basically just numbered lists is the point? Right, Rachel? That's right. The idea is we can talk about what we're missing without like and have numbers for them. Yeah. Strictly a syntactical thing. My only comment there have been as long as it's not implying and ordering in terms of what needs to get done before another. That's a fair point. Is that something we need to say up top? Like I had a sentence that says the numerical order here does not apply priority or anything like that? Yeah, it can be numerical ordering like within the milestones. Is everybody... Rachel, would you be okay with that? Numbering is intended to be for section headers. For section... What if I make the numbers into letters and we can say like alphabetical ordering is not... Oh yeah, I like that idea. Yeah, that's a good idea. Okay, is there any... If you record to 0.01a and then if we ended up having a 0.01, then it doesn't change things. Yeah. Nice. All right. I don't think that's that dramatically changes the PR strictly syntactical thing, so it's okay to get that in the last minute. Is there any objection then to... Can we do that to the main spec too? Do what to the main spec? The header section numbering. Like in the spec we should stop using bullets? Yeah, well in the main spec we have headers, but they are... Like we're relying on magic, usage scenarios, etc. And it would be really good if our top level sections had numbers in them because that makes them easier to refer to from the other main specs. Yeah, that sounds good. I don't really... Like it's kind of a boring PR to write, but... I'm sorry. If somebody wants to add a numbering to clarify the spec, I think... I think I heard a volunteer, Clemens. Hey, I have what? Five specs in flight? Yeah, but... So I think that like if somebody feels motivated to do the PR, then it sounds good. And if somebody has time, then that's okay too. But yes, I agree with... Like I am aligned and if you don't do it, then eventually I will have time. Okay. All right, so back to this PR. Any objection to the stated direction? So just be clear, Rachael, I believe you're gonna... Instead of using numbers, you're gonna use letters. And then you're gonna add a sentence and making sure that the new... The ordering of those letters does not imply priority or something like that, right? Yep. Okay. Any objection to that stated direction? Proof. All right, Rachael, Rachael, right here. Okay. Should we also pre-approve just being able to merge the renumbering of the main spec? Probably, but let's wait until we see the PR just to make sure that everybody agrees that it's strictly syntactical and nothing else jumps out at us. I don't want to pre-prove something before I see it. And to clarify on my end, I'm just gonna wait for this to get merged in and then refactor my PR real quick. Okay, I'll do it today so you can do that. All right. Thanks, Rachael. All right, cool. In terms of other PRs that I think are ready to go, well, these are clearly not 0.1. Are there any other PRs that people can think of that are either 0.1 or 0.2? Clement, what about this one? I don't think it's a PR, but there is the issue around cloud space events versus cloud events without the space. Oh, that major one. Okay, that's a good one. Thank you. Let me get to that once we even see it. Where is that? Oh, there it is. First one. So we are a little inconsistent in the spec right now. Sometimes we say cloud events as one word, and other times we say cloud events with a space between the two. I was just saying we need to pick what we should pick one and stick with it. And I believe Chris said we basically are trademarking cloud events without a space. And I think Sarah and who else here? Mark both said plus one to that. Is there any objection to heading in that direction? If not, I can create a PR for that and let it sit for a couple of days to make sure no one objects to it. I'm for it because it turns out to be very conky in the companion specs to always have it two words. Yeah, so yeah, basically I would propose that since we, ages ago, decided to trademark cloud events with no space, that if Doug finds instances of cloud space events that we authorize him to just go ahead and fix them. Yeah, just so that you know, there's a very good chance that when this PR comes through, it will include a tool that will check for this. Like those tools. All right, any objections to heading down this direction? And with basically approving it, okay, again, I don't like necessarily approving PRs before we have them. So I will create a PR, or sorry, if we agree to what I'm about to say, what I'm going to do is create a PR, it will sit there for a couple of days to make sure everybody's okay with it and I didn't do anything really stupid. But it's not going to wait until next Thursday before it gets approved. It's since it is. Yeah, maybe just wait for any LGTMs so that you have an approved reader. Exactly, yes. I was definitely going to wait for at least one. Yes, I do that with most things. I try anyway. Okay, any objection to that? Okay, okay, I'll finish that later. All right, any other issues or PRs for 01 or 02 that people can think of offhand? Thomas, I know this is too new to probably approve today, but I was wondering could we, would it be useful to talk about this PR of yours today? I can speak to it. Is anybody okay with that? Is no one else spoke up with the proposal for something to talk about? Okay, because I'd like to, if nothing else, I'd like to get a sense of people's general direction and then maybe vote on it next week. I see people are okay with the general direction, I should say. Sorry. Go ahead, Thomas. Yeah, this is just, you know, URI is a very broad spec. There's a lot of strings that can be considered URIs. And for purposes that are unfortunately, I think more clear in future milestones, where we might want to set up the relationship between software to say, software A should, events from software A should be sent to software B. It's very helpful to actually have an authority component, not just a path component to URI. And because I, you know, I decided this is called a should, not a must, to avoid some controversy there. But all in all, I didn't expect it to be a very controversial. To be clear, the authority is the HTTPS. No, no, so HTTPS is protocol. Yeah, you can put authority, or the protocol for a scheme with the authority, but you don't have to. Oh, it's a domain. Okay. So I made a comment on this one with a reference to the actual URI spec. In the URI spec, there's an, as I say, an extensive discussion about the fact that URIs are not necessarily system assets, which means they're not necessarily network addresses. And I can tell you that in our case, in our usage scenarios of how we're going to use cloud events, they will practically never be network addresses. Is there a way that we could maybe scope this and say like, if you were using it for case X, then you should do Y? Well, the URI, I think the URI specification is pretty extensive and covers many cases that you might be interested in. But there is a very clear definition of what an absolute URI is and what that looks like. Sure. Clemens, you're there? Can anybody hear me? I can hear you. Are you hearing me? Did it sound like Clemens got cut off there? Oh yeah, sorry. Okay, I thought it was just me. Yeah, I just, oh, I don't know how I got moved. So the URI specification is pretty clear about absolute and relative URIs. And I think they're both permissible here. And then there's a bunch of URI types, which are interesting here, including URIs, which simply do not have an authority name. So there's, I think you're looking at this as a URL and not as a URI. And you can, for your implementation, look at it as a URI URL. But I don't think we will, like from a Microsoft perspective, we will not, we will look at these as URIs and not URIs. Interesting. Yeah, mind you, I might be getting all the nuances wrong. Like I specifically don't intend to, with the events we send, include a scheme. So I don't consider them to be URIs either. But it is useful to understand that, you know, once again, that the document is from, you know, fire sort of GoogleAPIs.com, not docs.GoogleAPIs.com. Yeah, but I'm not sure you can actually use the authority without having a scheme in front of it. Oh, absolutely, you can. That's no. I don't think, that's not my reading of URI, because the scheme, you can use an authority in the context of a scheme, but you can't make a relative URI reference without a scheme is, doesn't include an authority component. You can probably go and make one, but that is then not an authority, but that's your first part, that's the first segment of your relative URI. Yeah, you always need a URI prefix and perhaps even have an alias for that as well. That's a nation thing, but you absolutely have to have that. So either you have scheme, authority, and then you have a path, which means the relative URI reference, or you just have a relative URI reference, but you can't pick and choose from the front pieces. So this means that if one wants to specify the authority component, one must specify the protocol. Well, don't consider protocol, it's just a URI. That's our scheme, I misspoke, I'm sorry. Correct, right, so this works really well for ARN, but maybe not so well for people who might be transporting, using different ways to refer to things. So my point is the RFC 3986 is a very extensive discussion of all those concerns, and it gives you a ton of options for how to deal with absolute things and relative things, so I'm not seeing the benefit of further constraining that in our specification here. Yeah, it was easier for my, I'm newer to Google than Thomas, so I don't necessarily know all the Google things, but it was easier when this was sort of broken out into an authority and a path to math. Yeah, so in a notation where you have a string that looks like this, let's say services.google.com slash foo slash bar, then that is actually a relative URI where the first segment of that is part of your relative URI. Yes, I'm familiar with the URI spec, and I'm sorry I did not catch this nuance in the reading of the cloud event spec, because our internal resources can be accessed through multiple URL schemes in multiple ways, and so that we'll have to think about how to map that effectively. And we don't want to parse URLs, but that's not ideal, because of course the URI spec is very, very flexible. You can put anything in there and then do string parsing, right? So it's possible, of course. There are plenty of libraries that do the right thing and tell you whether it's relative or absolute and what the scheme is and all this, so I don't think it's that hard. I wasn't, and as I said, this is not hard. It is just something that we'd like to be able to map to a bunch of different ways that different providers can do it, and we're not going to block it if it's inconvenient for Google, particularly, right? We can write code here, too, and we can use libraries, too. And we just, I think, you know, I think we should hold on this PR and we should give it some thought about how it works in different scenarios. Well, in particular, we found its best practice is to keep it in a manner, and so when you're identifying an event or a source or any part of an event, scheme is required. That identifies how to interpret the rest of the string, and the rest of the string, and typically, in our case, it will be a hash or something, a unique identifier, UID. You need nothing else in between, but that minimizes the event, in most cases, and that's what we'll produce. All right, so I'm not hearing, obviously, consensus yet, and we'd like to go back and think about it, so I think it's good to have the initial conversation here. I think that clarified something. We only have four minutes left, and I don't think we have time to really talk about anything other than I would like people to take a look at this list of issues that I think we can now close, or maybe Mark, once he finishes his stuff on the website, maybe this week, we should really close that one. But please take a look at these, and in particular, if you own those, and you think we can close it, just go ahead and close it on your own. Otherwise, we may talk about those and a future call to see if we can close them. I have a quick question for folks on the call. I added a comment to the somebody had an issue on getting to more of a normal LGTM process. I just joined a different open source product that's using Prowl, and so I don't know how to set it up, but it seems pretty neat because you can have owners of particular directories that can then LGTM and approve PRs without being like worldwide access and capabilities. And so I thought for some of the things like the about, and I've just proposed having with community directories, where we have the opportunity now to have sub directories, right? And we can imagine members of the working group being able to accept PRs into those sub directories and streamline the process with a little more, you know, make sure that some has review and like add a little process there. But I wanted to ask if anybody's familiar with Prowl. I'm familiar with it from the Kubernetes world because I believe they use it. And I can understand they may need that because they have a very large structure with lots of different owners for different sections of the project. But my initial gut reaction is I don't think our project is big enough to warrant that level of overhead. Okay. So maybe not the tool, but maybe we could think about a manual process that like mirrors what that tool does because I think that that might be good. So yeah, so I'm not familiar with the tool. Maybe it's hard to set up. I don't know. I don't find the process that we have here defective. I don't see the need to add complexity and extra tooling and process on what we have now. Okay. Any other comments? Okay. So with that, let me just do the quick roll card check. I think the one two people I missed is Chris Borchers, are you there? Yeah, I'm here. Okay. And Sven? Sven, are you there? Yes, I'm here. Sorry. Okay. That would be so long to get off of you. Not a problem. We have a whole minute left. So it's okay. Is there anybody on the call who is not on the agenda or the list of attendees? Did you mark Dan Rosanova? I'm just sitting here on a... I did not yet. No. Gotcha. Thank you. Anybody else? All right. Thank you guys very much. It was very productive. So please look over which PR was it? Clemens's HTTP transport binding for next week. I think that was the one we said we'd wait on. Oh, no, sorry. Type attribute system for next week. Yes, exactly. But you should also, if you do get a chance, please take a look at the HTTP one because that's probably going to come in fairly soon afterwards. So take a look at those two if you get a chance. And then interrupt meetings at 7 on Monday. Is that right? Correct. 7 a.m. Pacific time this coming Monday. Thank you. All right. With that... Thank you very much. Oh, go ahead Rachel. Sorry. Thank you. Oh, she was saying goodbye. Okay. Thanks guys. Bye. Great work everyone. Bye. Thank you.