 Oh, thank you. All right, it's three after the hour. We'll finish up the attendees' list later. Let's jump right into it. I'm sorry, who's that? I thought I heard someone speaking there. Okay. All right, let's go through the AI, see if there's anything that jumps out. Is there anybody who want to mention their AI status that's worthy of note? I think most people know about their AI's. They just need to find time to do it. I know, Kathy, you're working on your PR, so I know that's when the world works. I don't think it's worthy. Anybody want to talk about their AI's at all? Okay, moving forward then. So possible face-to-face at Shanghai. We may do a meeting. It will not be an official meeting because I don't believe we have a quorum based upon the due to poll. I guess that actually closes today. I think I just double-checked, I'm pretty sure. Actually, I know there were no new votes. Actually, I'm sorry, this is probably wrong. This probably should have said Seattle. Anyway, I'm sorry, I'm like, it's been a busy week for me, I'll clean up that stuff, but I do believe there's a due to poll out there. I'm sorry, what's that? Sorry, Seattle's in December and Shanghai's in November. Yeah, but I think I just messed up on this because I think we already decided we were not gonna do a face-to-face meeting, an official face-to-face meeting at Shanghai because we didn't get quorum but I did put a due to poll out there for Seattle and I think that one's still going. So I'll fix this. We have time for that due to poll to finish out so we don't need to worry about it. So I apologize for that little bit of confusion. Can you point me to the Seattle one because I think you're only saw the Shanghai one. Yeah, I'll do that after the call. I don't wanna, during the call, are there people talking? I'll try to find that. Okay, thanks. Yep, community time. This is a little time for people who don't normally join the call who are just part of the community in general. If they'd like to bring up a topic for discussion, we usually spend 10 minutes or so if there's a topic. Is there anybody on the call who, maybe not is a regular, who has a topic they'd like to bring up? Yes, I do. Okay. My name's Josh and I'm also from CHEG. All right. And what's your topic that you'd like to bring up? And we were recently, yeah, we're recently looking at the cloud event standard but we have a couple of issues with it regarding the camel case field maze and also the required nature of the event ID field. Okay. It sounds like those may actually be topics that might take more than, say, 10 minutes to discuss. Is this, or are these topics that you could open up issues for? So we can get some offline discussions and possibly deeper investigation into what you're concerned with. Yeah, for sure. Yeah, yeah, for sure. So how can I find where to have those topics? Or should I just send an email to the group? Okay. Well, do you- Yeah, you obviously could send emails to the group. But usually the best way is to go to the GitHub repo. I think it's github.com slash cloud events slash spec and just open up an issue there with your concerns and then you can get some offline discussions going and see where we land. Okay, sounds good. Excellent, thank you. All right. Any other community related topics if you want to bring up? Hi, my name is Luciano. I'm from Itaú in Brazil. It's a bank. We are discussing how to make an event driven architecture and last week we saw the standard and we didn't see any correlation ID between events. I don't know if it's already discussed or it's a topic for discussion. So this has come up in previous discussions. Is there someone on the call who would like to address this and talk about the current status of it? Like for example, maybe Kathy since that was a hot topic for you. Yeah, okay. So the question is about correlation ID, right? Yes, to correlate different events that were started by the same common event. Yeah, yeah, okay. Yeah, good. I think my PR will cover part of that. And then you can take a look at the workflow. I will put the workflow link in the meeting minutes. And you can take a look at that one, you know, to combine all those two together will help solve this problem. Ken, this is Rachel. Can I just ask what the problem is that you're saying like what your use case is so we can like, so we have a better sense of what you're trying to do? It's for me, Luciano. One example that we were discussing correlation ID, maybe I have a payroll of thousands of employees that I have to pay. I start just one event to pay all the employees but I have thousands of events in the account of each one. And in the future, I want to track that all the deposits was started by the same event that was the payroll event. Almost like a transaction ID kind of a thing that gets propagated across all the events as new ones are generated based on one original one. So maybe, I think maybe one way to, how about we have, you know, if you can present your use case in next meeting and then we can probably work on that. Or I can work with you on the use case and then we can see how that solved and then presented back to the team. Does that work? Yeah, I'll prepare something to show you. Okay, that would be good. Actually, I'm thinking because for this correlation ID, I think, you know, different, I feel some people is still not clear about what are the use cases, what is the problems. Probably it's good, you know, in the next meeting, you know, we present some use cases. I can present some use cases which people has put down in the workflows back. I can go through those or and then, you know, I think Lucino, you can also present your use case. So people has a better understanding of, you know, what problems we're trying to solve. And then, you know, we can start talking about the solution. Is that a better way? Yeah, I'd like the idea of gathering all the use cases that people want to address with this. I'm trying to figure out whether a Google doc or one issue that people add comments to would be a better way to go. You want to decide, Kathy, which way you'd like to go with that? Since I think this is a topic that you care a lot about. Yeah, I think, you know, so I'm going to put the link, that workflow link in this, in the meeting minutes. And then people can, in that workflows back, there are a section of use cases. People can go through those use cases, but I assume even, you know, even you go through that document, those use case section, you might still have some questions. So I think probably it's a, so then, you know, I can probably present, give me some time next meeting. I can quickly go through those use cases. Or if people have questions, we can, another way is, you know, people have questions. And then, you know, we can help answer the questions. Because those use cases are not just, it's not different people putting those use cases. So other people can also jump in to help answer questions. That's one way. Another way is I just present those use cases. So which way should we? Well, I think presenting the use cases would definitely be good. But I do think it would also be useful to allow a place for people to put their use cases down in advance of next week's phone call. And I'm trying to figure out whether that'd be best done as a Google doc or as an issue. I'm leading a little more towards an issue. That way it's saved within our repository for we can, so we can go back and reference it later. So Kathy, what do you think about opening an issue just to gather people's use cases around correlation? And so the spec already has a place for people to put in the use cases. They already, I think at least five or six use cases there. So why don't we, probably it's better just to put into that same place instead of we create another document for use cases? What do you think? Well, the use cases I'd document that we have is I think slightly different. I think that's a use case document for where we think cloud events will be used and how it could solve those particular problems. I think what we're doing here though is we're more of an information gathering stage where we're trying to figure out which use cases we want to support. And so I think it needs to be a little bit more free form. Okay. So if you want, so why don't I open the issue and then people can add their use cases to that issue and then we can figure out which ones we wanna support and then put those into the official use case document. Does that sound okay? That's fine. But I think those use cases document in the workflow are already people are already putting a lot of effort putting that use cases and also it's a discussed and agreed by that group of people which should be solved for related to the cloud events. So I think that part should also be, because that's already those use case have been discussed and should be included. I totally agree. Another one, you know. Another point is I'm not sure everyone is clear about what needs to be in sort of the envelope what we used to discuss or what should be in the payload because for some of those use cases the data could be in the payload not necessarily in the envelope. Yeah, I agree that I could use the payload for that but I think it could be a common field that a lot of events will need is the reason that maybe it should be a standard field. But it's not the role of the envelope. So every time we have new people coming to the call I think we're trying to clarify this again. Things that need to be outside of the payload of the message are things that are by observe the message. Like things that are routing and... Yarin, is it possible for you to get closer to the microphone? Yeah, it's very hard to hear. Sorry, I'm saying every time new people come to the call then we're trying to explain again what's the difference between the envelope and the message. And I think it needs to be clarified that things that are in the envelope need to serve things that observe the message. We don't try to put common fields in the envelope. I think getting that clear to be very, very good. I agree, Yarin. I agree with that. I also agree. I think it'd be useful even beyond sort of the workflow to have a repository of use cases where people can ask questions and people can respond to it. So I don't care whether it's an issue or a Google Doc but I think there's the use cases that we officially support and that we bring into the standard but I think from a community perspective I think it'd be very useful for people to be able to bring forth use cases that we can provide sort of the expertise of the group for and provide perspective on. Right. Okay, so I'm not sure what you, if you guys meant this or not but since this is a topic that seems to confuse a lot of folks could I ask for like some kind of, I don't know, like a, is there any document anywhere that explains this particular point? So I think we may have tried in the past. I think the primer does try to touch on this. I don't think it does a good enough job though. But I think that's the attempt is that we'll use the primer to help explain topics that don't necessarily go into the spec itself but help explain how to use the spec and some of the decisions we've made behind what the spec says. But we are running a little low on time here and I don't want to rattle too much on this because obviously this is gonna be a very important topic. So tell you what, why don't I take the X action item to create an issue to gather people's thoughts, requirements, use cases, very wanna call it, around correlation and see where that discussion leads us as part of that issue. What I'll also do is create another issue to make sure that we touch on this topic of envelope versus data, or slash body, whatever you wanna call it. Does that sound fair? That way we get some discussion going there? There is an issue for envelope versus payload data already. Oh, we do, okay. Yeah, there are not that many examples right now because the SDKs are still being worked on. As soon as the SDKs are in, I wouldn't say a better state, but more ready, people are gonna start building stuff, me included and more examples are gonna come out but right now it's still a bit early due to the lack of easy SDKs. Vlad, can you do me a favor, can you get the URL to the issue or get the issue number just to get into the notes here just so we have that? It's in chat, but I'll put it in the Google Doc too. Okay, thank you very much, yeah, I can't see the chat right now, but I appreciate that, thank you. Yeah, so Doug, I think the gentleman who spoke before you, I think raised a good point. I think we really need to have a document that explains very well what are the issues. So people are on the same page, otherwise I think this topic is going to be dragged on in a long time. So I can volunteer to write up something on that so to see whether you know people and then people can add more input or comments on that. I really would like to help with this use case because we have such use cases to solve too. So I think it's better we bring everyone on the same page on the issues we try to solve. Okay, yeah, that sounds wonderful. Thank you, Cathy for volunteering. But let me ask you a question just for clarity in my own mind. Are you talking about adding text that talks about correlation or are you talking about text that tries to clarify envelope versus payload? No, no, it's not envelope versus payload. That's a super issue. I'm talking about correlation that why we need it. It's not, okay. I think I'm not going to talk about the solution. I'm going to just talk about the problems. Basically we need to correlate multiple events. So there are use-service use cases that involves multiple events and then there are issues there we need to solve in order to support those use cases. So that's what I would like to talk about. Okay, that's fine. Okay, I give you an action item to write us a text around that. Thank you very much for volunteering. Hi, this is Jam. I have a question. I'm not sure if it's a process question or just a group question. When we look at propagating other contexts around, so I was looking at, for instance, open tracing which seemed to be something that we could propagate that context through the extensions in the context. Where do you see those sort of specs or guides living? Would you see that as an open tracing best practice or as a cloud events best practice? So I'm going to try to let someone else speak on this because I don't want to dominate the call. So let me pick on someone like Clemens. Clemens, do you want to take that one? I have not paid attention for the last 15 seconds but I did pay attention before that, I swear. So what was that? Okay, so when we look at something like open tracing which has defined mechanisms for propagating tracing contexts across either different transports, VR, HTTP and messaging and whatever, it would seem that you could map those similar constructs into the extensions in the context of a cloud event and then unify that. So the question then becomes, is that an open tracing piece of work or is that a cloud events piece of work? So the way I think about that is that it's effectively a, so on which side of the fence that lands, I'm not sure because it really depends like with every project in who's quicker to say yes or no. But from a general approach, I would say yes. If you have open tracing and you need to have a particular metadata that has particular types and has particular names you want to harmonize that across multiple transports then the right way to do this is to define how you project that into various transports or envelopes as you would do this with any prior art. So for instance, if you were slotting if I may use that old terminology for a second if you were adding an open tracing metadata island to soap what you would do is you would probably have some XML island, some XML that's defined in open tracing you would basically slot that into a soap outer as is. And I looked at this here in a very similar way is that you define the extension and put that into the extension catalog probably external or here and that probably also depends on the character of the project and whether we would take that here into our repo, like if it's open runs on the umbrella of the foundation, et cetera and then define it as an extension and you would use those things as is. So for correlation more broadly because that's a correlation item for correlation more broadly, if let's say there is the and I'm just making one up right now kind of the open home automation alliance, right? And they say we need to have a standard for defining where devices hang in a home and there's a notion of a room geometry and there's a notion of a floor and there's a notion of a unit and there's a notion of a building per se and that's all correlation data then that would also probably go into an extension that then everybody who's building systems that have to do with a home automation standard uses but they're only applicable to that subset of consumers and publishers and they don't affect the standard per se. Like everybody who's using cloud events must be using then that home automation standard but everybody who's using that home automation standard will use that extension to lay it on top of cloud events. That's how I look at it. So same, so that open tracing everything else like all of those various different of metadata extensions for all of those I see the same model. Done. So I, go ahead, sorry. Just as an FYI, this doesn't need to be necessarily a hypothetical discussion. So we wanted open tracing to work. We did some research from what I could tell it seems like open tracing over HTTP is based on the distributed tracing and that's why there's a distributed tracing extension. My attitude was A, like this back wasn't 0.1 yet and we are the smaller body and the WC3 back is stable. There was very little risk in just adding it to the documented extensions. Okay, and with that I think we're gonna have to call time because it's supposed to be bounded by 10 minutes. I think we've gone a little bit over. However, that's not to indicate that the topics that are brought up here aren't worthy of further discussion. What I would ask though is please don't hesitate to open up issues in our repo for some of these topics. That way we can get some offline discussions going and we don't have to limit ourselves to these 10 minute time slots for some of these things. Because some of these things are rather important that we get settled. And I think we're trying to discuss those two issues and do the best way forward on those. So thank you guys very much but we do need to kind of look forward. So I don't think there's any update on the SDK or on the workflows work group. So let's go ahead and jump right into the PRs. So on the extension PR that we've been discussing, I had the last time I checked, the last vote was like almost an hour or so ago, let me just double check here, see if there's anything new. No, okay, Mark was last on the vote. Okay, so it's out of, hold on a minute, my zoom will not get out of the way. Okay, so the vote finished and last time I checked, it was 10 to one in favor of the PR. So the PR has been approved and I will update a comment to the PR or I'm sorry, I will add a comment to the PR giving the results of the vote status in there. But it has been approved. I'm sorry, go ahead. Did I put Kathy votes vote against it? No, she changed her vote, she edited her comment. Yep, I did go back through and make sure that that was the only one that was edited unless I messed up. So thank you for bringing that up though. Yeah, I would like to clarify, I changed my vote and then later I think Doug will work with me together putting a new PR to clarify those points, you have to add those points, which means we allow partner bags with this type clearly defined but with this content open for open. I got this, thanks. Okay, thank you. All right, so that one's behind us. Next round list, I'm hoping this is an easy one. I'm drawing a blank Austin, sorry. He added a whole bunch of new logo artwork. Hopefully everybody's had a chance to look at that. It's been out there for, I guess, what it's seven days now a week. Scott, is there anything you want us to do with this one little comment? I just pointed out, like when I see that logo, I think of this symbol that's on almost every consumer electronic. They're advertising us, what can we say? Is this something other people are concerned about? To be honest, I don't think Clemens change to the logo is really significant in the sense that it's always look kind of the same. I think it just changed some spacing. Do you mean Austin? I'm sorry, Austin, geez, what did I say? Yeah, it's Austin. I don't think his change was huge. So I don't think any similarity or not to this CE that's on all electronic devices is a nuisance. Did we move away from the logo with a little cloud? No, here, let me see if I can show it on here. It's still a cloud, but I think we just added some spacing to, let me see, like five one. Did we just add some spacing? See if you still added a little cloud here. I think you just added some extra spacing, like between the C and the E, I think. Oh, I see. Like I said, it wasn't a huge change. It was just, I think it's tried to make it a little bit, makes the C and the E stand out a little more from each other, I think, if I remember correctly. And there's a break now between the cloud and the E tail. Ah, is that new? I see. I didn't realize that. So, I don't know, to me, they're relatively minor changes. Yeah, I don't know that the CE is, in the context of the cloud, it's not as, it doesn't read consumer, yeah. Okay, so is there any objection then to adopting this PR and the new logos? All right, done. Oops. So, I believe Dan Barker's gonna go ahead and make the changes to our website to pick up the new logos. I will start the process of getting the stickers updated with the new logos and then I do have a coupon code and I'll order some stickers and I believe we should probably get them in time for KubeCon, Shanghai, or at least Seattle, I would assume, so I'll work on that in the background. All right, moving forward. We have two PRs that were opened for additional transport bindings. If I remember correctly, there was a general sense on both of these that they may not have met the new bar relative to acceptance of new transports and bindings, but people were given another week, in fact, it's not been two weeks, to look these over. Has anybody changed their opinion? Is there any reason for us to accept either of those transport bindings? I wanna point out that Sarah proposed a change to what our standard is, and so maybe we should hold off on these until we decide on that. Oh, when did she propose that? Did I miss it? When did that fly through? I missed it. So I submitted it early yesterday and there was like, or sometime yesterday. It was just kind of in response to the whole discussion on that thread and we read the qualifying topics and I don't think it's being, it didn't feel like it was reflect, the wording was reflective of the conversation, right? We had this conversation many weeks ago and we were like, it's hard to describe de facto. And so now that we're looking at it through the lens of another test case, I was like, well, I'm not sure that de facto was, like, needs to be as narrow as it's literally interpreted if you read that paragraph. Okay, I apologize, I missed your, was it a note or an issue that you opened up? I did a PR, yeah. I did a PR, okay, I apologize then for missing it. I was traveling all day yesterday, so I missed that. So tell you what, Rachel, I think you're right then. Why don't we hold off on this decision of these two since we're headed towards closing them, it doesn't no harm to keep it open another week or so. So we can look at your PR, Sarah, that you just opened up and we'll discuss that next week to see if we want to change something. If I haven't looked at it, do you offer some alternative texts as part of your PR? Yeah, it's a very minor change. Okay. People can look at it, chime in and we can discuss it next week. Okay, excellent, thank you. Okay, so we'll defer these two then until next week. Thank you. Next, Kristoff, would you like to talk to this PR? I think it's pretty much ready to go Yes. So what it is, or the issue is that if you put too much stuff into extension, then into extensions that we may run the technical stuff, like for example, the HTTP transport, we'll put this in the headers and most HTTP servers will at some point reject requests if the header data gets to large. So I actually did an issue where I described like for a couple of things, like NGNX for example, as a limit of eight kilobytes, like the API gateway has 10 kilobytes and so on. So yeah, so this is like sort of just guidance saying you shouldn't put too much extensions into your cloud event because if that happens to be transported, for example, over HTTP, then you have so much header data that your request will be rejected. And I think this doesn't only apply to HTTP, it will also apply to other transport bindings, but this is just used as an example. All right, and I think this came up on a previous phone call and I think Sarah, you might have offered some slight wording tweaks which I believe are in there now. Yes. So what do people think about this? This is strictly for the primer, so it is not an orative text. Are there any concerns with this text going into the primer? Okay, it may make it official. Is there any objection then to adopting this PR? All right, excellent. Thank you very much, Christophe, I appreciate that. Okay, on a previous call, it may have been two weeks ago, I'm not herbicensure. When we're talking about a possible face-to-face meeting, actually, I think it might have been for the OSS summit this week. It was brought up, I think Clemens may have mentioned it, that we may have overlooked the fact that our governance doc doesn't talk about face-to-face meetings have to be announced with a certain time period in advance to give people a chance to get travel approval instead of travel plans, stuff like that. So I took the action item to create a PR to say that we have to do it at least four weeks in advance to give people plenty of warning. So here's my PR to add that to the governance doc. Hopefully it's fairly straightforward. Just as face-to-face meetings will be announced four weeks in advance. Are there any concerns with this? Any objections then to adopting it? All right, cool, thank you very much. All right, Kathy, we're on to your identity labels PR. Hold on a minute, let me bring it up. Would you like to talk about the current status of this one, Kathy? Okay, so this is a attribute that we saw, we saw the format of key value format and the key will be a string and the value will be a string. And this is a place to that people that the event producer can put identity labels inside it and then the event consumer can use that for example, for correlation purpose. Like I present some use cases before like for a travel request service application and that identity label could be the travel request ID or the employee ID. And then the consumer can use that to correlate that event could correlate a travel request event with a travel approval event. And there are many such use cases like I present another use cases which is a burglary detection system that could be a motion detection event and the window open event. And then people can use the identity label of these two events to correlate them to the same service application instance. So this is for that purpose. Let me see here. Yeah, basically that's about it. I think this correlation issue has been brought up multiple times in previous meetings. In order to support those use cases, I would like the cloud, I think we need the cloud events to have a place for the event producer to put in this information. And this is an optional field. If the event producer doesn't have any identity labels, then there's no need to have this field. And also from the event consumers point of view, if it doesn't need this information, it can just ignore the whole this bag. Doesn't need to go into this bag to decode every label. Yeah, that's about it. Okay, thank you Kathy. Is there somebody who'd like to bring up discussion point on this one? I'll just point out that it seems like there's some comments on the PR that I'm not sure are addressed. Yeah, I agree. Normally I wouldn't have actually put this one on the agenda but I know it's a very hot topic and I don't think there's anything huge after this. That's why I kind of moved it to the end, but yes. Kathy, do you want to talk about your responses now or should we wait to see it in the PR? I think I already replied. I think I'm saying they are not in the top level. Okay, so I think this is a very important, it's very important for the cloud events to include this information at the top level of the spec because there are a lot of use cases that need this, a lot of IoT use cases and even enterprise use cases. I think that there's a lot of use cases that you are going to use this for but I don't think that there's that many use cases that the community at large will use. So consider what the population would do with this, not just what you would do with this. Okay, because like in today's meeting I see that the Lucino also burned up use cases and in a workflow discussion, people from other companies also bring up the use cases. But yeah, just want to give some comments. I think there are some other use cases. Let me give you a very simple example. I say AWS, a user can upload images into S3 bucket. So let's say there are three buckets and when a user uploaded an image into one of the buckets, one service function is triggered. So the event source of this event is S3 bucket, the event type is objects created and also each event has an event ID. So for most of the cases, these information might possibly be good enough for the service function. But for some other cases, the service function might need to know who uploaded the image to bucket one or bucket two or bucket three and possibly need some other extra information about some sort of identification context of the event. So I think this is one possible use cases. I believe there are some other use cases. I think this is one thing I want to comment. The other thing is that this attribute, well, I think it doesn't matter, you call this attribute a bag or not. To me, this attribute is defined to be a map of map of key value pair. And the value of the key is also a string or is defined by Cassie. So it doesn't really matter is a map attribute or a string attribute. We can also make it a string attribute if we want by making it a string of comma separated key value pair. In that case, these identity attribute is just very similar to other attribute defined in this aspect. Another thing I want to say that the identity context for each event is very different from other events. So some events can have just a zero identity context but some others may have 10 or some others may have more context. So the information related to the identification is quite different. So it's kind of dynamic. It's kind of harder to put such kind of information into the top level. So I think it's a good idea to put all identity related information into these attributes. So this is just my thought. I'm just a new to this group. Maybe I'm catching up with you. So if anything wrong, please correct me. Okay. Well, thank you very much. We have some people raised in their hands. I don't know who was first, but Vlad, go ahead and go first. Now, Nichols was first. He was first in the JET. Yeah, Scott already spoke, I think. Actually, let me ask you. Scott, did you say what you wanted to say already? So my main point about this is I think that identity labeling is one use case and the general case of labeling events is actually interesting. And so my suggestion is that we not use a map, use a list of labels and you can optionally give a label a type and that type could be identity. So it's a little more generic. It's a little more extendable and it applies to every use case that applies to allowing an event to be labeled, not just identity. So if you allow this to be added to the top level and then you also want to label events in the future, now you have two places where generic labels get applied to your event. And why try to get this one thing to be that specific case? That was my point. Is this the comment related to that? No, there's a hidden comment somewhere. Yeah, I thought I saw something go by the mentioned type. I can't seem to find it. So yeah, it's probably hidden now, darn it. Okay, thank you, Scott. Vlad, go ahead, go next. Yeah, so there were two topics discussed. First of all, Cate's labels and then identity in AWS, which might be cognitive identity or actually key secret key or whatever. Do these really have to be part of the envelope and other payload? I brought up this issue in the GitHub issue for event versus payload too. There are limits on what we can put as payload and I'm not sure that this is the best place to be for them, but then again, this would be heavily impacted by the security discussion, especially the signing and encryption part. But do they really have to be part of the envelope? I think the question for Cathy. I didn't quite get that, get your question. So the reason we put a bag here is because if we do not have this bag, there will be a lot of information. As we know, the fact is that a lot of information, I mean, for different events, the identity could be different, right? For example, like I said, for travel request event, the identity will be like the travel request ID. For long application event, it will be a long application ID, right? For motion detection event, the label could be the house address. So if we do not have a bag, there will be a proliferation of a lot of labels. So I think it's better we have a bag. Of course, for each specific event, I don't expect the identity labels to be a lot because for each specific event, the event producer will just put whatever it's the identity, a few identity labels in it. So I think, and also this is good for a consumer point of view. If the consumer does not need it, the consumer can just pass this bag name and they ignore it. That's it. Do not need to go into, to pass every label. And also good for debugging purpose. So this is why I think it's better to do this way. And also we define the type, because sometimes if we leave the type open, I think some transport probably will have problem. So that's why we define what is a content type. It will be a key value of string. It's a key to be a string and the value is also of string format because it's a label. So there's no point to be an integer for the value. Okay, so I apologize I get this name wrong, but Tapini, I think you had your hand up. Did you wanna say something? Yeah, it was sort of addressed by Vlad, but it related to the fact that since, since the relation between the payload and the envelope is being discussed already, this seems to go, if this is accepted now as identification label, this seems to fall between a specifically, a specific envelope variable that can always be used because they are, they still have this free from definition between producers. And it seems that it should belong in the payload, but on the other hand, it's useful outside the payload when you want to drop events or something. And I think it should be clarified what the, how this relates to that discussion. Since it's, it's doesn't seem that the purpose is very clear in that regard. Okay, anybody else have a comment if I can bring up at this time? I would prefer it to be a part of the envelope rather than payload purely from a, purely from a troubleshooting standpoint. Yeah. That applies to a lot of things that say, that applies to a lot of things. And this is a highly specific field name, identity labels. That's what I'm talking about how it's not, doesn't seem to be scoped very well. I think actually, I think if we make it too broad, if we say, okay, we take the identity out, then there will be, then the producer can put just random information inside it. I hear other comments say, yeah, the producer put random information inside it. So that's why I think it's better to scope it to be identity. Otherwise, it's going to be a blow, unless it's a bloated. And also I want to suggest the point that, it's good to put into the envelope because if we put into the payload, right? It's not easy to pass. So if it's encrypted, it's hard. So I don't think anybody has their handups. Let me ask a question, because it doesn't seem like it's very clear to me that everybody is on the same page relative to the purpose behind this new bag that Kathy's looking to add. So for example, Kathy, I know you talk about it as being for identity purposes, but to me, the word identity isn't very precise. It can be most different things in different people. And then when I take a look at what Scott, and thank you, Scott for the link, what Scott posed here as an alternative, this seems like a very sort of generic value pair kind of tagging mechanism, right? And it's not necessarily specific to identity per se. It's any label that you want to add to there. And I'm not saying which one is necessarily right or wrong, but it just seems to me we don't necessarily have agreement on what the purpose is behind what we're trying to solve here. Is it just, we want to have a mechanism to be able to add additional properties for some purpose in general, or is it only for one very slice, thin slice of semantic meaning behind it? And if it's that very thin slice, I'm not sure that the word identity means enough to me to understand very clearly what would go in that bag versus not, because when I see it as currently defined, I would sit there and wonder, why isn't event ID part of this identity bag? Because obviously event ID is the identification of the event as a unique identifier. So why is that not in there? And so those are the things that I'm trying to understand in my head is, what is that the power trying to solve? Sorry, this is kind of what I was trying to say. It seems very counterintuitive how it is a place for identity information, but at the same time, the syntax and semantics for each label is open to interpretation. It seems like there's a random semantic applied to that field or that bag that isn't actually enforced or defined very well. Right, and that's part of a concern that I've had in the past, which is this feels like a generic bag for almost anything, even though it's called identification or identity, it's gonna get used for just about anything because it's so loosely defined, which means we're adding yet another accessibility point and people aren't gonna be clear where to add things. Everything else except the name identity label feels like it should be named routing labels or something similar where it's useful. The label is useful in routing and that's why it's in the envelope. So I think I'm hearing two different perspective on this one saying, you know, this identity label is too restrictive. Another is saying, you know, it's too broad because you say, you know, I think Dr. O'Pointe is, you know, identity, you know, it's, I need, people can put anything inside it, but I see, but I hear, I heard another comment before saying, you know, identity, just you call it label because identity too restrictive. Yes, you're hearing multiple things, yes, they're kind of- Yeah, so I'm just thinking, you know. But I think the point is the coping. I think here I want to address one of your point with the event ID because for you, you have event ID, right? You know, from an event source, it gave an event ID. That event ID has, you know, has nothing to do. So for the use case that the travel request, you're gonna have an event ID. But then how we correlate this travel request event to the travel approval event. Those two IDs has nothing, you know, they do not have any, you know, relationship. So that's why we, you know, if the event producer can put like, you know, a travel, specific travel request ID or the travel applications, you know, employee ID, something like that, that will help doing the correlation. So that's why, you know, event ID is not enough. So this is a place for the producer to put additional identification information on which, you know, thinking, you know, it has that. Okay, so we're running a little long time here and I want to come up with a suggestion for how to move forward here. But let me talk to some, let me get some people who have their hands up first. So Ryan, your hand was up first, I believe. Yeah, just want to clarify. Did we solve that correlation PR or if it sounds very similar to that PR, I thought that PR was not even addressed yet. I think that PR morphed into this one. Oh, okay. Yeah, if I remember correctly. Continuation of that discussion sounds like. Yes, I believe so. Sounds very familiar to me. Yes, I think that one morphed into this one eventually. Yes. Okay, I see. And Thomas, I believe you're next. Yeah, I just wanted to respond. There was a suggestion to change it to routing labels. I actually prefer Kathy's approach of labeling, of naming something based on what it is, not how you expect it to be used. I think that it shouldn't look weird in a system if we find any use for a property. For example, I could use this for filtering as well. Okay, cool. And I know, since your hand is up and I believe Eric, Eric send your hand one up first. Yeah, I just wanted to call out something I had put into the text is that I offered one property that was follows from, which perhaps captures a lot of what I think this is after, which I believe is the causal relationship between events. If the group would like, I can reopen that for discussion or rejection, whichever. Maybe you can add a pointer to that and it's part of this PR, so we can look at it. Okay, I'll add a pointer to it as a comment. Absolutely, we'll do it. Excellent, thank you very much. And Shenzhen? Yeah, at least actually the same to me is to identify some specific event among some same time, from the same event sources. So this is what I just want to clarify. Okay, thank you. And with that, I think we're almost out of time. So Kathy, I'm trying to figure out the best way to move forward here. I see two potential paths. One is to set up an offline meeting to have people who are interested in this topic discuss it. But I know sometimes those meetings aren't as productive as they could be because of limited attendance. The other option is to just bring this up on next week's phone call to continue the discussion as long as you don't have anything else pressing to work on it. How would you like to proceed on this, Kathy? Because I feel like there's a lot of uncertainty here about exactly what we're trying to do and I'm trying to figure out how to get some more clarity first. So how would you like to proceed on this one? I think probably in the next meeting after we present those use cases, so people can also think about that. And then if this identity is not... This is a name I can come up with. If people think this identity, whatever name, is not good, people can suggest another name. But I think for labels, I think it's a little bit too broad. That's my take. But if someone can come up with a better name, I would appreciate that. So let me ask you this, because you just now mentioned the use case stuff for correlation. And we did talk about talking about the correlation requirements on next week's phone call. I'm assuming that that discussion is very much related to this one. Is that correct? Yes, that's very much related to this one. That's right, yeah. Okay, so maybe it would make sense then for us to have that discussion next week and see where people land relative to how they wanna deal with correlation and then figure out the next steps on this PR since they're probably gonna be discussed at the same time anyway. Okay, yeah. Okay. I think we can actually improve the extension of the mission called correlation labels. But then there's some people saying that's not good, so I don't know what's a better name. Yeah, okay. So let's see how the conversation goes next week after we have the correlation discussion and see where maybe something will pop up and someone will have a brilliant idea on how to move forward on here. Obviously this is a very touchy subject or a complicated one I should say. Okay, with that we have three minutes left and I'm not sure we have a whole lot of time to do anything meaty. So let's, excuse me, let's just go back and finish the attendee list and then we'll call it a day with the whole two extra minutes. Let's see where to leave off. Klaus, are you there? Yes, I'm you. Excellent. Are you still there? William? Yes, I'm here. Excellent, thank you. Tapini, I got you. David Lyle, are you there? Yes, I'm here. Excellent, Erica Diaz. Yeah, I'm here. Okay, got you. Doug, Doug, I can never pronounce your last name, I apologize. I don't see him still on, so I missed him again this time. Okay, William, we already have. Luciano, I believe we heard you. Yeah, I'm here. Is there anybody on the call that I did not add to the agenda? Hey, Doug, it's Dan Barker. Dan Barker, okay. Actually, I'm sorry, Doug McGlory, oh, I apologize. McGlory, are you there, Doug McGlory? Okay, I guess he's not able to speak. Okay, is there anybody else that I missed? He wrote in chat. I'm sorry, who's that? Doug McGlory wrote in chat that he's here. Oh, he did, okay, excellent. Thank you, I missed that. I can't see the chat. Doug, it's Yaron, I'm not sure you missed it. I definitely got you, Yaron. Thank you, I forgot to mention that, thank you. All right, anybody else on the call that I missed? You and I have gotten me. I'm Josh Richardson from CHEG. Richardson, got it. Got it, okay, thank you. Anybody else? Excellent, thank you guys very much and we'll talk again next week.