 All right, there we go. Three past the hour. Why don't we go and get started? So today it was suggested that we focus heavily on extensions. It's such an important topic. So we're going to skip all the usual administration via and jump right into it. Now in the effort or in effort to try to have me as sort of moderator the phone calls to try to not influence people Suggested that maybe someone else could drive the discussion in terms of the proposal that's out there for extensions and Dan gladly Volunteer to do that So Dan Do you want me to share or do you like to share the screen? Could you share the screen? I'll just make the recording easier. Okay. Sure. So I assume you want to jump to this right here, right? I do yes Okay, go right. Thank you very much so I'm temporarily wearing the Clemens hat here and Trying to address some of this with the conversation that I've been lurking on for the last five weeks I think about this topic Which is really sort of how do we see? Extensions working and what are the kind of the pros and cons of that and I think this slide does a good Job kind of summing up the sort of ways that we could structure extensions and the ways that they would look Within our spec itself and highlight some of the pros and cons of each approach. I think the first bullet is self-explanatory It's that semantically there's no difference on the two locations so That where where this extension where this piece of data is specified in this case A bag with extensions and then common example extension and some value or just at the root with some label and some value semantically there's really no Meaning defined by either of those locations but then The next thing that kind of drives that is that all the data that's in whatever these These extensions are should be available to consuming apps regardless of whether we're using raw Which would be kind of on the left or structured HTTP? The the interesting things to look at or in this context are what these look like if we map these to HTTP headers And in this case HTTP is just an example It's not saying that's the only thing we're going to do but it's not a bad example in this case because it brings up some interesting points The first is that what these look like when they're kind of flattened out is that that extension? Piece kind of takes on like a dash sort of name So in this case see dash extensions dash Whatever that extensions name was and this kind of leans towards the what was done with With HTTP with the x-dash extensions that have long since been abandoned And that wasn't necessarily a successful foray Down that sort of extension path Concept so it's something we kind of want to be cognizant of and As we look at these examples, especially the one on the right What kind of stands out to me is if our intent with extensions is to kind of open up a way in the future where we're Going to start to figure out more of what is necessary within our specification over time Some things might graduate from being extensions themselves into being part of our spec And this makes a concrete example of what that would look like is if some label was just some some some extension I was using in my service or application or whatever And then it become we decide maybe it's something location based maybe it's something else We decided something important enough for events to actually go in our specification Then we introduced it in something like 1.1 or some later version of the spec You would actually be breaking code when you deploy that if it was Mapped in the first way so if it's something that's gone from Extensions in a path underneath that to something that now is part of our spec like as we roll that out Which is not going to be a clean cut for any of us We're really going to kind of run into some some issues about versioning and part of my concern with that is that if Version 1.1 of our spec added that some label whatever this extension happens to be there would be no code changes So It would just work like if we at all if people if half the industry had started using this same Sort of extension piece the same spec the same we're the same label Then all of our code would just continue working even when we when we rev the spec Otherwise we would have a breaking change because now c e dash extensions dash com example extension Would no longer be the name, you know, it would just be c e dash com example extension So that that kind of concerns me quite a bit. I think this is a fairly concrete case of it But I think this kind of leads to a broader Discussion of of what exactly we want to set as our goals Both for the spec and for kind of our future of this My my goals frankly are really to kind of Have us have as simple of a specification as possible and wait until there's really well defined sort of acute need To start adding more to it. Um, it's it's very tempting to Kind of build in unlimited extensibility at first without uh Without you know, feeling the pain of walking that back down and i'm i'm just Concerned that if we do something like the the the com example in this That it's going to be more complicated for tooling. It's going to be more complicated for Portable for versioning and that we're going to get a kind of drift into a place where We go from this what we have now is actually a very simple very kind of pure sort of thing And I know it can't stay that simple forever But um, i'm a little nervous about us trying to plan for stuff without concrete needs that In some ways kind of don't uh Don't express themselves yet in this drift. So I think uh to a little bit of a bigger sort of conversation about uh Which is kind of mentioned on the next slide about Uh how extensions Really need to work at all um And this part is what I'd kind of like to discuss a little bit more here today. I think a few of us Uh in this group and I myself being one of them have kind of uh, and I was probably the last one to make this Journey um have kind of moved this idea that having uh classifications and bags Uh which could be causing more trouble than it's worth You really have to think about what goes into which bag and if we're doing this we're kind of You know, we're really kind of planning for a future that we're kind of uncertain of I think a good example here is that You know the semantics of an attribute are defined by the spec not its location in the serialization Whereas when we have a version for our spec which we do We already know what's in the spec and then we can tell that anything that's not in that spec is is an extension Like that's already You know done and dusted and it's easy to do that with the with the spec we have in draft today uh The next would be that really the producer is what knows what those attributes mean Uh, it it doesn't know how the consumers will use them. It just knows where to put those so um Here's where the classification and bag thing gets complicated is does the producer need to know what the consumer is going to be using these for and does it need to decide if it's going to put uh values in an identification versus a correlation versus a logging or debugging bag and if a value is going to go into Multiple of these does it need to put them in multiple? And then that kind of raises a bigger problem of if it puts it into multiple What happens as those things change over time or because of bugs fall out of Out of sync, you know, and we kind of don't have a single source of source of truth anymore So I think the proposal here is to just say No classification Or bags at all that all extensions are serialized in the same way And that that kind of just it's it's a simple model. It's not perfect, but at least it It kind of puns on you know us kind of having a Make commitments right now that we don't know where they're going to lead in the future Okay, anything else or should we open it for questions? I think it's discussion time. Well, I have my first coffee. Sorry All right, any questions comments So I have a question here. I think here we are Suggesting, you know, like to so are we talking about serialization? I will talk about, you know on the format of Any attributes? So I think we need to separate these two Serialization, right will apply. We have one way to serialize it It doesn't matter what kind format the attribute it is So that's serialization and for the attribute itself looks like for Extension we there are only two options either we put everything in the extension Back or we put everything at top level and of course there's a third option Which is you know, we classify the different Different things into different classification backs, right? So it's I think there are three options um I can understand, you know, if we put everything into extension and you say if later if that That um its attribute is promoted to be in the spec then there's a Then, you know, we take it out. There's a backward compatibility issue. Um, so it looks like Put into I think the inclination is put into everything into one big bag Has that issue, right? But I'm thinking, you know, for the I would like to open up for discussion whether We it's good to have, you know on different classification Bags I think, you know for that for the issue looks like, you know, if we have multiple classification backs You are concerned that people is going to put the same information in different bags But I'm thinking, you know, it should be only in one bag if those Classification are defined well, then, you know, the event producer will know um Where to put that It has nothing to do how the event consumer use it. They are two separate entities We should not mix them together But how to do the classification I think should be from the event producer's point of view, you know What kind of information on To put into each bag I think, you know, um put everything At top level There will be there going to be a lot, right thousands of different informations So it doesn't seem to be very good. Put everything under one big bag It's going to be like also thousands of under that one bag And also I think you already pointed out there's an issue with Backward compatibility But if we put something into the different classification back, there will be no backward compatibility issue because, you know, even you promote it it's still going to be in that classification attribute So you would say that it doesn't get promoted into a standard part of our spec and now the Now the bag the classification needs to have a specification for what fields are part of the spec in that classification versus which aren't So i'm saying, you know, for example, if we have like a Bag called a system information, right? No matter whether it's an extension spec or is in the Man spec It's all system information. There's no need to you know, remove any tag or add any tag. It's the same thing Well, but I mean But if we promote If we have something in a classification and we promote it Does that mean that now that classification needs a spec of what is part needs a list of what is part of the Specification that goes in that classification and you then can you not put things in there that aren't part of the specification or what like Because the thing with the classifications that I think we can do is that you can define your own bag You can define your own extension and make it a bag if you want It's just that that's not really part of the spec. You're free to do it though And you're free to put limits on it. So how big it can be how many records it can have and how the semantics of it work Whereas like the thing that's kind of concerning me And I mean being like a lifetime messaging person I come from a background where the publisher probably knew more about the message than Than what we see nowadays and like in cloud messaging um from like an mq and and tibco background, but I've kind of come to see a little bit differently that in when you look at eventing It's more it's more subscriber driven generally than publisher driven So I don't know if the publishers really going to know about all the classifications and be able to respect them So the producer knows the event the best, right? So the producer should know how to classify them But it doesn't But the producer and consumer might not agree on what the classification means It's okay if the producer put the information into The a producer knows the event the best So I put the class if you can put some info put whatever information into that classification category, right? How the event consumer use it the event consumer has to look into those information to see which information, you know, he cares Or she cares and then which doesn't care if it doesn't care He just ignore the whole bag if you know if those information are what the consumer cares Then the consumer is going to decode. I mean to decode that bag Also, I mean Same thing can be accomplished though with the With your own bag with your own root level extension Because the consumer has to know what they're looking for and and I think it's easier to just say Anything that when you look at the cloud events version anything that's not in the spec we know is an extension So it then it's easy to say if I really only care about the spec Then anything that doesn't match what's in the spec. I don't need to look at or if I really care about something called some field I I know that it's there because I don't see what the classification buys us other than More categorization and complexity and considering how long it To agree on what we have already. I'm not sure if we're going to be able to agree on what these classifications are So it seems like this is the best of both worlds, right because anyone could make their own bag Um, if they if they wanted to go that route we want people to do that Yeah, but we want them and and if it's a successful bag we can promote it in the future and we can say hey This type of bag Turned out to be really successful. So this should actually become part of our spec And that's where things that you know might be vertical specific Uh could actually kind of happen And graduate into our spec that I think would be a good idea rather than putting out a prescriptive Hey, we're going to make these classifications and you have to fit into these classifications It's just I don't You all and clements are all a lot smarter than I am but I don't trust my own ability to see the future enough to know Uh What those classifications need to be but once we put them in the spec we're stuck with them Yeah, the market the market will tell us As long as we create an opportunity for the market to start creating these these classifications or these bags Um, and I think the best way to do that is going to be to put it at the at the top level Um, we'll we'll get a lot of great data from that. We'll probably be able to make more informed decisions Yeah, I agree. I think we should allow you know bags at the top level. Um Because you'll never know right why should we put some restrictions say, you know, either everything, you know, um No bags are allowed. I think we should allow bags and also, um from also as an event producer So if I see some bags, I see oh, okay That's that's where I should put my information rather than I just put into one big, you know, um extension bag Or just put one top level I would rather see the, you know, there's a need, you know for that Classification than I put there. I think it's more clear. It doesn't hurt I think it's better Also, yeah, I would like to say there are other particles out there standard particles that have bags, for example, there's a there's I think it's I forgot which one. Okay. Um, but it has an application Pop this bag. That's a standard Particle and that meant there's several many others So why should in here we should restrict it say no bags Can I can I clarify something seems like I'm not I'm not sure if I hear the proposal clearly my understanding from the discussion is We would just not allow Not allow not put any First-class bags for now, but allow users to uh Create their own customized bags on the top level and in the future if some bags are really popular We're going to promote it and the promote will basically be seamless because it's still basically the same place We just make it official. Is that the proposal? All right, I tried to make that a little more clear. Yeah, so no no classification You can expect itself, but extensions could out of bag. Does that clarify it? Yeah, I believe that the discussion was let the market decide and I My understanding is at least reading the comments that there are a lot of folks who would like a top level extension bag at least for identification or something Now do they want it as a top level extension bag or they just want the ability to have some sort of bag And it looks like a lot of folks who seem to prefer that idea and I guess I'm one of those in that camp also So maybe we can hear from some folks who have Can articulate the reasons for that so so for My experience like we came to this same problem Kedda So what we did is we decided to let anybody add top level attributes and When they wanted to but we had strict policies and rules about handling of that data downstream And we also provide two extension mechanism product tagging mechanism for simple classification tags As well as what you call just general extension bags if you will Which could have your eyes identified them And but we had rules about if you place things at certain places Things could be stripped because we had the problem of people would want to add log data or big amounts of data And for serverless, that's not a great thing So you want to you do need top level data and the market should decide absolutely But you need to have strict policies about handling and sizes of data and things like that Yeah, I think you know if we would like to define some Some classification back in the men's back. I think definitely we should have rules, you know, how to handle that I agree So so my my main point my main point is that I think of cloud events as Defining the the routing and some level of classification of the events and I worry that the Consumers or people that people that are using it will start putting more data into the headers Into the cloud event as opposed to the data of the event itself And we need to we need to provide guidance there to ensure that that People put all of the event data down in data and not into all of these headers I think that the default needs to be that event data goes in data You're free to to crack the data, especially if you're a consumer, you know what it is But I think you've hit the nail on the head, which is that what we we need to stress the kind of the routing aspect and the kind of minimalist aspect To to make sure that we don't get into a place where we're talking about soap No, no offense to anyone on the call. I'm sorry. I didn't think before I said that comment In my opinion, I again, I think that We just get this out in a way that's flexible right now so that users can teach us about how to use this thing And I do like the proposal here about just Enabling people to put things at the top level. It could be a their own bag It could be it could be anything And we could see what people are doing And heck if they're putting too much if they're putting data in those headers that we think should be in The event I think we should observe that and then and then move to solve the problem But as of right now, I I I guess my biggest concern is just moving forward and getting this out to the market And kind of being open to receive that data and open for users to teach us about this stuff I think this is a good proposal to help us move forward So is there a reason that we can't move forward if it being an extension and the reason I want to push for this is because We cannot like it seems like it's harder for us to move forward If it's an extension or if it's not an extension and if it is so Like what what's the reason that we can't go forward with it being an extension? Like I also want to like just move past this I don't see why moving it to be at the top level is the way to go forward May I ask are you are you proposing that we don't let people have arbitrary values at the top level? Yeah So then we can't graduate things out of extensions We would have a different process for graduating them out of extensions. We would have to define what they should be So let me understand what she said. I believe what you said is you would like well defined Uh bags at the top level but inside those well defined bags the users can put what they want For example, someone could put something like what Kathy is saying identification label So that is well defined, but inside the bag The app developer can put whatever labels he wants. Does that make sense? Uh, can you say that one more time? So what I'm saying is Uh, We define at the top level a well defined bag I like that idea that a couple of guys on the chat have said something like a system label system information identification label Now, I understand the concerns of those who say there'll be thousands of that Of them and then it loses its value My take is there won't be thousands of top level bags We define only like one or two or whatever is important for now At least the market seems to be saying something for identification So at the top level we define something called identification label system information, whatever And inside that the app developer can put whatever labels he wants Yeah, I would like to clarify why the reason is inside it You know, we cannot pre-define those labels. So for different event source You know, those labels will be different, but the bag will not change. It's all identification labels For example for our event source that's you know, I'm doing a motion detection You know, the label could be something related to that address, but for Uh A storage a storage event source The label could be a the bucket Okay, but but it will not be thousands of labels In that bag will be just a few because for specific event, you know, the the identification labels Won't be huge. But because of, you know, different event sources They have different, you know labels. So the only way we can normalize it We can you know, extract the common part is, you know, some It's called identification, you know label bag so people can put information there And this is important because you know There are some each event producer they could have some additional information They would like to put there on so that, you know, it's it will be making it easier Make the consumer easier to get those information. Otherwise, if everything is in the data um Yeah, I completely agree with It's encrypted, you know, it will be hard to, you know, be along producing a process to decode it Supposed supposing it knows how to decode it and then to extract those values and then, you know When we look at something like the motion sensing thing, are you going to use that for routing? But Dan, can we let Matt speak because he was Yes, I was saying so I I supported if you can't you shouldn't just have blockback box data It's useless to anybody you need to have an identification system And we use it we use your eyes to identify perhaps a specification you could go to So if this is sensor data or this is whatever data you have an identifier that says this is And your eye can be version. So as that data changes It can be against a spec it can be tracked and so that you can go there to know how to parse this black box You can't just have black box data. That's not it's not useful to anybody Exactly, that's exactly I think our schema already provides a way for you to tell what's in the data And what I'm trying to figure out here is why does this What is special about this like sensor data or something else that makes it so it wouldn't go in the data payload And that we're putting into a place where we're designing routing based on it So it's not just for routing purpose So, okay, so for my from my perspective, I would like to use it. This is not I'm not, you know And now I mean the event consumer point of view. I'm not using it as a routing purpose I'm more using it as to correlate the event with other events associated with the same application For that purpose, but you know, I think you know in that Um, so so I would like to explore a little bit in the data field. So if the data is encrypted, okay um I mean, how could the user? I mean if it's encrypted, it will be hard, you know to get all those information And I think I had this before say, you know, it's better. We put, you know, uh, other You know extract that out and put it into a uh a bag I think if someone has concerns say if it's in the encrypted data, the data could be huge That's why the proposal is to say that you can have arbitrary bags at the root level But I mean, I think I don't think any of us are in a position to say where I mean all of us are involved probably in serverless in some way If I mean, I don't know about anyone else But if I knew where serverless was going to be in five years, I'd probably have a different job than I do right now So I mean, I don't think I think it's Very bold for us to say we know how to do this classification. We know what people are going to use I think it's much easier to say let's we it's easy to change. It's easy to add It's just hard to take away and the proposal on the table is to say Let's just let people add And see how it goes and we can always Always add stuff into the spec label and specifically you mean let people add what? Properties the root level if that's what they want Hi, I'm from the gfc and protobuf team and One concern that I have is that if we let people add key value pairs Or data at the top level What would happen is that we would have to actually marshal this entire data before we can decide What we want and what we don't want Instead if you had like an extensions and then put the data that we want in there then we can We can actually go in there and and do that as a second level if you cared about any of the extensions And then marshal the sub data as we care about it So introducing a level of nesting to here's the stuff that we care about and here's the stuff that that's optional would I think Be a little bit more helpful I actually think that argument plays very well to the fact that you shouldn't be putting arbitrary stuff outside of the data anyway um By arbitrary so people are going to disagree about what arbitrary means right yeah arbitrary to one person is essential App logic to the other the point is like the point that I would like to make is that it's about and and uh Feel free to interrupt me if I'm getting this wrong, but it's that we need to understand what kind of data will be Uh, like what kind of data are we expecting here? And if we're getting arbitrary data Anywhere in the anywhere in the properties then that's harder for us to do. Did I get that right? um Yes, um and also like if if you want a version of this then every time we add a New key value power to the top level shouldn't it be that we have to bump the version up? um Only if it's part of the spec Well, let's be clear In what let's say 1.0 Uh, some label does not exist, but then 1.1 some label does exist That's okay as long as some label is optional If we want to make it required that requires a 2.0 bump Um, how then is that meaning conveyed like which label is Is optional and which label is The the specification The spec itself tells you what's required versus optional. So In version 1.1 of the spec we would have to say there's a new top level property called some label And it would be marked as optional and that's why 1.0 receivers Should be prepared for extra stuff at the top level exactly for that reason new things may get added to the spec That are non-breaking changes, which is why I said it would be optional But it would so so basically like every receiver in addition to receiving the data. I'm sorry I'm new to this so sorry if I'm asking like um jump questions Um, but every that means that every receiver that receives this data should not just have this data But it should have an understanding of the spec that's defined outside the data That's received to actually make decisions on each of the key value Um, can we encode this in in in some ways what I'm suggesting which is that if you had an extensions back then Then everything at the top level You know it that that meaning is conveyed that everything at the top level is part of the spec and Does that make sense? I'm I'm I'm it's so hard for me to keep my mouth shut Let me just say this In my experience It is very common for people in jason to add new properties Especially at the top level and I think it would be a mistake for a receiver to blindly drop them on the floor Especially when those exact same labels when serialized as htp headers will appear So based on whether you're in binary versus structured jason You may get different results as an application I think the last five minutes of this conversation is drifted to us strictly saying We won't allow anyone to put anything at the top level Which is I I think that's extremely restrictive um I mean that's I don't think that's the proposal that that we're requesting right like at least from my perspective I think if we you think we allowed No, I think that's what I said I said that okay, sorry If if you want to add key values at the top level that has to be reflected in the spec as well like Maybe that's the same thing, but yeah Sorry I think we'll agree that you know, we do not put restrictions say, you know You can only you know the format of the of new properties, right? It could be you know on some label. It could be some bags I think if we are putting restrictions say a lot of restriction So how many people is going to use this? I think our purpose is it would like this to be you know To more people to use it, right? Right. So that's what I'm suggesting that the extensions um sub-level could have that information Then we're restricting what can go at the top level is is what you're saying is don't let people add anything to the top level Unless unless that's that's approved by the spec not crazy Like I don't want to I don't want to like push everyone there right now We should talk about it But I want to say like that seems reasonable if we do that though and I have a bunch of customers using 1.0 and I mean I actively have customers using our draft right now I actually have actively customers using a 10 year old messaging service right now, which is a cloud service And I have I literally am spending half my day making phone calls right now to try and get them to upgrade because they're using 10 year old software Okay, what do we do when we add 1.1? So they just won't get the like their design their their Software was designed just to ignore everything at the top level that wasn't explicitly listed in 1.0 Or should we kind of push the industry to be prepared for other things at the top level so that you don't have The versioning pain that's that's naturally going to come your way because things will get added over time That's that's the part that I think drove me the most towards this model is this notion of receivers Blindly ignoring things the top level which is going to completely break an old receiver talking to a new producer And the notion of when things do get promoted People are going to have to change code right Because things are moving from inside the bag to outside the bag and then do Consumers now have to put it in both places because they don't know whether they're talking to old or new consumers Those are the kind of things that that really pushed me over the edge towards this model even though I know Fags tend to get people a warm comfy feeling And It's not like like that's not the point. It's not like I feel better about this It's that I know exactly where I know exactly what kind of data to expect at the top level And if I'm and if I want something in the extensions, I can go get it So just to be clear it's not about my feelings. Yeah, I don't understand It's just it's just you you can't know exact But that's the point right you can't know what you're going to get as a receiver because this the producer could be on How does that work in any strongly typed language then I don't understand That's that's an engineering challenge that we all have to overcome but what I can say as a middleware person is that My middleware is going to need to be able to pass stuff that's not in Versions of the spec I need to be flexible enough for that or none of my consumers can upgrade till I upgrade And what we're proposing with this whole initiative is not a point to point not a client server model It's going to be very distributed. There's going to be lots of middleware And if we back ourselves into a place where we make a strict statement that it's okay to ignore things that just show up Then we're going to have a painful time with versioning So I think that um the people the the json http crowd has been very vocal here and we have a Few people who are trying to figure out how to map this to binary protocol and I would suggest that Proto and grpc are widely used in distributed systems and you know places where they have to deal with middleware And other protocols like thrift. Yes So like I'd like to hear more discussion of the actual arguments against Rather than reiteration of the arguments for Okay, um I think the assumption that you know when we do the um serialization We have to remove the back name. I think that assumption We need to discuss that because here you put the extension a big bag Then you think yeah, that's not useful. But if there are different bags, why do you remove this name? For example, if there's like a the extension is not the extension. It's it's called system info Then you know inside system info you have you know, um, I just make it up like cpu cpu or whatever requirement it might not apply to the event But just that why do you remove that system info? There's no need. So there's no upgrade I think here I gotta jump in there. I'm not sure I follow and I hope I don't think I'm the only one What do you mean by remove the bag and serialization like for this example here The bag does appear because the word extensions appears in there. So can you elaborate on what you mean by that? Oh, yeah, okay So I'm hearing that because so, you know, when you upgrade from extension to the man's back You know, the back name is removed. For example, if the back name is called system info Or Label then that's removed. So there's a backward compatibility issue My point is that when you upgrade that there's no There's no need to remove that because that's a that's a that's an attribute name the system info is the attribute name Oh, so you're suggesting that if comm example extension were to be promoted it would Oh, I'm sorry go ahead So when I say he's promoted it's not promote this come example extension It's promote this like this attribute is called Just remove that extension, you know, just say call it system info You're promoting the system info Not promoting any specific information inside that system info. It's all the same information You're promoting that system info That's the attribute The the format of the attribute is like a map format, right the format and then in the specific, you know, value So here is not, you know, the system info is not just one value. It could be, you know, inside it could be key value pair So where does it live though system info? Are you saying it lives under extensions or are you saying it lives at the root or or what? There's a root at the root There's no I don't think that we need another Level of, you know, just that extension keyword. We have different backs, right You have system info. I will not see a lot But you maybe have a few why there's no need to put another extension on top of it And when you serialize it, you just serialize same as, you know, the event type or event event type or event time time Or source, right just like the sourcing for People can put different sourcing for there. We cannot predict what kind of sourcing for will be put there My take is that We do not know how, you know, we cannot predict future how people is going to You know, the event producer is going how they are going to, you know, Use this so I think it's more open more flexible. I think more people is going to use it If we put a lot of restrictions Say we cannot allow this we cannot allow that we only allow a single Key-value pair at the top level at the root level Then we are going to then there will be scenarios People cannot use this back So Kathy, I'm trying to follow what you're saying. Are you suggesting that Extensions should be serialized The same like like all the other attributes at the top level or not Yeah, yeah, but not called extension because when you call extension, it's a big bag, right You call it just just give an example say system info that's easier for people to understand Could you change this slide to like system info and then on the right side you say, you know system info It sounds like So can I interject one second? It sounds like the discussion is kind of what you're saying is What you don't like about some label in this is that it's a key value pair No Some label here just happens to be a key value pair. It can be whatever you want it to be. It's that value can be Yeah, like that Exactly. So I'm I'm yeah, that's good. So I'm saying it could be key value pair Or could be, you know, like a system Assystem info which inside it there are other, you know inside it is a bag inside it. There's yeah, something like that I think that's it something like that. Yeah Oh, you the other you do not need to say system before you can just say what yeah, okay What Kathy's trying to say is she wants a top level bag something called system info, which I think makes sense I'm fine with that I think she wants the ability to add an arbitrary top level bag Yes So I think I just make sure everybody understands what Kathy's saying. So Kathy, I think what you're suggesting is that Event producers should be able to add new top level Individual properties or even bags structured data. Whatever you want to call it other things at the top level. Is that correct? Yeah structured top level structures or top level key value pair Right and these are defined and these are defined by the event producer, correct Yeah, by the event producer and then if we think it's yeah, oh by uh by this group, right Just like we define this event Event type, you know, and then we define source, right? The source itself, you know could be a bag, you know You know, we need to take a look at the source itself if it's a map format. It could be a bag too Right. I just want no restrictions say we only need one. We only allow one format Which is just a key value. That's it I think, you know, we should allow, you know, key value. We should also allow a structured top level property Hey, Kathy, when you say we who are we? I think it's this group, right? What when we define this bag. So what restriction we put there? I think I think the I thought The discussion was really between whether we put Whatever you said in our main spec or we allow users to or producers to define them arbitrarily I thought that was the discussion and when the Jason side says I think we both agree we need that I thought that this difference was One side says we do not put those into the main spec Yes, so let me ask Kathy this question is to get a little clarity. So Kathy when you talk about the system info as an example Um, let's assume for a minute that system info is not defined by our specification Are you suggesting that An event producer can add system info As an extension at the top level Okay, so event producer can add, you know, um System info or whatever other Name that's more appropriate, you know in at the top level um, the extension or we can also define such structure, um at the in the main spec at the root level, yeah So, okay, my whole point is just we do not need to put any restriction on the format of the metadata no matter whether it's in the main spec or it's in the extension Or it is an extension That's my whole point. We don't need to put any restriction there And then when the anything is promoted from the From the extension to the when I say extension, it's not the extension back. Okay What I mean is anything is promoted for you know from not it from no non-main spec to the main spec We do not need to add any extra tag like an extension that keyword tag there What is a defined, you know in the non-spec If it's called system info when we Promote it it's still called system info So there's no backward compatibility issue that fix the version that fixes the versioning problems Right. Um, so Hey Doug, I think we've been going over this issue for months And we've just been going in circles and a lot of it, you know, new people join the conversation. They don't have the context and they Um, they haven't been involved in the earlier conversations. I think we I think the bigger issue is just Is the lack of decision velocity here Um, and I think we should just We should come to a vote at some point and figure out how we're going to get to a resolution hopefully by the next meeting on this And perhaps people could present for a minute or two And propose, you know, what what they think and maybe we could just handle it with a vote Yeah, I mean, I would like to see you present it like This is so we have a specification, right that That is constructed with an extensions bucket and there is a proposal where people have raised a a value add to not having that and um There's been a bunch of discussion in the pr and um It sounds like, you know, we there needs to be a defense Of like the reasons why it is a value Um, and I feel like the conversation hasn't had that like there's been concerns raised about how this gets encoded in binary protocols and maybe having a Presentation or multiple presentations like I think we talked through Kathy's concern where it seems like That's part like that's now part of this proposal So that's progress, but you know, I think that there are people struggling to actually Implement this in things other than Jason Right and and you had asked for people who were not You know, like the grpc and protobuf people to speak up and I don't think they got a chance to yet But I apologize. I'm not still used to zoom with their little hand thing. Well, I think you've tried to put your hand up At least that's what it looks like Yeah, I haven't had enough. I like to discuss a bit about Promotion and getting something from an extension to an official top-level attribute What does the group want at this level as in doing both forward and backwards compatibility What if I define a top-level extension called tracing where I just put in Trace ID and then the spec Comes up and promotes another official extension that is open tracing compatible and it's an ID and trace ID How's that gonna be handle and what do you How are we gonna do this? What are the requirements for this because this is gonna impact the Having top level random top-level properties Seems like we're taking what was supposed to be an extension Then moving them into top-level properties that are gonna have to be namespace. But then again, we're still gonna need code Changes because I'm obviously not gonna put the extensions as just extension. I'm gonna put the company info dash extension so I think we need to talk a bit about the promotion workflow and may Did the encryption and signing that the whole security thing has been continuously postponed for a while And especially in a captain's example, there were discussions about, okay, this shooting and data This might be mirrored Into data, but data might be encrypted or sign on whatever and the point was that extensions could be modified by Middleware without actually modifying data. They adding the extensions. I wrote a huge comment on that Seems like these two topics promotion and encryption signing whatever has been they ignored Are they were discussing in this context because it seems like it's affecting this also? Yeah, I do agree We kind of need to take a decision because this is Aspecting the SDK work and until we have proper working SDKs. We are not going to get any relevant workflows It's obviously gonna we're obviously gonna have more examples of uses once the SDKs are released Okay, so we're running a little long time here And I heard a couple of different suggestions for topics to be brought up for discussions. Glad you just had to the The promotion discussion and then the encryption stuff. I'm not I honestly I'm not quite sure about the encryption stuff in terms of how that 100% relates to this but is someone willing to talk about those two issues because we talked a little bit about About the promotion already today But it was in fate it was while it was bringing it up in favor of the proposals being shown here Is there's someone who would like to talk about the promotion issue? Perhaps looking at it from the other side where a bag is necessary For next time or for this time? I'm as well. We only have five minutes. So probably not today For next time. Yeah I think we have a spec called extension md that documents the What should be put into the main spec? What should we put into as an extension? We probably can start from there If needed, I can be that discussion. I just Share that that's back and then people can comment on that back. Well, I think that's something different I think it's not just promotion Well, I guess no, yeah, never mind. It's okay never mind. Okay. So so Kathy wants to head up those those discussions. That's fine now Sarah talked about other protocols besides jason Yeah, I think Kelly's from um clash from uh, grpc proto team. Okay. Yeah In the next meeting like one thing that we could do is um, let's let's actually have like, um I could I could take maybe five or ten minutes and put like two three slides on On the problems that we're hitting up against a spec. Um from a protobuf definition Perspective and also compare and contrast both of these options And see how that would look in the protobuf spec so that we can talk to some concrete details as to how this would look Outside of the jason land would that be helpful for this group? Yes, that'd be very very helpful because A lot of people have said even on this call He said they want to start with something simple and the way to actually need it if you can Give concrete examples for why things are needed or have to be a certain way. That's very very helpful. Yeah So what I do is um, uh, we would look at both these specs see how it would recommend and um, we have Quite a bit of experience on protobuf and how specs evolve around that so we can speak to that experience as well That'd be wonderful. Great Okay, so also with that just a request. Um, because I I hear rachel's and sarah's and Kilesh, I hear your your points um One thing that would be helpful to me personally is just if you can come up with an idea as to how to promote an extension to the spec If we keep the extensions namespace Got it Make sense. I I think if I think that's a fair question. I think that that we would have to address that so yes Yeah, additionally, maybe we could time box these presentations on the next call and then Perhaps consider a vote afterward. Yeah, I was I was going to suggest something along the line Five to ten minutes for each presentation and then plan on a vote even if we run out of time We're going to take the last five minutes and vote one way or another um, but yeah, although I think that we don't like Let's give time to the new presentation rather than limiting that to ten minutes giving this one an hour Yeah One was given so much time was because this is the only presentation or proposal that had been made I don't like I would have given time for other people Yeah, we chanted it. We chanted a lot of it seems like we might need two or three votes Not in sequence, but it seems like there are a few different issues here. So I just want to flag this Well, I was going to mention that between now and then I'm going to try to work on exactly what we're voting on because as you said There are many different issues at play here and it's not 100 clear But it's on the same page about which issue we're talking about. So I'm going to try to get some clarity there before we actually vote. Yes great Yeah, so I think yeah, I agree with Rachel. There are several issues, you know looks like being Discussed here. I think one issue is today's discussion is you know, um, what kind of um, I think it's a format Right be allowed in the extension or in the men's back and then another is how to promote this, right? So I think even for the first one we have different suggestions So I would suggest, you know, each person present the suggestion I can present my suggestion and then maybe there are other two suggestions I see why is everything put into extension back and the second one is everything top level and But my suggestion is, you know at the top level, but we allow, you know different format We allow key value pair. We allow bags. So we can probably present each of us present the Suggestion proposal and then people can vote Yeah, so Now we're mixing together so people might not be clear what what is what The problem is Kathy some of these issues are very much sort of intertwined and I'm going to try to work very hard to come up with the Exact statement of what we're voting on before next week because that's what Rachel said It may actually have more than one vote. It all depends on how it plays out The one thing I would really ask of people and this goes along with what I think Austin was asking for which is Rather than simply saying, you know, you want so-and-so for For when you give reasons for why you want so-and-so Please try to explain the technical reasons for why your life is like hard without it or why it makes life easier with it Or something like that because we I've heard over Many times on this call you'll want an implementation experience For why we need to do something one way or the other And so anything you can bring to the table would be very very useful in that respect Okay, and with that we have one minute left. I'm going to have to call it Let me just go back and do the roll call if we can very quickly Um, there's some typing in the background makes it hard to hear Roe hit. Are you there? Roe hit you there? Okay, um, chris Hansen you're there Yeah, okay chris. What about eric stahl? Stahlic Or eric erickson Erickson's here. Okay, rich will I heard claus? Are you there? Yes, I'm here. Thank you. Louie. Are you there? Yep. I'm here. Okay. Go circle back around eric. Are you there stahlic? Stahlic? Cool I apologize. I roll hit Is there anybody I missed on the attendance? All right, cool. Thank you guys very much. I appreciate it. We'll talk again next week. Bye. Thank you Thanks everyone Thank you