 All right, let me go ahead and share my screen. I'll have a minute. All right. Am I missing anybody? Hey, hey, Mark Chris Portschers, are you there? Okay, thank you and William William always seems to take a little bit time to get the microphone going. It's kind of weird. Hey, Collin either. I'm here Excellent. Thank you. Jim Curtis. Yep. Hi. Hello J. L. Butler Yeah. Hey, is that Doug? Yes. Yeah. Hey, it's Jesse Butler. How are you? Hey, good This is your first time here that yeah, I just I just move over to a new DevRel role in the cloud So when I focus on serverless a couple of projects, so I figured I'd start Cool, and see if I can help. Excellent. Welcome. Yeah. Thanks. Good to hear from you You're not really in here. Oh, hey William. Finally All right, that's somebody name in there. Who was that? You're in here And Thomas here is Rachel with you. Oh, no, I work on one of this or there's it. Okay This is a worry. Oh, hello. Hey, sorry. I'm late. No problem. You're not late Anybody else that I'm missing on the agenda for those attendees. Yes, Klaus is here. Oh, hey, Klaus Yeah, hi, this is Aaron. Hello, Aaron Steve over here Steve. Oh, thank you He's like his box reactor for the new folks See ginger. Are you there? Oh, cool. Gotcha. Thank you Neal Avery Hello Are you new to the car camera for sure? I apologize. I am. Yeah, I've been watching the videos of the Previous meetings. So I'm from Confluent Confluent. Okay. Cool. Thank you Anybody else on the call that's missing from the list of attendees Hey, thank you. Hey Kathy Hey, Doug, it's a little sure from IBM. Hello Welcome. Thank you. Actually, for those of you who don't see it, paste it one more time. There's the list. There's the attendee. I'm sorry, the agenda The star indicates a confirmed attendee The star just indicates that I've heard you. That way people don't try to game the system by adding their name without actually showing up Yeah, so you added my name but didn't add a start up. Oh, I'm sorry. Who was that? Oh, I'm sorry. That's all right I apologize. Thank you for keeping me honest All right, tell you what it's three after why don't you go ahead and get started got quite a few things on the agenda today I want to try to finish it all up So let's see first of all Let you guys know that the CNCF created a new mailing list Excuse me. So they not only moved us from Google group to this list dot CNCF that IO for the serverless working group Just today they created a cloud events working group and while it's annoying that we're gonna have multiple mailing lists now It probably is the right thing to do because cloud events is its own little thing now It's not just under the serverless working group. So as you can see, here's the URL and the email I'm sorry. Yeah, the email address for the group itself Everybody in the serverless working group who's on the other mailing list on the service man list should have been copied over If you didn't just follow the link there to add yourself I'm not sure whether people have the same pain that they went through on a service working mailing list or not but give it a try and We'll work through it. Anyway So try to send cloud events topics to that mailing list as opposed to the serverless one We'll keep the serverless one for the serverless working group All right, so let's see serverless face to face We do have the doc here if you are planning on going Please add your name to the list so that we can get an accurate account for the headcount and Then just as important, please try to add to just a topic so people can prepare Prepare for them in advance in particular what I'm really like to have is people sign up for these topics down here at the bottom This is just my initial guess. It's some of the bigger ones or meteor ones I'd like to use the face-to-face time to get through I tried to put some names next to some of them I thought based upon, you know, if they but people have spoken about in the past They might have an interest in those topics Please add your name next to one or if I mislabeled you, you know, remove your name or if you're okay with it Remove the question mark, you know, whatever, but please if you take ownership of it Please try to send out in advance just your initial thoughts or proposal or something So people can think about it before we get to the meeting Other than that, you know, or if not, that's fine I'm just hoping maybe you could leave the discussion at the face-to-face itself just to keep us going forward Okay, Doug. Yeah You have a different address yet, Austin. I have a conflict unfortunately opposite of what we're looking for We got a challenge here. Yeah, as of right now, we can't we can't host the face-to-face Breaking my heart Is anybody else with the fantastic office near Moscone Center? Yeah, we are a few blocks away Okay, so Rachel you're offering to host yeah, okay, so hold on so Google's gonna host Can you paste into there the location I can't let me I'll confirm Where the best space is before I place them, okay? So hopefully that doesn't miss anybody up, but I can't demand it is more than a block of more than cold blocks away So shouldn't be that big a deal All right, anything else related to the face-to-face then I guess one question I have with people A few weeks ago someone asked How many people do we have to get to have quorum and we didn't really decide on a particular number But we have at least 11 right now that seems like it is sufficient Is there anybody who questions that that's enough to make it an official meeting? Assuming we do have the zoom setup Okay, not hearing any objection then this will be an official meeting then All right, any other topics questions About the face-to-face it is next Friday not tomorrow the day after the week from tomorrow all day Hopefully nine to five Google office San Francisco. All right not hearing any thank you guys. Well, yeah I mean I you do have a slight concern that this was raised last meeting that Other people have other commitments around docker con and so having the entire day blocked out might not might not be Doable for everyone. Yeah, I just said Yeah, so we should if we need to have consensus on something We should certainly not do that. Well people are away Yeah, it's just I'm not sure how many people we lose before we reach that bar Alex Alex, I know you have some stuff going on there Do you have to Make decisions Face-to-face cannot not just be done in the normal way where we can all make the work group call Following week, right? So I think it depends on the topic so what I was gonna what I was planning on doing was For a proposal that's been out there for more than a week because that's the general rule that we have We can't make a decision on that at this face-to-face because it's been out there people have a chance to comment on the issue Or PR and stuff like that for a proposal that's brought up at the face-to-face We we can agree on a general direction at that time and say yes This is the direction we'd like to go and there's general consensus I don't think it's fair to take an official vote because that's less than that one week period So for new topics, we won't we won't officially approve it then but for existing ones that have been out there for about a week or so I think that's fair game. Does that sound right to people? Yeah, I agree Okay, so Alex so for example or Alex or anybody else who feels like they may not be able to make the entire meeting if there are Existing topics out there that are you know popping up on the agenda Please review those PRs in advance There aren't luckily there aren't that many of them. I think we have a total of maybe only 18 PR So it's not exactly a huge list So, all right anything else in the face-to-face All right See face-to-face next works. Okay, so Doga I couldn't get to the mute button quick enough is is the intention for that to be from nine to five. I Was hoping to is that an issue? It will be for me. I won't be able to make the whole day, but I'll try to come. Okay. I appreciate that Yeah, I'd like to make the most of out of our out of our face-to-face time Would it be so sweet? So we have topics to be helpful if we broke that into an agenda so that People could decide like if they have limited time so they could decide what is most important Yeah It's it could almost be better to have the Yeah, what's been proposed there a rough an agenda and time blocking for it You have the brainstorm for a demo the next intro demo That would be useful to do with them. Perhaps the most people there So I could definitely try to put together an agenda I'm not quite sure how that works out though with people like yourself Alex where I suspect your overlap with DockerCon is Gonna be dictated by However, they set up Friday's DockerCon schedule. So it's gonna be out of your control. I assume, right? Yeah. Yeah, so What would it be else would it be helpful then if the people who cannot be there all day if on their name on the List of attendees if you put down which topics you're most interested in and which times work best for you Even though you may not be able to answer be yourself Alex Good then I could try to you could try to schedule things for those times if possible I just I just don't know how to do it because a lot of these things are Are gonna kind of free-flowing here, right? I guess most of us should be around it over over lunch Depending on what's going on Yeah, except we may be taking we do we do have some sessions that run through lunch it already like the serverless panel Container sake earlier in the week. So yeah, I don't know Yeah, so I'm not sure how to work that Open suggestions though So I think either you know, I think they're your suggestions saying you know people who can only draw and part of the day Can give their available time slots and the interesting topics. I think that's that's that's good suggestion Or you can just leave a time for each topic like roughly the time Okay, well, why don't we start with that? Why don't we have people put down the times that they will be able to make it and What topics they're interested in and we'll see we can try to align those the best we can Okay All right, anything else we're up face-to-face All right, cool So Kathy you had an action item to write up a more formal proposal for the work stream slash function composition stuff I was just wondering I haven't seen it yet, but I'm wondering Do you think you'll have that in time for the face-to-face? Yeah, I would have it. I would have posted it if you go to The You know that work stream propose. Oh, you already posted it. I didn't realize that I'm not sure whether this link Let me take a look No, not this one. It's the other one. Okay. Could you go back? Which other one did you want me to go to up up the first up? Oh here I'm sorry. I missed that Okay, so did people get a chance to review this yet? I'm assuming maybe not So tell you what why don't we do this? Why don't we Um Everybody take the action item to review this document and then Kathy can present it and we can talk to it at the face-to-face Okay, sure. Yeah The link to this it's in the AI section. Let me go ahead and copy it and put it down Did you do where's it? So this is the workflow uh proposed. This is gliding by the way. This is the workflow proposal that was brought up last week Correct. Yes. Okay It's it's not long. It's a purposely Made it very short so you can go through it. Uh, what you will not spend much time, you know Going through it Looks great Kathy and Doug. I think this function workflow is A good topic to address at our face-to-face because it could be kind of Wide-ranging Yep, all right any other comments questions about um That proposal I'd like to see this face perhaps others could bring proposals as well and maybe present at the face-to-face Yep All right, so Austin you added a topic to the agenda about the The SDK stuff you want to talk about that right now? Yes, it's just a quick question for everybody. Um, we all voted on where we think Uh, we should allocate our efforts. It seems like there was a lot of interest in the um in the workflow topic Uh, one of the other items out there that we voted on was just building some simple SDKs and libraries around cloud events Even though we decided as the working group that we're not going to focus on that right now Um, I believe some people are already Trying to make some SDKs and libraries for cloud events. Our company certainly is Um, and I'm just wondering kind of who's working on this right now And if there's a way that we can collaborate with each other We uh, we created one as well for extent. I think I said you did that Austin. Yep Um, of course, it's early days. We don't have anybody using it yet But we're you know, we're interested in it and we we definitely want to you know, get on board Yes, okay, cool Then I'll definitely reach out to you glenn. Is there anyone else who started kind of nibbling at this Thomas and google, uh, I actually have uh an early draft as well I'm trying to ship it around internally and see like how we want to position it. Um, Like ideally I'd like to use this to start kind of papering over the gaps that google has from cloud events Fantastic, I think We're also interested in that John McCabe um from puppet puppet and open fuzz had a um A job, sorry a go a go lang, um, struct that he was pausing into for cloud events And I think project dispatch may have had something similar for that for their demo So we're probably all creating these structs or at least these definitions Um, it could be useful to have them in a common place or not to have to keep Rewriting exactly the same code Yeah quite a bit marshalling Agreed on the dispatch side that uh, we definitely have You know the same structs etc along with uh code that we were putting into event handlers Or event drivers so I think we're all moving in the same direction, especially with respect to go Is the is the intent with the sdk is purely to sort of provide sort of the ability to handle the events or is it sort of starting to delve into kind of Kind of reconciling the different types of events you get from different providers for You know similar services. Is that something that exists or is seen existing in the sdks? I think first we have to figure out who who's interested in working on this and then set the scope And those are great suggestions as to what the sdk could do john Would this be a good topic for the face-to-face meeting to try to get a little consensus and uh commonality or sharing of stuff Oh, yeah, absolutely. Okay You're not going to be there Well austin, are you going to be there or is it just that you can't host? Oh, sorry. I'm definitely going to be there. Uh, we can't host though I'm gonna I'm going to figure out from our side what sort of code we Are building for the azure functions functions integration Because we should be able to share that and because it's not only azure functions integration with the grid that we have but it's It's broader than that. So, um, I'll go and ask those folks and then see what we can put into I mean ultimately we're gonna we're gonna open source it all but uh, the question is whether we can go and break those pieces out And then put them into a different repo Yeah, I think that's a direction that would make sense to move in so that we're not Vendoring microsoft slash azure slash cloud events. Maybe yeah, exactly like we have this cloud events repo Maybe there could be something um or or maybe there could be something in that Yeah, there's there's a bit of um for the product code then And there's all kinds of weird things, but I'll I'll I'll try to I'll try to get us get us a C sharp thing Would it make sense to open up an issue around this and then we can obviously links to The code that we have and that would make it easy for people to Be able to find it Absolutely. I think it's sort of volunteer Yep Thanks, Mark. There you go. Yeah, I would so I would I would like to have a For the net for the net crowd It'd be nice to have just have a new get that has the necessary structures To go and deal with the cloud event and with your civilization and all this thing and that then gets used by The no all the other stuff that we do so I'll I'll talk to the Yeah, I mean for that to be to for that to be useful for dot net probably needs to be Published as a new get package or something like that. That's right, but I'd be happy to work with you on it. Um We have a template for dot net c sharp could make use of it So I see someone's posted in the chat about java another post another person posted in the chat about go And then some folks have been talking about c sharp Would it make sense at a base level to use swagger and then be able to generate SDKs in all these languages I'm that's a great idea. Yeah, I'm So having some experience with doing things with swagger kind of in that way I'm not a big fan of that approach because they The swagger generated stuff it ends up being a little weird in every way It doesn't hurt to have it, but I think it's in terms of like specifically like making the api idiomatic Is where it tends to run into holes Yeah, trying to tweak it to really feel like a natural experience So I'm going to call time on this not because it's not an interesting discussion But I think this is better for the face to face and for the issue that mark is going to open up So let's table this right now Because I do want to try to get we get some prs and stuff that are open Yeah, and first we should have the scope conversation too. So kind of chiming in on that issue with what we think the SDK should do for you know one dot oh I think would be helpful, but overall, you know, we put out a great specification It could solve a whole bunch of problems I create a big impact and now I think it's going to be great to work together to put this in hands In the hands of developers via SDKs libraries Anything that adds convenience around this so looking forward to chatting with all of you at the face to face about it All right. And so with that let's adjourn. Let's skip that one or move on to the next one A couple of what I kind of kind of considered to be more maintenance issues or anything else Um Before we get to some meteor discussions There are two issues that have been lingering which I put comments in that I would like to close because based upon how I But I've heard people say in the past and the sentiment of the group I don't think there's a whole lot of interest in doing these If however, someone on the call does feel differently to speak up and I we won't close it But I'd like to see if we can close this issue right here At an authentication context attribute Based upon what I've heard so far. I haven't heard anybody saying that they actually want this So I'd like to close this one if you were okay with that Not that we can't reopen it later There's a problem that this seeks to solve that's important I don't know if this is the best way to do it at this time. It seems maybe a bit early in my opinion for this And maybe we can get some you know get this in the hands of users and you know See how they're trying to solve it and find the solution organically for that right Because the entire topic of security is something we haven't even talked about yet Yeah, I think I'd rather have have this handle with security and encryption and signing Since it's kind of in the same way and it's affecting quite a lot all right, I thought we had already put Security into the spec for the HTTP that clements is working on. That's right. And I'm pretty sure we have So we have we have so specifically We have this we have authorization there where I think it belongs and that is at the transport Um at the transport level when it gets to the to the exact gesture of how you do the transfer So we have this in the webhook spec We don't have this we don't have that in the specs that do that deal with projecting them the message onto Onto messages because for mqp And for mqtt the whole notion of how you do authenticate Is not happening at the message level that's actually happening at the at the connection level And moving that into the message will actually not help you with anything because the brokers will not be able to Deal with that authentication field. So there's a there's a question of whether so ultimately To make use of something that is inside of the message That would only the only thing it would make sense. There is a signature Where you then can go and decide based on the value of the signature Whether you want to go and take that message because it's coming from A source that you trust plus a source that hasn't tamper plus the message has not been tampered with That's how you'd usually do that sort of thing and we have a different thread a different issue that we had About signatures and that's also complicated but this one just as a As something that writes inside of the message is something that is actually not doable In protocols or makes no sense in protocols such as mqp or mqtt And it does make sense at a request level for mq for for htp Just because that's a choice of htp to do that on a request basis All right, so is there anybody on the call who would like to keep this issue open? Okay, any objection then to closing the issue Okay, what about this one a receipt q context attribute basically specifying the destination Anybody on the call who would like to see this one remain open? those Normally you would have a you publish to a topic And then something will figure out what q that might go on to I I guess What is this a trying to get to Just trying to put some internal knowledge of what q q it should be Processed on yeah, we've we've specifically avoided doing things like specifying the url The destination address as an example. That's something outside the scope of us I think this is the the there's a construct in mq for For where you get receipts after so there's not that were even the reply q this is the recce q Of where you want to have notifications for when that event was ultimately delivered And it's really a more a messaging concept than it is an eventing concept And I can see that being useful I just don't see that being so useful that we should have that at the top level attribute that looks like an extension to me And and maybe if we see widespread use then that's something that Maybe worth promoting into the standard, but it's some not something that I would like So this is what something like go use an extension and then come with that extension back when you've shown that it's useful So I would close that for now okay Any objection to closing this one anybody want to keep it open? I do think it's uh, you know, it's valuable It's your own but uh, again, I don't want to insist on having it Okay, well tell you what I since some people Clemens and your honor both expresses some interest in maybe this thing should live on Let's not close it then let's figure out whether we want to close it later or define it as optional or making an extension But I was assuming people didn't want it at all which is now there's some merit there's some merit to it and um, it is The one the one messaging infrastructure that is actually doing things in this way Is the one that comes from your house, Doug. Yeah. Yeah Okay, that's fine Like I said, we couldn't resolve it quickly. They don't want to move on and we're gonna keep that one, but just fine Okay, so let's get to some of the other what I consider to be easy prs First one. Colin you are on the call, right? I believe I am. Thanks, Doug. Um, okay. Yeah. Yeah, so this is uh, the nas trans nats transport binding Very very similar to the mqtt 311 binding. In fact, uh, I borrowed heavily from clemens Uh proposal, so thank you clemens Um, it's really simple nats doesn't have header. So it's structured mode. You basically take your event and uh, Put it into the payload of nats, which is a byte array Right now this one I believe has been out there for at least a couple weeks now and I don't believe there are any outstanding comments Uh, there's one this morning that I need to rebate, but oh, yeah, we could work. I put that because I saw the merge conflict Yeah, we can work on that So as with all the other Working draft documents we put in there. This is just to get some baseline out there so that people can open up follow on prs Uh, and so the general the basic question here is are people okay with the general direction? And I'm not seeing any comments on there. I'm assuming people are so Yeah, let me ask the formal question. Is there any objection to adopting this? I think there could be a few clarification like for example, how do you identify that it's cloud events Messages within nats, but I could open it up That sounds great follow on prs or good All right, any objection to approving? All right. Cool. Thank you very much colin Thank you. You have a document for us to hopefully approve. Let me bring it up Yes Here you go Well, that's the that's the mqt spec the mqt spec is also very similar to the mqt spec And it's uh, they are brothers and sisters now also with a nat spec and just like the others mqt and the htp the htp messaging spec What they do is they Simply go and project the cloud events message in either This structured mode or the binary modes onto the transport message and are furthermore not specific about um, you know What that is being routed to and and the direction of things being routed and so this is for Effectively anything that's using mqt to be able to leverage The cloud events format in a predictable way. So this will be compatible So and and the way this is crafted is that it's going to be compatible with effectively all the existing app brokers And messaging infrastructures that are out there. There's um on the ingester side There's ibm message boss and there is the n mass project from red hat That's wrapping kafka. There is event house from our side and then there's various messaging brokers from mq to um apache kafka apache Active mq and kupid et cetera and our on our brokers, which all speak ngp And this will be enabling those all right I don't see any ask any questions or comments on this one. So is there any objection To adopting this one has it that's the other one. It's just a working draft All right, not hearing any objection. Thank you guys very much. Thank you All right. Hopefully this next one is easy. This is I think just more syntactical if I remember correctly Uh, yeah, there are a couple spots where we use the word property instead of attribute. So Just syntactical any questions or comments or concerns about this one Any objection to approving it Done easy. Okay um next one Okay, this one Hopefully it's not that controversial. There are a couple of things here. Let me start at the bottom So first I thought it was really weird that the spec itself Did not have an example I know that people can obviously jump over to the jason encoding spec if they want to see an example But it just feels a little odd to me that our main spec itself has no examples whatsoever And it's just straight text. So all I did is steal the example from the jason one Just so people have something to look at without having to lean leave the main spec Obviously as we update the jason spec, we're gonna have to update this example But I think this makes the spec a little bit more readable. So that's the first change the second change in here is I the to see was a little messed up. We didn't include everything at the Some things at certain levels are not included in toc and other things were so I just tried to make that consistent So that's not a big deal But I did remove the reference to the use case document and the reference document I thought it was a little bit odd that the toc pointed to them But it's not actually in this doc itself. So it was weird that this doc toc points to a completely other Set of documents without even explaining why it points to them So what I did is I removed them from the spec itself But because they're interesting docs, I put them in the read me So from the read me we point to existing use cases And the existing gun structures that are out there today. So we don't lose the information I just added it basically in my opinion a better point or two them So this is for the most parts strictly syntactical changes Any questions about that any concerns? That's good Okay, any objection then to approving I have a question for what's the difference between the use case and the usage scenarios My concerns and people might put, you know, just randomly set one place to put Yeah, I think that's a different issue. This doesn't try to address that I actually am working on a poor request to try to resolve that particular issue right now, Kathy Okay This doesn't actually change those documents. It just changes the worry point to them But I will be trying to fix that confusion Okay, thanks Okay Any objection then to adopting this one All right, thank you very much You made it through quickly All right, so Kathy do you want to bring this up to speed on the correlation ID discussions that we had? I think it was yesterday Yeah, so if you can open that so people I'm not sure whether Anyone has a chance to go through this yet It's also short And so this is what we We discussed in yesterday's meeting. So the poor the doodle poor result shows Meeting majority meeting time and then we chose that time and discuss this Basically, we're going to have I the new property. This is just either for property I the new attribute like the data attribute It could be called property bucket or could be called it or could be put or this could be put into the extension Extension section So I just you know put it into this property bucket section by the name You know can be it's open for discussion And it will be a key value pair will be a flat structure So basically I give an example there And then they will be no duplication In that party bucket. There should be no duplication of event of duplication of you know keys In that public bucket Is there a reason this wouldn't be just called properties? Pardon, could you speak up a little bit? Is there a reason it wouldn't be just called properties? Um It's open. Uh, no specific reason. I second that Yeah, me too. I think a very common pattern to just use properties Okay Bucket looks a little baroque So one of the things we talked about on yesterday's phone call is do we actually want a separate Bag for these things or could we just reuse the extensions? Or have them all as top-level attributes That was also an option. I gave examples in a Huge wall of facts on this PR. I think or on the issue one of those things because I just like talking without having clear examples So just to set context. This is really just a way to attach additional metadata to the event Yeah, it lives outside the payload like for routing business logic that kind of thing. That's right Okay Another clarification we tried especially in the binary mode to keep things out of json so In a binary mode would that still be sort of a json structure within an extension That would be a yeah, so that would it's so this structure would have to flow in If it's if it's a separate um If it's a complex type as it is here Then it would be a header that then would effectively have to carry Encoded data it can't encode the structure data if we simply say We're allowing these properties to be top level so making the top level the same extension mechanism Then the encoding for the binary mode is obviously easier Yeah, I think we should just Prefix them for a binary mode just have Yeah So the pc dash something dash Because you don't necessarily want to put the base 64 or something like that within the Prefix Yeah, that's so the prefixing thing is that this is this is affected where we end up with the Discussion where I'm still I still haven't done the harmonization because all the the the transport specs weren't done yet um, I'm so in terms of prior art there is Um, just to cite two things quickly So in in mqp in an mqtt. There's special buckets That are for user properties, so they could and that's how I would map those I would go and take those and map them um into There's a user bucket and there's a Properties bucket and I would probably go and put them there Um I'm not sure whether I would create some stop structure for those I would because that makes a lot of things hard, especially if you have some infrastructure, which does filtering It's not clear that for filtering rules. You always have access to Stuff that is kind of more structured data inside of a of a top level transport property So having that structure is going to be a little harder if we Top-level extensibility and simply say we're going to prefix these kinds of properties in a in a in a in a uniform way That would get us out of that problem for For our htp mapping for our product so for service bus and for event hubs What we've chosen to do is for all of these kinds of properties We're prefixing them simply with p dash And and then we take the normal the normal name and Then effectively in the programming model we Strip the p dash out again, but with p dash we make it easy for the transfer for to avoid clashes with the transport properties Um, right and assuming a lot of the uses for things like routing decisions that sarah You don't want to make it too complicated and uh resources. Yeah. Yeah, and that's that's the risk because because if we So if you think about what the transport mapping means we already We're already take today all the the the cloud events properties and we're mapping them into that property bag Right for mqp and for for mqtt If we now took this took this property bucket And made that it's made that an attribute then necessarily that attribute needs to have content that is a complex content And in if you route this event via let's say, um, you know message broker the message broker can go and look at The value of a property, but it cannot go and decode You know complex type in that property and the text processing capabilities of you know A jms message selector are obviously very limited And so you can't really do a lot with that property bucket So i'm we should allow custom properties, but i'm not sure that that that that model here is the right one Now since we're only talking about an abstract type system here It could quite well be that we decide hey, we're having a property bucket here in this spec And then are are deciding in the transport specs to explode that in a different way and to say no We're actually going to make that flat. So that's a choice that we have right Sorry, i want to define the for example that it's a string type and things like that, you know thinking about the naming convention Sorry, i want to speak in something here. There was a discussion years ago very regarding if we want another top level field core properties or if this is going to be an extension and it was uh A difference between the two was uh Pointed out like we could have a Well another top level proper top level property called properties Which is just key value pairs Uh, and both of them being stringed not full jfm objects and the extensions Actually being full jfm objects that may be parts who encoded whatever And that might need a lot of processing the idea was that if we do have a separate bucket a separate top level proper separate top level P for it Then it would just be a key value pair Which is easier to do quick processing of especially in regards to routing And stuff like that. Yeah, I think what I would Yes, that's great But then you still have if you still make this a flat property bag You still have the problem that you need to go and project that property bag so into a message that um, do you allow the the infrastructure to go and process that message, right? And so And the way how you can do this today with with the current infrastructure that's that's that exists Is in the user header section effectively of mqtt or of mqp or in the in the Transport headers of htp um, and those are flat lists and and in those flat lists our The the other properties that we have to find in cloud events. There are already properties So if you create a subsection underneath this, you're now making the processing of everything in that subsection really difficult Well, it seems to me the easiest solution would be to not have a separate bucket Just make them all extensions and actually remove the wrapper around extensions Yeah, so yes, so there's two. In fact, there's two options one is We create we create a we create a properties bag here Because this is the abstract. This is the abstract model and then we can make a projection rule that says For mapping this into a message We can always say everything that comes from the properties Bucket gets prefix with p dash and everything that comes from the extensions bucket gets prefix with e dash As it gets projected into mqp and into mqtt and into htp so that The programming model right a programming model can go and look at this abstract thing here And can go and say we're going to in the abstract program model We're going to go and create a property bag Then we're going to hand that down to the transport layer Which is going to go and turn that into these prefixed expressions Which are exposed to you know rules rules, etc And then if you read a cloud event into your framework Then the framework can go and turn that back into that property bucket That's that's the thing we can do and that's how you get the ugliness of the prefixes So one of the other options too is this could theoretically be subsumed by the Distributed tracing proposal because it does have the correlation context field which already has for example an htp standard encoding The downside is that we would be limited in the number of bytes that we're supposed to use The upside is that you can actually like you will for free get integration into visualization and tracing frameworks I know this was considered by somebody Thomas, I think and there was a issue of here detailing why this once really works I am Thomas So, uh, I had looked at some parts of the spec the correlation context is not widely Explained like it's it's not linked from the main set of the spec and I may have missed actually parts of the Uh detail so actually last week appended my findings was saying oh, there is actually correlation context um because I was thinking originally of the trace context which is totally different and not the right purpose um, so the the big thing is uh Over an htp framework. I'm not sure if correlation context would be dropped Or not. I know trace context may not be propagated What what are you referring to? I don't know exactly what you're talking about. Uh, there is a wc3 spec called distributed tracing Uh, it is the foundation for open tracing, which is like the pipeline that prometheus and things fit into Um, and it basically has two sets of related fields one are just raw trace IDs Uh, and there is a property bag that I originally thought was being proposed Which is for vendor specific metadata? And so that would be something that can get dropped into and out of the cloud There's a second field called, uh, correlation context, which is actually a property bag that has well-defined header encoding Yeah, but we I think I think what we want to have here is really and this is I think by this example by Kathy is great Is what we want to have is application level Context setting that's and I think of that as being very different from What you use for tracing Right, this is this is for this is for this is effectively classifying. Hey, there's a sensor that sits over in that corner And I want now want to go and route events from that sensor To a particular location. I think that's somewhat orthogonal to the concern of you know tracing Tracing events that are coming from from various contexts Yeah, I agree with, um, Kermans And you need to have some I think you need to have that that the richness effectively of Allowing arbitrary metadata definitions here. This is just a question of how we're going to go and project that correctly so Go ahead comments So I think I think if we go and project if we just say we're going to make a property bag I think the the after thinking about this for for two more minutes I think if we just go and and project this out into the Transport binding such that we are choosing A projection where we're making Flat properties, but we're for each each of these property bags. So this property is back as well as the extension's backs Gets a different prefix We would be having a fairly clean projection into the various transports and the various metadata Areas and then also be able to use, you know, leverage the transport level facilities while Keep maintaining a clean separation and we can go and in the abstractions that we build on top for programming We can go and and effectively Plug out everything that's prefixed with p-dash and and stuff that back into the properties collection And we can go and plug out everything that's that's prefixed with e-dash And and and stuff that back into the extension's collection and then give people who are interfacing with the cloud events a clean view While if you look at the events from the transport perspective, you're going to see those fields prefixed But I think if you are are dealing with stuff down at the at the transport level you understand what that means So what's the advantage of having two separate buckets? um I I still can't grab my head around that both cases. They're both just extension metadata pieces of metadata Um, oh, I wasn't I was I was just I was just going from the the the the fact that we have them So I didn't try to have both discussions at once Okay, I Sorry, go ahead So if you if you know if you know ask me why do I need to have the extensions back? I can't give you a good answer on that I was actually going to say I think we need some clarification on what exactly you would expect to see in properties versus extensions and vice versa and I would suggest kind of falling that up in a separate pr, right? Like a much if this is really just an enrichment for what is effectively Uh descriptors of source. Maybe this is just consumed into the source Like we started with source being an object And then we moved away from source being an object and now we're Reinstituting this object to describe the source better, especially if this is going to be mandatory It might be worth kind of converging source Yeah into a richer structure But it can be empty Yes, it should be empty and uh, this is not going to be just of the source like what was discussed is that the Middleware could also add some labels like a light bulb light bulb doesn't know it's address And that might be added by the first department level even Whatever Got I've got a question here after after after just answer Go ahead Was there any consideration of like some type of type descriptor like json ld or Some way of being able to you know defund being that this is open properties And we have lots of different mechanisms out there today for Describing data. I don't care exactly which one is used, but was it considered To support, you know, some way of like attaching a schema almost To like if I have a complex property that I'm passing in this bucket I could attach some type of attribute that would say here's you know, and json ld was just one that popped off But I'm not set on that But it just seems like potentially that would be useful as a way to communicate Like here's what this data is That would be a great other property Right so We didn't talk about that yesterday But what we did talk about was the fact that in order for someone to actually do something meaningful with in essence One of these extension properties They're probably going to have to know about it in advance and therefore they're probably going to know about the specification that defines it So you're saying it doesn't need to be inlined in the data They'll they'll have built a system that has an expectation that the data that it's going to be receiving For this specific type of event But that requires out of ban. I'm just wondering if there's a way to I'm a big fan of you know, self-discipline I don't want to I just want to throw it out No, no, no, because it is a good point right There's a I guess it depends on what you plan on doing with the data right in order to actually do something meaningful with it From a semantic perspective I don't think knowing the shape is going to help you at all Well, json ld goes more than shape though, right? That's why I threw out json ld because json ld is all about semantics as well if you dig into it Because you have context and you can describe I mean google's using it for exact I mean, it's really for describing data not just Validating the structure So so then maybe we do actually have a reason for why schema URL our field exists Maybe yeah, we also haven't that we also haven't really made sense of just yet that just somehow magically has shown up in the document from the beginning of time, but um That we're also confused about so that might be a place where that makes sense It's mainly a simple way that exists But I think if we if we want to go and carry some schema reference or reference us That might be a good place to do that Yeah, let me say second back that point as well. Um, schema URL is definitely I I imagine scheming URL was going to be the place where um If I needed to actually find the definitive source for you know vert type plus event type plus event type version Right like so microsoft or confluent or oracle might have totally different schema registries It actually made sense for me for type and version to kind of be consumed into You know payload schema URL, right? Which is to say here's where you can look up like a public facing URL for the definitive Source on what this payload is One question this would be at the cloud event level, right? Like the whole Structure would have to be described in this I was thinking more specifically what's in data, right? Like we've left data to be this opaque section of the Not even okay, like we're talking about the envelope, right? We're not talking about the message Um, but really we need a way to say here's what's in the message. That's what I imagine If you're doing the crazy thing and are actually using protobuf in the to encode your Your payload then without having a clear notion of what that schema is that belongs with that protobuf encoding You're kind of lost And you don't want to go into the message into the data Which is the payload to actually get these properties because we discussed that the payload might be encrypted And we want these properties not to be to be visible to the middleware and the vent routing and that's right So they're promoted. They're promoted out. I think so so for this for these I think the discussion where where Doug was trying to let the lead the discussion was kind of You know, do we need to have the extensions and the property and the properties? Do we need to have both of them? Right and and for that, I actually don't say any reason, but I think we need to have that property back I just want to add one thing too. So the the the reason why I was also throwing out jason ld And part of this too is I I need to understand more of what the semantics of what the property bag would be But imagine it has mixed Data like different types of data jason ld does a really good job of being able to say oh Well, this property has this type associated with this property as opposed to just a high level thing that says Okay, this is the type of the property bag itself, which is of course another way that you can address it see see It's glad just because that's you um It was it was it was very possible to go and associate Individual schemas with every little island that existed in whistles. Yeah, of course Yes, and I'm kind of trying to No, no, no, I'm not trying to go down there. I'm not trying to go down that rough Clemens wants to reinvent soap. I'm too sorry for that No, I'm I'm actually I'm I'm exactly trying the opposite. I know I know anything. I don't know. I saw all those bindings clemens Anyway, it's a good conversation. I just wanted to throw it out there So let John say something then what I think we have to cut off right here Yeah, so it's just is the intent for this that this that these properties are specific to an individual source Or are they intended to be Something that could be common to multiple sources because if you're if you're consuming sort of the event and You know, every property bucket contains completely different data. That's that seems to be a different thing That does seem to lock it down very specifically to an individual resource Okay, I'm gonna ask for this. Sorry because we're doing the same thing again We're rehashing discussions that were already had on the stopping which is really annoying Yeah, because this annoys me. I wrote a huge wall of facts Describing what the use case actually is what was discussed and what points still need to be debated If everybody could read that and we would all have the same image because this is getting quite complex With quite a lot of examples and we're not all talking about the same examples, which is obviously It means that we're rehashing the same issues meeting after meeting after meeting right so so so with the last comment I'm sorry. Sorry. I think I have to cut people off here because we're running out of time So glad first thing. I know you pasted that into the slack channel. Did you paste that or can you please paste that into this particular pr? So it's not lost Is a commenter on the pr. Okay. Great. Thank you Second people on the call. Please look at this pr comment on it Let's get the discussion going back and forth within the pr itself. This is obviously going to be a topic for the face-to-face But we since we are out of time or almost out of time. There are two things I want to bring up first of all Do we have a phone call next thursday? I'm inclined to cancel it because people may be traveling either for docker con itself or at docker con or traveling for the face-to-face I'll be on the airplane to the face-to-face Is there any objection then to canceling next thursday's meeting with the assumption that obviously we'll have it on friday for the face-to-face No, let's cancel. No, okay. No objection to canceling. Okay. And before before we complete around the time people vanish Let me just finish up the roll call Alex you're still there. Will there be support for the face-to-face? Say that again Rob. Will there be support for people attending the face-to-face remotely? Yes, we're going to try to have zoom setup Awesome. Yep. All right. And I think I heard Alex in there right Alex debris. Yep. I'm here. Okay mark Fisher Mark yes, I'm here struggling with my mute button when I heard Joe Sherman. Yes, I'm here AJ AJ near What about Dan Barker? Here. Adjay had to jump off just about 10 minutes ago. Okay. That's true. He did comment. Okay. That's good enough Savannah you're there. Yes. Okay. Yep. Oh my god Matt Rakowski Hippy hacker on another call. Sorry. Okay. That's fine Matt hippie hacker How about Ganesh? Yep, I'm here. Okay. And I think I heard Stanley on the call David Baldwin And what about hippie hacker again? I can't remember your real name. I apologize. I want to say Chris, but I don't know if that's right Okay, anybody on the call who I missed from the agenda or for the I'm sorry, who's that? Uh, Rahul. Can you add your name to the list, please? Yep, can I do in the chat? That's fine do it in the chat. I'll do anybody else Oh, Rahul. Sorry. Okay All right with that we are adjourned and we'll talk to everybody next Friday at the face to face one way or another Hopefully Thank you guys very much and please comment on this issue in particular so we can try to resolve this at the face to face Thanks everyone. All right. Thanks guys. Thanks everyone Thanks guys. Thank you