Session Date/Time: 24 Aug 2026 16:30
[00:00:22] Martin Duke: It's sixteen thirty UTC. Welcome, everyone, the few of you who are already here for the media over quick interim. Welcome back to those of you who are on vacation, including my co chair, Magnus. As always, this session is being recorded. We already know we're gonna have a fair number of absences today. And if the numbers don't improve, we may truncate this meeting or or cancel entirely. This is the ITF note. Well, if for some reason you're unfamiliar with it, please familiarize familiarize yourself with it. It covers the the legalistic implications of you being an attendee at ITF. You can scan the QR code or type ITF Notewell into your favorite search engine to read more. You've already figured out MeetEco because you're here. If you choose to speak, please mute yourself about one second before you intend to speak because of the lag. Also, if there's any possibility you think you might speak up in this meeting, please find yourself headset because the echo cancellation properties are not good. Otherwise, you should have your if you're not speaking, you should have your audio and video off unless you're in a very quick back and forth. And, of course, you'll use the raise hand button at the bottom of your screen to enter the queue to speak up. Number of upcoming dates. The first one is today Today is the end of a call for comment on the published priority PR number 1770. We had a discussion two weeks ago, and the consensus among people there was this was not worth having this feature of being able to change the default priority because of a lot of the complexities with immutable properties and ambiguity and race conditions. There was a thought that maybe some people that weren't there might have an opinion. So go find that email on the list if you have an opinion about this and comment. Otherwise, it's likely the editors will close this issue slash PR with no action. We have a virtual interop scheduled. Thanks to Mike English for making this happen on February 2 September 2 rather in roughly nine days. There will be a interrupt for draft 18. I believe this is our last attempt to do draft 18 before moving on to something more advanced at the Seattle interim meeting. There are two more virtual interims much like this one. And then finally, in October, we're gonna meet in Seattle in Seattle, where? As you can see in my typo. There, we will likely interrupt some draft beyond 18 in addition to our usual issue management content on the fourteenth and fifteenth of October. This is today's agenda. Alan is one of the more notable absences today. Ian will resume his traditional role as as prime editor of draft-ietf-moq-transport for today, and we'll run through a number of issues and PRs. You can see, based on the ones that need discussion. I did not list them all on the slide. What do you like to bash the agenda? Alright. It looks like, my three minutes of boilerplate have brought us to a reasonable level of participation. So, again, Ian, if you feel that there's an issue that has, where the the key protagonists are not present, let's not waste a ton of time on something that'll be just relegated later, but I'll trust you on your judgment on that. And I will put up Ian's slides
[00:03:56] Ian Swett: Sounds good.
[00:03:56] Martin Duke: And give him control. Okay. And you're off from the races. Take it away.
[00:04:02] Ian Swett: Thank you. Alright. First, reminder that the two the fill fetch and the switch from hard PRs have been updated after the location filter landed, and I can't remember. Something else was landed. So if you've not taken a look at those, please take a look. I know Alan is not here, but are is there anyone on the call who reviewed those and has questions about them or confusions, concerns that they wanna voice now just to, like, make sure that I or Alan, like, address them promptly? Cullen.
[00:04:47] Cullen Jennings: So look. There's a comment in there, and and I I had the same sort of comment. It I'm sure this is just a misunderstanding of the text or something, but it almost looks like if you're trying to do a joining fetch, you need to know the location of head or whatever, the largest object or else there's no way to specify that in in in the fetch. Like, couldn't understand how you set up the filters to be basically the joining fetch use case. That was the And I'm sure there's an answer to this question. I just was unclear on it.
[00:05:21] Ian Swett: There's literally an editorial section about, like, how to join a track, and so we should make sure that that, at the very least, spells it out really clearly because, yes, it definitely should be possible. Okay. Yes. Okay. But thanks. I will I will review with that in mind to make sure, like, that gets addressed because, obviously, that needs to be addressed.
[00:05:43] Cullen Jennings: Yeah. I mean, I think there's a comment from Sue Austin that's been there for a while. So
[00:05:46] Ian Swett: Sure. Sure.
[00:05:47] Cullen Jennings: I hadn't really come at
[00:05:47] Ian Swett: all yet. K.
[00:05:48] Martin Duke: So, Cullen, the the the as I understand it, the filter stuff is very, very subtle and that if you encode a just a group ID, then it's relative. And if it's a group ID with an object ID, it's absolute. And, that is, like it is very it's very, like, precious, I guess. But we were talking we actually spoke about this is two weeks ago, and, like, the doing something a little more, intuitive is also creates a lot of weird edge cases and things. And so this is this is a a compact and good encoding that since even though it's not super
[00:06:27] Cullen Jennings: I I I don't give a crap about compact. People keep trying to optimize for compact on the control channel. We've all agreed countless times it doesn't matter. So I just wonder if we could have an explicit and non shoot yourself in the foot encoding.
[00:06:42] Martin Duke: Well, again, the primary thing that said is
[00:06:44] Cullen Jennings: not wanting to generate edge cases, but Yeah. I'd rather have it clear how to do things with clear handling of edge cases than really up like, this weird obtuse, we these bits mean this on Wednesdays and that on Thursdays. Like, I really don't like those types of encodings. Right? Maybe I I don't have specific comments other than the current read of the draft is doesn't make sense to somebody who knows this protocol as well as I do. Right?
[00:07:16] Ian Swett: There might be ways we can editorialize, like, some of that text and, like, make it just clearer the way we explain it. I think it it might be a bit too, bit too short in some of its explanation. So we you know, I think the encoding, as much as I tried to come up with something that was a little bit more obvious, I I failed as well. And so you know? But better text explaining it might just make it easier to read. So let's maybe I'll I guess, AI notetaker file for me to file an editorial sheet to see if we can make the text around location filter clear.
[00:07:56] Cullen Jennings: Okay. Thanks, Ian. And, like, look, if you tried and, like, I I I don't have a proposal, so I'm not take this as a weak comment given I don't have an alternative I want. It's just one. Yeah.
[00:08:07] Ian Swett: No. I think it's a good reminder that, like, if I I will try to take an editorial pass. I think I might have time to just to see if I can come up with something. I mean, sometimes I try to do this and I epically fail, and I'm just like, I don't know. It's, like, it's hard. But know and if anyone else has suggestions on it, readability or you know? This is relatively new, so if we wanna tweak the wire format a bit, we can. But, in terms of the actual format, I I agree that it's it's pretty good about not creating edge cases or, like, weird things that you can do that you would never ever want to do. You just have to, like, avoid. So that's nice a nice aspect of it for sure. K. I also wanted to remind people, I think I was talking with Luke. There is actually a IETF- Aman. For oh, yeah. Moe, go
[00:09:00] Mo Zanaty: for it. Yeah. Can can I just quickly respond to Cullen? Cullen, can can you clarify, is the confusion just about the difference between relative and absolute location filters, or is it about the fill fetch parameter and what it means in a subscription and what it inherits and what it what it doesn't and what it can override? Is the is the confusion about just the relative versus absolute location filters? Because I think maybe just two sections, you know, a subsection and location filter that would say, you know, relative, you know, relative starts and then absolute starts. Maybe those subsections would help clarify.
[00:09:42] Cullen Jennings: But part of it it might be just an issue of reading the PR. Like, the PR is so fragmented versus reading the whole complete draft. Right? But it was not the prior how the priorities override, like, is the default and if you have fill things that overrides the base ones, that was all really clear. That part made total sense. But what you set the values of the two different filters to to get the the effect you wanted Mhmm. When you were trying to do a classic joining fetch, that part was the part that was less clear.
[00:10:14] Mo Zanaty: Yes. I I agree. So your your confusion is around more more or less the the fill fill fetch parameter description about how that parameter plus the location filter parameter on the subscription plus the location filter parameter inside of the fill parameters. The confusion is around the relationship between all three of those things.
[00:10:36] Cullen Jennings: Right. And particularly when you want them synchronized, when you wanna fetch up to where the subscribe started and have to subscribe after that. That was what was on
[00:10:43] Mo Zanaty: Got it. Got it. Yeah. Yeah. I I agree. I think the the highest runner case is I just wanna do a joining fetch. So let's make sure that we have a section that starts off exactly like that in order to accomplish what we used to be called joining fetch, do exactly this. And I and I think it's as simple as you just put the location filter in the subscription as if you were doing a classic joining fetch. And and you just add a full fetch parameter, but it could it could tech technically be empty. I think that's the short of it. But, yeah, I think a section up front about that would be would be good because that's the 99% case. I'm not even sure if there's any other case.
[00:11:23] Cullen Jennings: Sure that the design allowed that. But when I read it, I couldn't figure out how to do it. Like, that was where I was like, oh, I'm really confused if that's the case.
[00:11:33] Mo Zanaty: Alright. Yeah. I'll I'll I'll try to take a stab at that editorial change too.
[00:11:42] Ian Swett: Cool. Thank you. That was very helpful. So cool. Oh, to finish my I was saying before, yes, there's a web cal for all the MoQ meetings. That way, you never ever miss an MoQ meeting. I'm sure you wouldn't anyway, but, you know, calendar is your friend. Used to be think you had to download all of them individually or something. I don't know. It was very tedious, but at some point, this got added. Alright. Onto so I've made slides for two issues. There's a a handful of other needs discussion issues I don't have, slides for, but, I think a few of them were filed by Cullen. So if there's if Cullen wants to discuss them, we can today. And, otherwise, we'll just stick to these two. So I'll preface it with that. Okay. So 1881, I think Victor filed this a while ago, and I think it was basically when range filters landed. The question of whether the or functionality, which is encoded as, like, a set ID functionality, whether that was, like, a little bit too complex. So now and then I think this wasn't true when you landed this, but now you can have two subscriptions to the same track, or you can have one subscription with or filters specified by set ID. And the key difference is the set ID functionality does the deduplication, and the first one does not. One other note is that range filters are technically optional. However, the site ID functionality is not also, location filters don't have a site ID. K. Just her backup. And, also, you can actually or things within a given, say, property or something today without the set ID functionality. It's just you can't span properties and say, like, you know, I want anything where, like, this property is this value or that property is that value, and I want to deduplicate if they happen to overlap or something. Just as a very high level example. So there is some more functionality already in this in the functionality. K. These are Victor's comments from a while ago. Basically, this is spectrum, how simple versus flexible. We can make filters removing or kind of, in his opinion, hit a sweet spot, and then we can always make it more complex in the future. Victor, are you on? Did you wanna add anything to this?
[00:14:28] Victor Vasiliev: Can you hear me?
[00:14:29] Ian Swett: Yep.
[00:14:30] Victor Vasiliev: Okay. So my rough roughly the point here is that there is, like, an entire spectrum of complexity we can have and, like, on the simplest side is what we have right now without or, and that was, like, the original design before we added or to support deduplication. And on the other end, there are, like, edge compute style approaches. And there is, like, a whole spectrum of how complex with we can go. And my suspicion is that the version of or does not add that much in terms of use cases. So I would wait until we see what people want in the wild in terms of I want a more complex filtering on really. And once we know that and we have more experience with that, we could ship that mechanism in addition to the very simple filters that we originally proposed.
[00:15:30] Ian Swett: Thanks, Victor. Oh, Mo, go for
[00:15:34] Mo Zanaty: it. Yeah. So I I think there are use cases for for the or even outside of aggregation of downstream subscriptions. And I thought that there was consensus that that that functionality was useful enough to justify adding the set ID. But I admit that very few people were involved with with that decision. So it would be good to hear from the rest of the work group. Do they feel that that the or capability is is a core thing that's needed, or do they think we should remove it? I think the the bar should be higher now to remove it. We should really get a very clear signal from the work group to remove it because, you know, we we thought that we there was a there was a good signal to to add it. So let's keep the aggregation side out of it and first ask a question to the work group. Is is the core functionality of having or useful? And I think the dominant use case that I can think of would be the property filters. You know, if you wanted to have a property filter of temperature or pressure, you know, exceeding some limit or in some range, that that would be the dominant case that I could see. Having property filters on different properties, and and you wanna be able to order those from the same subscriber, not different subscribers. Then, of course, there's the aggregation case of different subscribers ask for different filters, and they really wants to be able to do oars in order to propagate a single filter upstream and not have to receive duplicate objects. So I think we should ask, you know, two separate things to the work of. Is the core functionality useful for a single subscriber? And then two, is the due due duplication for aggregation a necessary thing? And I think that that signal will help us decide whether or not to keep it or remove it.
[00:17:30] Ian Swett: Cullen? Your turn.
[00:17:32] Cullen Jennings: I so just a couple that makes sense how Mo frames frames this. And to answer so there's sort of three things I had on this was, one is, yes, I think there is good use cases for it. We've we've talked about over times. But the the number the the second one is the deduplication is incredibly trivial. Right? It's just when you when you have an object, you decide whether to forward it or not. It's not it's not like you're saving objects and doing some really complex deduplication. You're just trying to decide if it matches the filter at the time it was described. So it's it's not a complexity implement issue. And then the the third one was, I anytime you have a filters that don't cover, like, you know, only do greater than, but don't do less than, like, you know, a year later, you're adding the other thing. And this seems like or seems like really would be challenging to add in later if we didn't do it from the beginning. So I I think that we will eventually end up with it and I think it'd be one of those things that would be easier to do from the beginning than add in later.
[00:18:29] Ian Swett: K. Thanks. Let me proceed forward. So this is something I observed when I was trying to review a different PR. But I think updating or filter sets today is somewhat complex. And so regardless of what we do, I think we might wanna, like, tweak the framing. And let me kind of lay out why I think that's true. So if the length is zero, the filter is entirely removed. So let's, like, only look at object property filter for the moment because it's, you know, an obvious example, and, you know, I I think it's very useful. And so if the length is zero, it removes all object property filters because the set ID is after the blank. And if the length is not zero, a set ID is specified. And so only that set ID is overwritten. And so I believe to why don't I
[00:19:23] Mo Zanaty: just Hold on just a second. You know, let me clarify that that that that's incorrect. The the there's a the section in range filters says and this was something Alan requested, that if you do a replacement of a filter parameter, it's the entire parameter, including all sets. So if you had previous sets before, you have to respecify them if you wanted to keep them. We did used to have the ability to, if the length was one the original PR set, if the length is one, that means only set ID is available is encoded. And then you could you could individually remove a single set ID. And Alan argued that was too complex. Let's just blow away the entire filter parameter with length zero. And if you specify anything that's nonzero, you have to put everything there, and it completely replaces all the filters that were on that parameter before. That was something Alan wanted as a as a change.
[00:20:17] Ian Swett: So that's what we did. Never mind. I guess this is just an editorial comment because I did not figure that out from text.
[00:20:25] Mo Zanaty: It's probably confusing because you probably have the the past memory of we had we had this ability to do exactly what you're describing is only specifying one single set to replace, but we removed that in a in a later in the final merged PR, we removed that.
[00:20:40] Ian Swett: Yeah. I think that was probably an improvement because if you see here, I think the only solution if you try to if you are only able to update one at once is you end up, like, nuking all of them and adding back all the ones you want in, like, a single request update, which is pretty weird. So, I think it was probably a good choice to do what you're saying.
[00:21:03] Mo Zanaty: Let Alan take the credit. He's the one that wanted to blow them all away for the replace. Okay.
[00:21:09] Ian Swett: Yeah. I'll have to think about that more. Anyway, I still think that logic of how to update these just for our framing and everything perspective is a little complicated, partially because we have we have different types of filters and some are on properties and some aren't, but that's kind of a detail. But, like, the the set is not a unit that's, like, updated at once. And so it's not like I'm updating all the filters associated with a given set. It's like I'm updating this filter, which happens to have the set ID and this filter, and so they're they're not close to each other from, like, a
[00:21:46] Mo Zanaty: It's an indirect
[00:21:46] Cullen Jennings: linking a little weird. But
[00:21:48] Mo Zanaty: Yeah. The set ID is an indirect linking. I agree that it's a little confusing because it would conceptually be maybe more proper to lay everything out in terms of the entire set. Here's entire set zero. It's all of these other, you know, filter parameters. Here's the entire set one, all these filter parameters. Unfortunately, the way we have things encoded, though, you know, you you have to put the parameter type first. And so that's the Sure. That's filter parameter. It has to be delta encoded, so you can't even you have no flexibility. You have to put all of the same parameters, the the same filter types together. So you can't have set zero, all the different all the different types of filters on set zero first. You have to put all of the types of filters first. Yeah. Because because they have to be delta encoded. So Thanks thanks for
[00:22:32] Ian Swett: clarifying for me, though. Although I did misunderstand the text. Okay. So when I'll follow back up, I guess, onto SPR to, like, try to update the editorial text. So, Martin.
[00:22:45] Martin Duke: As an individual, I share the sadness of the two ways to do this, but it seems like the or thing is, like, strictly superior to having two separate subscribes that cover two different ranges. And I would favor strong language, discouraging multiple subscriptions. Like, endpoints should close one subscription before starting another one to the same track. This should be good. You can't actually enforce it because, you know, race conditions, and you don't wanna kill a connection because a reset is lost or something like that. But I think we thought when we were talking about however many weeks ago, we talked about mobile subscriptions. We kinda said, look. Like, bad things are gonna happen, and you're gonna have duplication. You just have to deal, like, so don't do that. So I I think I'm fine making I'm glad that we're providing better ways. Even it's not I am about multiple techniques. I'm glad that we're eliminating excuses to have multiple concurrent subscriptions over a long span. And I think adding more language to make that explicitly, like, a bad idea is good.
[00:24:02] Ian Swett: K. That that's a logically consistent viewpoint. Okay. How about that? Then I will drop my recommendation on the next slide, but I will put up the next slide because I wanna talk about it. Alright. So much forward. We could do nothing. I guess the status quo of the syntax is actually better than I thought. Sorry, Mo, for misunderstanding it. Either way, yeah, I that text is a little difficult to read. I think we probably need an entire dedicated section on set ID or functionality, because it's it's very subtle. Another option is which is what this issue was, which was the removed set ID functionality for now. It sounds like from a few different perspectives, there are people who would rather not do that, partially because we think we'll end up with that eventually and partially because, as Martin said, if you're doing aggregation upstream, you know, maybe we should recommend not to have overlapping subscriptions. And, you know, the two subscriptions for the same track is, like, more of a race condition than a persistent state of being. One another option is to adjust the wire format to make filter sets easier to manage. I don't have a specific proposal at the moment. It is a little awkward, but it's not the worst. Another is to I guess, there's a five too, which is, like, add set ID to location filter. But, like, I guess there's a key question here, which is, like, should location filter have a set ID as well? Because every other filter does now. Location filter is added relatively recently. So the fact that it doesn't is just kind of the nature of, its recent addition. But, do people if we really think we want to allow all aggregation upstream to be done with this, it seems like we would want location filter to be included. That's I see some comments on chat. Does anyone wanna speak up about what they would prefer, what they would like the editors and or Moe and others to try to make happen or not happen? Go for it, Omar.
[00:26:20] Mo Zanaty: Yeah. What I see from a quick read of the chat is I see a couple of arguments that we need we need the or. So retain the or functionality, and that's from from Luke and and you. And so I haven't seen any objection. I haven't seen anyone asking for removing the the or on the chat. A question about changing the text or changing the wire format, nobody's been talking about if even if we keep it, what what is a better way to spell it, or what is a better way to describe it in the text? And I think we we do have we do have the we do have the one open issue on clarifying the text, so we can probably use that issue to to make some changes here too. But changing the wire format, I'm a little more hesitant too because, you know, the the we went through a lot of different iterations on this, and and I think we came up with the best compromise in the end. The only other way if the sets are the are the point of confusion and and wanting to have them as a as a, you know, a a structure on their own altogether, the entire set together, then you could rewrite all of the filter parameters as sets rather than, you know, object property filter or or subgroup filter. You say just set filter and, you know, set zero filter, set one filter. And then within this ins inside of the set filter, you would say, I'm filtering object properties or I'm filtering, you know, subgroups or something like that. So I I think that kind of two layered, you know, approach with the set being the primary property the the the primary parameter type and then the the the filter type being a a subtype, I think that's that would make the sets more clear, but I think it would make the actual filters more confusing. I think it's conceptually easier the way the things are laid out now. You have a subgroup filter. You have a property filter. You know, you you have an object ID filter. I think it's a little clearer to lay them out that way than just to say you have a set filter, which is kind of a, you know, an abstract thing that nobody's gonna say, what the hell is a set filter? And then they have to look at the subtypes to figure out, oh, they mean filtering subgroups. They mean filtering object properties, track properties. So I think the way that we have it now is is more intuitive for for readers.
[00:28:54] Ian Swett: To to make an argument against that, that's which is a relatively recent one, which is, like, it's fairly easy. It seems to, like, forget to add set ID and describe how set ID works in a new filter. And so I think, like, location filter is the example that does not have set ID right now. And if we really want these to be, like, filter sets, it seems like location filter should be part of it and should have set ID. And if I had add WASM filter, then, you know, I I presumably would want set ID in that. But, like, I guess my point is, like, having a simple filter and then making the set functionality, like, the composable bit has the benefit that, like, everyone who adds a new filter of some sort doesn't need to do something different. I don't know. It would certainly make it easier to figure out what's going on, I have to say. Like, having a filter set parameter that, like, has a nested thing as much as I hate nesting. Like, it would make it much clearer as to, like, how functionality works because I mean, I mean, maybe it's just a spelling thing. So maybe it doesn't matter, but I think it would for readers, it's definitely more readable.
[00:30:10] Mo Zanaty: Just to clarify one thing on the location filter. Originally, the location in the very, very first filters PR 1401, location filter was exactly like all the other filters. It supported multiple ranges, and then it would've it would've supported sets, but we added sets later. 1401 didn't have sets. But the the when we removed the location filter from 1401 and then we came to write the for the location filter PR, the feeling was that it shouldn't it definitely should not be controlled by a setup option. It has to be, you know, always enforced and mandatory by publishers and subscribers to to be able to interpret and and use. So it was already different there. And then people questioned whether there's any reason to have multiple ranges in it, and it seemed clear it seemed clear just to have a single range. And then being able to combine it with sets also didn't make a lot of sense because it seemed like the location would always trump everything. The low the you're asking for some specific locations that trumps you know, that's always gonna be an end condition over all the other filter criteria that you have. So it seems like that would always trump things, whereas the the the sets are a way to do ors. And it didn't seem like you wanna say, you know, I want, you know, this group or I want, you know, things that are red. It just it didn't seem it didn't seem like it was a a use case. So that's why we ended up with location filter spelled differently than everything else. Doesn't have sets IDs. It's not it's not optional. You can't you can't not do it. It's not controlled by the setup option, max filter ranges, and and it doesn't have multiple ranges. It only has a single range, single start and end.
[00:32:01] Ian Swett: Okay. Alright. I mean, I'm not that unhappy with the status quo. I just kinda wanted to point out for everyone to kinda figure out, like, what expectations they have. I don't know if not having location filter limits how people can aggregate in relays upstream because it does it mean that if I have two subscriptions, then I can aggregate all my filters except for location filter. Does that cause people problems? I don't know. I guess I was trying to put that out there. Maybe it doesn't, and this is largely just an editorial resolution. Or let me say that out loud. My understanding from the group right now is maybe the spelling is not perfect, but no one has a better suggestion. Everyone agrees that we could do some editorial work to improve the text. So it's already has a PR to do that. Maybe we need more. And, otherwise, we're, like, largely happy with the feature set as it exists today. Is that the correct read I'm getting from the group? Okay. I wanna move forward with that assumption. People can always change their mind with flare, but I will move forward with that assumption and largely focus on just, trying to make this easier to understand for readers. 1,800. News case doesn't have parameters. I don't know. Luke, did you wanna talk about this, or do you want me to talk about it?
[00:33:50] Luke Curley: I don't care. Whatever you want.
[00:33:51] Ian Swett: Sure. I'll I'll I'll give you the spiel, which is publishing space has parameters. Namespace does not. That's basically the big difference between the two messages. You know, it was an intentional choice to make namespace as small as possible, but maybe we made it too small. We also didn't, I think, have use cases for many parameters in namespace at the time. Publish namespace had off, and I think namespace, we didn't really have any brands. So it was kind of unclear whether we needed them. But I think Luke has some use cases where parameters might make sense, so I'll hand it off to him.
[00:34:28] Luke Curley: Yeah. I won't I won't spend too long on them because they're I don't wanna argue for each extension. But, basically, when there's multiple connections and you ask both sides, like, hey. What namespaces do you have? You need to figure out which connection you route a subscription to. So you need some information about, oh, you know, this connection has this namespace, and this one has this one, and how do they differ. So it's mostly what my extensions focus on, like, you know, what's the start time, like, so you know which one's newer, An etag to know if they're the same thing. Like, are they seamless, or they should be treated as separate? And I'm using custom hops. So I know that if I'm connecting to somebody peer to peer versus using a CDN, I wanna use the peer to peer connection, you know, ideally, stuff like that. So that's mostly what it gets down to. And right now, all my, extensions have to spell out if you, you know, use SUBSCRIBE_NAMESPACE and add parameters to to the namespace message because only published namespace has it.
[00:35:34] Ian Swett: Martin, go for it.
[00:35:36] Martin Duke: Yeah. As an individual, I I thought we decided that if you get if two upstreams advertise in the space, you're actually supposed to subscribe to both of them, and therefore, like, distinguishing between them doesn't matter. Is that not where the current draft is?
[00:35:57] Luke Curley: So I think fetch, you have to pick one. Because I remember arguing with Alan about this. Right. Describe, you're supposed to be both for multi publisher with, but I I don't necessarily agree with that.
[00:36:10] Martin Duke: Okay. So, like, as an implementer, this makes me incredibly sad, not because adding the parameters is a big deal, but now we've opened up REQUEST_UPDATE on specific namespaces, which reopens all the weird, like, sequential REQUEST_UPDATE things that we'd put to bed. And this this is that to me is very scary and seems like an issue fountain waiting to happen if we change that. Like, we could just ban REQUEST_UPDATE on the published side of subscribed namespace, I
[00:36:51] Victor Vasiliev: guess,
[00:36:52] Martin Duke: But that it's very scary to me.
[00:36:57] Ian Swett: I mean, you could do something like we did with the interlateral, you know, updating of parameters where we just tell you, like, what the new values are, and there's no, like, REQUEST_UPDATE, REQUEST_OK kind of back and forth.
[00:37:12] Martin Duke: Yeah. I like pop help us notify, which I think is what you're talking about, what might actually solve that that would my implementer concern that this is a friend is nightmare, would be, I believe, addressed by using PUBLISH_NOTIFY and set REQUEST_UPDATE. Thanks.
[00:37:31] Ian Swett: Sure. Cullen.
[00:37:34] Cullen Jennings: I mean, as already been pointed out that they you know, the subscribe ones need to be multiple. But, I mean, Luke could easily solve that by having a parameter that says, you know, route these differently than normal. Right? So, Luke, I mean, I I think your use cases, like, this type of interior routing protocol versus an exterior routing protocol type things terrifies me as a way to do this. But that's a comment about what you wanna do with these, not not not the actual idea of adding parameters and being able to do this type of thing. So, like, I I think it's just I think sensibility slip up that we didn't have parameters on namespaces. I suspect I suspect we need to add this. Like, I I I support that idea. Yeah. And the the specific use cases that we're talking about here and things, that's well, that's a separate draft and a separate issue. Question is, do we have extensibility here? And I think the answer should be yes.
[00:38:25] Ian Swett: Thanks. No. I think it's a fair it's a fair statement. I mean, I think we oh, yeah. Basically, I think we might have gone a little bit too far. I think the old approach is a little bit too complicated, and, obviously, we wanted to get rid of that. And I think if we allow updates per Martin's comment, we might wanna do something like I I might it wouldn't be published, notified maybe. Maybe I don't know how we'd spell it, but the point is, like, it would be unilateral. Like, these are just the new brands. I think we need to be careful about what how parameters are propagated probably. Off is one I assume we would not wanna propagate. Do we have any other parameters that can go and publish new space today besides off? I can't remember.
[00:39:13] Cullen Jennings: And this is one of the things about the draft is there's no easy way to answer that question you just asked. It comes up a lot, so we should probably fix
[00:39:20] Ian Swett: too. I mean yeah. I mean, that's like a appendix editorially thing, but, yes, that would be good to we have an editorial meeting, I think, next Monday and Tuesday to try to fix as many things like that as possible in person. So okay. Then I am hearing from the group that adding parameters back in both makes the draft more consistent in the sense that published namespace and publish. Oh, sorry. And namespace, look more similar from a wire from our perspective as well as it seems like a reasonable extensibility point. Does anyone object to that conclusion? Okay. Ah, yes. And we're not doing REQUEST_UPDATE in SUBSCRIBE_NAMESPACE. Well, at least we're not doing you can't REQUEST_UPDATE in SUBSCRIBE_NAMESPACE. I guess you could REQUEST_UPDATE in SUBSCRIBE_NAMESPACE. So Yep. Thank you, Martin. Those are all the slides I had. We can either end early, or there were a handful of these discussion issues I can present if people wanna talk to them. I will go in that direction and then oh, I need stop slots. Perfect. Alright. First two we've come through. Unless people wanna discuss it, I'm not gonna talk about off today because there's an off design team for that. Cullen, would we you'd be happy to walk us through this or the updating cash fields properties 17 o three? Okay. It's that's okay.
[00:41:53] Cullen Jennings: No. I can read it along with the rest of the group. It be the truth, the matter where I am.
[00:42:01] Ian Swett: Okay. I I mean, I can I'm trying to remember right now as well. I was it's hopping in. Apologize.
[00:42:12] Cullen Jennings: Yeah. I mean, I I guess on the cache one, it was just simply, like, I I think that we should just you you know, we we have this idea that the objects and their properties, they're immutable, and trying to make it so we can update caches seems like a whole new design path that would be a large effort.
[00:42:35] Ian Swett: I I
[00:42:35] Cullen Jennings: mean, this this is how we get eventual consistency in our current relay system with its incredibly small design. So I I don't know. Okay.
[00:42:44] Ian Swett: I think alright. So this might be a matter of just tweaking the existing text because I think it kind of says you have to do something. Okay. I'll go back. Oh, and then let me reread. I think I think I think conceptually, I agree with you. I think it's just a matter of, like, writing something down that's, like, you have to do something if you get two different values and, like, what do you do kind of thing.
[00:43:07] Cullen Jennings: Yeah. Yeah. Right. Right. And yeah. Yeah. So it I mean, we need to write down something there, but I don't think we should try and design a I I think that we should basically be you like, you know, ignore the later one or whatever. Right?
[00:43:17] Ian Swett: Okay. And then the other one is the nonexist exist nonexist sort of problem.
[00:43:23] Cullen Jennings: Well, this seems to be like there's some really I think that we had some I think we had some confusion of people of how the protocol worked at various times. We had some older texts and some things that could happen where you could get up, where you could get into a state where you thought an object didn't exist, and then later find out it didn't it does exist. And, I mean, this just this should be a protocol violation. This categorically cannot happen. Like, the the you know, if the original publisher has lost the objects that it sent earlier and it can no longer respond to them with a fetch, that's fine. It doesn't have to respond to them, but it can't claim they don't exist if it previously sent them. That's a protocol error. That's basically the heart of this one. Okay. And anything else, it's impossible to design a system that doesn't require every request to go back the origin every single time. Like, if you find out an object doesn't exist, you should never have to go back to the origin and ask whether it exists again.
[00:44:21] Victor Vasiliev: Right. Yeah. But that's the current state because it's only if it does exist, you cannot transition to you can transition to nonexistent. It cannot transition from nonexistent to existence.
[00:44:36] Cullen Jennings: Right. Fair. But, I mean, I think there was there was yes. Exactly. So we're we're saying the same thing, Victor.
[00:44:43] Ian Swett: Yeah. So
[00:44:44] Martin Duke: I I think this I I, like, I agree this should never happen, but I think this falls in the category of malformed tracks, not protocol errors because I
[00:44:54] Ian Swett: Fair.
[00:44:54] Martin Duke: Yeah. It it seems like this is a like, if you kill the session, then you have weird upstream poisoning problems, right, where, like, the original publisher violates the thing, the relays, and smart enough to see it as violating the thing, and then you kill the the multipurpose connection to the relay, which is complete no go or worse, like the upstream connection. So, yeah, malformed track rather than port fire. But other than that, yes.
[00:45:16] Cullen Jennings: Yeah. Martin, you're thinking I agree with you totally. I wasn't thinking about that. You're right. I I thanks. Yeah.
[00:45:25] Ian Swett: That make that makes sense. Yes. I I think there's always a possibility some relay, like, goes offline for some period of time and pops up later and starts shoving out data that is stale or something. But okay. So think Malforb track probably in this case is is sensible in the sense that, you know, this person is publishing information to you that you think it shouldn't be publishing to you because it should have been timed out in the past. Victor?
[00:45:53] Victor Vasiliev: I'm not sure you what you're saying is sensible, but what's currently in the draft is definitely sensible. And I I have no idea what the proposed changes, so I cannot comment. But I'm pointing out that what's currently in the draft is sensible in the sense that the object has, like, roughly three states, unknowns, and it transitioned to exist, and then it's gonna transition to does not exist. And it cannot go backwards anywhere on that path, but it is expected in most cases that would go forward towards those paths.
[00:46:30] Cullen Jennings: So so, Victor, the the exact text in the bug well, either it's up on the screen there is an endpoint can receive an object after it's already recorded the object does not exist. And what like, I just think it's that one line is, like like like, that's that's
[00:46:47] Victor Vasiliev: Oh, yes. That's why it's really weird. It's mostly it's supposed to address race conditions. I'm not sure what it what are the race conditions. At some point, someone claims that there are.
[00:47:04] Cullen Jennings: And I think that those claims that there was race conditions turned out not like it won't happen in a case where it isn't a protocol violet. Like, worse if everything's followed the spec that there's no race condition where that happens that I'm aware of, and we're just in a lot of discussion about that. So that and so so look, I my comment there says it should be a protocol error. Like, totally convinced me I'm wrong about that. It should be a, you know, a malformed track. But I I think the only thing is, like, my only proposed change is to just change it that line to say that that, you know, doesn't happen. And if and if it does happen, then it's a malformed track. That's my proposed change. That work for you, Victor? Does that make sense?
[00:48:09] Victor Vasiliev: That sounds reasonable to me because I have no idea what those risk conditions are. And if Right.
[00:48:16] Ian Swett: Okay. Sorry. I was muted, but I was saying, I I think that seems like a reasonable direction going. And I think I, Victor, and others can reread the surrounding text and just try to make sure, like, all this is clear and hopefully come up with a PR that is not particularly large that kind of makes this clear and and addresses it. So
[00:48:37] Cullen Jennings: Yeah. I think it may be a three word PR PR. But yeah. Perfect. Thank you.
[00:48:41] Ian Swett: Ideally. Cool. Okay. And then in that case, I'm not sure does anyone have anything else on this list they would like to discuss? This if you wanna discuss off, you can, but I didn't have anything prepared for auth. Otherwise, I think we're done for today, maybe. I'm not sure.
[00:49:11] Cullen Jennings: I'm dropping off in ten minutes whether we're done or not. So done would be awesome for me.
[00:49:15] Ian Swett: Alright. I will note that there's a PR up for this.
[00:49:18] Luke Curley: I thought
[00:49:20] Ian Swett: it was interesting to review. If people have time, please review it. Yes. No. Go for it.
[00:49:28] Mo Zanaty: Yeah. Not from this list, but the the the top tracks PR, eighteen thirty. I was hoping to be able to get that updated to use the new functionality from, I believe, it's 1820, but that hasn't landed yet. Right? So can can we try to get the PUBLISH_NOTIFY landed soon? Because I would like to try to get that functionality added to the top tracks filter because I believe that would be a useful addition to reduce the state change messages, cut the control traffic in half whenever there's a track switch. Just to notify instead of REQUEST_UPDATE and OK. I don't hear you, Ian. If is anybody else not here?
[00:50:19] Ian Swett: I should not mute myself. I apologize. I just was trying to avoid echo. Yes. That was merged, it looks like two weeks ago. Can you see my screen? Eighteen twenty.
[00:50:32] Mo Zanaty: Okay. Oh, it was merged. Okay.
[00:50:34] Ian Swett: Yep. So you you should now be able to update your PR. But Okay. Great. Thank you for asking. Yes. I was gonna actually point people to top tracks, but I I think it had I think last time I checked, it hadn't been updated with that, and so that's what I was waiting for.
[00:50:50] Mo Zanaty: Okay. I thought I thought we were I thought that was one of the topics for today's meeting. I didn't realize it already merged. Great that it emerged. I'll I'll start using it.
[00:51:00] Ian Swett: Great. Awesome. Thanks, Mo. And thanks for bringing it up because there's no reason for you to block on things that, thankfully, are actually making progress. And the good news is, like, of the things that need discussion, a good number are off. You know, other things have PRs. It's feeling like of the major issues, we're really getting down to a much more manageable number. There's a ton of editorial issues. Hopefully, we will be able to make progress on those next week when we're all together in person. And by we, I mean myself, Victor, Alan. And with that, I I will return it to the chairs. And Alright. Your time.
[00:51:40] Martin Duke: You, Ian. Thanks to everyone who participated today. Our next meeting is in fifteen days. It is gonna be on a Tuesday because of US Labor Day. Happy Labor Day to all those all those celebrate, and we will see you then.