 Hey everybody. Hey Doug, this is Mark. Hey Mark. Whoops. Alright, if you guys want to add your names to the agenda, I appreciate that. So Angel, are you there? Yes, I'm here. Okay, cool. Just wanted to get, make sure I heard your voice for attendance. Thank you. You're on, are you there? Alright, what about Travis? Are you there? I'm sorry, not Travis. Yeah, I'm Mark. Tavis Westfall NAIC. Yep. Okay, got it. Thank you. You might notice there's no R in the name. It's, I get Travis a lot, but it's actually Tavis. Yeah, I'm sorry. I tried to correct myself, but you probably didn't hear that. Hey, I'm used to it. No worries. Yeah. Alright, let's see. Danny there. Yes, good morning for anyone in our time zone. Sorry. Let's see, who else could I call out? You're on, are you there there? Are you there yet? Danny there. Russ Nova, can you hear me? Yep. Oh, hey, Dan. Alright. Henry, where's that Louis? Is it Henry or Lewis? Oh, it's Louis, actually. That's fine. Okay, because your slack thing or zoom thing says Henry. Yeah, fix that. Okay, I'm very, I get very easily confused. Thank you. All right, I did hear David Baldwin and Louis or Louis. Good morning. David Baldwin. Yes. Yeah, okay. I already had you. Let's see who else for waiting. Matt. There. I'm here. All right. Rachel, are you there? Yep. I'm here. All right. I can split your name right. Got it. Eat it. Eat it. You there. Hello. I hear you. Okay. Thomas. See you there. I'm here. All right. I can see I'm getting that. You show up as in line by reverse Thomas. I'm getting there slowly. Stevo. I'm in. All right. Rupak. Yeah, I'm here. All right. Are you on the attendance tracker, by the way? I don't make this little check. So Rupak, which company are you from? Serverless. Serverless, okay. Okay. Okay. Let's check that. All right. Chris. Okay. His porters. Yep. Sorry. I defined on you. Okay. That's it. Dan Parker. Have I heard you yet? Yeah. Excellent. Okay. Ben, are you there? I am. Good morning. Good morning. Jim Curtis. Yes, I'm here. All right. I think we've got everybody in the list so far. Anybody on the call that I have not recognized yet? Yes. Who's that? Can you underneath the attendance list for some reason? I'm having trouble hearing your first name. Clements. C-L-E-M-E-N-S. Okay. Okay. You're on. Are you on the call? I'll switch the call. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. All right. I'll switch your computer on you in a second. All right. Let me start sharing my screen. Start any moment. Actually. There's the agenda again. People don't have it handy. Can you guys see my Chrome window? Yep. Excellent. Thank you. And William. Are you there? Okay. Cool. Thank you. All right. I want to go ahead and get started. Okay. I did roll call Austin. We'll not be able to make the call today. He pinged me yesterday. I think it was yesterday. I mentioned he is actively working on his AIs. So hopefully those will get finished soon. In particular, on the transfer domain aspect. He did send all the emails that he thought he needed to send over to the CNCF guys so they should all the information they need. He just not, he just not had confirmation for them yet that he needed to send it to the CNCF. So that's how it works. I hear a lot of background noises. Can people go on mute if you're not talking? All right. Cool. Thank you. Let's see. White paper status. So the white paper was officially published yesterday, day before. Anyway. It was just recently in time for the service conference in Paris. So that's all done. Good job, guys. So I can. Finished. I could say we're published. All right. So let's go ahead and jump into PRs. Now we actually only have one PR that I think is technically ready for merging. So let me put out a reminder there that one, try to get all comments addressed in any PR that you've opened addressed before two days before the meeting. We do have a rule that says any substantive substantial change made to a PR within like two days. We'll not get merged on the weekly call because we want to get people time to review it offline because since not everybody can make the phone call. So that does mean you need to get your, any textual updates made to your PR is done of these two days in advance. And if there are outstanding comments or questions on your PRs, we're probably not going to address those or we're probably not going to merge your PR until those have been addressed because we don't want people to feel like we're just ignoring their comments or questions. So try to get to your PRs earlier in the week rather than later in the week if you can. Okay. So with that in the other way, let's now talk about the one PR that I'm pretty sure is ready to go in. And Mark, you want to talk to this one since this one's yours. Mark, you're sure. Yeah, I am. You know, as we're just looking at expanding out the number of use cases, I wrote something up to say why it would be important for IoT devices. I also mentioned that because of the potential CPU memory issues with smaller format, format IoT devices that it may result in a binary and coding as opposed to a textual to try to elaborate on that aspect of it should be pretty straightforward. And, you know, obviously we could accept this and then make additional edits of people who have issues with it. Doug. Yeah. Hi. I can't join you. Did you already talk about the white paper getting released yesterday? Yes. And there were round of cheers. No questions about it at all. Actually, I didn't ask. Are there any questions about the white paper? You have to like bring it up. If everybody's happy, I'm happy. Well, there weren't any complaints or yells about it. I figured everybody is very happy. We did a couple of interviews and we kept pointing back to what we're working on now. And so there's, we're kind of building a little bit of excitement about the event, what we're doing. The format and kind of what we want to take that that was getting a lot of good press right now as well. So on this one, Clemens here from Microsoft. But I'm a little concerned about this one just because of the the scope to creep that will happen because of that. I think in the, in the initial face to face meeting that we had, we had a discussion about the kinds of events that we wanted to tackle first. And there is two and actually shared some material on, on the triage can it can do on events and events are either. The events that we typically deal with for, or so far I've dealt with and discussed in this form at least. Is a, an event that's immediately actionable that gets raised and that you write a lambda or a function for that you can then go and handle. Telemetry is very different in that it typically is cause is interrelated and constitutes time series data. So if you're talking about temperature, temperature information, you will typically not act on a single, on a single tick, but you will rather go and collect information in a. Ingestor for events and then go and do, do action based on the, the intelligence you gather over that event, basically you go and aggregate it and then you run some rules over it, which is very different from this distinct actionable events. I'm worried about taking, taking this one in because now then we have effectively two kinds, two kinds of events, events we have the telemetry events, which are really time series data. And we have events which are immediately actionable. And once we mesh to, we must those things together. That's dangerous territory for scope creep. Maybe we can clarify on this one, this is Dan. Is the intent here just the event that says to change the temperature or does this including the, the temperature readings themselves or I just reading this, it wasn't totally clear to me as long as the scope is not. I think we're less dangerous. We just need to make them more clear. Yeah. But isn't the line between telemetry and events kind of blurry. I mean a thermometer. Okay. It's reading all the time. Maybe a hydrometer is sending an event because it detected water. You know, it's still essentially telemetry, but that is clearly an actionable event. Maybe you need to, you know, change a spigot or something like that. I agree. I think the test is whether an event is independent. So whether that, whether the event can stand and can be actioned upon by just looking at that one event and with a temperature reading that in, in a, in a system that's not a toy, that is not true. You will not go and cause something to happen just because the temperature from a temperature center spikes, just spikes over whatever some temperature, but you will go and observe whether the temperature then by average is over a certain value and then you will go and act. So which means you're doing the action not based on that event, but based on the, the inside over that event. So you're doing that over the time series. So if the, if the event is in the, is, is immediately and independently actionable. Yes. Then it fits the, the, the, the scope here. Telemetry data. Then it's, that's, that's harder. Yeah. That's a distinction. It's so blurry. It doesn't exist. Wait, wait, wait, wait. Let's try to keep a little bit order here. So let Mark talk since this is PR. So let him try to address some of the comments that are being raised. Go ahead, Mark. So number one, I said for example, so, you know, an example is an example. It's not the only thing. With respect to telemetry that, that is really up to the functions when they're running as to whether they treated as a time series or a singular event. And the fact was that we're just talking about how do we transit something from an IOT device into a system could be functions, could be something else in order to now take some action associated with that. I am not implying that we need to tackle the, the time series telemetry issue. I'm merely stating that as a message format as a way of transiting these events that we can, we can do it in implying that a binary encoded format in an IOT device may be needed. Does that help? Or alleviate people's concerns? Keep in mind this isn't part of the spec. This is just use cases. It's just use cases. It's not normative. I think it's good to have an IOT use case. I think we just need to make sure it's a good use case. I think the important part of what Mark was saying is that different vendors or different users may choose to use this format for different use cases for different purposes. It doesn't necessarily mean that the way in which we're formatting events needs to change. Any other comments, questions? I think it's good to have this use case because a lot of use cases for serverless will be related to IOT. And having this case will help us to see whether we are missing some attributes or not or whether we define what we define really can be applied to some very useful serverless use cases. Thank you, Kathy. Any other comments, questions? Okay, now some people had raised some original concerns given all the conversations gone on. I don't know if you have any concerns been addressed. So we may be able to move forward with this. Or do we want to make some proposed changes? And can I also say that I'm trying to capture people's points, but feel free to represent your points in the notes to yourself. Is that Rachel? Yeah. Excellent. Thank you so much for taking notes. I appreciate that. Hi, this is David Baldwin. I want to add one point. This is somewhat in support of what Mark had mentioned. I'm not going to leave it as is just because different consumers of the events. It could be a point in time and could be time series. It depends on the situation. I've been in both experiences where a single event can cause an alert action of some sort. A different situation that has time series. So it just depends on the situation. So in this case, I'm actually okay with the example. But I do understand the telemetry argument, but I would prefer that to be a decision of the consumer, but I would prefer that to be a decision of the consumer. Yeah. Not us. That's it. Anything else. Okay. Is there any objection to merging this PR? And keep in mind if you don't. You know, this doesn't stop you from opening up with additional PRs later to tweak wording and stuff. This is just, is it more. Correct. Is it, you know, Is it more correct than wrong? Is it picking things better than they are now? Put whatever phrase you want around there. Yeah. I think that's fine. Yeah. All right. Any objection to unanimous consent on merging this thing? Merge it. All right. I think that's fine. Yeah. All right. Any objection to unanimous consent on merging this thing? Merge it. All right. All right. All right. All right. All right. Hold on a second. Well, I'll fix that later. All right. Next one. You're on it. Are you on the call yet? Okay. I thought it was going to be able to make it. Yeah. Yeah. Oh, there you are. Yep. Very bad connection. Okay. Well, do the best you can. Do you want to talk to your content type? Change. I don't think you actually made any changes last week. Did you? Right. The only comment team between you and the rest of the. Okay. So any change to the content type? Okay. So this PR has not changed since last week. If I remember correctly, I think some of the concerns from last week were around. Well, is this content type about simply what's going to be sort of kept in memory? Is it what's represented on or how the event is transmitted on the page? Or things along those lines. Now, since last week, though, to try to address that, I had made a comment in this PR so I can find it. Where is it? Okay. Right here. You guys look at this text that I started to highlight here, the as of text. What I was recommending was that in the status section of the specification, we add this little paragraph here that basically says we're talking that this spec as of right now just defines the abstract definition of what an event is. Kind of like just the in memory representation more than anything else. And whether or not this group defines how it's going to look on the wire and how that's represented, how we deal with the content type for HTTP header as an example or anything like that. Or at the other end, how the event gets presented to the consumer of it, meaning the functions of service or application or whatever. That has yet to be determined. So all we're talking about here is the abstract definition of event. And then what goes on before it or after that is still TBD. And so what I did is since your own was okay with that. And I think a couple of people were okay with adding that text to specification. That would then allow this PR to go in. But then I opened up a second PR just a few minutes ago to add this text to the spec. So the goal here was to between these two PRs to get us out of this rat hole that we had the last week. But unfortunately, we can't merge my PR yet because it hasn't been there long enough. So I was hoping that we could merge your own PR, the assumption that if you're okay with this general direction of my PR and make some forward progress here, certainly pause there and see if there are any questions or comments. So I think if we have data, then we should have a content type that describes what that data is. Okay. Do you think the definition here is sufficient for the time being for that definition? Describe the data in corny format. So I think the way how it is layers is, at least in my mind, you have data which is arbitrary payload, which can be binary. And then you have content type which says, here's how you interpret that binary. And then you have a schema URL, which says now that you have a content type that you can decipher, may that be JSON or XML or whatever it is, here's a schema that gives you further information about it. Okay. So my question I'd raised on that is, wouldn't schema URL, I liked the discussion about this being for things like JPEG. This makes sense if you're talking about unstructured data, JPEG or zip or something. I'm not sure if it makes sense. If you have something that has a schema, because that schema can tell you what it is. Like an X and X, how is it with XML? Yeah, but the schema field is optional. So in the case of a JPEG, maybe it's not required because if JPEG has, header is something well defined and it contains tons of metadata. My point being, as I put in the comment this morning, is that why would you have both? Wouldn't you only use this for things that are schema lists, that are binary? Yeah, but because it has to have the option if the content is a JSON or an XML or a protocol, you do know how to interpret the field. So Dan, my question. I think there was another assumption that I think was a weird observation. The content type is also required on the API, not just as a wire problem. It could become necessarily a field for all languages and all use cases that the language API will go and deserialize everything that's for you. In some cases, it's pretty extensive, especially in types of languages. You may not want to do that. So anyway, for both use cases, the in-memory or what I call API definition or messaging, you would probably need that. That's why you might need to settle the distinction between API or wire, if that's the matter. So Dan, is it correct to restate your concern that while you're okay with the text that's being proposed here, you think we may need to tweak the... How do I phrase this? You may want to tweak the spec slightly to say that one or both... I'm sorry, only one may be needed at particular times. You may not need both. Is that correct? Yeah, I think that's correct. So is that something that we could possibly address in a follow-on PR? Because I think that's sort of additive to this. It doesn't necessarily fundamentally change this PR itself. Yeah, I mean, I still... My real, real concern here is we never... I liked your new PR because I think it simplified things, but still my concern is how do we express something like stuff that's going to break JSON in an envelope that is JSON? So like the event, everything we've been talking about so far has been... Even if we haven't explicitly said it, we've been dancing around the fact that this envelope has some format, some encoding. And now we're going to have a separate encoding. And that... I mean, do we need to face 64 encode whatever is in data so it doesn't break if this envelope happens to be XML or JSON or something else? You don't really need that. Why would you need that? Because again, if we're talking about the API definition and the header or the extension of the whole flat map of strings, then you don't need a definition of it through elitization. That's the API. The API will talk to the protocol, and they'll do that on the back end. We're not defining the protocol. Does that answer your question, Dan, or concerns? No, I mean, I just don't see how a JSON parser is going to react when you give it an object, when you give it a text file that has non-JSON in it. So Dan... Yeah, but are you talking about the extension, the extension being a JSON and then the data being another JSON? I'm talking about the envelope, yes. Everything except for data is one type, and then data is another encoding altogether. Right, but if you notice the data is not a document. It's just a flat frame map. So let's assume you do choose to have a JSON to define your envelope and then another JSON to define your document. Then once you get to the API, the first JSON is already getting deteriorated. I don't know if that's the right choice of writing a protocol, having JSON within JSON, but I would do the headers in a different way if it's a way than writing it in a JSON. But if that's your choice, then I will already get that deteriorated because we're not talking about how we're deteriorating the header in the message. With JSON, we wouldn't have a problem. If it's something that's going to break... That's my only... Are you going to have to escape it? Do we need then two content types, like one to say this is some sort of state field and then this is what's really in it? This spec is not defined... This spec is not talking about how we're going to do the envelope, right? Isn't it the envelope's responsibility to make sure that every value for each key is serializable in whatever format the envelope takes and it's not part of this spec? At first, there's going to be serialization and second, there's going to be protocol mapping. So the data is a property that we're defining now that we carry. If we map this to HTTP, then the data property may quite well be mapped to the HTTP body. And if we map this to the MQP, it may quite well be mapped to the MQP body. And then we still need to have a property that we then carry in an HTTP header or that we carry into an MQP header or an MQTT header that describes what that data is. And I think this is how this kind of resolves into a mapping. So effectively, the way I look at this at all these properties that we're defining here is elements of an info set that we then go and project out onto a message that then goes on the wire in the appropriate form for the respective protocol and then also in the appropriate rendering on the respective protocol as we need it. So we're just talking about in the abstract here. And for that, having a description as proposed here for content type for data is, I think, a right choice. And that will then natively, if you do an HTTP mapping, the content type that we define here will then directly project onto the HTTP content type. So, I mean... Okay, right, I buy that. You talk about the MQTT headers or the HTTP headers, where we'll need a content type. One of my concerns is that a content type only applies to an array of bytes. Once it's a parsed array of bytes, content type no longer applies. So, I would expect to have content type application JSON if I have an unencoded JSON string, but once I decode it, it's no longer something I would pass to a parser based on that content type. And in fact, it doesn't even need to stay as JSON. As I mentioned last week, we create actual native SDK objects based on the encoded format. Which is... Well, that's the second part. What you're describing now is the ability to interpret the decoded data using the schema, right? Yes, but what's in this pull request says that the payload is encoded. I think practically speaking for content stuff on the wire, it is. But we're not... This spec isn't about the wire right now. So, let's back up a sec here. I thought we were getting really close, and then I lost it. So, let's keep focused here. So, the specification as it stands now is just focusing on the abstract definition of an event. The content type... Wait, Thomas, wait. Let me finish. How that gets serialized or the rules for serializing each of the properties in here into the appropriate format for whatever transport you're going to use for moving it across the wire has yet to be written. So, that's not part of what we're worrying about here. Nor how you convert this stuff into the data that's going to be handed off to the application. That hasn't been determined either. The content type here is just telling you how you can interpret the data basically. So, between the schema and the content type fields, this is how you're going to interpret the data and be able to parse it. That's all we're talking about here. I totally agree with Doug. You need to understand that in some cases people don't want to serialize up front. So, you may have two sets of API as API layer, one which is sort of here is a block because of all sort of things. Maybe you just want to do forwarding of an event from one sort of person to another. You don't want to serialize. Maybe there will be a second set of API which is, I don't know, get fields with the name of the field or an iterator that iterates and that's going to be part of the API definition which will also probably be language dependence because different languages will have different ways of doing those things. I absolutely agree that we will at some point care about how things go across the wire and that when it goes across the wire it would be great to conform to industry standard content types. The way that this pull request that's on the screen, number 64 that we're looking at, it specifically says Payload is encoded. And if the type is not an arbitrary payload, it is a byte array. So, I might from a source publish an event that is none of the middlewares business but it's really only interpretable by the receivers. So I go and choose to do a public private key where I go and say I'm going to go and encrypt that payload with my private key all the receivers that want to go and get it have my public key and I'm just going to stuff that data into that information into the data field. And now with the content type field I'm going to label it as binary that's encrypted. Probably going to have parameters on the content type that says this is what the key you will use and then go and flow that to the other parties which means the middleware never ought to go and interpret what data is but I still need to have a way to express, hey there's data flowing with an event that I need to be able to describe that data. The middleware if it's clever or if it's being put in the know it can, if it has the key it can go and start cracking the data and then it can go and start interpreting the data based on the schema that's delivered with it. But there's got to be a way to go and do basically a pure pass through of an event through middleware infrastructure without touching the data. Yeah and I think since we need to do we need to account for media types like the shows on here that this is okay to have. I agree. You guys, I could pitch late. Okay. I'm trying to understand this so does this mean this payload is how this payload is represented in some format like either JSON or YAML or other formats? Is this what it means? Are you talking about the schema or the content type? No, the content type. The content type just tells you the type of the data. So it will tell you whether it's JSON, XML or something else. Yeah. So when you go to look at the data field you'll know what type of data you'll find in there. You might say it's text encoded in FSDIC. Yeah. Or could be YAML. Sure, yeah. So I probably, I think, you know, a bit confusing is that this encoded I see someone, I hear someone racist. Maybe we can say the payload is represented in some format, right? It is JSON or whatever. Is that something that we can look at in a follow-on PR, Kathy? Because if we kind of have gone to the beginning where we're circling around the agreement on this, I'd rather move forward by merging this one and work on potential syntax fixes later if that's okay. Okay, that's fine. Okay. So let me gamble a little here. What do people think? Is there objection with moving forward with this one? I think that this is important enough that we should have, I don't want to say that we shouldn't vote, but I think people should agree because this seems really substantive. Yeah, that's why I'm planning if anybody raised objections. I mean, no one really had made any substantial comment on the PR since last week. It's a little concerning and I want to nag people to remember to please don't wait for these phone calls to speak up because if I don't see comments on PRs, I don't know whether silence means everybody agrees or no one's had time to read it. And these calls are mainly about trying to merge PRs. They're not really the time to do deep discussions about design sessions. That should happen offline so we get as a broad participation as possible. So with that nagging reminder, are there any objections with adopting this one? Going once? Going twice? Sold. Thank you guys very much for the lively conversation. Now, just so we know, so we approve that one. The other one that I mentioned wait, this one we are not going to merge this today but I do want to draw your attention to it because I did point it out earlier. It's the one about Addison Texas status section. Please take a look at that one because I do think this one got us a little bit out of the rat hole we got into last week and this makes it clear that we're just talking about the abstract definition. So I'd like to get this one in sooner rather than later because people feel comfortable about the PR we just merged but we can't do it today, it's too soon. So please look at number 84 when you get a chance. Just a reminder there. All right. So we have two other PRs that may actually be ready to go. I'm not 100% sure. There's a lot of back and forth or there are some back and forth and some open questions but let's take a look at this one. Thomas, this one is yours. You want to take this one? Bring people up to speed on it. Sure. So this is just a small detail that I have proposed in another pull request source ID was a fully qualified thing, almost like a URI very often the URI I've found it very useful to split the path and the host component of these just because it makes a lot of software come out a lot cleaner. So for example with the service that will be the only thing that differs the entire system for staging and production tiers for meta APIs like I am an access control identity access management where many services exposed at within a cloud provider or also with multiple instances of open source software where you can have an ID for a common resource and the only thing that's separate is the service name. Any comments or questions on this one? URI includes that information. Yes. What I'm saying is I have found it repeatedly much simpler in the software that is used to actually create the entire eventing infrastructure when the service and the ID are separate keys. I'm not saying that URI is a bad idea. I think that the the URI should be present. Show me a library that doesn't have URI support where you can break up the host name in the path. I I'm not saying that URI is a bad idea. This concept was specifically taken out of this video where once again it's been very useful. One of the things that is also interesting is that Thomas, hold on just a second. If you're typing, please go on mute or if you're not talking, please go on mute. That was me. Sorry. That's a problem. Thank you. Sorry, Thomas. Go ahead. We use service very specifically because we we use the service ID off our private infrastructure for actually wiring up the event trigger based on the service ID that lets us know the private infrastructure we need to contact. Being able to have that very explicit in the contract makes it a lot clear. I'm very against magic or implicit APIs. Also, Google has traditionally effectively the URI, but missing the version information because we're talking about an actual logical thing that's globally addressable, but we're talking about the version, the agnostic version of it. Yeah, but still, I still don't understand why it's necessary to break out the information that you have together in a URI in this way. Like what changes through you breaking that apart while you're trying to break out the information as well as totally possible with every language and every runtime to go and extract that information very clearly from a URI. The URI so the great advantage of a URI is it's one string. Okay. Sources more than just these two as well. So that I'm going to raise my hand here. That actually is something that I was a little worried about with this as well. And I actually put a comment about this and raising this and that's it seems to me that when you start talking about identifying the source of the event itself different people are going to want in essence different bits of data about that source, right? Some people may just want a UUID some people may want some IP some people may want a host name some people may want a service as well as an ID and the number of different ways people could break up this data is probably going to vary and I have this sense that there's no way we're ever going to be able to define all the various ways people are going to want to break up this data and so I'm wondering whether we better to just say here's a single string that represents the source and you can encode that string however you want whether it's a single URI a single UUID or a set of fields separated by colons or something like that let the source decide how they want to process that or encode things in there because you as a receiver of this you're probably going to have to understand the source anyway to be able to understand all the various fields and the way they go together therefore you should be able to understand how to break apart the single string as well and that way we as a group don't have to pick and choose which fields to break things into let the source decide it I think that's a top up wait wait wait guys wait wait wait guys guys guys guys hold on wait wait Matt Matt and Clemens Clemens please only one person speak at a time I think I heard Matt go first and then Clemens you can go after him I mean I mean you have to have I mean if you're trying to the whole region includes sources for identification and most people on the internet cover your eye to identify where that what that resource is or you are in so people can define that's why a protocol prefix exists in your eyes so you can actually know how to interpret the rest of the string so that allows us in the future to actually if we want to or others that they choose to define their own protocol prefixes that dictate how the string is interpreted additionally people are accustomed to in terms of sharing resources across different domains using a URI and using their already established domain name so that they can clearly identify one domain versus another so you know you have to know where it came from it's for it to be actionable you really do so wait Clemens before I get to you I want to make sure I understand what Matt was saying there Matt are you saying that you want a single field but you want it to be a URI or and that I was just being too loose by saying it's a string or are you saying you want a single field a string basically says I don't care what the contents is and we do care what the contents is if it's identifying a source okay so you're saying you want a URI yeah absolutely okay thank you okay Clemens think you're up next just precedent in other areas so in the APP that discussion has been had and that landed on being unspecific about to and from and various other addressing fields and basically just made them strings with a strong hint that that would be a URI relative or absolute while not making it prescriptive I think if we were writing the URI in the APP spec today we would clearly make it a URI because we're defining a URI format and that has proven to be we're doing quite a bit of work right now on that in terms of routing etc and that the URI basically holds up to even the most complicated routing patterns that we're trying to establish so so that's just an anecdote from the APP and the same is true for other rounds as well so having a URI, having a single expression is quite handy and it's universally supported so instead of splitting the source URI for it being more palatable to individual implementations I would rather go and consolidate and flow a single field and then I would also be okay with just making mandating in that it is URI I'm a little bit curious is it specifically considered valuable that for example URI has a scheme yes even though many services show the same resource on multiple schemes and therefore we have to just pick one and it may not be what it was even referred to it does have a scheme it is significant and especially in the terms of inventing if you're doing identification a scheme it is very important I actually consider it to be a detriment because for example all of my services are going to be used in multiple schemes and the scheme is actually not it's not the thing that was that was talked to it's how it was talked to without a scheme you have no idea how to parse the entire URI the information on the URI is invaluable to identify the source it's used to identify the source within the domain that the protocol we already have a field though called source type that's how you identify what type of source it is would you suggest consolidating all four source fields into only one instead that would probably be things that you can condense to get more information of a single field it would be good absolutely you need to convince the event you need to convince the event information as much as possible so how do I represent a source that is available on multiple schemes a source that is what available over HTTP or RPC we're talking about URIs not URIs URIs start with a scheme identifier so the scheme could be either HTTPS or GRPC if you choose to use URI identifier that's your choice but I assume people here are going to be more expansive in the use of a full URI not just to limit to a URL so it's identifier it doesn't necessarily mean it's accessible you're not going to hit that source it's basically identifying the source you can choose to make it such that you can hit that source but we're talking about URI in the sense of identifiers not locators not identifiers maybe okay if I am wildly wrong and the scheme is not a required part of URI so the definition of URI is that you have a scheme that basically says the following part is to be interpreted as follows and HTTP has a scheme that has a certain set of rules and APP has a certain set of rules and Mail2 has a certain set of rules for how you go and parse the URI out and you can go and make URI which is fine and that's just a name and that also has rules for how you can go and interpret that and that names your source whether you can also locate your source with that URI is something that you can also do but the primary purpose of this field is to identify the source and that can be any of the available schemes if there's anything about the event you need to do globally, you have to well does that make sense? Thomas are you still there? yeah I'm here at least to me it sounds like you cut out there for a second I want to make sure you didn't get dropped go ahead I would like to not be forced to pick a scheme I understand that URLs are a subset of URIs I just want to make sure that I don't have to for example pick whether it's HDP, colon, slash, slash for my scheme tag or whether it's GRPC, colon, slash, slash or something like that so Thomas one thing I think that may be missed here at least it may not be clear to everybody is that whatever this value is whether it's a URI, URI just a string or whatever it's really just for identification purposes meaning just to sort of uniquely identify it from everything else in the world that it's accessible via any kind of network connection it's just a unique string in essence you really want to dump it down yeah but with that done we want it to be sort of namespace just like in Kubernetes we have like company names like something on the annotation so if I want to add my own event for Amazon want to add their own event otherwise they'll perfect it with let's say Amazon.com I'm not talking about how I'm not talking about how people go about making that value unique that's a different discussion I just want to make sure Thomas understands that the string here does not mean you have to have some endpoint somewhere that's accessible by the receiver of this event to be able to reach back and attack it yeah I agree but I don't think we want to have different interpretations for every guy we want to be able to have it in a namespace in a way that the new vendor comes in and they need to conform to that format we'll be fine the namespacing is really given by the available schemes so there's an RFC for your eyes and how they're built and how you register schemes in the typical way how this has been done in other rounds for instance with XML is that you are taking an HDP URI with a domain that you own and then you have a namespace for yourself that you can go and define the story here is exactly the same as with XML namespaces in that the XML namespace identifier the HDP URI was basically never meant to go and resolve to an actual document sometimes it did but mostly it didn't and it just was there we just all used the domain names to make sure that things were reasonably unique we can land at a convention like this I don't even think there was ever a formal convention in XML lands which was arguably over defined for how the namespace URI should really look so I don't think collision is too much of a concern here right but I want to go back to Thomas because Thomas you keep focusing on you don't want to be forced to take a particular scheme and I'm telling you it doesn't matter that's fine then okay the scheme is almost irrelevant except in terms of interpreting the rest of the string kind of stuff okay so okay so Thomas I think since this is your PR what would you like to do next I'm getting the sense that there's a fairly large push to not include this and potentially merge other fields so we just have a single source value I don't so I I think I can abandon this one it sounds like we're just going to have a source ID I don't see how type an ID could reasonably be merged they're just completely revolvable okay well since we don't have a PR yet with someone proposing that we don't have to worry too much about that yet we only have to worry about it when someone actually suggests it happen so we can so that I 100% agree that ID shouldn't be incorporated because ID is for the unique identity of the event not the source I'm not sure what is event type but no one has opened a PR yet to do it so I don't need to worry about that yet so what I think I'm hearing though is is there any objection then to closing this with no action okay okay cool thank you so let's move on to the next we have about five minutes let's see how far we can get on this next one Thomas this one sorry Thomas this one's yours as well yeah I was just trying to offer some language I think some other people have better suggestions as well possibly but just there was some concern about like is the source the end user on my web browser we're trying to codify that this is actually a piece of software that first identified so it's not an end user it's not a relay it is the actual originating source where the occurrence happened any questions on this one I think correct for one here Thomas this is just a syntax change you're not really changing any normativeness or anything like that right it's more of a syntax tweak right correct it's just a description tweak and then I offered some extra examples okay I think someone's trying to speak in there actually I have a question on this you know the source for example if like just give an example if there's a like a motion detection sensor so that sensor you know triggers the event right that image being downloaded and through maybe some gateway and then going to the storage in the cloud and then that triggers you know a function to process that image or that picture so it's a source that sensor I mean whatever video camera or the source is a gateway the API gateway maybe it goes through API gateway or go through any other you know IoT side gateway or is a source that storage which might be the for example AWS S3 so what is the source I would suggest that if the event type is an object upload it's S3 if the if the event type is in the domain of IoT or like say a movement detected event then it should be the actual IoT device so you are saying depending on how we define the event type the source will need to be specified to be consistent with the event type specification is that what you mean effectively because I think in the process of handling an event or doing some other software you can cause another event to happen so in your example you specifically said the image was uploaded to S3 well S3 already exposes an event type or you know an object upload so that already does exist but there is use in saying okay I'm an IoT vendor I want to do something with IoT and in most of the IoT use cases it makes sense that the individual sensor should be a source but again wouldn't that be part of the payload itself so the guy that is the source is essentially the thing that shocks you into this eventing system not necessarily the end end device but I think that in general the if you allow any piece of middleware to be the source then you can always say what about the next middleware in the stack this is the only thing that you can actually like take a firm stance on without opening up for the next player my interpretation of Kathy's question please correct me if this is wrong there are actually a couple events taking a picture uploading that so if the if we're talking about the camera uploading a picture as the event then the camera is obviously the source if you're talking about triggering the function as the event well then S3 is the source because it's creating an event that said I just had an object upload if you're then talking about the function itself creating an event that perhaps somebody else reacts to I mean each one of those can be considered an event and each one has a different source there isn't like one unifying thing that you know because a long chain of different pieces of software chose to process data in different ways there has to be a single event that tracks the whole thing yeah I think there might be a need for some form of correlation ID that would actually link together this chain of events let's take your example with the S3 what will happen actually S3 will be the source and you'll probably expect information about the camera inside the S3 object or metadata so that means that if you let's assume now the event carries the S3 object or metadata around the S3 object then the information about the camera will be in the data not in the event when the camera sends it okay then it will be the camera device ID whatever the serial number that will be the guy sending the event yeah so can I ask a question here just for clarity's sake is Kathy's question or this line of discussion is this directly related to the textual changes that Thomas made here or were they more of an abstract question because I'm wondering whether the questions are being raised because they have because people have concerns with his text here or because they were asking a tangential question I just feel we probably need to I'm not sure whether you know it's directly related to this PR but here it said the event at the wrong time the event at the wrong time so I think we need more clarification on this you know just give like you know if that event an action that event goes through a lot a chain of you know devices and they eventually triggers the action so where is the event source is it at the very beginning or is it at the end which at the very beginning will be the camera at the end could be the S3 for example that storage of course in the middle there will be a lot of other devices too but I guess will not be in the middle devices otherwise they are civil so maybe I could give some help with some clarity here working on the OPC way pop-up specification which is for industrial automation industrial devices and where the specification is being wrapped up right now so the way how this works in industrial devices is that really you have a bus that sits inside of the machine and then you have effectively a multiple interface towards I would say IT and OPC way is one of the leading interoperability standards for that so the sensor will go and raise an event on the local real-time bus typically the sensor may also be its own source that raises the event kind of onto an internal communication link of some other sorts and then you will have an outside gateway that will go and publish that event then out to an IT system which means this is where this would come to pass the source of that will likely be the machine itself so the OPC server per se that will take ownership and will effectively speak for the machine and then in the past section of the URI it may go and further qualify what part that comes from there's a whole notion of identification of subdivisions inside of an OPC way server which is as it goes hierarchical so URI to identify both the machine as well as the part that emitted the event is possible using URI Clemens can I interrupt you for a second I think this is a more substantive conversation that we can finish in the last two minutes and I would ask I would suggest and see what everyone thinks of this I think it might be a good idea to set some time aside in the next meeting to have maybe three presentations three short presentations to be clear not long presentations maybe like five minutes each tops maybe one from Clemens maybe really nice to have one from Yaren and then maybe one from either Thomas or Sarah if someone else feels like if that doesn't seem like because I think there are a few different models going on and I would like to hear each of them and kind of iron out where they are different so I would really like to set aside time for each person to walk through their model of events like where is the action where is the source if you're training together actions how are you doing that that's a suggestion for next time and with that I'm going to call time but that is an excellent idea so I heard Clemens Yaren there was a third one name I was thinking either Thomas or Sarah because it seems to be a distinct model we'll set aside some time if you were just mentioned would you like to do a presentation either ping me or add your name to the agenda once I add the agenda item to next week's call and we'll allocate some time for it but I think that's an excellent idea I'm sorry if I just made work for Yaren and Clemens it's always good making work for people is good but keep in mind please people comment on these PRs before this phone call because a lot of this discussion could and should have happened before today so I'm not going to remind her now before we run out of time we'll go here so Michael Payne are you still there Michael Payne yes I'm here okay that's fine David Lyle yes I'm here Klaus yes I'm here okay Joe Sherman from Microsoft Joe okay is there anybody on the call who is not in the agenda right in the list of attendees Austin here I'm sorry who else at the same time as Austin alright alright okay got it anybody else it's good to have Clemens on board there you go it's always good to have more people alright with that do we have Ajay from AWS on this call I have not heard him yet now okay alright he expressed interest in joining hopefully we'll see him in the near future yep and with that we're one minute over time I apologize for going over but this was a great lively discussion and reminder please look at those PRs before this call and please address comments in your PRs at least two days in advance so we can try to get them merged and with that thank you guys very much talk to you later bye