 All right three after why don't I go when I get started um let's see in terms of ai's The only thing that we want to point out actually never mind. I'll point that out later If you have an ai, please get to it when you get a chance. There's the list is shrinking those. That's all goodness About the face-to-face in Shanghai We do have a list of proposed topics in a Google doc so when you get a chance if even if you're not going but you think there would be a Topic that isn't listed there that you think might be a good topic to talk about please feel free to add it I am planning on setting up a call next week for the people who will be there to discuss Options for what we're going to discuss and who wants to talk to which topic If you do want to participate in that please just add your name to the mailing list or to the Google doc and Include your email in case I don't have it. There's one person in there I can't remember their email address unfortunately Now we I am planning on doing a phone call this Friday at 3 p.m Based upon the little poll that I sent out for a brainstorming around the next possible interop type event Do you have a Google doc here? With a list of ideas nothing is set in stone at all right now is just sort of my rambling so far So please if you have additional ideas or suggestions, please make them in there Even if you can't join that call or don't think you're going to be able to participate in the event itself If you think you have a good idea for us to look at please add to the doc But according to the as I mentioned according to the doodle poll looks like 3 p.m This Friday eastern time is when we'll have the phone call So I'll send that an invite to the whole mailing list. So anybody's free to join even if they didn't put the name on the doc Anything about those two events that people want to bring up any questions or comments. All right, not hearing any stickers the new logos that Austin put together for us are finally available in the cncf shop and So they are finally in stock and I was given a coupon code So so I was able to order 200 of them this morning. Hopefully they will arrive relatively soon and I'll be able to bring those to the coupon event in Shanghai as well as Seattle and hand those out to not just other people but to you guys as well So you guys should be able to Share that with your family and friends because that's always exciting. So just want to share the latest status on that I suppose if you guys have a conference that you'd like to give those out to before those events Jump me a note that I'll do my best. Maybe ship some off to you Step to you or you can wait to the conference. I will bring the full stack available To those conferences All right. Any questions on that? All right, community time. Is there anybody on the call who's not a regular Person on this phone call from the community who'd like to bring up a topic in general All right now hang anybody. Let's keep moving forward then. I don't see Austin on the call So I'll try to update what as far as I know what happened with the SDK group I believe we had a phone call last week And really for the most part we talked about the GitHub repos or maybe that was actually before Anyway, I think from our last Thursday phone call. We agreed to go ahead and create the repos one per language So I created a Python C sharp Java and JavaScript repo VMware wants us to just migrate the resisting goal line repo over so they're working on whatever I Think internal approval process. They have to make that happen. So hopefully that happened fairly soon But then we should have what is that five different repos all set up. I Need to be given the names or I'm sorry the GitHub IDs of people who would like to be made admins on those Because as of right now, I don't think I've made anybody an admin And I'm definitely not doing all the work on all five repos So I need you to send me a note or ping me on slack with the GitHub IDs of who you want to have admin access on there At some point, we should probably talk about the governance of those repos but for right now We'll leave it a little bit loose just to get the things Bootstrapped a little But anyway, we should probably talk about it at some point Any questions about SDK work or anybody who was on the ST a call can they think of something that I forgot to mention All right, not hearing anything moving forward Cathy. Is there anything you'd like to mention relative to the workflow? I'm sorry workflow subgroup Not really. Yeah Okay, all right in that case. Are there any questions for Cathy? All right now hearing any moving forward then All right PR reviews a couple on here, which should hopefully be fairly straightforward. Let's see what we got here first one All right So this one I wanted to just this is just the minor typo everything else in this list was singular So I decided to make admin singular as well the bulk of the PR is I wanted to update our owner's file to be a little more consistent with Owners file that I've seen in other projects In particular, this is just basically this at the admins and I which I still keep so I still have the admin section But I wanted to do was add in a prover section now even though we don't have a formal list of approvers Per the normal get-up process What I did do is add a comment here pointing to our spreadsheet Telling people to look at the voting rights column in there and that will give them the current list of in essence approvers Meeting people who have voting rights since that's the closest thing we have to that. I don't think this is a change in our process I just wanted to document what we're actually doing Yeah, it looks good to me. Okay. Thank you, sir. Any other questions or comments on this? I have a question when we talked about this before I thought we're going to cover How we like what we do if one of our current admin sleeves Yes, and I actually did that this morning and since that I think on a previous phone call We talked about opening up an issue to make sure that we add additional documentation to cover that I open the issue this morning I have not had a chance to actually execute on the issue yet, but that is on my to-do list. So, yes Yep All right, any other questions or comments? All right, any objection to adopting this poor quest? All right, not hearing any. Thank you guys All right next one This was also mine a couple things here one is We're not really a new effort anymore. So I just wanted to clean that up Well, I was in here making the other real changes, which is we are I Wanted to make it clear that I'm sorry, I got distracted there. I want to make it clear when we actually became a sandbox project Mainly because and this is a strictly selfish reason Every now and then somebody pings me about our status what we're doing or when we became a real project and I Life me have the hardest time remembering it and I figure other people May have made me the information about when we became a sandbox project so I wanted to include a link to the Google doc for the TOC Meeting in which they actually voted to make us a real sandbox project and it was a May 15th So I just want to put that information in there That's really the main purpose behind this PR So that other people can reference it if they need it any questions on that comments Any objections to approving the only yeah, hey Doug This is and the only the comment and it's kind of a dumb comment I apologize, but I think we're gonna try to change sandbox to cloud native sandbox We'll kind of in discussions on that right now But since you're making changes if you want to just instead of saying sandbox a cloud native sandbox in front of that And that should cover cover you for going forward with the CNCF sandbox. So you want cloud native sandbox? Okay, I can do that. Is there any objections to making that change along with everything else in the PR? So it would appear right here Doug you fix the the columns I mean the 80 column thing Now the URL the you've removed a bunch of text on the line 18 and now line 18 is very short. I Don't mind short. I mind long, but if it makes you happy, I will try to make it look a little more consistent just for you Scott it has to be aligned Anyway, I'll work on that Scott any other comments or questions on this any objections are approving All right. Whoops. That's good. Sorry, Scott. That's got Okay, approve. Thank you guys very much Uh Kathy this PR is yours. I believe There we go All right, you want to talk to this one Kathy? Yeah, this is just a minor twist for last meetings on action item just to clarify That you know if the primary representative cannot attend the meeting and He he or she can have a delegate And that attendance will be counted Yeah All right Any questions or comments on this one? English is kind of hard in this the they in line 71 doesn't it's not clear if it's the delegate or the pair Should we change it to I Don't want to say company or individuals may kind of work verbose I Think here the day is same as the lens 70, you know, they obtain right that's not changed Yeah, I think I think Scott's Worried about it because you introduced a sentence in between the two when they're right next to each other the day was a little more clear Am I right Scott? Right. Originally the day was the a single person. Oh Actually was company, but you don't get that so definitely need to clear that up then Also columns Kind of kill me any suggested alternate word there then instead of they participants or entity Yeah, I was gonna suggest entity Okay, it works. Okay Kathy, are you okay with that? Yeah, so I just change that to the entity. Okay Yeah, if you can give you that that'd be great Any other suggestions or comments on this? I'm sorry someone speaking as Jesse so not to nitpick, but I think that his her could be there Kathy you want to get that one too. It's a little cleaner too Kathy you okay with that one too? Yeah Okay Anything else? All right, any objections to adopting this PR with those minor wording tweaks. All right not hearing any Let me make note of that and columns busy. Yes Scott. I got you So scathing if you can just adjust the columns to make Scott happy. I appreciate it Okay, here we go one that's a little bit meteor so if you guys remember correctly we wanted to define a bar for adding new Extension attributes to the extension document. I believe last time we talked about this It may have been Thomas who suggested that We actually have in essence sort of sponsors Meaning at least two voting members of the group say that they Are willing to say yes, we should adopt this as a well-known extension That doesn't mean that they're necessarily going to implement it themselves It just means that they think it's worthy enough to be included And I believe that's in here um Yeah, I need to have at least two voting members and the if the if The author of the poor request is a voting member they are allowed to be one of the two as well That way we don't have to worry about people playing funny games Give me about like other people submitting PRs, you know on behalf of other people just so they can vote Anyway, I think it's been out there for at least five days or something like that Any questions on this or comments go in once Any objection then to adopting it? All right. Well, that was easy. Thank you guys All right, Kristoff and now I know Kristoff There may be some open comments on this one So we may not be able to approve it today But I did want to get people's general sense about the direction because I think it was a very interesting approach And I just wanted to bring it up for the group. You want to talk to this one? Yeah, I apologize in advance. My two year old is here. So he may talk in between Try anything if it's too annoying. Just stop me So this came from a couple of problems specifically for HTTP a problem is that names or headers are not case sensitive So we have a problem if you want to convert a case sensitive attribute name to a to an HTTP header So we already had a What I drew naming convention. So I basically in this PR I sharpened it. So maybe you can scroll down The other file Out of the other file. Yeah Yeah So that's already said we should use camel casing for example, so I made this a bit What I say it more strict And saying that you should only use alphanumeric characters and it must start with a letter So we had before as a goal that the attribute names should be Okay should be available for or should eight integration of common programming languages And I think like if you limited to alphanumeric characters, we actually get closer to this goal So it's really well, it takes away a lot of freedom like okay But then we are kind of sure that we can use this name in all programming languages And we also open up the possibility to convert between cable case and snake case or for HTTP converted to non case sensitive ways so that that one I did then in the upper file. So I made new rules basically for HTTP headers where there is kind of an existing Convention that you separate words with a dash. So I made that the rule for the HP Okay, that's it on my side. Do you want to mention though the one that's a little bit weird. Oh, yeah, that that one so Follow this this rule For longest rule strictly means that for example ID will be separated by two dashes which is also not how you would do it in the HEP convention so we could think about making exceptions for example ID and URL and so on But I think we can discuss this Yeah All right, any questions on this one. I thought it was kind of interesting approach I wanted to get it out there because I know this is a big topic for people. I Like it I think the only concern that I would have about the special casing is we would have to make that list huge up front Because adding to it later would break version Changes later. So the earlier SDKs that don't know about the special named ones wouldn't know how to deal with Those later So if we're gonna go that approach, we should find every Special case that we could possibly want up front To avoid breaking the the SDKs later Just that a curiosity on that Would it be sufficient for us to say that acronyms or abbreviations Are special and leave it that or do you think we'd actually need to list them out I? Would imagine that we would probably need to list them out Because again, if they're all lower cased By you know, whatever means it'd be hard to actually tell If those letters were meant to be an acronym or if they're just actually a word You're right. I forget about going the other direction. Yeah Right any comments for other people? Yeah The so I'm running into the same problem yet again now with in another context with trying to get mqp and HTTP aligned We'll have the same problem and I Think ultimately from a so this mapping from with Injecting the dashes and pluses. I think that's gonna get ugly very fast In practical use because It's not entirely clear what that means and then you may may Have mixed mixed use cases where so I don't want to make it too complicated I would probably I would probably rather go and make our Constraint our names more That we use in the specification and say you can only use your lower case Because because right now we use camel casing because it's pretty and that's the only reason But we can constrain ourselves and and making things case insensitive is a giant deep pit So if we can because case folding and then what is a character and are we constraining ourselves to ASCII? And if we're not then you need to have eight their territory then you're in case folding Scenario, so I think if we're more could if we're more restrictive About what we allow and say you can only use lower case And you can only use Effectively ASCII Characters Then we would make that easy for everybody So just to be clear that would mean In particular to say the Jason in format all the Jason properties would be lower case Yeah, everything would be lower case every everything everywhere, but with that we don't have any problems with case sensitivity right and We would simply I mean you would lose the prettiness of having a word separator But I'm not sure how terrible that is Any comments This is Tim I that I think that's probably a good idea anytime case folding can possibly be avoided It should be it tends to be a performance bottleneck in some languages because they try and be unicode complete and locale sensitive and so on We did that in an AWS CloudWatch events. Everything's lower case and it's we've not regretted it Doug I think you might not be on mute. Was that just because you're not on mute or because you wanted to say something Okay, maybe it's not anything anybody else have a comment Yeah, I wanted to clarify that this is alphanumeric characters only so I think case folding If you really like only that those base SK letters It is not as bad if you as if you have to fall full UTF 8 or you have 16 Actually, it sometimes it is in a Turkish locale the upper case of lower case. I isn't ever case I something different And like languages will try and look at your locale setting and do the right thing So just don't do it if you can possibly not do it Okay, any other questions or comments? I hear two different alternatives being proposed one is Is whether this PR and another one is just lower case everything Anybody else have any feedback on which direction they prefer or an alternative? I Must rather have it be case insensitive. Is that advocating for the Yeah, okay. Thank you. Bye Anybody else I'm gonna pick on somebody here just because I can Austin I'm gonna pick on you as sort of the leader of the SDK subgroup. Do you have an opinion on this? Hey, duck. Hi everyone. You caught me writing emails. I'm totally tuned out. I have an opinion I just I don't know what that is because I wasn't paying attention to this. Okay, fair enough. At least you're honest about it. Thank you Okay Okay, let me pick on somebody else than just for fun Because I know the background and in some of these protocols like this Matt Rikowski In your experience with some of your other inventing type of protocols and stuff. Do you have an opinion on this one? I Mean, it's better to be prescriptive on the on the specification side and post things in the authors of these events because if people bought into the spec and they're gonna they they're interested gonna author the spec Why suffer any issues in terms of case folding or having to add things to your pipeline to to deal with, you know Transfer in case Unicode all the things why inject other tools in the pipeline and things don't need to if people bottom the spec They're going to do it with the more prescriptive things to make processing more efficient Okay, thank you sir Anybody else want to comment? So hey, this is Jen. Um, this would indicate a spec version change. Yeah Well, we're not at 1.0 yet. So we can make this change freely Okay, so you won't bust anybody. That's already Programming to 0.1. Yeah, my understanding is and again new in yeah, you're on 0.1 at the moment Yeah, yeah, well, I wouldn't say we won't break somebody because we would But it's okay that we break them because we haven't reached a major version of it yet And until you reach a major version of it, you can break them all you want. Okay. No, that's fine I just wanted to understand your policy. That's cool. Yeah All right, I was just looking at the HTTP headers Specification looks like there's an RFC profile there to specify case insensitivity so that might point to prior art Yes, I think somewhere in our spec we do talk about ACP headers being case insensitive as well Actually, it has it right here line 167. So yeah, right Klaus. Would you like to say something? You said something in the chat. Okay In the case that you have case insensitive names, you still would have some kind of word separator like the minus So also in that case, you would somehow need to mark up the map entries So Clemens, you want to take that one? Was there a question for me? Yeah, it's basically saying what if there are dashes in the in the property name, I believe, right, right, Heinz? Yeah, I might actually change this in line 181. So I changed the dash to a plus sign to make it for the map entries clear Yeah I'm a little so the So here's the thing that I that I'm struggling with with that annotation The so the CE is the CE prefix was meant to be basically just a namespacing Where you everything is pretty prefix with CE you can go and take the string that follows CE And basically stash that back into a dictionary and then and then clients will go and consume The attributes from the dictionary and the CE will be stripped. So that's just a purely just a wire construct The injection now of this this dash or plus as an indicator Now turns that into a far more elaborate string operation because first you need to go and break the string apart And then on the other side, you need to go and reassemble it again And that is assuming I guess That a there's a case where we actually have properties which differ only by by name by case And then you can also need to go and find out the casing Without any help just from that arriving HGP header so Again, I'm leaving towards towards that that sounds all very complicated and basically speaks for us our Camel casing assumption from the base spec to be probably not correct Because it's causing complication here Okay, uh matt I see your hand raised Yeah, I just wanted to Did you got me my brain cells firing? I thought I Acknowledged that I think that this discussion is indicative of the maturity the spec and the the Current state of where people are at with it in terms of implementation That which means that people are looking at what tool I'm going to use what product He got every last bit of performance how to avoid confusing implementations Um, and and if the next logical step then is to ask yourself Since this discussion is about you know, how do you do word separation? The question is why do we need word separation? Why you know, if you look at all the examples here above Why is why do we have to have an event in every name? It seems redundant by context unless you have multiple times or multiple IDs You need to be the differentiator, you know word differentiator or some other indicator But unless it's it's needed why wouldn't you compact the event format and and the keys as much as possible? So I'll just throw that out there Okay, thank you Um, so I have my hand raised. I just wanted to point out one thing I had I put this as a comment in one of the other issues out there If you scroll up in the chat, you can see where I put in seed as my property I just don't want to feel to remember that HB headers can have in essence multiple values in there So you put a semicolon and then put you know name equals the real proper name in the proper casing with dashes or whatever you want and that could be Completely independent from however it's specified on the left hand side of the colon as HB header So we do have options like that as well. I'm not necessarily advocating that I just want to make sure people remember that we had that kind of option so Going forward though. I hear at least two options here um I suspect people want to want to think about both of them going forward What I would like to suggest in terms of a next step here is maybe clemens. Could you open up a pull request? of With your approach of just lower casing everything so people could actually look at your pull requests side by side with um Christoph's and they can take a look at that and maybe on next week's call We could figure out which direction the group prefers. Does that sound okay? Yes What other people think in terms of next step? Is that an appropriate next step? Or is there some other approach you guys like to take to this? Okay, obviously if someone has a brilliant idea for a third alternative don't hesitate to open up another pull request Because I I think having them in their complete form as full-blown spec edits makes it really easier for people to compare and contrast them going forward So don't don't hesitate to create another one if you need to Yeah Um, all right can raise one point This also like I said, it limits it to alphan americ characters and it means you cannot use utf 8 or like Like tim said like turkish names will be possible So I would just like to go out. Is that cool with everybody or do you think this is a no go? Because that would also change with the direction of things Now, I think I think we should we should really go and constrain constrain the character set to be Stay within ascii Because you know everything out. So you have the choices of either allowing everything gets in utf 8 or is constraining it to ask you it seems to be the the two fair choices And I think that's something that we can reasonably do and should do Any other comments on that? You know in 2018 handling utf 8 isn't rocket science. I mean neither approach is completely insane All right anything else All right, any other comments or questions on this topic in general before we move on to the next agenda item utf 8 would be nice I don't know the hassle it implies with the sdk and the transport specs, but it would be nice especially as Not having to encode the payload it anyway if it contains any Let's say exotic uta utf characters Okay, any other last comments questions All right, so I think we have a direction to go All right now since we've Approved the pr about the bar for extension attributes We have this one here called sequence Uh, let me hide the comment here for a sec This one's actually been out there for quite a while. I don't think it's actually changed much recently Um, let me pick on somebody. So I'm not doing all the talking here Christoph would you like to talk to this one? Or did you have the do you enable to? I can try okay um Yeah, this didn't Thought out uh from me, but I think like from uh, we as commerce tools the company I work for This is like one thing we generally have that people are really so we are working in the commerce space And it's for a lot of things important to understand the order of events and that you make sure that you process them in the right order um Yeah, so what I did is Ben started it. I think and then I added some stuff to it What is what is what is basically does is Two things it generally says there is an attribute called sequence And there is some value in it and we don't really know what it is but uh, if you know how to interpret it then You can find out which event comes from another and um, the second thing it does is it defines a sequence type And if that is known to you then you know how to interpret what you find in sequence And this we have one sequence type defined called integer and it's basically an increasing integer So pretty straightforward starts with one then goes to two three fours and so on Um, and then it wraps around at some point Yep, all right. That's it. Thank you. Thank you. Are there any questions on this? Now keep in mind this is just an extension. So the bar is lower They have to be perfect. It can change over time The question here for the group is whether this Uh Seems appropriate, you know a thing for us to add is an extension. Is it in scope for our spec? Um, does it seem like it's at least well thought out not necessarily saying you agree with it or that you're gonna implement it But does it seem like it's a valid thing that people may want to do as an extension? I think it is and and part of that is because I believe somewhere in the spec we specifically call out being able to process stuff kind of in an order And that's not built into the the basics back. Um, so I think this is a The very least applicable for an extension if not A full-on property because I can't remember exactly where it is, but it's called out as a like a use case somewhere in the spec Being able to process stuff in order Okay, thank you any other comments, I see some people in the chat saying that they think it's a valid thing Let me so let me turn the question slightly around Is there anybody who would object to adding this as an extension? I I guess I I think I was common. I was considering commenting on this one. I I like the concept um, I think we could do with a second example and I guess I was more hung up on the um, the fact that it was For an integer sort of a gapless sequence So I I was sort of thinking there was an argument for You know saying it's of type gapless sequence rather than integer or um Just a gap sequence and I'm more sort of coming at that from the fact that as soon as you say this is a A gapless sequence. It means your publishers become stateful. Yeah, so um That could that could result in problems in some situations But that was more of a I think a semantic argument than anything else Okay, it sounds like also the kind of thing that might be worthy Of a follow on pr mainly because I think it may require a little bit of back and forth to get the wording and the and the syntax of it quite, you know a little bit More fleshed out Right, and so I think you maybe have a follow on pr might be more appropriate and keep in mind These are just extensions. They can change anytime. They're not going to be version with the rest of the specs So these things are free to be changed on a daily basis if they need to be so okay Okay, um, oh There was a question about uh, should it go into the main body? And I think that the sequencing is is specific to Context, um, we already have time for ordering across boundaries So I think it looks good in the extension. I'd vote for it to be there In favor of adopting it. Okay I'm matt, um Thank you matt All right, so back to the question. Is there any objection then to adding this? I'm not necessarily Okay, let me I'm sorry. I'm going to rephrase this Um, I'm going to get exactly as a two-part question here. Um, is there any objection to this? being a an extension property This is hind I'm not sure if it's a strong objection, but I think we're adding redundant data Where generally the transport protocols already have sequence numbers And there's a large complexity where this all only works if there's one producer of the event Because now if I have let's say five producers to the event going to the same namespace Which other transport could be a topic or a queue The ordering is only for that stream. So you would not have order across all of those And those are usually solved at a transport level as opposed to in the Message itself at least as far as something that would relate to the event Okay, um matt, I think you have your hand up. Are you responding to that comment? yeah, I This is the same project earlier and I hesitated because I didn't want to Put you off agenda but you know We're going to see a lot of these things coming up where people have want to add a value And it always comes in a pair. You have to give it a type So you always have a type value So, you know one thing that we we did in past approaches is we went to a tagging methodology We have just an area where you just put tags the tags themselves you use A uri and uri by means of having a protocol and domain Well, mainly the protocol it indicates the class And the value itself can be appended to the path or other other ur means at the end as a As a value or a query string or whatever So if you if you might want to think about if you you're going to have a lot of these things come up having a single line way of doing it instead of having to all cases have pairs or sometimes tuples all right So I apologize. I forgot who was making the other comment gem. That was you, right? I did make a comment. Yeah, okay Um You but you were the one making the comment that you weren't you weren't herperson sure if it was an objection But you were the one that would raised it, right? I believe so. Yeah. Okay. Okay. So um How how strongly do you do that way because? I'm not taking chair out of half here. This is strictly me. This is one of my representatives in the group I tend to have a fairly low bar for extensions because the whole point of them is to see whether they're useful or not um And in some cases it may be duplicate information and that's part of the thing that's going to get fleshed out when people play with it And if so people may decide, okay, we're going to kill the extension But I know that there are necessarily not to say i'm sorry not necessarily all protocols Have some sort of ordering aspect to them That that this would fit nicely into Um, so that's why my my bar is fairly low for what should be an extension I look at this as more of a playpen type area and that's why I I'm very resistant to to Having a high bar as my take on it anyway Anyway, uh, jesse, I think your hands up So, you know that you you've kind of gone in that direction. I would that's what I was going to say earlier is I I feel like it's an extension so I'd be inclined to allow Something that isn't explicitly um airtight, but this this sort of thing Um around kind of a sequential protocol does open up a few Things that I wonder about One I believe it was matt that brought it up where or actually matt replied to someone who brought it up It might have been gem Just recently brought up the idea of you know multiple producers So multiple producers multiple consumers have possibly something where the sequence matters from the beginning to an end And there's a number of steps So that's that's not really something that's Informed here and also I think this sort of opens a It opens a door to advising in the case of you know, what happens if if you receive things out of order And a sequent, you know one one or more members of the sequence are missing And what's you know, sort of that's that's obviously something that is to find outside the scope of the spec in this extension But I think calling that out Sort of goes down the road a little bit So I think yeah, I mean I'm not I don't have any specific advice around this and I wouldn't Block the acceptance of this particular pr, but I think I just wanted to voice that that's sort of where my head starts going Okay So we could take an action item to extend this with some information about something like vector clocks To give an example of multi producer sequencing Yeah, and and I think that might actually shore up half of my concerns is to have an example and to end that That also indicates, you know, like you can find an answer It's not as it won't necessarily be here, right? So gem not to pick on you, but I'll pick on you Since you're the one that voiced the possibility of a concern about this um How strongly do you do you feel about this? Is this something that you'd like to Have the group like take a formal vote on or you know, how'd you like to proceed? Yeah, I mean I I I agree with your comment around this being a relatively sort of low bar thing And it to me it's sort of an an end-to-end application concern not a transport concern. Yeah um, I I think The other comment that was made around multiple producers um, maybe that could be addressed by saying that sequences are Uh within a type and a source or something like that because I would assume You know, you would generally have one event Source, you know given one publisher per source. So maybe that is a clarifying point, but other than that, you know, I Um, it was just an opinion. I'm not uh dead set on anything Okay, so there were a couple of comments made about potential changes Or follow-on pieces of work that could happen here Of those ones that were mentioned um Are any of those things that people feel strongly enough that they'd want to block The current pr from going in as opposed to doing it in follow-on prs Because I'm trying to figure out whether we should move forward with in essence doing a vote now or Does anybody feel strongly that their suggestion should go in before we even adopt this one? Okay, let me phrase it more succinctly Of the suggestions mentioned is anybody advocating merging their suggestion in before we merge this pr Okay, not hearing any I'm going to take that as people are okay with doing follow-on pro request in that case Is there any other question or comment about this pr before I ask the question about adopting it? All right. Is there any ejecting then to adopting this pro request and merging it? All right. Thank you guys. That was cool I Feel this process will get a little easier as we start adding more and more um, all right next issue this one I'm not sure we only resolved this today because people may need more time to look at it But the open messaging spec or protocol I transport where we call it Has been out there now Excuse me. Um, hold on a minute Let me get to there was some questions about whether this spec met the minimum bar So without talking For the moment about the content of the spec itself I was wondering if people had had a chance to look at this particular comment, which I think was edited Last night About why they think it meets the minimum bar and I'll give you guys a minute just to read this in case you haven't read it yet Okay, so I'm not necessarily going to ask everybody to definitively say for sure whether they think is met the bar or not because I think they may need more time to To think about it. However, I am going to ask the question of is does somebody have an initial reaction? And I or a gut feeling as to whether this specification based upon the information this comment is going to meet the minimum bar That depends that depends on what's actually so if there has been a change to the uh, uh submission Because my understanding is that open messaging is three things It's an abstraction And then it also has a wire format and then it's a benchmarking a collaboration project And I think the only thing that really matters to us here since we're talking about intro would be a specific a wire Specification and the last time I looked at this submissions. I haven't looked haven't looked uh in the last few weeks um was um that it didn't describe a wire spec But rather referred to more like a framework Okay, it's the the the spec as it as it exists is very abstract Okay, but do you have a comment on like because one of our minimum bars was things like adoption in the industry and stuff like that Do you have an opinion clements on whether these satisfy the criteria? so rock so I mean if you look at open message and everybody needs to need to really look at this themselves But if you look at at it from a yeah, so those are projects that exist in multiparty Organizations so that clears that bar But I would say if you look at the contributors list for both projects for rocket mq as well as for um open messaging You'll find that The community is rather unilateral in both Excepted open messaging in the benchmarking project where there's a lot of activity, but that's not related to this submission um, I would I would so personally um I would not be a big fan of um of this binding, but if it's a wire specification then I'm probably cool with it Okay, is there anybody else on the call? Excuse me who'd like to comment on their feelings about whether it meets the minimum bar not I poked around the open messaging cloud website just now a bit and I can't find anything that looks like a wire Format I can find a java api, but it just talks abstractly about headers and fields So it's hard to understand what Doing this would mean concretely Uh, is there more pull request somewhere that explains what you'd actually do? Okay, I'm not sure. I think that's I think that's getting to what clements was saying too. It's very abstract Yeah, the spec the spec is really abstract and really what it is about is that this it's the it's The rocket mq wire format which is interestingly so the rocket mq wire format apparently That's my understanding of it has been elevated into the open messaging specification without the actual wire specification making it yet on the open messaging side Which is The thing that kind of rubs me in the wrong way and it's a little weird is it's it's apache rocket mq something has been put into apache By alibaba apparently Open messaging has been started by alibaba and most of the people who I see contributing to the project Basically exclusively except in the benchmark benchmarking project are from alibaba Um, so That makes me a little uneasy about this because that's all smells Like preparatory work being done being done under the umbrella of an organization without much, you know community pull Okay, we have some hands up. Uh gem. I think you're first The when I looked at open messaging a while ago and I haven't looked I have to say for quite a while My understanding was more of a programming model So that would to me that's akin to somebody wanting to do um A mapping document from cloud events to jms it was more of a That sort of level I I never took it as a wire level thing. I took it as a abstraction of a messaging infrastructure Okay, I think Vlad you were next and then Heinz so Vlad Yeah, this is a tiny nitpick, but in the comment There are no Links to the claims. I again, this is a nitpick, but if Doug if you could move to the comment, they're saying that the several companies the voice support of I'm gonna use I would really really like to see links for this and this is not just for this PR But for most PRs who Claim such stuff. I'm not saying I don't believe the comment But I'm seeing their links for open messaging apache rocket and q and apache bulls are but no links for claims That companies would support or they're getting involved or have another participation If we're if we have a bar that bar should at least come with some proof not just claiming they have participated They definitely If they announce their participation, they definitely have a blog post or a tweet or something. That's official and that should be a link Can I get you to make that comment into the PR itself? Sure. Thank you very much And Heinz you're next Uh, yeah, just a quick comment where we actually had somebody in our group do a evaluation on Open messaging and the concern was we could not use it for asynchronous type Messaging which you would probably consider a lot of events would be asynchronous and not necessarily synchronous so what they've been looking at as an alternative which You might want to have a look at to compare if this should meet the minimum bar Is the information on the async api that is out there as well Which is what our people tend to be leaning towards for asynchronous eventing as opposed to They could not seem to make it work with the open api Okay, Perry. I think you're next Yeah, I was just looking at their github repo seems to have a tab under specification Or it's a little bit spread out that you can get in to see what they're expecting in message headers And there's some descriptions about types expectations. So it is a bit more prescriptive. Um, I think it's it's less uh flexible It was like there's concerns that seem to be outside of the messaging space to me And there is information there if people want to reference that Okay, so all the points everybody's I think the speaker key is empty now. So um All the points you guys brought up seem like very valid things Can I ask all you guys who spoke up to please add comments to the pull request itself? In particular if you needed additional information like lad us for pointers and stuff like that Please put those as comments into the pull request so that the author can respond to those And then please take a look at the pr itself in particular the the actual file changes themselves to see whether that Whether it meets your guys needs whether you need more information whether it's too abstract, you know Whatever comments you feel appropriate Because this pr has actually been out there for quite a while and they've been kind of blocked by that That bar that we defined and so I feel kind of bad that it's taken this long for us to give them a definitive answer so if possible I'd like to On next week's call come back with a definite yes or no to them and not string them along any further So please put your comments out there sooner rather than later. So they have a chance to respond to them And with that I think Pretty much out of time, but there's one thing that I forgot to do that if I need to go back and do On the previous pr about the sequence attribute Now I know Kristoff since it's basically Isn't he'll write the pr and I know he's expressed interest in supporting it I'm sorry. He's claiming he's one of the voters who says yes I want to you know I want this thing in there because we have a minimum bar of two voting voting entities approving extensions Who would like to be the second voting entity approving that extension? Anybody want to volunteer for that if you're voting in a company? You can put me down for that and who's that? Thank you I was going to pick on Vlad since he expressed interest before but I'm glad someone else spoke up voluntarily. Thank you All right, cool. With that, I believe at the end of the agenda or at least for the time for today Um, are there any last-minute questions or comments before I go back and do final roll call? All right, not hearing any let's go back up here. I think I heard most people Matt, I heard Uh, Rohit. Are you there? Yeah, yeah. Okay, cool. Um Oh, you're there twice. All right, uh, red auto Renato, are you there? Did we lose them? Yeah. Oh, yeah. Okay. Excellent. Thank you All right. Is there anybody on the agenda who I did not get? All right, who's on the call is not an agenda All right, and that is Vladimir from Vladimir Bakvansky from PayPal. Uh, I have joined. Uh, this is my first time with the group Excellent. Do me a favor. Can you put your full name and uh, you said you're from PayPal, right? Yes, that's right Okay, can you do it? Yeah, put your full name into the agenda thing into the agenda doc and I'll add you to the attendees I appreciate that. Thank you You're welcome All right, anybody else? All right, in that case since we have a whole two minutes last chance any other topic we want to Want us to bring that really really quick All right, in that case, we're done. Thank you guys very much. You made it through quite a few today I appreciate that. I think you're done. All right. Talk to you guys next week. Thank you. Bye