 Hey everybody. Hey Doug. All right. I see Lee John Mitchell Good morning. Good morning. What about Varun? Yep. Okay. And what about Joe Sherman? Louie? Louis? Is it Louis or Louie? I apologize. It's Louie. Louie. Okay. I'm sorry Louie Ganesh. Ganesh, are you there? Yes, I'm here. Okay. Excellent. Thank you Rachel I'm here Who is TS Nook? That's a new name to me. Oh Tony Snook. Hello. Are you new to the group? I don't recognize the name. I am. I am new to the group How you doing? Excellent. Good. Very well. What company are you from? NAIC NAIC got it Thank you, sir No problem I assume you're gonna be joining regularly, so I should add you to the 10D tracker That'd be great. Excellent. Okay. We'll do I think that's everybody's. Oh I'm gonna butcher it. Jay Prakash Hey, hi, even I'm new to here. Hello Hello. Yeah. All right. So make sure I got you Chris Borchers Hey, I'm here. Hello Jim Curtis Jim, are you there? Yeah, I'm here. Excellent. Eric Erickson Eric, are you there? Okay. I don't see a little microphone. So I'll have to wait on him Stanley, are you there? What about Kathy? Yes. Yeah. Okay. Hey, Kathy Stevo Yes, hello. Hello, Austin Austin. Are you there? I'm here. Just here. There we go. Cool. Dan, I'm not sure which Dan that is though. Is that Rosanova or Dan Barker. Barker, that's it. Thank you Hey, Doug, I think you might have called my name and I had my mute. This is Stan Alka. Oh, Stan. Hey, excellent. Gotcha. Thank you So Eric Erickson, are you there yet? I'm here. Excellent. Thank you Let's see. Who do I not have close? Yeah, I'm here. Cool. Sean Here. Cool. Thank you. Is that really everybody? You guys are early today. Actually, there's Ryan. Are you there? Hey, this is Vio. I'm here. I'm sorry. Who is that? This is Vio. Hello. I'll add you Vio. Thank you. Okay. Thanks, Stanley. Oh, cool. Um, Gannett. Oh, sorry, you already got Gannish. Sorry. Thomas. I'm here. Cool. Is there anybody on the call I'm missing? Oh, actually, wait a minute. Ryan. Yeah, I got to be Ryan. Did I get it? Yeah. That's what I thought. Okay. Vio is there. So is there anybody on the call who I don't have on the attendee list yet? That's pretty good. Oh, William. You just joined. There, William. Hey, cool. You guys are anxious today. And just so you guys know, you know, obviously, I don't mind if you do it, but you don't technically have to add your last name and company unless you really want to in there. As long as your name is unique enough that I know which, like for example, which Dan I'm referring to. I'll get you on the attendee tracker. But obviously you're still free to add the other things that you want. It's just not mandatory. I just like doing it so that I know when someone is talking who like where they're from. Yep. No, it's definitely a good idea. I just didn't want people to feel compelled to, you know, I don't want people to think if they left their company name off, I wouldn't track them. It's also future proofing a little bit, right? Like another stand could join. Another stand. Oh, no. Okay. Yeah. Um, all right. Give this other 30 seconds or so. Is there anybody who joined the call? Hey, Mark peek. You made it. Mark Fisher, you there too? Hey, Mark. I did make it. I'm still in Armenia. Cool. What about Mark Fisher? Are you there? I'm here. Yes. Excellent. Thank you. Sarah haven't heard you yet. Okay, cool. All right. You're on. You're on. Are you there? Sorry. And also rate is with me. Okay, cool. Hold on. Why is my cursor not working? All right. Before we get started, is there anybody on the call who is not an attendee list? All right. With that, I think we're good to go. Cool. Thank you guys. So action items. I believe there's nothing really to say here other than to remind people to please complete your AIs when you get a chance. Reminder, we do have the face to face coming up at KubeCon. It will be an official meeting. So far, 18 people there is going to say they're going to show up. Obviously, you can still show up. Maybe if you don't do the doodle poll and I will set up a proposed topic doc as you get closer. Usual spiel. So I thought it wasn't going to be an official meeting. I thought you're, I mean, are you going to have AV so that people can join if they're. I was going to try to have it. Yeah. My request to Sarah was that we, like there was the just call into the zoom, the standard. Okay. I just think it should only be an official meeting if we can definitely do AV. Oh, that's no fun. If we can't exclude people, what's the fun of that? Okay. So actually, I guess I should have actually formally asked the question. Is there any objection to making an official meeting as long as we can get a dial-in? Probably zoom. And the assumption there is if we for some reason have technical problems and we don't have zoom, then we're going to have to say it's not an official meeting. Is everybody okay with that? Yeah, I'm okay with that. Okay. Any objection? All right. So no objection. Cool. Thank you. Thank you. All right. Let's move on to the fun stuff. PRs. First one up is Clemens PR for use scenarios. My internet's going really slow here. So I believe last time we agreed that we were going to basically vote on this one this week. People should have had more than a week to review it so far. Are there any, actually, I guess I should ask, since Clemens isn't here, actually, Dan knows a rough, actually, who was it? I'm still bad with names. Joe? Yeah, I'm here. Now, I think Doug might have the latest status because he was in the intermediate meetings during the week last week. Okay. Yeah. Well, the latest status is definitely here. So let's just ask the question. Is there any objection to adopting 117 or accepting 117 scenarios? Going once. Okay. Cool. Thank you guys very much. And keep in mind, I should have said this actually before that one, the goal here on the call is to try to make forward progress as best we can. As with any PR, we can always accept changes later on. We're going for heading in the right direction, not perfection. All right. Next one. Sarah contributor list. Is there anything you'd want to say on this one before we ask the question? I don't have any additions. Okay. In that case, are there any questions for Sarah before we ask the question? All right. Any objection then? Oh, yes, sorry, Kathy. Kathy, she did get your change, I believe. Oh, okay, that's good. Anticipating your question. Yes. Okay. Any objection then to adopting that one or approving it? All right. Cool. Next up. 120. So Sarah, just some clarification here. I did not actually delete content. I did a rename earlier and to remove a space from a file name. And I just forgot to delete the file that had the space in it. I didn't actually move content. Okay. Sorry. I didn't have a chance to do forensics. No, that's fine. Like I said in my comment there, I thought I put a comment into that effect, but apparently I forgot to hit enter or something. Okay, I was just confused by the thing. Yeah, I think in the future, having them as separate PRs would clarify that, but I'm not going to object to it based on that. Okay. So this one is just adding a link to Clemens video that he sent out an email about, I believe, on the 22nd and a link to the PowerPoint itself. All right. Any questions on that? All right. Any objection to accepting it? Let me go ahead and close this. Okay. Any objection? Cool. Moving forward then. One, two, three. So this one's been out there for about a week. Unchanged, I believe. So this one is mine. It basically takes the position of having source be defined as a URI. And that collapses source ID, source type, namespace and the source object all into just this one URI. As I mentioned in the PR itself, the assumption here is that people will open up follow on PRs to potentially extract information if they think it's worthy of being a separate attribute. But this at least gets us a baseline at which to work from. Any questions or comments on this one? Just thank you. I think this does help simplify. I'm glad to see the source object go away since that was confusing people. And you already know I have a follow up. Yep. I've heard several different people want to follow up. So yeah. All right. Anything else? All right. Any objection to approving? Excellent. Thank you guys. Moving on to one, two, six. Another one of mine. I believe this was open like a little while ago. Three days ago. Okay. So this one, I can't read exactly the context of which it came up, but I know I've heard at least more than once people talk about potentially having well defined extensions that have no official standing from the working group other than some people think it would be nice to at least have a common place where people can agree on the syntax or shape or definition of some extensions and they just want sort of a common place to put it. So I thought it might be nice to have a place within our repo to list out well known extensions. As I said, they have no official standing, but that people can have a common place to keep them and then people can add or remove things as necessary here. Let me just sort of pause there. Are there any questions on that? Well, I just want to say that like I would really love it if we prioritized changes to required attributes that people think are necessary to hit our point one milestone. I think that this is a kind of a good way to deal with like a lot of things that but anytime we start up would be nice. I just feel like we have really crowded working group meetings and I'd love to focus on the required things. Yep, and just let you know one of the reasons I did put this one fairly high is because as we start talking about other attributes, I wanted to give people a home in which to put extensions like this. So for example, if we start talking about an attribute that someone says they need, I want someone to be able to say well that's nice but it should really be an extension and it should go into this document there. That way there's no ambiguity about where it would go if it does get into that bucket. Without this document there, we were sort of left in this nebulous state of you'll get to find someplace else and I wanted people to feel like if they wanted to, they could have a home for it. That was the reason I kind of prioritized this one that way. If there is any objection or concern at all, I have no problem with deferring this to later. But that was my thinking. Hey Doug, this is Austin. I'm going to ask second what Sarah said, of course that is super important. At the same time, I do like this idea. And I recognize the intent and I think we actually came up with this at the end of last year and it simply just fell through the cracks and got lost in the shuffle. So I'm glad to see this come back. So I think it will solve a lot of problems. Okay. Right. Any other questions? Yeah, go ahead. We accept this PR and then had a follow on that basically not only at none at this time adds something about just come a point of order like we will review extensions after zero dot one is ratified. Sounds fine. APR is valid to me. So yeah. Well, where would that go? Because this is. Well, can we defer that? Can we defer that discussion for when they open the PR? Sure. Yeah, I think it's just, we don't really have a place to discuss how to move more efficiently in the working group. And so I'm not quite sure how to address that. Okay, so let's focus on this. So any other questions or comments on this particular PR? Any objections to approving it? All right, cool. Thank you very much. Definition of events. Clemens is not here, but this one's been sitting there for quite a while now. So hopefully people had a chance to review it. Are there any questions or comments on this one? What concerns? Go on once. All right. Any objection to approving? All right, cool. Thank you very much. Next. Jason's serialization. Okay, so this one's opened up six days ago. This one takes a first pass at defining what a cloud event would look like as realized in Jason. I believe Thomas had a suggestion for a slight change to there, which I hope we might be able to do in a follow on PR. So the bulk of the PR has been unchanged in basically six days. The only thing I did change today was based upon someone's comment. I made it clear that non-mandatory properties, as defined by the spec, are not required to appear in the Jason. I thought that was implicit, but I'm trying to make it explicit. But if they do appear here, then they have to adhere to the description described above. And then I just added a quick example, because sometimes examples help people understand what's going on. Are there any questions on this one? Well, I think that this is, I like to sort of work on the Jason format and I don't disagree with it. I just, is this going to cause that every time somebody proposes an attribute, we have to change it in two places. Yeah, I mean, if they're going to add an attribute, then I would think it would be good to show its serialization. Yes. Yeah, I think that's inevitable as we make more examples of this anyway. But I do like the idea of getting this example out there. People think it's helpful and it's not too much overhead, then I'm not opposed to it. Okay, I noticed that there are two versioning methods. I'm not sure if this is disgusting, but if you scroll down, the cloud events version is using one format and then the event type version is using another format. If you scroll down to the example. Oh, did I mess up? Yeah, just it. I thought they're both strings. So you can make it whatever you wanted. It makes you feel better. I can move a V. I guess we probably, I guess perhaps we haven't discussed this yet. Yeah, I mean, too, I think, I think the spec just says it's just a string. So, okay, well, let's, yeah, let's skip it for now. We could. Yeah, and this, this will never, this will have to be updated to be in sync with today's changes. It's definitely, yes. And I'll do the separate PR. I'm not going to update this one, but as part of this, if we do accept it, I'll do a separate PR to update. I think there's too many changes to sort of put under the covers as typos. So, I have a question. So I think some of the fields here. Since we have the new use cases, just, I mean, just committed, right? There might be some question. I saw some question about some of the fields, whether, you know, it should be there or not. So this is not the final version as we add or remove attributes. I expect this to change. Oh, okay. That's fine. All right. Any other questions or comments? Um, what was, um, about my question regarding the encoding, is it base 64 or for the data? Is that something we could address and follow up here? Cause I think that's probably going to be a bit of a discussion. Yeah, probably. Yeah. Cause I can see that being a very big rat hole, to be honest. Yeah, probably. Yes. Okay. I appreciate that. Thank you. Okay. I'll make a note to add that. Actually, in fact, I'll add an issue to remind myself. I'll make a note here to add an issue for encoding data. That way I remember to do that because I don't want to forget your comment. Okay. Okay. I think the assumption was that it's not going to be encoded. That's going to be part of the issue that I'm going to open up is what do we want to do with anything within coding? Okay. Any other questions or comments? Okay. Any objection to approving it? All right. Cool. Thank you guys very much. It's been on the call. I don't think I saw his name go by. I was just chatting with him on Slack. He's not here today. Oh, bummer. Okay. So let's see if we can look at this anyway. So maybe if somebody, one of the ideas that if somebody else is an advocate for this, they could talk to it. Yeah, obviously. Yes. I'm a huge advocate of this use case. And I can talk a bit about like why, for example, sampling is not averaging or anything like that. I am not 100% sure, like I've been ambivalent about whether this is a top level field or an extension. I think that Ben's concern was that, you know, like as a provider of an observability system, this needs to be something that is not just like the few hipster services might support being observable. Yeah. To add context, the reason I think that Ben isn't here is because he thought that he would not be able to get this changed through this working group and his interest, like in being able to contribute. Like he was just sure that he wouldn't be able to affect change in this working group. So I actually had a conversation with him. I can't remember. I think it was last week. He definitely didn't get to me that he may be pulling back. I didn't get the indication it was because of not being able to get this through or other changes. It was more he just he was busy and they're a small startup on this particular change. He did seem to get to have the feeling that and I apologize for if I'm for speaking for him, but this was my interpretation what he said was that his general sense was that the working group would probably not accept this as a top level thing. And that's showing up as as an extension, I think was okay with him, but I have to go back until checking my notes or a slack chat that we had, but it definitely was not going to be a required thing. At best it was the optional but probably fall into the extension bucket. Well, certainly it being optional and not in the extension bucket would allow multiple observability systems to like then they don't like we don't have to wait for everybody to align on some name. It makes it more likely that But if we take this example, I think we can come with a dozen of more things to add to the spec. I think this is a clear extension. It's not something that's mandatory to observe the system. Well it's listed as optional right so this is comes into the right but I'm saying I can have a dozen more options that will make sense the same at the same level. Right which is to like my prior point of prioritizing things that are required. Like where you know I would I would eliminate such things from the spec because then I would argue for a dozen more. Well, I mean, then you'd argue for eliminating timestamp which I think we all agree not everybody has but is high value if it's named the same across systems right. So one of the things that I was what I in my mind one of the things to consider is something that appears in the spec even as optional cannot be easily removed without a version bump. That's something to think about. And the other thing is when people have talked about the well defined extension document that we just approved. A lot of people view that as an experimental place. So if for example, people aren't sure with how they feel about something like this. It could go into that particular bucket until people have some some real world experience with it to see whether it gets used enough or is popular enough to then warrant at some point in the future to be elevated to become an optional part of the spec or even required at some point. So that's another path for people to think about. Yeah, I agree with that approach. You know, I can give you just another example is like batch size, you know, maybe I'm getting a batch of events. It's at least the same level of importance as having a sample rate, because then when I decide for the message, I know if it's an array or individual event. So if I if that's the level of things that we want to ratify here, then I could come with a dozen that are the same level of importance. I rather keep it minimal. Yes. So let me put forward the question or the been put forward a proposal. Is there any objection to adopting this property as the first extension to go into the document we just agreed to the extension document. I think we should actually address the how are we going to have multiple teams, you know, who are all aligning on a attribute which needs to be produced by one team and consumed by another, you know, like going to work. And this is exactly why I propose this governance model of having multiple if multiple active members are like we want this thing and it will help us interoperate, then I think that's a really strong, you know, argument towards doing something. Rather than just saying anytime somebody thinks maybe it's not required or high value then we just throw it into the extensions bucket and like and this is and I think that this conversation is really important. It's just frustrating to have this conversation before we have aligned on the required attributes. So my interpretation is that right now as we're discussing this before request, if people claim that they have use cases and hard requirements that justify this being as part of the spec either as required or optional that they should speak up now. I want to say I agree with Sarah's suggestion. I think, you know, we should not just take I'm not talking about this specific sample rate. But I think we should not, you know, take out attribute just because of, you know, one person or two person said no it's not needed. I think if it helps with interoperability and they supported by, you know, several teams. I think, you know, we should consider it. It's an important attribute. Because there are other fields that are optional to which are part of these attributes. Either we have a good guideline of how we, you know, decide. I think the suggestion is a good way, you know, because for some people it might not be useful. But for many other people, it's very useful for interoperability. So Sarah has a poor request to discuss our governance model in the process. But as of right now, the process is someone puts forward a proposal. We analyze it, we talk about it, and then ultimately we do some sort of voting on it. So if we want to change the governance model, that's fine. Sarah has a PR and we should talk about the governance change in that PR and that's fine. But right now in front of us, we're looking at this. And there are, in my mind, there are two different proposals on the table. One is accept the PR as it is, and I'm not hearing a whole lot of support for accepting that, but I could be wrong. The other proposal is to accept the definition as defined here, but move it into the extension doc. I think we should table this until we figure, like, I would like to hear, I actually think Ben makes good case, I would like to hear that multiple vendors would like this as is. And then I really want it in the spec otherwise, because if it helps have those vendors participate in order to have alignment on the naming, then I would advocate for it. If the extensions is going to make it harder for small companies to invest the time in doing this work, then I would not want it to be in the extensions, and I can't speak to that given the data we have. Okay, so is there anybody on the call who would like to advocate for the PR as it is? One once? Okay, I'm not hearing support for it. I would like to put forward a formal proposal to adopt the definition of this, but put it into the extension document. So, can we table it until we have more, until we can, like, hear from Ben? I suppose we could. I'm just not sure. This PR has been out there for quite a while with virtually no comments, so I'm not quite sure what additional data we're waiting for. Well, to be fair, we haven't really dealt with a lot of PRs. We've been very focused on one or two PRs like the last three weeks, so. Okay, so tell you what, I will make a comment in this PR that says, basically, that says the current status, because I don't want to rush people, so say the current status and let people know that we're probably going to make a decision next week and put the various options are, so be prepared. How's that? Well, if it takes more than a week, I think that it is fine. I agree, but people need to come prepared to advocate for a particular position, but if no one is going to advocate for, for example, taking the PR as it is, then we're going to take that data and deal with it. So, I would like to see support from additional vendors who need this field before making a decision. I'm not quite sure what you're asking for, Sarah. People who have. I'm advocate, so I would like to table this discussion rather than queuing it up for next week until we discuss the governance model. So, Sarah, I have to admit, I'm very confused. You start off the conversation, basically the phone call talking about how you want to be able to go through things in essence faster. I summarize, you know, I'm being kind of blunt with it, but basically you want to be able to move faster. And yet, when we try to move faster, you want to talk about governance, about moving faster, which talking about governance doesn't necessarily move us faster. I would like to focus on the required attributes. Therefore, I would like this not to be put on the agenda next week. Okay. Unless there is support from multiple vendors who need this field. So, Sarah, of the PRs that are out there, I'm not aware of any that talk about required attributes that are ready to go as of right now. The next item on the agenda. That is not ready to go because of previous PRs that we just accepted. What? Why would that be true? Because we can talk about it and that's why it's on there. But I don't believe it's ready to merge because of the previous PRs that we accepted today. It's going to have to go through some textual changes, if nothing else. So, what I would like on the agenda for next week is either people have PRs to the required attributes or we all accept that it is sufficient and we have the required attributes that would allow us to be moving on to making samples and validated that those required attributes work. Yes. I believe that is the process we have. If people don't like something, they add a PR. If there are no PRs available, it's going to be a very short phone call. That's the process. And I would like if there are no PRs available but people don't feel that the spec is sufficient, I think that having a discussion of that is important. Rather than talking about optional attributes. Priority is given to PRs. PRs are the only thing that changes made. So, if you want to discuss something, that's fine we could have a discussion, but I am going to give priority to PRs because those are actual proposals. How about this? How about you leave a comment on that PR. We don't add it to the agenda for next week because I suspect it will take more than one week's worth of work. And then we move on to the conversation about the next PR, about Thomas' PR. Understanding that we'll have to change it in light of the things we just accepted. Right. So, like I said, I'm okay adding the issue there and let's take the discussion of governance and process offline. But as I said, we'll defer action on Ben's PR and we'll move on. Doug, I have another suggestion. So, for discussion of any PR, it's better, you know, the PR author to be in that meeting. Definitely. Yeah, if the PR, you know, people might go on business trip, right? If that person is not in the meeting, you know, I think we can postpone that PR discussion. Yes, I agree. I just know I've talked to Ben and it sounds like he wasn't going to be able to join us, not just today, but possibly going forward. Yeah, I'm not talking specifically about this PR. I just said, you know, general. That's a general rule. Yeah, I totally agree. Okay, good. Okay, so with that, let's move on. I feel like what's missing is clear, clear criteria for what it means to be a core attribute in the first place. And so we have these discussions. Like my proposal would be that a core attribute is something descriptive generically, like the source, the type, content type, so on. But any, any attribute that's related to the context in which an event is being used or emitted, sampling, batching, those types of things should be extensions, if anything, and not core attributes. Is that Context attributes should be moved to the extensions. Are you suggesting that I don't think that All optional attributes should be in the extensions. Right, so I think some attributes and within the core attributes there are required and optional. Yeah, I think what I'm suggesting is that if something is like sample type is clearly not going to be relevant in in all systems. Feels like an extension as opposed to content type is relevant in all systems. So Mark, I think this is a really good. So Mark, I think this is a really good thing to discuss and I'm wondering whether you think it makes sense perhaps to take an AI Add a little bit of text to the specification to explain, in essence, the three different buckets of attributes we have and the The thought process that went into deciding what's which things go into which bucket and that way it provides us guidelines and explains to readers of the spec how we made our decisions. Would you want to do that? Yeah, that sounds good to me. I'm sure there will be a lot of discussion on the PR but Oh, I'm sure. I have another suggestion. So in the extensions you I mean it's mentioned. It's not officially supported by this work group something like that some wording like that. I think that what why we put that if people spend time discussing that and agree on it. I think you know You know why we know we said that you know it's not officially supported by this work group. Okay, I was just removing that you know if you know people think that it's not needed that you know we remove that from extensions, but that does not you know put the extension as a you know I put the you know extension as a lower standing than than the document. Okay, hold on just seconds trying to make some notes here. Just so we have it. Okay, so I got your AI there work. Thank you. Okay, so. So Kathy. If you're proposing to remove some text from that documentary is accepted. I think that that's a that's okay. Could you do that to the form through a PR so we can discuss it and people can see exactly which text you'd like to see removed or modified. Okay, yeah, I can do that. Okay, thank you very much. All right, I think with that we can move on to Thomas's and you can discuss why you'd like to pull out some I assume you probably want to decide after you reshape it you're basically going to advocate pulling out some data right. Yeah, so I wanted to like my theory about like why some of these fields have been contentious is that when you look at the trees you lose the forest so I want to at least be able to discuss the forest with everyone. And then we can, like if we see that some subset is non controversial and some is controversial. I'll certainly break it up. I just want to break it up according to actual controversy as opposed to just preemptive and cautious pieces. I think the examples might be the best way in the description might be the best way to navigate this. Sorry, I was going to touch on where to go. Yeah. So there's a couple of motivating factors here. One is I was trying to bring back some of my original inspiration of using the Istio vocabulary for what they call re actually I think they call it source as well. And also some of my confusion I had had with namespace which we already you know now just removed. I think there's two things that ultimately need namespacing the source and the event type. So I had cut that and put it into the source where authority and path or break basically re breaking up the URI for source. I don't honestly mind if we want to instead merge authority and path and keep it as one thing if we specify that the URI must be a subtype of the URI spec that includes the authority component. But these are basically source authority source path are very explicitly defined as portions of a URI that make it an absolute reference in practical use. I find this very useful that the path is something that generally the you know the C code inside the software has decided whereas the authority is probably based on some config about the deployment. So you in a later example you'll see that I have the I think the GitHub events and maybe a GitHub path but where the authority is my actual local deploy of Enterprise GitHub. The Kubernetes concept of source also includes labels. So there's Kubernetes has this AWS has this GCP has this and I realize that this also solves a lot of the IOT cases because it can allow a late time binding for something like a correlation ID. Where if we have for example that the deployment location is this house or the types a certain window your subscription could actually key off of and filter these things. And then with event type. Since I was getting rid of namespace felt that we needed that in the event type because if I have some observability system document dot change is very different from talking about a word document or a database document. Any questions. Do you want me to scroll down to the next one or how do you want to proceed. We can scroll through examples and hopefully someone will chime up with objections or like that they see value less or. I would really like to hear both from your own and Kathy about that IOT use case does that match what you like to see here. To be honest I haven't got a chance to read through this PR yet. I'm sorry about that. Okay, no worries. Yeah, but I would I will go straight and yeah and think about this. I think this is good you know I just need to go into details on you know all these fields. Okay, we can move on to the next use case and give you time to like look through my next week. And and otherwise Kathy I'm happy to talk either here offline if you have extra time since I know we've been chatting on our respective PRs. And I just want to make sure like I think I'm trying really hard to make sure I cover your use case as well as possible and I think this actually gives a more flexible solution. Then for example the correlation ID because of the router itself can do the correlation ID and key off of any label. It allows different software to for example listen to all things that are deployed on Windows or things that are deployed at a certain house. Yeah I think this carries the information but you know for application for but how do we know which one. Like for example the previous example the LT example right you have the source path you'll have the. So here you have the difference you have source path source label event time. How could application know which field which one will be used to correlate all those different events from different event sources together. Yes I think. You need to know right here I know this gives the information but we still don't know whether we should use source path to do that or we should use a source label or any other fields. Yeah I think that's in some ways intentional that the it's decoupling. Information so I wanted to make sure that the for example the IOT sensor didn't need to understand the way that any given application would be correlating the data. And that it could provide non structured information where. For example the the application that allows a maintenance staff to make sure that something is working could look at a particular house or maybe the vendor itself of certain boilers could make sure that they're not overheating. I think that that's the this feels like it is properly decoupling that the source does not understand or depend on the exact application of or routing information of the action. Yeah I agree with your points. I'm more thinking from an application point of view. But maybe we can take this discussion offline. Okay I yeah. So maybe how would you like to shoot me an email we can probably set up a meeting. Okay thanks. And if you have time to look at this before next week to see if this is your case that would be awesome too. So I think the gist of what you're proposing is basically required attributes source authority and sort of path and then basically as a place for forgive me source extensions basically. I mean these are labels which is not really an extension for most platforms like these are very well defined first party concepts and a number of especially cloud systems. Yeah but yeah I mean that obviously that extensions to the person putting them there or they may not be extensions to the person putting there but from the spec perspective it's sort of a open space where you could stick stuff that you need to but make it clear that these aren't just general extensions they're extensions that are related to the source. Well I think specifically my reading of this is they they are things that the source the source is the sources would be consistent in how they advertise these labels so they they get to define them. But then they don't like just arbitrarily use them like you know what if like the idea is that they're consistent for a particular source so that the consumer actually says okay this source has this set of labels and you know maybe they wouldn't always be there but. I mean I don't need to overly specify it but the idea is that. They're. They're source define the source gets to define them right I mean I guess everything the source defines never mind. Your point is you know for different vendors if they have the same type of you know source source I would say for example same same type of sensors but those sensors produced by different vendors you would like. A standard way of you know how they define all these source paths and labels so the consumer kind of how to use right have a standard way of using it. Is that what you want. Well just that I mean I think that what I'm saying is that I think that I see that that I see patterns where. Sources provide kind of like some consistent metadata of their own devising right that then is useful to the consumer but I think that that sort of you know just kind of extends this notion. So I think that like extensions is one way of putting it. However you know there was sort of the side conversation in the chat that extensions in the in the main spec are like really for these like experimental things but this is really that for particular vendor or particular source type these would be. You would have a sort of expected shape. I would I would argue that you're trying to essentially put the event itself into the you know envelope. And actually this is this is precisely addressing the need of filtering. So this is when there is certain metadata for the event. Which needs to be kind of like on the outside of the envelope that then the router is totally the source decides this right the source is like hey there's some of my. I have some metadata that I think would be useful for routing and the source has a place to promote that is it Thomas I'm articulating that. I want to be very careful with the word source because especially with hosted software. There's multiple actors involved so very practical example that happened to me in the past was you know during Google I O last year Google was rolling out some new software. And they really really didn't want to accidentally roll out the software and break a demo Google I O. So Google Cloud Platform has the concept of labels built in and if I just annotated my project with like a certain key and certain value that said I want to opt out of changes during this time window. Then someone else's software who you know the IT enforcement policy at Google would change the behavior for my specific Google Cloud storage bucket. And that's like the type of thing where it's it's not even the in the hosted service case for example it's not even the person who created Google Cloud storage that knows to to. Inject a specific label they have given a platform for the operators of the system as a whole. Whereas experiments it's very often that for example the router or the source has a non canonical field that they understand they publish and they. Whereas labels are left to the developers or operators of this cluster. Yeah you know two comments one if I'm looking at the hosted service example I wouldn't classify something like bar.jpg as a source. I think it's sort of the thing we're talking about it's not necessarily the thing that generated the event. And the second is that labels doesn't have to be confined to the source that may be labels that are injected throughout the way. So why not generalize the notion of labels. That is a fair point I want I had prefixed it with source because I was explicitly suggesting that these are the labels that are the developer has added to the source. I think that this is a very interesting use case and I want to see more about it before I really wait in. It sounds to me like we're confusing the term source once again because if you take the example I published with S3 topic that comes from SNS that comes from S3 etc. You know the source is not in this event the source is not really the object that was generated in the S3 bucket. Is either the SNS service or the S3 service that reports about something. Well then I think that's a different kind of label that isn't a source label and it's valuable to the consumer to know like in you know in the actual PR. It says labels associated with the resource that emitted the event right allowing filtering a routing based on non hierarchical source metadata like I think that's pretty clear that it is exclusive of something. That is like oh I'm going to add something that says this was transmitted over SNS which doesn't preclude having a as we discussed in last call doesn't preclude having some middleware that access the source and says no actually I know that this. IoT device was in a particular location so I'm going to annotate it because I I'm making my IoT device more efficient right. It sounds like putting the attachment name in the email a source versus the you know from in the email a source and the second again around the labels. If there is a need for that I would argue that labels needs to be generic not specific to source because as a intermediate point I may want to inject label because I've inspected the message and I've noticed something and I may want to label it so I would. Generate generalized labels not necessarily a source label and the source could be the thing that generates the first labels and others may inspect it or add additional labels. I personally think this would be a lot less confusing if we had a single attribute that was the uri because all that's basically happening here is breaking uri components and the labels actually correspond to the query. Where optional non hierarchical values can go. Think just a quick point of order kind of thing if you're not talking can you please go on mute someone someone was typing there and it's kind of overriding what Mark was saying Mark maybe you can just repeat the last part again kind of hard to hear. I was just saying like it's very explicit in this doc that the source authority and source path relate to the uri. RFC and the corresponding section of the uri that would match labels is actually the query string which I agree query would be a terrible. Confusing name if it's broken out like this but if we just had the uri as a single value and the optional query string is where you add key values for labels. Seems like that would be clear that it's directly related to the uri representation of the source and not something that you picked up on the on the path. Yes, to me, I tend to agree with that but I think you're saying there Mark and that's one of the reasons that I propose the idea of a single uri is because ultimately the source, and I guess the consumer, because they're going to understand it. You know they're going to decide what data to include and stuff and and if the many start splitting these things out you then have to get agreement on how many different ways you split it what does each thing actually mean. And each source may actually have their own way of interpreting those things or their own set of data they want to pull out. Whereas if you just say it's a uri and the receiver because they know they're talking to me is going to be forced to extract the things that I tell them to do extracting the right way to extract it. Then we as a spec author don't have to get into that business of doing that for them or trying to find a normative way to define how to split it sort of let the uri producer to find it themselves. The only thing I've heard that would be worthy of making things get pulled out is if for some reason the process of extracting information becomes a burden from a performance perspective. That was one of the arguments that I heard that really made me think okay there may be some things we need to pull out because it's common enough and and it impacts performance enough that asking everybody to pull it out is just to going to slow things down too much that was what I've heard and that's sort of where my head is at in all this. I think some of the other cases that as the vendors for a system that will handle these events the stricter we can define the the meaning of these properties the better software we can build on it so whether source authority and path are joined as one source or not. I would like to at least specify that the uri must include an authority component. This is fairly important for knowing how to actually set up the triggers that will fire these events which I know is not currently like triggering is not currently part of the spec but I do want to make sure that the. I'm kind of indirectly trying to solve that problem with this as far as the labels I put a comment in github asking for votes plus up or down whether or not it should be source prefix or not. I am a little hesitant and putting it in the uri because I think it is valid that. For example, if I have a simple event that track when someone clicked post on a uri and that you are I had already a query fragment but the resource backed by that you are I had labels that are internal and operational. These are very different types of concepts and they have very different integrity levels as well. One is user input one is developer input so I do think that these actually adds a lot of value being separate. I didn't quite follow that I'm sorry. So describe that a little more. So. So we've got seven minutes left I wonder whether. If we say that if source labels were in a separate PR we could have a separate discussion around whether they should be source labels or just labels. And then I'm curious whether people on the call like this breakup of source authority and source path which I think is a clarifying concept but. Thomas has indicated a willingness to go one way or the other so I think that it might be good to hear people's opinions on that maybe we could close off that part. I think you could still refer to the RFC and the fact that authority is a required attribute this must conform to the uri. I apologize I was actually talking on mute earlier. So Thomas I was going to ask you what how do you want to proceed on this is this something that you'd like to work through just comments. In the PR itself do you want to try to set up an offline meeting to have a discussion or wait till next week's phone call which I'd rather not do but. I would like to make more progress than wait till next week. So it seems like from what I'm gathering there's a couple discussions. One is whether or not source should be split into authority and path. The other is about labels. The three options is they are part of the source directly. The second is what their attributes their names based a source and the third is that they're just global. The only one I'm against is the first for reasons I can go into in another PR and we haven't had a discussion on event type. Right. So what I would ask the committee members is that for a like I will put a couple of please vote yay or nay on comments. If you do a thumbs up or thumbs down in GitHub I will do follow up PRs this week and next day or two that will split this into three PRs according to what has the best vote. Okay. Do you do you want it to be voting in GitHub would it be helpful if we had a like a separate meeting a different day to just come. Why do you need a meeting for the URI. I think there's a very clear question. Do we want to URI or do we want to break it down. I think I sense a consensus around trying to get to a URI. I think we can vote and then see what we don't need a session because I think the question is clear. It's it's your choice Thomas since it's your PR. However you want to work at it. I'm hearing you want to do a vote is that true. I think I'll give people one day to vote. And then do you separate PRs. Okay. Yeah the people can and I also would like to ask people when they vote to say why. Because I think that helps other people align. Hey Doug we've only got a few minutes left I'm wondering if we could just take a couple minutes just calibrate on a possible schedule. Because with our next meeting is going to be in the month of April and we have cloud native con happening at the beginning of May. And we'd love to announce this and it'd be so great to announce this there. And we have to make sure that we're moving as fast as possible to get you know get the specification. The MVP of it finished and then getting some examples and reference architectures built around it. Yeah and it would be great to use this meeting to focus on the required fields that are necessary for that. Yep. So Austin how would you recommend best way to sort of I guess define what MVP is for the coupon event. Should we because we already have the milestone stuff I suspect that's not fine grained enough for that definition. No. Maybe a wiki setup for people to define what their requirements are for MVP. I thought that was the point one specification or you mean specifically what do they think the required fields are necessary for the point one. Yes exactly or one way to do it is to say open up issues or pull requests for whatever you think is for MVP. And then we could just tag those in GitHub with the milestone point one and that's the way to track it. Yes I thought that's what we were doing. Here I mean that's why I requested these holistic PRs right. So what if we do this. Go ahead. Right so what if I send out a note to me on this to tell to tell people that on next week's call we're going to try to narrow down what the MVP items are and so get your issues into GitHub or PRs into GitHub one of the two. And we'll figure out which things get the V1 I'm sorry V0.1 label. Perfect. Great. I think we should vote on that and make that finalize that by the end of the next meeting. And are we just not going to talk about processing governments like that that just do you want to have a separate talk about that I just I really feel like we could have some structure around the async conversations that could move us forward quickly. So Sarah why don't you and I first talk offline. That'd be great. Okay. And I guess I guess in the notes. I will ask for people to especially make a comment somewhere in their PR or issue that they would like it be to be part of the MVP. Just so we can get our list of things we're going to discuss and vote on next week because it is not. If you don't say they want to party MVP I think the default has to be that they don't think it's important enough for MVP. So fair. All right. Cool. And with that we're almost out of time. So let me just do a quick roll call. Grish are you there? Yeah. David Lyle. Yes, I'm here. Okay. Is there anybody? Excuse me. Is there anybody on the call who is not on the attendee list? All right. Cool. With that I think we're done. Thank you guys very much. Talk next week. Thanks everyone. Bye. Thank you. Bye.