Session Date/Time: 21 Sep 2026 16:30
[00:00:15] Martin Duke: It's 09:30AM. Welcome everyone to the meet you over quick virtual interim for September 21. As always, this session is being recorded. This is the IETF Note Well. If you are unfamiliar with what it talks about, which is our code of conduct, the IPR, and other legal implications of you participating in this meeting, please do so at your earliest convenience. There's a QR code you can scan to access all this information, or you can type ietf.org into your favorite search engine. You've already figured out how to get into Meetecho. If you wish to join the discussion queue, please use the raise hand button at the bottom of your screen. If you are going to participate, I I strongly recommend that you use a headset as I have. The echo cancellation properties of this tool are not great. There's also about one second of latency between unmuting and actually us being able to hear you. So please take that into account when you press buttons on this device. At the same time k. Doesn't matter. Never mind. Okay. Here's some upcoming dates. We just finished the draft 19 consensus call, and I I actually ought to close that. So you have, I guess, a a moment or two to maybe an hour before I actually about ninety minutes before I actually go and that that consensus call, which technically concluded on Friday, the way to register your your issues in any particular draft diff is to file an issue in the GitHub. Past the deadline, issues will be marked in such a way so as we're gonna give them lower priority. There's I'm not gonna go through all the details of that later. If you're going to attend the hybrid interim in Seattle, please add your name to the Wiki by September 26. Many of you that I expect to be there have not done so. There's some basic logistic information about where the meeting is, hotel options, etcetera on the Wiki. You can find it if you go to the the GitHub, and there's a Wiki tab, and you can find the information there. If you would like to be in the agenda for Seattle Meeting, please email the chairs no later than September 29. I have a fairly long email about about that. It's on the list. Our focus is on MoQT and not the other drafts. We are gonna have an IETF 121 meeting where we traditionally go through all the other drafts the work group is working on. That said, I don't wish to penalize work that could be in the MoQT draft, but it's not for one reason or another. So if you have something like the DOS draft, like top end, like s SSTS, and you wanted to talk through technical issues in Seattle, we are happy to give you time for that. That said, I'm not really interested the chairs are not really interested in talks that are just pitching, getting the document into the MoQT. We can have that discussion offline. As chairs, we also owe you a, like, an a list discussion about that, but we don't wanna use agenda time for these sorts of document arrangement discussions. Alright. Moving on. We the chairs have also proposed one interim meeting between Seattle and San Francisco. It's October 26. If that you have a problem with that date, please email the list or the chairs. We then have the actual hybrid interim that I've been talking about for the last ten minutes in Seattle, twelve fifteen October. First two days are interop. The second two days are issue discussion. There's a possibility we'll have another hybrid interim in February around Mile High Video in the Denver area as we have traditionally. Part of me wants not have that meeting, but I think chances are good that we will have that meeting. If you are able to host a meeting in the Denver area in February, we would be grateful for, possible venues in that that that are available at that time. So please be prepared to talk about that in February. I'm sorry. In the sea at the Seattle meeting, traditionally, we talk about a next potential hybrid interim meeting. So if you are able to host in the Denver area, please do a little initial research into that prior to the Seattle meeting, and we can discuss that offline and then later in the session about possible venues. Will has asked the question. Let me see if I can get the the actual
[00:05:17] Cullen Jennings: oh, boy.
[00:05:18] Martin Duke: Let's see. Okay. You're working at the Mock Transport repo, and it is in the work group materials repo, I think, is the problem. So let me find that right now. There it is. There it is. I'm gonna put it in the chat. This is it's actually under the working group materials repo rather than the moq-transport repo, which maybe has confused some people. Anyway, there it is. Okay. So once again, in Seattle, if you can possibly host in Denver area, please, come ready with some basic information about that, and we can start that discussion. As I just mentioned, we have a tentative virtual interim on the October 26. And then, the last thing on the calendar right now is the I t one twenty seven in San Francisco, which is the appropriate venue for discussion of drafts that are not intimately really integrated with Moq-t. Any questions about all this? Yes, Cullen. Thank you. Thank you for that. That would be great if you if we could just be prepared to talk about that and, like, available dates and stuff in in in Seattle. Alrighty. Moving on. This is the agenda today. Alan sent this out to the list last week. Ian will Alan is actually, away for the first thirty minutes or so, but Ian will take the lead on this discussion until he arrives. And, this is the last slide. So, Ian, you can take it away. As I understand, you want to share your screen. And, yes, there's this request, and you have it.
[00:07:18] Ian Swett: Wonderful. Yeah. I didn't update that many things, but I did reorder a few things, especially since Alan is not gonna be available for a few minutes. Perfect. Okay. Good. We should draft 21. Based on the discussion, It is 99 over 99% just move text and kind of the updates and referential updates to, like, make that work. So it is it is not necessarily sensical. It does not have the changes to make it read plausibly, but it does you know, it is the absolute minimum just to make sure you understand, like, what's moved. We plan to cut 22 today ish. That is an effort to make some of that text that we moved make more sense. Sometimes it's split sections. Sometimes it, you know, moves text that all is on one topic like fetch into one area. But we believe it's still wire compatible, and any changes to normative language were merely cases where, like, in one case, it said may and the other one said must, and, you know, the May was from kinda leftover from previous times or something like that. But, there were clarifications. So if anything is surprising, please file an issue. Yeah. K. So in terms of the next draft that actually has functional changes, you know, I think we'd like input on when you would like us to cut that. We can do it a little bit before Seattle, like, week before. It's quite soon. We can cut it, you know, near or few days before the San Francisco IETf draft deadline. Something else. Do people have thoughts? Cullen, go for it.
[00:09:27] Cullen Jennings: I I was just gonna say, you know, both. Like, whatever is done, cut like, the drafts are free. So, I mean, even I I'm you you know, whatever the editors have ready at, you know, a week before Seattle and the for the San Francisco deadline, cut them both.
[00:09:41] Ian Swett: Okay. And the one the if we cut one a week before Seattle, it probably will not have very much, but that might be okay. Because maybe the things that that are in there are going to be kind of incremental improvements and clarifications to the existing draft. I don't know. So, well, maybe we should wait and see and see if there's actually enough in there to, like, make it worthwhile. I'm not
[00:10:02] Cullen Jennings: sure. Yeah.
[00:10:04] Ian Swett: Fair enough.
[00:10:05] Martin Duke: So a dumb question. Draft 22 is functionally similar to draft 20?
[00:10:14] Ian Swett: Yes.
[00:10:15] Martin Duke: Okay. Yep. So They should be in
[00:10:17] Ian Swett: your app at all.
[00:10:18] Martin Duke: Yep. Do do we just want so, like, the only wire difference then is gonna be the ALPN. Do we just wanna make the interrupt target draft 22? Is there any reason not to do that just to feel a little more forward? I I guess it really doesn't matter.
[00:10:32] Ian Swett: It's a fair suggestion, actually. I mean, I I think that's a question for other folks who
[00:10:39] Martin Duke: Mike typed something adjacent but similar. Yeah. Okay. Mike, if if you don't have the strong opinion out of this, I'm just gonna declare that draft 22 is the target just because we need to agree on an ALPN.
[00:10:58] Cullen Jennings: I thought last meeting we agreed that we were going to do wasn't it two drafts we were gonna do as the interop target for this interop?
[00:11:07] Martin Duke: So, yeah, so people like me are still stuck on 18.
[00:11:11] Cullen Jennings: It's actually eighteen and twenty two are the two interop targets.
[00:11:14] Martin Duke: Correct. It's
[00:11:15] Cullen Jennings: Got it.
[00:11:15] Martin Duke: If they're all functioning similar, let's just move the number forward from you know, I don't know. I guess it doesn't really matter. But It I guess we did. We just we it doesn't matter. We need to decide. So I'm gonna declare 22 unless Mike has something to say.
[00:11:31] Ian Swett: I mean, if we're gonna file new issues, I'd rather have interrupt people file issues against 22 than 20 in case, like, any of the clarifications actually were material. So
[00:11:44] Martin Duke: Mike, you're still showing your little you're I guess you're still on audio. Are you trying to say something? No. Okay. Everyone loves 22. Let let it let it be it is now official. Draft '22 is the target. And
[00:12:02] Ian Swett: I guess the others wanna talk about whether we wanna bother to cut anything before Seattle. As I said, right now, there's literally nothing new that has gone in since '20. But, anyway, we can see what comes out of this discussion as well that we have today. Alright. Let's move on. And oh, that's the wrong
[00:12:20] Martin Duke: slide. K.
[00:12:22] Ian Swett: Alright. I actually reinserted this in because I thought maybe it would be easy at least to resolve one way or the other. Currently, the location filter that was recently added has a length in bytes, which allows you to kind of determine how many variants are present. There were some commentary that, like, this is sort of an unusual format. The proposal is to potentially change it to an enum. And I I wanna point out kind of why this originally was not an enum, which is at the time that the location filter was originally designed. Parameters were either, like, length limited, like, how to look, you know, lengthen and blob, or they were of aren't. And those are the only two options. At some point, we changed parameters to be kind of, you know, every parameter describes, like, what its format is. And so now we can use a slightly more complicated data structure if we want. The I think this makes it a little bit easier to parse to use an enum. It also makes it maybe a little bit more accessible, but the main change is just it it's a good I think it'd be a good bit easier to read. But, anyway, I don't have a PR for this yet, but I want to put this in front of everyone before we made this change. This might be an example of something we could cut a draft for because at this point, I think probably no one's actually implemented the new location filter stuff. I don't know if people wanna implement it one day wait and then change it or if people have thoughts on that. So, Martin, you're on the queue first. Alan, you're on the queue first.
[00:14:08] Alan Frindell: Hey. Sorry. I'm driving. So, I I think maybe I slightly prefer the, like, enum ish spelling, and I'd put a proposal in the issue. Maybe it's what you have there. But, like, if you if you spell enum kind of right, then the value is also the number of warrants you expect, at least in the form we currently have now. I think my main objection is that I don't wanna have it's really annoying if we like, I think nineteen and twenty and twenty one and twenty two will all have the length version. And then, you know, then if we cut 23 and it has the eNum version, those of us who support multiple versions, it's just annoying. I'd sort of rather not have an official interrupt target that has I think we already do because 20 has it. So, anyway, I just don't wanna I prefer not to support two, but I'm it's not the end of the world.
[00:15:07] Ian Swett: K. Thanks. Yeah. No. I mean, I think it'd be better to do this sooner rather than later if we're gonna do it, which is kinda why I put it first. Just, but I don't know how to, like, fix that pain at the moment. I mean, if we really care to, we could put this into '22 when, since we're declaring that the interrupt target. But, you know, I'd want some feedback from people here as to whether that's what they want.
[00:15:30] Martin Duke: As an individual and as an implementer, I, we're not gonna lie down on the road over this one way or the other. But one thing I like about the present formulation is that it is impossible to express an invalid. That's not true. But there are relatively fewer cases of of invalid location filters, whereas, like, you know, we have to do a test for, like, the value is greater than five if if we use this unknown thing, which is annoying. It's not critical, but it but it is you know, it's just more stuff.
[00:16:03] Ian Swett: There are some actual illegal values in the current one, but, yes, it's I mean, you're changing around which which things end up being illegal, but there's a few comments, I think, on the issue about this. Mo?
[00:16:18] Mo Zanaty: Yeah. I think the only the only pain point I heard when we did the location filter change in the first place was none of these things. It was only the last one, largest object. The fact that you had a special code point for largest object was weird. I don't remember anybody objecting that it was ambiguous whether you left the end off what that meant. If you left the end object off what that meant. That clearly meant that there was no end object. If you left off the end group and the end object, that clearly meant there was no end group and no end object. So I don't remember anybody complaining about whether it was, know, one or two or three or four varints being the problem. The only problem I remember was largest object having a special encoding of zero zero. That was was the only thing I remember as as a real problem. And now we also have this forward parameter being proposed as a as a location filter instead of an explicit thing. That would be another one. That would be, you know, maybe six would be you know, paused or not paused. So those are the two things I think are top of mind for people that they're they're weird. They they don't match the spirit of the location filter. It's not a start group and an end group. It's some, you know, it's some special hard coded code point that means zero zero means largest object and something else will mean, you know, end before start means paused. Those are the two things I think are a problem. I don't think these other ones, you know, absolute start versus absolute range versus a lot of start. I don't think those were ever a problem.
[00:17:44] Ian Swett: Yeah. Yeah. I agree. Most of the concern is about larger topic being weird. Okay. Alan?
[00:17:52] Alan Frindell: Yeah. I just responded to Martin's point, but I think you already covered which is that I I think I tried to think about it. I think the number of error cases is the same either way. They're just different errors. And so, like, I don't know that that weighs heavily on what we decide to do.
[00:18:13] Ian Swett: Well, either way, I'll I or someone will create a PR in the near future, we can decide. Let me go to next slide. Yes. So this is the forward, filter. We landed the editorial change to talk about paused subscriptions instead of just saying forward equals zero one everywhere. I think it makes the language a lot clearer, and especially with the acknowledgement that, you know, you can kind of stop the subscription in other ways now if you really want to. But that is not a functional change. There's a PR pending that kinda removes it and says you can use the location filter. We could add a variant where the location filter instead of expressing something, which is, like, I believe the start is after the end is the way we express nothing today. We can add a, you know, value if we did the email thing. Thoughts? Has anyone read the new PR? Other things. Martin?
[00:19:12] Martin Duke: I'm not, but I wanna ask a question related to the pre so are are these PRs potentially in '22? Did we just make a huge mistake by making that the interrupt target? Or is all these all these is everything under discussion here post '22?
[00:19:30] Ian Swett: The intent at the moment is that everything here is post '22. Is what? Because is post '22 because '22 is basically what's is all editorial and non wire format changes.
[00:19:41] Martin Duke: Okay. Got it. Okay. Thanks.
[00:19:48] Ian Swett: Come on. Go for it.
[00:19:49] Cullen Jennings: So I started trying to think about these a bunch, and there's a bunch of things I'm worried about. They might all be fine, but they all have the form of of when you're trying to restore something. So basically, you pause something and now you want to unpause it. And particularly when it was the server relay that wanted to unpause it, what state does it restore it to? Does it restore it to the same state it was before? Those types of things. Let's say we had a bunch of filters that were all anded together or ored together or something like this, and you had to put clauses on each one of the or branches to pause it to start with, what the draft mentions you could do. Then when you restore it, how do you come back out of it? What happens if you have an algorithm running on the relay that's trying to change the filter state at the same time the client's trying to change the filter state? And these aren't really atomic transactions. There's no way to do a three way handshake on them. I mean, I just came into the, you know, locations location filter or or filters are an incredibly powerful technology. And but on the other hand, having a single bit of paused to unpaused might be exactly what we want for an an additional thing and a bunch of things. So it's it's all those corner cases that got me worried, and I didn't know whether people have really reasoned through all of these and thought about them and they're fine or or what. But but but anyway, the I wanted to have some discussion around that. Moe, you're there. Go go ahead and see see you. Yeah.
[00:21:17] Mo Zanaty: Yeah. I I I think we should divorce range filters from from the pausing. That that was my comment to the to the to this PR. Don't even mention the range filters or or or say that they're explicitly not for pausing. It's only the location filter, which is not part of the range filters at all. It's only the location filter that could be used for pausing. If we if we remove the forward parameter by itself and just put it into the location filter, that I think is okay. And if you do this enum thing, I would make it one of the enums. Would make it six as paused. You know, maybe zero is paused or something. So then it's clear that you're saying, don't want any locations. I'm pausing. Locations are irrelevant now because I'm pausing you. When you when you unpause, it would be putting a real location on there. It's saying, I want these locations or there's no location filter. You can give me everything basically, you know, unfiltered. That's how I would that's how I would spell it if we wanna remove the forward parameter and and not make it at all related to the range parameters the range filters. Because you're right. Those are complex. And although you could make up a range filter that effectively pauses everything, I don't think that's the right way to for an app to do it, and I don't think that's certainly not the right way for the spec to tell an app to do it.
[00:22:36] Martin Duke: Okay. Okay. I see where
[00:22:37] Ian Swett: you're going with this. I agree with you, Moe. Yeah. Alan, go for it.
[00:22:47] Alan Frindell: Yeah. I think the what kinda what Cullen is poking at is, like, convincing to me that this is, like, not a direction we should go. Like, the idea that, like, pause is, like, a totally it's in like, I sell locations. So, like, I I'm interested in range from a to b. It's sort of an independent access from I'm not interested in anything right now. And in particular, if I had, like, you know, the part where, like, oh, if I had a bunch of of filters or together, I have to change the location filter in every four set every handset in order to get what I want, which is to pause. And then when I resume, I would need to, like, remember what each of the location filters were for each of those sets was is, like, confusing. And I I kind of think if you read, like, how we express pausing and resuming is, like, a pretty high level thing for a track, Having a parameter for it is not, like, outrageous. And I think spelling it like Moe just suggested where, like, oh, it's just another enum value in the location filter is effectively the same thing as having it be a parameter, but it, I think it's better to be able to express both at the same time. Like, my location is a to b, and I am paused. So I think I'm saying, like, I like the editorial change we've landed, but I'm I think I'm don't I don't know that we need this or that we should do this. I think we should probably just close this here.
[00:24:17] Will Law: Yeah. I think I'm saying the same thing as Alan. I put a comment in the thread, but I think filters and pause stage should be orthogonal. That you just pause on top of your filters. The filters are never removed. Therefore, you never have to remember the prior state before you paused. You simply apply your filters, and then you have this other layer that can stop the flow, and that's paused or unpaused. So I like the language paused or unpaused versus forward, but I don't think it should be attached to the filters. It should be completely separate and applied after all your filters have been applied.
[00:24:54] Mo Zanaty: I think we're converging on on the same thing. Just wanna clarify that Alan and Cullen still have this confusion about the range filters impacting any of this. They don't. The location filter is not related to any of the range filters. It's not part any of the and or or sets of range filters. It's literally just a respelling of the old subscription filter enum, and it may end up being back to the enum. We're basically just gonna go back to the location subscription location filter enum that we had before. But that is outside of the range filters and it's not in any of the end and or sets. And if you add or remove that filter parameter, it doesn't impact any of the other filters. So you could leave all the filters on on a subscription, pause it, and unpause it, and all those filters are still there if you didn't touch them.
[00:25:43] Cullen Jennings: Yeah. No. I was definitely confused on that. Thanks for the clarification.
[00:25:48] Alan Frindell: Yeah. Sam, that makes sense. So the location there's only one location filter that's above all your other range filter handsets. But it still has the problem of if I set it to pause, then I have to remember what the old version was when I unpause.
[00:26:08] Ian Swett: Yes. Agreed. That is totally different. Okay. Then I think probably it makes sense to not do the current change, but maybe if we do the prior PR, we can add a no objects, you know, value into that, and people can take a look at that. Alan, you're you're not in a good place to present for another bit. Right?
[00:26:37] Alan Frindell: I'm almost home. Do, like, one more easy issue, and then I'll be actually on the computer.
[00:26:42] Ian Swett: Perfect. Let's talk about empty namespace and whether we want to do anything. Alright. It's okay to publish tracks in a in the zero triple namespace, the kind of
[00:26:55] Cullen Jennings: root
[00:26:55] Ian Swett: namespace. However, this could create a problem with publishing space because, basically, if you allow a publishing space in the root, it basically says that that person can publish anything kinda in in any namespace. So maybe that's a feature. Maybe that's a bug. There's some concern that Realize are unlikely to give you an off token to do that, but maybe that's okay. So the options are we could do something about this by saying you can't have tracks in that new space. We could add a feature to publish new space about whether or not that publishes recursive. Seems like a fairly large feature addition at this point, but I'm curious, like, what people think about that. I think we could keep the status quo and maybe clarify it, which is if you want to allow someone to publish to any possible names case, then go for it. But, like, you know, buyer beware that, you're gonna get us subscribed from, like, basically everything. Maybe there's some other option. I don't know. What do people think about this issue? Martin?
[00:28:19] Martin Duke: Is it really nuts that, like, in a, like, a gateway situation that that, like, the relay might just be authoritative for everything? Like, there's a default upstream and everything comes from there? Or maybe not. I don't know. I don't like, as I often say, I don't have a use case. But that's
[00:28:35] Ian Swett: I mean, as an individual
[00:28:36] Martin Duke: obviously ridiculous to me that that could be a use case.
[00:28:40] Ian Swett: Yeah. As an individual, I think I'm inclined towards seed because, I don't know, it's hard for me to reason about exactly how people are gonna use these tools, but that's I am not an expert on it, so that's exactly why we want feedback. Cullen.
[00:28:54] Cullen Jennings: I mean, there might be a case like that where, like, there's somebody who's, like, a recorder and recaches and can republish in the whole space or something like that. And remember, these spaces are inside of a scope as well. Right? So, you know, they might not be that much in the scope. Who knows? I don't know. But, like, I just think that this is one of the the like, I I don't feel strongly about any of this anyway. I think anything we decide can be made to work. It's all the same, basically, from the code point of view. But I do feel like that people have x you know, if you told me your file system supported, you know, directory names that were zero length, I would look at you or like you were pretty weird, and I wouldn't be surprised if lots of people's code had bugs accessing that files space. And that's sort of what we're doing here is having URLs that have, like, you know, tuples of you know, fields in the namespace that are empty seems weird. Like, why would you do that? I I don't know. I mean, we we can do that, but it seems like it's gonna be surprising. So I have a slight preference for sort of maybe requiring them to have something. And that's different from the issue of, like, can you subscribe to the root or publish the root? Right now, I'm sorry.
[00:30:06] Ian Swett: You can you can publish the empty name empty track name to the empty namespace, which I'm sure no one will ever have a bug with. Anyway, Mo.
[00:30:21] Mo Zanaty: Yeah. If it was only this issue at the top level, I would kind of agree with Ian. It seems okay. It's, you know, don't know what an app is gonna run. They may not care about names or namespaces at all. Maybe only one thing that they're ever publishing. And so names and namespaces are ridiculous and irrelevant. So, you know, zero tuple, no name is exactly what they want. So I would go with C if it's only about this. However, b, in the more general sense, independent of this zero tuple case may make sense because it's not clear to me that we ever thought about if I'm publishing a a namespace, does that also mean everything, you know, recursively underneath that or not? So independent of this top level route, I think b merits consideration separately.
[00:31:05] Cullen Jennings: I I just wanna play that, Mo. I I I had always read the spec as very much. It does mean you you're recursively publishing under all subspaces of it. I think that's how it reads today. So I I I thought that was clear in the spec that it's always recursive equals true.
[00:31:22] Ian Swett: I believe so. Yes.
[00:31:24] Mo Zanaty: If the intent was this is a namespace and there is nothing under it, this is a terminal namespace or something. And, you know, this all implies that something dot something dot something else is also, you know, a valid namespace and and it's not. If if this flag was saying, no, there's no recursion. This is the namespace. There's only tracks under this. There's no namespaces under it that I could that I know about, that I control. That does kinda make sense to me. You know, but but the relation between a subscriber and a publisher, knowing the full set of namespaces and and and tracks, is kind of a, you know, question mark anyway in general for the whole for the whole protocol. It may be that this is known anyway. The apps already know. Subscriber publisher apps already know, you know, the the full namespace and all the tracks underneath it.
[00:32:18] Will Law: Yeah. I'm against empty namespace. I think for the reason Cullen gave a great example of of a file system. It'd be very hard to work with it. These solutions, MoQ solutions, are gonna be debugged by humans. We're gonna have logs. Right? And they're gonna have empty things in them, which are are just difficult. We invented a a hierarchy and a taxonomy for describing objects, and to say that some of that is now invisible and that we had and we attach special meaning to empty things, I think, is just asking for problems. And anyone who has a use case where they have to subscribe to everything, they can just create a namespace that is everything and put all their stuff in there. So it can be solved with the application layer with the taxonomy that we have today.
[00:33:05] Ian Swett: Just to comment, Will, that I'm not saying I disagree with you, but I guess in London, we decided that zero triple namespaces were okay. So I'm not saying we have to stick with that choice, but I guess this is where we're just predicate. In
[00:33:20] Will Law: Seattle, can we undecide that they're okay?
[00:33:22] Ian Swett: Sure. We we can. We could potentially do that. Yeah. I don't know if that consensus call is closed. Maybe
[00:33:29] Gwendal Simon: you
[00:33:29] Ian Swett: have fifteen more minutes.
[00:33:32] Martin Duke: Alright. As an individual, I I don't really care if we have empty namespaces or not. It I do like the idea of a option a, permitting tracks, then all set just for the same reasons that Cullen raised and Will plus one. But I I see the the potential benefit for, like, wildcard subscriptions. The other point I would make is if we retain empty namespaces, I would kind of prefer if you weren't allowed to say send publish without a corresponding subscribe tracks. Publish seems sort of dossier in certain ways as it stands. And, I mean, I guess there's, like, a half RTD penalty or something if somebody joins and, like, you have to wait for the described tracks to actually send you publish. But it seems to me like that may be seeing some rough edges in this, and you there's still a way to and it kinda leaves you one day one way to do things that multiple ways, which I think is a positive improvement. So I would ask to consider that if we keep empty namespaces.
[00:34:42] Mo Zanaty: Just to point out, we keep saying empty namespaces, but here we're talking about zero tuples. So the length of the tuples is zero. You're still always allowed a empty name empty namespace in any tuple. Right? Every tuple could end up being empty, null, zero length. This is the talking about the number of tuples, not the length of each one of those tuples. So if you if you don't care about namespaces or names and you just wanna publish something, then prohibiting the zero tuple will force you to say, I have a one tuple, zero length tuple. Is that any better? Does that does that does that create less corner cases for people? They still have to deal with null tuples anyway. They have to deal with a tuple having a length zero anyway. Right? So having to deal with the length number of tuples being zero and the length of each tuple being zero, are those two really different things for you know, I think if somebody's gonna make a bug, it's gonna hit either one of those two randomly. So I wouldn't I wouldn't consider either of those to be good criteria for deciding that that we should prohibit this. Because I think robust applications need to handle zeros in both of those fields.
[00:36:02] Ian Swett: Well go ahead. We can't hear you, Will, if you're talking. Sorry. Oh, nope. Yeah. I mean, I I agree that empty anything provides a possibility for edge cases. Okay. So we had, like I guess we had some interest in potentially all of these. Although, was there really how much interest is there really in opening up b? I would like to get it because that's actually, like, a fairly substantial, I I would argue, like, functionality change maybe to the spec, whereas the other ones are kind of you know, you can do whatever you want, but, like, there's no change in functionality. It's just, like, how you spell it. Come on.
[00:36:57] Cullen Jennings: Yeah. I I mean, most of this, really don't care in the slightest. I could be happy either way. But on this one, I'd really rather not add this at this point unless we had a real need for it. I'd rather just keep things as we are because this does seem like it is a real like, a nontrivial change where the other ones just seem like we're defining the error on the edge condition. So, that's sort of my take on it. But if there is a real use case for it, then then I don't mind. But I wanna understand the use case before we add it, a recursive.
[00:37:23] Ian Swett: I agree with you, Cullen. Yes. At this late stage in the game, I would like a real requirement to cause us to do something like b. Cool. Okay. I don't know if there is a clear consensus. I think there are a number of opinions expressed. Alan, do you wanna
[00:37:42] Alan Frindell: Where's the button for camera? Yeah. I think I've heard the same thing, which is that I'd I'd I think some people said it would be easier if we just required everything to have at least some data in it for debugging reasons than but also that you need to have a robust implementation that can handle zeros everywhere. I don't know that anybody has a legitimate use case. Like, their application is gonna be horribly broken if we prohibited things of zero length. Like, those people can just add a character, which can be like a space or something, and it can be just as blank as it was before. But I don't I guess I don't know how to move forward. I I didn't I heard a lot of different opinions.
[00:38:30] Mo Zanaty: Real real real quick. Alan just made me think of something. The canonical representation that we had, I'm not sure if there's a way to disambiguate now. If you you have zero tuples, would you would you not put a dash dash anymore? Or would you still have a dash dash? And then how would you differentiate a null name with versus zero tuples? One tuple with with null name versus zero tuples. I think our canonical notation may not work for those two cases
[00:39:01] Alan Frindell: to decide. I I think there I think there is a case where you get two things that are the same. If you have an the empty namespace and empty track name would just be dash dash. No. But then if you have
[00:39:12] Mo Zanaty: They're both empty then that that case. That that means both empty namespace and empty. No.
[00:39:17] Alan Frindell: No. I I think it's Why would I design that made the same
[00:39:20] Cullen Jennings: bug and you all approve the same bug that I'm
[00:39:23] Alan Frindell: talking about might because a bug on this whole thing. We sort of as a self Okay. I don't want obviously,
[00:39:27] Cullen Jennings: we need to fix the canonical notation.
[00:39:28] Mo Zanaty: Put dash dash?
[00:39:30] Ian Swett: It's broken.
[00:39:30] Mo Zanaty: Yeah. Dash dash means both the namespace is null, length, and the track name is null length. The question is, would a zero length zero number of tuples versus one tuple of null?
[00:39:45] Cullen Jennings: Yeah. Yeah. It's okay. You're right, Mo.
[00:39:47] Alan Frindell: Oh, okay. I think we need to let's not do it on the fly, but let's take some time offline and make sure that we didn't screw it up.
[00:39:53] Cullen Jennings: It's fully an AI to make sure. As a whole working group screwed up on exactly the bug I'm talking about people are gonna screw up on here.
[00:40:01] Alan Frindell: So, I mean, is that, like, an a reason to just say, like, every namespace tuple has to have at least one character in it? Or it has to be at least length one? Is that what
[00:40:11] Cullen Jennings: people want? Mean, look, look, that would be I mean, that's what most file systems say is that every one of those tuples has to have, like, a length of at least one. And, look, I'm not arguing for that. We can obviously fix the canonical representation to solve this problem or whatever. But, like, I mean, it's sort of funny that we did that. Right? I did that. And it it's yeah. Like, I I
[00:40:35] Martin Duke: don't know. I mean, that'll
[00:40:36] Cullen Jennings: be an alternative. I and and, again, I I just I I think this is just, like either way can work. We're just gonna have to be and, obviously, we'll be clear in the spec about what what it is, and we need to, like I mean, this isn't quite editorial, but it's damn close to editorial if the editors want to, like, figure out how to solve this.
[00:40:52] Alan Frindell: I think the
[00:40:53] Alan Frindell: important question is,
[00:40:54] Alan Frindell: is anybody's use case broken if we require at least one character? I don't wanna break anybody by adding a new restriction, but I can't think of how it would be broken. Just choose a different
[00:41:02] Mo Zanaty: Just to clarify. I I think I think we're confused. There is nothing wrong with no length of of any of the tuples or the names or the or the track name. That already works with the canonical representation today. What doesn't work is the zero number of tuples, disambiguating that from one tuple that's null. Because right now, both of those would be dash dash, nothing else. That's that's the disambiguation that we need if we need it at all or prohibit the zero tuple namespaces completely. The the null namespaces are okay. Having no link is okay. We just have a dash dash.
[00:41:40] Cullen Jennings: Having Yeah. We can't you can't null. Anyway, fine. We'll we'll do it offline. We can let's try
[00:41:44] Ian Swett: it out.
[00:41:45] Cullen Jennings: I don't yeah.
[00:41:47] Martin Duke: Okay. I just I made a modest proposal in the chat. Like, it seems like the people want the reason people want this is for wildcard stuff. Can we just use, like, dot all as as a wildcard thing and just ban all the weird empty stuff, like the the nulls and the zero length and blah blah blah. And and then, like because we have the dot domains now, and then that solves that solves the use case without all the, like, implementation foot guns. Or I mean, could bike shed dot all. I don't care what you call it. But
[00:42:26] Alan Frindell: Why
[00:42:26] Alan Frindell: don't why don't we go well, let's let's let's try to write a PR.
[00:42:30] Cullen Jennings: Yeah. Yeah. I don't think we need dot all. I think the wildcards completely solve by themselves. No problem. Either way, nothing to do with this. I don't think I think I don't think we need dot all, but maybe I'm confused.
[00:42:41] Alan Frindell: That's only like, dot all is a pre like, if what if if what you're trying to do is advertise a prefix that you can handle everything, that's okay to have an empty prefix. Right? That's not bad. Like, if I send you published namespace with zero tuples, it means I accept everything. I am your default gateway. And I think that's fine, and we shouldn't eliminate that, which is what your which is what dot all would be. Right? Similar to subscribe tracks. If I were like, just Yes.
[00:43:10] Martin Duke: I mean, I'm just kind of annoyed because I don't really have a distinction into prefix and a namespace in my implementation, but, you know, I I don't know.
[00:43:21] Ian Swett: Alright. I think Mike said something reasonable. Mike English said something reasonable in the chat, which I agree with, which is, like, you can the empty namespace with zero tuples is fine, but, like, namespaces and names, like, need to have at least one character in them. So you can, like, print them out as a thing. I think that's what Mike said. I think that's fine.
[00:43:43] Cullen Jennings: I don't know.
[00:43:44] Ian Swett: But I'm hesitant to design this on the fly. And I also wanna give, Alan time to talk about Switch. So unless anyone objects, I'd like to move on to that, and others can write a PR in the meantime in the near future. I'm gonna hand over to Alan.
[00:44:05] Alan Frindell: Okay. You still have slide control, though?
[00:44:08] Ian Swett: I will give up slide control because I did not change the source slides.
[00:44:11] Alan Frindell: Okay. So I should just put, request slides. Martin. Thank you. Oh, there it was. Okay. We haven't talked about switch from in a while, and several people have provided a lot of feedback there, and the draft has moved along. And so the PRs have been updated to sort of reflect the current state of the draft and some of the feedback. So I'm just gonna kinda go back over, like, what we what what the shape of the algorithm is now. So the algorithm has, like, six steps. So the first one is, like, you validate the request that you get. Remember, this is a parameter that can come and subscribe, and it can come and request update. And it you're and it comes so it comes on the what we call the activating track, the new one, and then it has an ID that references the one you wanna switch from. So step one is you validate that, like, the ID actually named something useful, etcetera. This is new. There's so step two is as soon as you know the largest object in the activating track, you can send the either subscribe okay or request okay. Before that step was deferred all the way to the end, and that was some of the feedback people wanted that sooner. Should be like, I know that this is going to work. Going upstream or, like, determining what the largest object is. If you don't have a subscription yet, for example, like, you may need to go upstream to to to get that, and that may fail. You may never learn largest object because that track is not actually a track. You might get track not found or you might get unauthorized or there may be a number of reasons why you can't actually do this. In which case, you're like, that request fails, either the subscriber or the request update fails, and the switch from thing is unchanged. Once you have sent the okay, you actually you enable this activating subscription. So this slide may be old before we rename forward state to pause on pause. But as soon as you send the okay, you whatever the location filter is for the subscription piece, like, you add it. And so if between steps three and four, if you happen to get some future object that matches your filter, it will go ahead and like, it gets forwarded. It doesn't get get lost. You don't have to buffer it. Then step four is a waiting step, which is, like, you don't actually do anything to the old subscription until you have an object in start group. Now start group is the it's like, it'll be the start group from the fill parameters present, which means that could be something in the past. You may have to go upstream and fetch it, etcetera. So, like and there's, like, a special rule for descending in there. Like, what is the start group for decent if the if your fill is in descending order? Fun times. But, anyway, you you you identify this one start group, and the PR defines what that is. And as soon as you have any object in that group, you're like, you pass the waiting gate, and you can move on. So at that time, you pause. This is for hard mode. You pause the old subscription. You reset any of its outstanding streams. You send publish date notify on the old subscription that that happened and identify what the largest object was at the time that you knew it. There's an option in there to switch from, which is, like, I wanna publish done, which means I want not only do I want to pause the old subscription, I want to end it. So if that happened, if the subscriber requested that, then you send publish done, and then you start delivering the start group, the objects from start group. This is, like, for the hard mode, not for the, like, aligned switch. So, like, is the the general flow. So the the main change was, like, because we now have publish date notify at the end, we have the okay come earlier. Okay. So here are some questions that are open in the PR still. So let's see. How to fail after you sent the okay? So I'm trying to think of what what some cases might be where you might fail after you send the okay. It's a case where you're waiting for you you you everything is valid about the switch, and you're trying to find you're waiting for the upstream to give you an object from the start group. So, like, that, for example, I think time out is one that's identified in the thing where it's like, the upstream just never produced or could not give me that object in some reasonable time. So I think the answer to how do you fail is, like, the news subscription would get a publish done potentially. I don't know if anybody thinks there's, like, a different thing that could happen, Cullen.
[00:49:16] Cullen Jennings: I'm just not sure we have to deal with this. Look. Like, let's say you're gonna you're you're basically trying to say, wanna switch on the next group, and the original publisher never produces another group in its life. Right? I don't I don't think you have to fail. Like, I I don't I think we're creating a bunch of work here that if the if the application shouldn't do that, if it doesn't want that to happen. Right?
[00:49:41] Alan Frindell: Well, okay. I are you saying the application shouldn't have tried to switch from in the first place?
[00:49:46] Cullen Jennings: No. No. It can just switch from, but because there's never a new it's if if the instructions are switched at the next group and there's never another group, that's not the relay's problem to solve.
[00:49:59] Alan Frindell: But what would the relay do with the new subs when so it would just sit there forever with, like Forever.
[00:50:05] Cullen Jennings: Yeah. It would never it would never like, it's basically the same algorithm you have. I'm not proposing that. It just means it doesn't have to do anything goofy. Like, it just does what it was told to do, which was switch on the next group.
[00:50:17] Alan Frindell: I see. And so you wouldn't essentially you would have, like, an infinite there there's no timeout. There's no there's no concept.
[00:50:22] Cullen Jennings: There's no timer. There's no nothing. It's like when it sees a new start of a new group is when it switches. That's it.
[00:50:26] Alan Frindell: I think it can live with that. Like, if the client had a timeout, it can do it itself. It's like, hey. Yeah. I I wanted something in two seconds and, like, literally, like, I'm still getting the old track. I haven't seen anything from the new track. It's been two seconds. Like, I
[00:50:38] Cullen Jennings: I mean, we can send a new group request up to the publisher if it wants to do something. If the publisher doesn't do that, then it's like like, the the subscriber and the publisher have to be coordinated and working together for any mock application to work. So it doesn't bother me that that that you can't solve this problem.
[00:50:53] Alan Frindell: Think there may be so if that makes sense for the time out case, I wonder there may be other cases. Like, for example, if the fill like, what if there's a if the subs if the switch, the new activating subscription, you asked for something in the past and then, like, you have to fetch for it and the fetch fit part of it fails, which I guess we already have that already, which is, like, you open the stream and you reset you open the fetch stream and you reset it.
[00:51:16] Cullen Jennings: Remember this hard switch was supposed to be the basic, most simplest switch in the world and more complex algorithms could define new ones. I don't think it should do Phil. Right? I mean, I think we we could have hard with Phil, which would be another extension algorithm or whatever, but I think the basic one I mean, I I don't care. I mean, like, it's you know?
[00:51:33] Alan Frindell: I think, Phil I I mean, starting from like, getting in it getting a whole group is an important constraint of, like Of course. Usually. And so, like, defining switch without a way to fill is like that seems like I mean, if you wanted to do it without fill, that's easy enough, but, like, we have to also say how to do it with fill.
[00:51:53] Cullen Jennings: Okay. No. Not. I just think I mean, I I don't know. May maybe I've gotten lost on the difference between a hard and soft mode and which ones are used in which cases. But Okay. I think
[00:52:01] Alan Frindell: we'll say I
[00:52:02] Cullen Jennings: guess what I'm saying is I think that we could define this in a way that didn't require timers and didn't require and, hopefully, we don't have these other error states. I liked it. So as soon as you know the large object, you send the okay, and that, basically, you can't really do an error after that. You could close streams or publish that more, but I'll I'll let it go through.
[00:52:18] Alan Frindell: Okay. Thanks, Cullen.
[00:52:21] Will Law: Yeah. Just to illustrate Cullen's question of do we need fetch bill? I I think we would. If you if the next if you just risk you're you've delivered group 20 on the stream you're switching from, say, I wanna switch on 21, but 21 actually arrived before 20 did. So you have it in cache. Right? So you would wanna fetch full 21 and then do the normal subscribe from then on. That would be a valid, fast, efficient switch just in the case where my the two switches I'm I'm switching between are not perfectly time synced in their group numbers. And if the one's in the future, well, then you wait for it as as has been said. I wanted to answer your question number two, should forward zero and the activating subscription be allowed? I think yes. I mean, it may seem strange why do you wanna switch to it but then not forward it, but you're switching it so that it's available for you to then forward with a single bit, right, as an update versus having to go through the switch mechanism. An example there could be a VR headset where I'm not doing bitrate switching, but I've moved my head. So I but for some reason, I don't want the the the visual scene to come, but I I want the streams so that when I turn them on, I then get the streams that are associated with the direction I'm looking.
[00:53:34] Alan Frindell: I think the reason why I made that not and maybe I don't like, why I put that prohibition in there is that it the way the algorithm works is sorta like, it it's conditioned on, like, having something to send, trigger something else. But then if if the new thing is zero, then, like, I okay. Yes. I've got whatever you said you wanted to switch on whatever. As soon as something is available, something is available, and I don't do anything. I'm not sending it
[00:53:58] Ian Swett: to you.
[00:53:59] Will Law: Okay. That's a good point because I I wanna use this to rewrite the SSTS. If we merge this, which I really believe we should, then we're going to have the relay automatically when it receives a group. It's gonna be effectively as if it received a switch from on that track. Right? So we wanna make sure that the semantics here will apply when they're automatically triggered on group perception if they've been set up that way for SSTS.
[00:54:26] Alan Frindell: Yeah. I mean, I I think we can write it in such a way that, like, it would do something if you set forward zero, but, like, it seemed like you really reached for the wrong tool if that's what you sent, like, somehow. Like, if what you wanted was to pause the old subscription and you didn't care about the new one, like, why don't you just pause the old one and subscribe to the new one, forward zero? Like, you're not act switch from is for coordinating two activities, the sending of two different objects from two different tracks. If you're only trying to do it on one track, you should make them independent and not use switch from. But
[00:54:54] Will Law: Yeah. It just seems you're going out of your way to block something that you can't think of a use case for. But
[00:54:58] Alan Frindell: It was more like it just like, I didn't wanna describe how to make it work when you did this. So it was easier to just prohibit it because I couldn't think of why you would want to. But the the group seems to have a general preference for, like, just allow nonsensical things and people get what they ask for. And if that's what they want, can write it that way.
[00:55:17] Cullen Jennings: Okay. Thanks.
[00:55:18] Ian Swett: Okay.
[00:55:19] Zafer Gürel: Moe?
[00:55:20] Mo Zanaty: Just to clarify for the hard mode, this would never be used if you just want the basic use case of of I wanna switch to the next group. I don't I don't wanna stop the streams, you know, abruptly. I I just wanna I'm I'm getting this stream, but I know I can't handle it, you know, indefinitely. So I wanna switch to lower rendition, but I don't wanna lose part of the video when I'm doing my switch. I wanna still play, you know, out that video. And then when the new when the new group comes of the switch to stream, I wanna start that group and then end that the the prior track. But the re number four, resetting all the streams would mean that I'm gonna have a glitch. Right? So the hard mode is is not for the common case of I just wanna gracefully switch from one track to the other.
[00:56:06] Alan Frindell: Let let me I mean, what I think that the of the use case for hard is, like, the or or, like, there's another slide about naming and where we should think about the two tracks are switching between between have no relationship to each other in terms of group alignment. So I'm looking at a a grid of, you know, Hollywood squares, and I wanna switch from Alice to Bob. Like, as soon as I don't wanna stop Alice's track until I have Bob's ready to send, but as soon as I do, I do not care about any more Alice data. Right? Like, I just want Bob data. And so it's like, keep sending Alice until Bob's ready, and then as soon as Bob's ready, drop all Alice stuff. Right? That's kind of the use case. If what you're trying to do is I wanna switch Bob from low to high or high to low, that's a case for the other mode, the aligned mode where you expect the group numbers between those two tracks to mean something useful, and it's less in that case, the re the four doesn't reset everything. It only resets things that the new subscription are covering based on where the switch happened, if that makes sense.
[00:57:10] Mo Zanaty: Yeah. That makes sense. Okay. Yeah. I'm good with that.
[00:57:13] Alan Frindell: Okay.
[00:57:15] Gwendal Simon: Yeah. The hard mode is also to cover the one of the use cases coming from Luke, I think, where you you start downloading your group and you realize you will never survive. And this group is in your buffer, and you say, okay. If you fetch the other the track b, and then you will start the track b as soon as possible at the lower resolution. And so because your buffer will manage the transition between both. So field fetch is really necessary for this kind of hard mode. It is from disaster recovery and track b as soon as possible. And you are you will maintain something which is no gap if you have a refer or just a small gap if you if you started playing the track. Yeah.
[00:58:14] Alan Frindell: I just wanna point out too, like, in in disaster mode, switch may not be what you want. You might want to just request update the old one and say stop, like and not coordinate in any way with something new.
[00:58:26] Gwendal Simon: Yeah. But since you don't know if the relay doesn't have the track b in cache, you don't want to stop completely your your
[00:58:34] Alan Frindell: your But it may not matter. If if if a is just too big, you're like, I don't care whether you have b or not. I don't want a clogging the pipe. And so I just wanted to, like, switch from as a tool, but it's not the tool you should always reach for. There are cases where there are other tools that do the backdrop better.
[00:58:50] Gwendal Simon: But, anyway, field fetch is is necessary for this for for this use case. And if if your player has a minimum of buffer, it can sometimes just flush what it has as the buffer for the for the group and restart from a from a from a better track.
[00:59:06] Alan Frindell: Thanks. Suhas?
[00:59:09] Suhas Nandakumar: I think I think, I was a bit surprised that the use case for hard switch is going from Alice and Bob. I'm not saying we should do it or not, but, until now, my understanding of all the switch cases was between different resolutions, not between different users. I I can at more clearly, it it does not matter because it just tracks, but, at least that was new use case that I've heard until, now. But other than that, we I I agree with, this is like if if the if you do switch to a track and you do not get any data from that, I don't think so adding extra complex machinery on that is needed. It's an application thing, and it things will time out on the clients. It's those clients know that they switch and nothing happened. They will they will unsubscribe or do something. We should not add lot of application logic into that part there.
[00:59:55] Alan Frindell: Okay. I think I'm hearing at least from Cullen and Suhas that, like, the at least the time out case is not really valid, and it may not be disastrous to, like, leave these things from the Relay's perspective. It's just one ex you know, it's as if they subscribed again, and it consumes a a bidirectional stream, which have their own limits, and subscribers can do what they need to do. I don't know if anybody else wants to weigh in on two on forward zero being allowed or not allowed in in for the activating subscription? Cullen?
[01:00:31] Cullen Jennings: I put a really weak vote for yes on it just in the sense that and not if it greatly complicates implementations, but just on the you're you're lining up a bunch of windows that you might show what one. As I you realized your bandwidth changed, so you're moving them all to different resolutions, but you're still not unpausing all of them. Yeah. You've only unpaused
[01:00:49] Ian Swett: some of them, but you
[01:00:49] Cullen Jennings: wanna have them there and ready to sort of unpause at any point in time. So I I can I I think you could construct a use case where that was was valid? So I I put a a week plus one for it.
[01:01:03] Alan Frindell: I think it's gonna end. I I I I heard some weak plus ones. I think my minus one is weak also. So, I'll try to write it with with allowing it. I think it it made it be more text to allow, but I don't know that it's gonna be more it might be less implementation. It might be less code. So that may be a good a good trade off. There on three, there was a question about what so if if aRelay decides it's gonna handle the switch, it says, you know, basically, like, if if if you're the relay executing switch, you're not supposed to send the switch from parameter upstream. And I know, Cullen, you had a question about that in a case where but if you're not the relay that's handling the switch, like, you're a stub relay that's kinda too dumb and you want the upstream to handle the switch, you do forward it. It just says if you're doing basically, you don't want two relays in the chain doing it the
[01:01:54] Cullen Jennings: same thing. I think I was con I I might not say exactly what you think in the PR. I thought it said you must not send it up. But, I mean, what you just described there is if you're the one handling it, then you handle it and you don't forward it. If you're not the person handling it in rare cases where that might happen, then you forward it. That is exactly what I think we should have. So what you said
[01:02:10] Martin Duke: is what
[01:02:11] Alan Frindell: I want.
[01:02:11] Alan Frindell: Okay. Good. I think that's what
[01:02:12] Ian Swett: it says.
[01:02:13] Cullen Jennings: Even better.
[01:02:16] Alan Frindell: Okay. Four was like, yeah. Do just hard mode reset streams in the middle of an object. So if you if you're switching away from Alice or someone else put another use case in there, which is you're switching away from camera one to camera two, like and you have camera two ready. Like, do you and you're in the middle of an object. Should you reset there, or should you wait until you've sent everything? I think you should reset immediate like, if if you're ready if somebody asked to go from a to b and b is ready, I think you'd want to kill all of your a stuff in flight even if it's mid object, unless somebody else wants to make a case for something else. Okay. I don't really hear anything, so I'm gonna I'm gonna leave it like that. Let's see. Should a failed switch in request update terminate the activating subscription. So you let's say you had you have you have a and b. You're switching from a to b. You already had a subscription to b, but it was paused. And then you send a request update switch from that somehow fails. Now we also said that maybe we should try to create fewer ways to fail. But it seems like there could be some failures. And I think the language says, like, if the switch fails, then you terminate the subscription, but that sort of leaves you in a worse state than you were before. And so maybe we should try to make if the if a request update fails, you you can leave the subscription in place. Or maybe we already have text that says if a request if any request update fails, it tears down your subscription. I don't remember. Okay. I see a lot of people on four, yes, which is good. Any thoughts on five? Like, how how far should an error a switch error take like, what should it take down with it?
[01:04:10] Ian Swett: No? I
[01:04:11] Mo Zanaty: think the common problem that we have with this, we and specified all over the place, is that, you know, an an update will will kill the subs the entire subscription if there's an error because we don't know how to derive the the parameters that are relevant because you don't you don't know this mean this what what what level of impact did this failure have? That's what's not known. So we just blow away all subscriptions if the if the update fails. It would be weird to make an exception just for this. And in every other case, request update blows with the whole subscription.
[01:04:46] Alan Frindell: Yeah. I I think I think I'm inclined to agree. Like, since it leaves you in a in a little bit uncomfortable state, it may be better to just, like, tear it down. And I think we do have language that basically says any up failed update tears down your subscription, so this shouldn't be different. Yeah. Yeah. Okay. Six. How strict should the ordering be for the algorithm? I I think it's in an okay place now. I don't know if anybody had gripes about the ordering or I think maybe, Gwendal, this might have been your comment, and it may have been more on soft mode than hard mode. So, I think it's I think it's fairly well I mean, basically, there's three steps. The first three are likely I mean, roll back real quick. The first three are effectively can be done synchronously by the receiving relay. Like, you validate, you send assuming you know largest object, you can send it, and then you, like, add forwarding state. And then you have sort of this waiting step in four, and then once four happens, then five and six happen together.
[01:05:51] Cullen Jennings: I I I think I had a comment on that, though. Isn't what you describe as step six, didn't that actually happen in basically step three?
[01:06:02] Alan Frindell: What can happen is if an if it receives an object that's larger than the group that you're trying to start from so let's make it concrete. Let's say, the you want the switch from said, gave a location filter. This is start from group 11.
[01:06:23] Ian Swett: Mhmm.
[01:06:23] Alan Frindell: And largest object is currently 10, and you're so you're waiting for a group 11 object, and this actually leads into the next point. But, like, you're wait let's assume groups are all there. Let's assume those groups all exist. He says, I wanna start from 11. And somehow you get a 12, but not an 11. What happens is 12 gets delivered, but it doesn't execute step four. This is basically like, I said I wanted to switch at ten or I said I wanted to switch at eleven, so I want to wait to turn off the old one until the new one actually shows up. So I it's not so deliver from
[01:07:01] Cullen Jennings: start Look. That all made sense. Totally agree. But I don't understand step six.
[01:07:05] Alan Frindell: So okay. From start group means, like, eleven was start group. And so if I deliver you an object in 12, it didn't meet my definition of deliver from start group, if that makes any sense. So, yes, you can receive objects, but we don't we're you're not on step six yet, if that makes any sense.
[01:07:25] Cullen Jennings: I just don't know how to I don't I I I I like when an object comes in that is it meets the location filter of 11, let's say eleven zero comes in, I don't wait till step six to deliver it. Basically, step three will allow me to have already forwarded it. That's why I didn't understand about step six.
[01:07:43] Alan Frindell: So once you have 11, then four is satisfied and five and six execute.
[01:07:49] Cullen Jennings: I don't understand what step six is. I I I would say that step six is covered by step three. There's nothing new in
[01:07:55] Alan Frindell: step six.
[01:07:56] Alan Frindell: The reason why it's confusing is if you think about it instead if if if start group was a fill fetch. So if instead what somebody said was if largest object was 10 and someone said switch from nine, now, like, deliver from start group might mean reading from your cache and actually delivering things from nine once you have something from nine.
[01:08:21] Cullen Jennings: Yeah. Okay. I think we need to write up a whole bunch. I mean, I I get that. That seems like right type of thing, but I think you need to fully cover the order of things that like, if if I'm if I'm doing a fill fetch and trying to deliver, do I have to fully deliver my fill fetch before I start delivering any of the objects that come after the fill fetch is the question to me.
[01:08:38] Alan Frindell: Definitely. Think
[01:08:39] Cullen Jennings: that there's a bunch of write up needed here to make fill fetch work in this. I don't think we should do fill fetch in the most like, look. We agreed we were gonna have a very minimal switch algorithm in the base case that allowed extensibility. This is turning into a very not minimal switch in the base spec, which I'm fine with. Whatever. Like but, like, I mean, this does not cover how fill fetch works in this algorithm.
[01:09:00] Alan Frindell: I I mean, I I don't know. Like, I I hear you're asking for more detail, but I don't know if I know exactly how I can satisfy your request. I do think that, like, fill fetch I I mean and and if you wanna have a way that I think if you just omit fill parameters, like, the algorithm works the way you expected it, then it's fine. But I think there's a lot of people and the people there, especially the switch enthusiasts, like, want to be able to start at a group that may or even the current group may have start maybe slightly in the past.
[01:09:28] Cullen Jennings: Oh, okay. Look. I'm I'm not trying to say oh, let me like, I'm fine. Let's do fill fetch. I will go read it from the fill point of view, but I think that that step six completely has to do with fill fetch only, and that's the part I wasn't getting about it. I'll reread the algorithm, but I think it's still underspecified for what happens with fill fetch.
[01:09:45] Alan Frindell: Okay. And and I wanna make sure that it is completely specified. So, like, appreciate any additional view. And your view of it has been great. Please keep it coming. Yep. Thanks.
[01:09:54] Mo Zanaty: The the thing that confused me there was I did not realize you're waiting for exactly that start group, and I I assume you're waiting for exactly start group object zero or just exactly start group?
[01:10:06] Alan Frindell: It says any object in start group. But Okay.
[01:10:08] Mo Zanaty: Yeah. So so I I thought the original proposal would not switch from parameter, the or Windows original switch proposal. It was any group that any group that that that level or higher. So I thought that made a lot more sense that if if you just got newer things, that would start immediately getting delivered. I'm surprised that we're waiting on that one exact group to trigger this algorithm to work. Is that what really we want? Is that what switch designers really want?
[01:10:35] Alan Frindell: So I so you've hit so, like, in reviewing Colin's comment last night, and this discussion also highlighted it, and I kinda glossed over it, which is what if I asked for a star group that doesn't exist at all? Like, I said switch at eleven and there is no eleven, then outcome to me
[01:10:50] Mo Zanaty: is I'm receiving group n. Shit. I can't receive group n. Switch from group n plus one. Or maybe group n and do fill fetch, but that's the dominant use case to me. I'm receiving n. I can't I know I can't handle it. Switch from, you know, and and and specify n plus one or n, one of those two. In which n would mean I have to do a fill fetch to to back up and get n. But n plus one means, you know, I don't really know there's an exact group n plus one, but the next group just, you know, just start forwarding me the this lower stream. That's what I think the dominant use case is. If that can't be expressed, I'm a little worried.
[01:11:26] Alan Frindell: Yeah. I I think the answer to that is in the case where start group is greater than the largest objects group, e g, it's in I'm gonna use a time term here. Don't get upset. It's in the future, not the past. Then anything from the future probably auto immediate immediately trigger the switch, which is like, I say switch from eleven and I get twelve, I should be like, great. We're switching.
[01:11:47] Mo Zanaty: Yes.
[01:11:47] Alan Frindell: I think in the case where it's in the past is where you want to wait into if if somebody said, like, do you wanna wait till you have something from and it's really for I mean, think it's it's really for current group, I think, but also maybe current group minus one is, like, the common use case where, like, I actually wanna make sure I've got that object before I turn off the other stream because I don't wanna render it until I, like if you think about what the application's gonna do, it's gonna render something else in a box that it's in the one that's about to turn off. You don't wanna turn that guy off until there's actually where the person wanted to start from. You're still frowning.
[01:12:23] Mo Zanaty: Yeah. Be because because in that case, it still seems weird to me to disallow the the the new groups from the new stream that you wanna switch to because you're waiting for the old group to come. If if that's really what you want, I would use priorities to disambiguate that. If you don't want the new groups to to outrace the old groups, then put priorities on the old groups if you want them to come first. But I don't think you should stop the stop this algorithm from working, you know, until the trigger is at this exact group because it may be in the past. That seems kind of, first of all, low runner case. And second of all, even for that low runner case, I don't think that's the desired behavior.
[01:13:08] Alan Frindell: I I mean, I think I'm gonna let Gwendal and Zafer talk because they thought way more and have written code that actually does this. And I and we might know what works. So save me save me, Gwendal.
[01:13:17] Gwendal Simon: No. But it's it's a it's it's not a question of where I need to switch from. It is a question related to fill fetch. And fill fetch, there is a fill timeout which allows you to say, don't want to wait more than x milliseconds before before starting the point. And and so this is how you can say, well, you know, I want to go switch from in the past. But in fact, it's not a question related to switch from. It's it's just the I want to subscribe and the starting group is maybe in the past, maybe in the future, maybe it's a current one. And I think we have it is already in the draft '21 ish, and there is no specific need for switch from there. The start group is the one which is computed from the field fetch or the new group. And if field time out is is over, the start group is changing. Okay.
[01:14:18] Alan Frindell: I I guess the question I think Cullen or someone just asked and or maybe both of them, and maybe the question I have is, like, will it work at least in hard mode if we take any if the receipt of any object for the switch to subscription satisfies step four, or will that break things if we are if we get if we said switch from we're at ten, we said switch from nine, and we get eleven, is it okay if we turn off the old one and start delivering from eleven in hard mode?
[01:14:52] Gwendal Simon: That would be a super hard mode saying that it's not what you wanted initially, but we already have data for for this new track, so let's go. I mean, this
[01:15:02] Alan Frindell: I mean, that's kind of what hard mode is, though. It's like because Yeah. But it
[01:15:07] Gwendal Simon: It's hard mode, but from the specific starting group, if you say whatever you have, give me and stop the other one, it would be super hard mode in that case. Meaning, like Okay. Either just it it means I don't want to wait for any field fetch to be to be starting. I want anything with I think field timeout is exactly this. If you put field timeout equal to zero, you would have something that says, if the data is not ready in your cache, just ignore.
[01:15:39] Alan Frindell: Yeah. I mean I think this is you say switch from, you can also say switch from and the target can be the next group. Right? You can express a a relative range there. So, like, that's totally like, it's totally valid. The question is what happens in these cases where, like, people use exotic filters and there's in in the switch from
[01:15:54] Gwendal Simon: But but it's not switch from nine. It's it's you switch from track b, and it's it's just a subscribe, which can have a location start group, which can be in the past. It's not switch from nine. It says just manage this new subscription, and that's it. And so if we follow the regular subscription I mean, we we have defined a subscription. I mean, subscribe, we fill fetch. And so if this work, it will work here exactly the same. Just the point that we fill time out, the start group can be changing over time.
[01:16:31] Alan Frindell: Yeah. No. I the fill time, it doesn't the algorithm doesn't describe what happens if you said start at nine and then you got a fill time at trying to reach nine. What do you do? And ten shows up. What happens is not specified. Maybe that's part of what Mel is talking about, that it's not described. Correct. Zafer?
[01:16:49] Zafer Gürel: Hi. So I just want to share our experience with the switch from. Actually implemented it, and we faced a couple of issues. But these were, like, the alignment of the tracks where, actually, we realized that after some trials, we realized that our publishers were not publishing in an aligned way, so that happened to be a problem. But when we fixed that problem, it really started to work. So what we did was, like, we our player gave us start from in a in a as a future group. And, I mean, like, one group later, it worked pretty well and still working right now. I think, like I mean, as long as we do it on the client instead of on the server, there will be, I mean, always some complexity. And I think this is the, I mean, best method that we can come up with, like, as far as I can say. So it's easy to implement, and it works. So that's my take on this.
[01:17:59] Alan Frindell: Alright. Yeah. That's good feedback. Thank you. Suhas?
[01:18:03] Suhas Nandakumar: So I I bit con confused. I I heard the use case where a switch from in the hard mode goes from user a to it can be from user a to user b. And in that case, the tracks or the groups are not aligned. Then what does the start group even mean?
[01:18:20] Alan Frindell: The start group is in the case where the subscriber asked to start in track b from a specific group for some reason. Now that start group could be relative to largest object. Right? Like, I could say Right. Start from next. Right? And then we'll start from or start from current. I think those are probably the two most common you're gonna get when you're when you're doing a hard switch. Right?
[01:18:40] Ian Swett: Like
[01:18:40] Suhas Nandakumar: But but that that could that could mean that could have a useful meaning only if they if those tracks are aligned group aligned.
[01:18:48] Alan Frindell: I don't think that's true. Because they can be relative to track these largest.
[01:18:54] Suhas Nandakumar: Like, if if I'm on al Alice's I'm watching Alice's group 10, and I'm asking to go to Bob's group 15, How how do I know where the Bob Bob is? He's
[01:19:04] Martin Duke: not in
[01:19:05] Cullen Jennings: the chart?
[01:19:05] Alan Frindell: I mean, if you if the subscriber did a a hard switch from with an absolute start group, presumably, got that information from a catalog or some way out of band. Mock doesn't describe how to do it, but it's totally fine and probably common that they would say they would use a relative filter there, which is relative only to b's large.
[01:19:24] Suhas Nandakumar: Right. I I think I think that might probably need
[01:19:26] Gwendal Simon: to specify. I I don't know how do
[01:19:28] Suhas Nandakumar: you specify, but but the point I thought that goes to the point that it cannot be the exact the group number. It should be something greater or equal to that group number. If you find, you should let it go because because the very fact that they are not aligned makes it you cannot exactly match.
[01:19:44] Martin Duke: I I
[01:19:44] Alan Frindell: I would hard. I I I would be fine making that. I think okay. So I think the algorithm is broken as described right now, particularly in the case where start group doesn't exist or maybe the fill fetch times out. So I would be okay changing it to greater than or equal being that's when you execute the hard switch. Cool. I just don't know if that works for the people who really care about this, and so I can't speak I don't know if I can
[01:20:08] Cullen Jennings: make that
[01:20:08] Alan Frindell: change. That's why I'm asking.
[01:20:09] Suhas Nandakumar: At least my thinking about that is that, like, if you if the groups are or tracks are aligned group aligned, then by natural curves, the next group will be the group that you asked for, which would be the next group. That's when we want to do the switch. But in the case where it's unaligned, then it it falls into water as the next group comes. So I think it it should work for both the cases, without having to force, the the the behavior here. But, yeah, I'll I'll I'll let the switch people explain more.
[01:20:44] Cullen Jennings: I mean, I think I
[01:20:45] Ian Swett: was coming around to the
[01:20:46] Cullen Jennings: same thing of of sort of saying that I I think that the start group isn't the thing here. I think when we do when we what we actually want for hard mode, all let let let's I think we need to back up and talk about what we think these modes actually do versus the nuances of them at some level, and I'm not sure we all agree. My understanding of hard mode was the switch was going to happen when there was data that would allow me to start decoding the new stream. Alright? And so it had nothing to do with the group numbers in the old stream. The group those would hard stop as soon as there was something I could display in the new stream. And I mean, maybe, like, maybe that's all hard mode should have been, or maybe we should call it very hard mode or whatever where it's just like, no. There's no there's no relative filter. There's no anything else. When you see a new group in the new stream, you stop the old stream. That's it. And, you know, maybe it doesn't look yeah. Like right? But, I mean, it seems like we're I don't understand how I don't understand how anybody gets these numbers to be able to fill in these things. That's basically the problem.
[01:21:45] Alan Frindell: I don't think people will use absolute numbers in in hard mode, Cullen. I think that there's two common cases. One of them is next group, which is exactly what you described, and it's very easy. The other one is current group, and that might involve a fill fetch, and it's a little bit more complicated, but I think it's also a very common case. So I think we should at least and I and I I think the original original like, if you remember the original sixteen forty two for fill the fill fetch had defined a current group mode, and that made the switch from much simpler to describe. But now we've, like, gone a different direction with fill fetch, and we've tried to adopt switch adapt switch to it, and it's gotten a little bit harder to reason about.
[01:22:25] Cullen Jennings: Okay. Maybe we just need to back up and take those two different modes, like, next group and current group. Those are both very I get both of those reasons. Maybe we just need to basically, you know, have switch on next group, switch on you know, switch hard next group. I don't like hard either, but switch next you know, switch switch next group, switch current group, and then we'll get and then switch aligned. Right? I mean, like, maybe we just need both of those modes. Maybe that'll make it much easier to reason about and write up.
[01:22:56] Alan Frindell: I mean, I'd be if it made life simpler, I would say, like, in when you switch from in hard mode, you can't specify an absolute start. But then someone is gonna come and tell me that because every time I try to say, oh, you can't do x because it doesn't make sense, somebody comes and tells me not to do that. So
[01:23:13] Cullen Jennings: Yeah. Okay. Fair enough. I I I get the point. Anyway, Gwendal will have better info.
[01:23:17] Gwendal Simon: Yeah. So first, group alignment for hard mode, this is not, I mean, it's completely unrelated. You you stop one track when when you have data for the other track with whatever the the the group IDs are. So if you don't have track with group alignment, you use hard mode. It just works. We need to have I mean, we need to authorize subscribe with field fetch because sometimes you are lagging three, four groups before, I mean, behind live. I think I explained, like, so many times why we should have this. And and so in that case, you do a track status, and then you you say, okay. Given how late I am with respect to the to the live, I need to fill fetch to all three groups. And so you do subscribe, fill fetch to three groups, fill time out two hundred milliseconds, and then.
[01:24:24] Cullen Jennings: But is it Gwendal, wasn't it what you were describing right then soft, like, in a lined case?
[01:24:28] Gwendal Simon: You I mean, you can say hard or or off top, but
[01:24:32] Cullen Jennings: or or No. Just like soft. I know. I totally get the requirement of why you need soft, but you keep trying to turn hard mode into into all the complexity of soft mode. Right?
[01:24:41] Gwendal Simon: That's that's
[01:24:42] Cullen Jennings: where I get lost.
[01:24:43] Gwendal Simon: No. Wait. It hard mode just says when you have the data that I am looking for, just give it
[01:24:50] Alan Frindell: just solve that.
[01:24:52] Cullen Jennings: When you have the data I'm looking for, switch. Right? I mean No.
[01:24:55] Gwendal Simon: This is both words. You say, subscribe me starting at group 10. And when and switch from Just put 10
[01:25:03] Cullen Jennings: on which stream?
[01:25:05] Gwendal Simon: On what subscribe, track a, starting 10, switch How do
[01:25:12] Cullen Jennings: you know 10? When if you're if you're receiving let's say we're switching from a to b. If I know the numbers on a, how do I know what number to do on b if they're unaligned? I totally get this for aligned soft mode. I totally get how all works.
[01:25:24] Gwendal Simon: No. But even even even hard mode, this is okay. You can
[01:25:28] Cullen Jennings: you know?
[01:25:30] Gwendal Simon: You so you can know if
[01:25:32] Will Law: the track
[01:25:32] Gwendal Simon: status, you can know if because you have any other information coming. You can know because you know where where you are compared to what you want.
[01:25:42] Cullen Jennings: And I don't need to switch in all those cases. If I'm doing those things, I can just use subscribe and unsubscribe and filters. I don't need any of this.
[01:25:50] Gwendal Simon: Well, you don't know what the relay has or not. And so you
[01:25:54] Cullen Jennings: can matter. I just do I don't know in this case. I just do a fill fetch on whatever I want. Yeah. But you just want to
[01:26:00] Gwendal Simon: you just you want to continue having the track a until the relay is ready to give you track b. This is this is so this is what we do here, switch from hot mode. When you will be ready to send me the data, whatever the status of the other, you stop it. This is Okay.
[01:26:19] Cullen Jennings: I don't think this is at all what we agreed on when we were in London. I'm basically checking out. I I I don't I don't have a problem on this, but this is I'm checking out on this. So I think this has put us exactly back to where we couldn't get consensus on Switch.
[01:26:35] Alan Frindell: Okay. I I hope that we it's that we're not so lost because I feel like we're we're driving in a fruitful direction, and the devil's a little bit in the details and the cases are kind of complicated. I I hear that we'd it sounds like there's still more work to do at least based on some of the feedback today. And, like, I guess, well, I would like to maybe request some time in London to try to make forward progress and get because I don't think it's coming it's obviously not going in '22, which is a new feature. So or sorry. Did I say London? Seattle. Whatever whatever city I live in. Anyway, Martin, I don't know if you wanted to bring us home in some meaningful way.
[01:27:09] Martin Duke: Not well, I mean, I I it didn't feel like we were driving to conclusion with three minutes left. It sounds like you're gonna go rev the PR based on what you've heard, which I guess is something. But is there some sort of question you have that we can resolve in the next two minutes on this issue, or we just need to talk about it more?
[01:27:26] Alan Frindell: I I think I think what I wanna do is, like, huddle with the main so I've been sort of acting as a proxy for the main switch proponents since London, and I would try to like to back off of that role a little bit and let the sort of the Gwendal and Zafer and Ali and and Will maybe do a little more of the driving first to make sure that the use cases are there. I'm happy to to try to be an intermediary to explain it better. And, Cullen, we can bring you back into the, it's not so complicated, and there there is there there is some there there. So I I think we just need some more some more time.
[01:28:00] Ian Swett: Cullen?
[01:28:01] Cullen Jennings: 100%. Wanna be there. I just think we need to clarify a bit of this stuff here.
[01:28:03] Martin Duke: Sorry. So I I think I think reassigning I think reassigning the issue to the to the team switch is is great, and let's get I mean, Cullen seems engaged, so let's get him back in. Frankly, like, I haven't even started to implement this because I'm still stuck on draft 18, so I am I am not like, I I zoned out a while ago. But okay. Great. So Look. I don't
[01:28:24] Alan Frindell: care deeply. I don't need
[01:28:25] Cullen Jennings: to be involved. I'll read the PR. If it's implementable, amendable, makes sense. I got no objection to switch coming in in whatever form, hard, soft, medium, over easy, whatever. Right?
[01:28:34] Martin Duke: I appreciate that. I appreciate that Cullen, but at the same time, like, you know, I I love that there's somebody who's not a switch proponent who's actually engaged on this other than Alan. And, like, I I'd I'd rather you not tune out if if we can get you to understand what is happening and be comfortable with it just because, you know, good review is valuable. Okay. So it's it's about quitting time.
[01:28:58] Alan Frindell: Martin, can I make one just request? Like, there there's a bunch of slides left, folks. I don't have time to go through them. They cover a bunch of issues. I'm gonna propose that you go look at the the decks up on on on data tracker. After this meeting, whenever you have a break today, go read those five, six slides, whatever they are. If you care about those five, six issues, please go weigh in asynchronously, and the editors will resolve them and not take your meeting time the next time we meet to try to go over them. So that's my my please ask. It should not take long, less time than we just spent talking about Switch. Most of the issues are fairly simple, but just a little bit of signal would be useful for the editors and authors to make a proposal because we're not exactly sure. There's a couple choices there. Thanks.
[01:29:39] Martin Duke: Okay. While we're talking about slides, if for some reason you missed the chair slides, I encourage you to go look at them, particularly the upcoming dates thing because there's tons of stuff that have deadlines for you now in in Seattle. Most important, which by far, is if you plan to attend in person to add your name to the Wiki. I know there are there are numerous people who I strongly suspect are gonna be in Seattle who have not bothered to add their names, so please go do that. Like, the link is in the Zoom up there, and you can also find it under the work group materials wiki. And, you know, it's obviously important you do that. We got the date closed, I think, on the twenty ninth, and I'm gonna send it to list at five. So don't mess that up, please. Okay. So and then, again, if you have the capability to host in Denver, please look into that so we can discuss it in Seattle. Alright. It's 11:00. Thanks, everyone. And next time we will be together, we'll be in person in Seattle. So we will see you on the 48th Floor. Bye. You.