Session Date/Time: 26 Oct 2026 16:30
[00:00:04] Alan Frindell: Starting to wander into more... Like, it's sort of more about zero RTT, and so I added them.
[00:00:09] Martin Duke: Yeah.
[00:00:09] Alan Frindell: I don't know if we wanna split out, but, like, h three, for example, has, like, more specific text about what you're... How you're supposed to remember settings in zero RTT.
[00:00:25] Martin Duke: Okay.
[00:00:26] Alan Frindell: So I don't know if you you... If you wanna be like, that's another PR. I want this in as is, and we can follow-up. That's fine. But I just That
[00:00:33] Martin Duke: that is cute. That is a editorial PR. Is it not? I was just... Yes. I was just trying to, like, clarify the test as is. I'm not... I'm really not trying to drive any sort of design change. Okay. So if, like, people want to do something with zero RTT, that's a great discussion to have. But I I I might get unsure for a reason. I'm not trying to change anything.
[00:01:00] Alan Frindell: Okay. Fair. I will... I'll remove the block tag, and we can just... I'll maybe file a separate issue about
[00:01:06] Martin Duke: Okay. Thank you.
[00:01:08] Mo Zanaty: That. Okay.
[00:01:09] Martin Duke: Alright. Well, that that was, I guess, useful issue discussion, but it is now meeting time. So welcome everybody to the... To our biweekly media real quick virtual interim meeting. This is the only one between our in person meeting in Seattle and I t f one twenty seven. As always, this session is being recorded. This is the I t f notewell. It talks about the intellectual property implications of you being here as well as going over our code of conduct. You can scan that QR code if you would like to read more about it, or just type IETF Notewell into your favorite search engine. You're in MeetEcho. That's how we're doing this here. If you wish to join the queue to make a comment, you can press the raise hand button at the bottom of your screen. You can also use the Zulip, which is accessible with the chat bubbles at the top of your screen. And if you don't wanna clog up the queue with your comment because maybe it's a joke or it's not that significant. If you are going to speak, two things. Number one, please use a headset. The echo cancellation properties of mute echo are not great, and we'll probably have to aggressively mutely... Mute you if you do not have a headset. Secondly, there is a latency of about a second when you press that mute, so give yourself a little grace before you start talking. Alright. We have a number of calls for consensus, for lack of a better word, that are out there. We have agenda requests due, I believe, it's next Monday, if I'm not mistaken. Maybe it's Tuesday. Let's see. Why am I having trouble doing it? No. That's next Monday. So, yes, if you would like time at I t... IETf-one twenty seven, please email the chairs. If it's kind of a new topic, sending the time in a little... Sending the request a little bit before the deadline would be kind of good because Magnus and I, especially Magnus, been doing a great job of maybe asking some follow-up questions to make sure that your proposal kinda fits what we're trying to do at the meeting. So earlier is better, but the deadline is next Monday. Also, there's a call out. We agreed in Seattle to meet in, Europe for our next in person hybrid interim, and the dates are going to be eight to eleven February. If you are interested in hosting... There's a... We always have loose talk in the group as well. We... You know, we have offices in x, y, and z. We could host in those places. If you actually want to host there and want to do the work, please email the chairs to say that you're interested in pursuing that, and then we will have a short list of of venues that are almost certainly available, those dates, and then figure out where we're gonna meet. Magnus?
[00:03:52] Magnus Westerlund: Otherwise, you will end up in Chista in February.
[00:03:57] Martin Duke: That is the... That... We've actually received... Well, we've received one proposal so far, which to me seems sort of out of left field. We'll see how that one emerges. If that one turns out to be not really suitable, then, yes, you're gonna meet in. So that is a threat hanging over you. Okay. About, I don't know, thirty minutes ago, I I sent out a proposed virtual interim dates between IETF 127 and that February interim. There are four of them. We avoid the Christmas holiday. We avoid the MLK three day weekend in The US. So if those dates work for you, great. If those dates don't work for you, please email. Don't email the chairs. Email the list because I would like to have an open discussion. One thing that's happened in the past is somebody's privately said, oh, that date doesn't work because of holiday x, and we change it, and that breaks it for five other people. We We wouldn't like that to happen again, so let's just do it all in the open. I don't think this is confidential communications. They talk about holidays and trips and so on. So let's please conduct that conversation on the list. On November 9, we will finalize those dates and send them to to data tracker. And then, of course, I think we're all aware of I t f one twenty seven coming in less than a month, and we hope to see many of you there.
[00:05:10] Magnus Westerlund: And on that, before we go on, I mean, the final agenda has been posted. We will meet Tuesday, Thursday, and Friday, and the Friday is the last session. So we are going all the way to seventy... 05:30 on Friday.
[00:05:30] Martin Duke: And we will keep doing this to you until you agree to to to ship MOQT. So that's that's your punishment for working
[00:05:36] Alan Frindell: on this.
[00:05:39] Martin Duke: Okay. This is the agenda. Alan sent this out this morning... Or... Sorry. Last night... This morning for some of you. It's just a list of issues. Does... Would anyone like to bash this agenda, or can we just get get going on the discussion? Alrighty. Oops. That's not the button I wanted.
[00:06:09] Alan Frindell: Hey, Martin. Before you do the deck, I was just gonna share my screen for one second
[00:06:13] Martin Duke: Okay. If it's okay.
[00:06:16] Alan Frindell: Or I'm gonna try. Yes.
[00:06:26] Martin Duke: Tried to give you... There. Okay. Happened.
[00:06:29] Alan Frindell: Just so people know, because I I I know most people have kinda tuned out GitHub because the... There's so... Too much going on, and this is sort of no exception. But in response to the issues discussion that we had in Seattle, there are a lot of PRs that are up. Some are editorial and minor design, which follow a more streamlined process. Some are design, which have a more formal process. The ones that are marked merge ready are ready to go in terms of approvals. They're either waiting for time or because they depend on a design change. If you are interested in reading the text before the draft gets published, you're welcome to review there. So I I just wanted to let people know there's a lot going on. This is the list of PRs that's filtered out the ones that need discussion or ones that are parked because they're blocked on something else right now. So we expect a lot of these to merge before the draft deadline. So things are happening. That's all I wanted to say there. Okay. Now we can do slides. And I'll turn my video on so
[00:07:40] Ian Swett: you can see me. Boop. Boop.
[00:07:48] Alan Frindell: Okay. Okay. So we've been talking about this forward pause deal for a while. We've made the editorial change to, like, talk about tracks that are paused and unpaused. And then the only question left is, like, what do we do with the parameter? So 2,002, it doesn't just rename the parameter because it also inverted the bit. So forward one meant unpaused, and paused one meant paused, means paused in this PR. So it's sort of churn and doesn't add anything to the draft, but there was at least one concern raised in Seattle that four people get confused why we call it forward. So... And people have also said, like, hey. You guys keep changing stuff, and it doesn't add any value. So this has enough stamps to go, but we wanted to get a a signal. Like, do people want this change, or people just wanna leave it like it is? And I did see that Magnus commented this morning and said, why don't you just leave the bits how they are and use it as a... Just do an editorial. Just change the name, which is a third option. Aman says bike shed. Giovanni says forward is fine.
[00:09:13] Ian Swett: Would would the purely editorial change be to... Change it to unpaused?
[00:09:18] Alan Frindell: I guess. You could do that.
[00:09:20] Ian Swett: I'm asking. I just don't know.
[00:09:22] Alan Frindell: I mean... Or you could just say paused and paused one means unpaused. Yeah. No. That doesn't seem better, Mo.
[00:09:32] Mo Zanaty: I think we should rename it to paused, and I think we should invert the bit. Two two reasons. One is now the default state is is is on zero, which makes logical sense. And and the the word forward is confusing because, you know, people are thinking, you know, people are thinking about about the meaning of of it in in other context. Pause is clear. Pause means, yeah. I'm just gonna temporarily pause this. So the word forward is is not a good word for it. Pause is much more clear about what it's actually doing And the default state being being zero, it's not paused, makes more sense.
[00:10:16] Alan Frindell: K. Thanks. Magnus?
[00:10:18] Magnus Westerlund: Yeah. I I have no strong opinion. I think the power's name is... Using that is probably clearer for for the readers when you come into this. And... But... Yeah. I was just wondering. I mean, for me, I I can define the bits either way, but that's if people wants to have the bit in a particular way and you're keeping that, I guess, it's... Redefining everything is fine. You're, anyway, gonna touch code if you brought another parameter. So... And that, I guess, is... Might be the easiest to avoid collisions in the... If you change it. So
[00:10:50] Alan Frindell: I mean, if we left the bit pattern in place, we don't have to change the code point. It could be just an editorial change, but it sounds like people want... I mean, and I I mean, I think most point is, like, zero being the default and zero meaning forward... And and the default being forward, both are desirable. So sounds like
[00:11:09] Mo Zanaty: Yeah. And I'm surprised, Magnus, that you didn't mention that RTP has a pause. This this matches RTP because RTP has an RFC for pause.
[00:11:17] Magnus Westerlund: Yes. Yes. It exists.
[00:11:21] Alan Frindell: Okay. I guess... I don't know. I'm suspecting there's a bunch of unvocal implementers out there who are silently cursing this. If you'd like to unsilently curse it, feel free. Martin, this is who wants both.
[00:11:39] Martin Duke: I'm, so I'm famous as being an employer who doesn't really care what we what we... Like, it's it's kind of annoying, but I think it's probably the right thing to do. I I... It's I don't think this will be super onerous in the age of AI to implement because it's a pretty straightforward thing to do.
[00:12:01] Alan Frindell: Okay. Alright. I've... No no no one's gonna be super vocal about it. I've I've... We we can merge this one in and flip it. Long live pause. AI notetaker, please record that we will merge this PR.
[00:12:21] Martin Duke: There is something I... I'm gonna steal a little of your time, Alan. So one thing I I forgot to mention because there's no deadline attached to it is the minutes for Seattle are out. Magnus, thank you for cultivating those. Because we had a weird mix... We... It wasn't MeetEcho. We had a weird mix mix of tools. It was much flickier than usual. So I strongly encourage you to have a look at the the chat minutes, which hopefully, Magnus will put it in the Zulip here in a minute. Look at the Seattle minutes rather, and and Magnus put a LinkedIn Zulip to those minutes and make sure that what you said is is accurately represented there because it it was pretty rough. Thanks.
[00:13:00] Alan Frindell: Is the AI transcript available from the meeting?
[00:13:05] Martin Duke: Yes. But it doesn't know who's who.
[00:13:07] Alan Frindell: Oh, well, at least one could take an agent pointed at the text in the minutes and be like, did the other agent that wrote these minutes do it okay?
[00:13:15] Martin Duke: I I will say that Magnus has done plenty of work on this. I'm not gonna ask him to do more. If somebody would like to take... Well, the YouTube recording is online. So someone would like to point an agent at the YouTube and the minutes and, like, run a check, that would that would be great. But I'm not gonna ask Magnus to do more in this in this regard.
[00:13:37] Magnus Westerlund: So this... I mean, this... All the transcript we have, that's what I've run with the games combined with my private notes as well as the agenda, the slides, everything to make it... Try to actually figure out what's what's applied. So the only thing I haven't had it connected to is the GitHub issues, basically.
[00:13:56] Alan Frindell: Okay.
[00:13:56] Martin Duke: And and when we use... When we don't use MeetEcho, like, it's easy for the ad to be confused about who is talking because MeetEcho obviously has the queue, and I think that's a useful thing. So, like, that's that's particularly rough. So please... It is more likely that something was misattributed than misstated, if that makes sense. So that's worth checking out.
[00:14:22] Alan Frindell: Got it. Okay. And just for the AI notetaker, prior to this discussion about a... About notes, we were discussing issue 2,002... PR 2,002. Okay. Now we're talking about PR twenty twenty two, which is changing the object state machine for Moq t or its proposal two based on our discussion in Seattle. So this is what the PR does. It adds a fourth state for an object. So here's a picture of the state machine as it is... And this is the state machine of a receiver. So all objects in a track start out as unknown. You have no information about any objects. If you receive an object, that goes to exists. If you receive some do not exist signal, which can be in the form of gap headers or could be an implicit gap in a fetch, then that object does not exist. And there are no transitions between those two. If you get conflicting signals at any time, that is a malformed track. What we've added is this idea of gone, and that terminology mirrors what HTTP uses for this, which is if you have lost state somehow and someone asks you about something that you are really unsure if it existed or doesn't exist, you can report that that is now gone, and that is cacheable state. And if somehow there is a due to some sort of reordering on the wire, you get a conflict... You have gone information and then you receive exists or don't exist, that is not an error. And all of those three states other than unknown are cacheable up to max cache duration. So I'd... You'd approve the PR, but he think he said he was still confused, Martin. So, anyway, ask your questions now, Martin.
[00:16:10] Martin Duke: The... Is this different from what we discussed in Seattle? Didn't we have some other state... Was that just a different name? Did you wish you knew where something
[00:16:16] Alan Frindell: Someone proposed the name lost, or the original slides there said persistent unknown and transient unknown. So Yes. But, no, it's not... It is not different from my takeaway from our discussion there, which is that we wanted another state that was cacheable that represented the, I don't really know if that... If the object you asked for exists or doesn't exist, and I will never know. So please don't ask again.
[00:16:42] Martin Duke: Okay. So gone is, like, persistent unknown.
[00:16:44] Alan Frindell: Yes. Okay.
[00:16:47] Martin Duke: Then, what are... I I could live whatever we did in Seattle. So this is just that with a different word, which is
[00:16:52] Alan Frindell: Yes. I... It is. I just wanted to, like, put it all in front of people and before... It is a design PR. You can weigh in there. Yes. And there... This diagram also exists in the PR. Mo?
[00:17:03] Mo Zanaty: I'm confused about what information Gong gives above unknown. I thought you just said it's a permanent unknown, but it shows transition arrows to to exist or or not exist. So it's not permanent. It's transient. How's it any different from unknown then?
[00:17:19] Alan Frindell: Okay. Number one, it is cacheable and unknown is not. So let's give a concrete example. I'm a publisher. I'm publishing a single track. My groups are based on time. Then I restart, and I start publishing again. And then I get a fetch from the relay about object from before the current start. So I don't know if that existed or doesn't exist. I have no state about it. And I am all... So I don't ever wanna hear about it again. I don't ever wanna get another request. I'm never gonna learn about this state. Right? That is a use case where the publisher would send gone. That information is gone. I don't have it. And that is cacheable by Relay or another downstream subscribers for up to max cache duration. Now it's possible that, like, that Relay had multiple publishers, and one of them was a cache from... That does have state about it. So it's possible that those things race, and the Relay gets both a gone from the original publisher and it exists that came from cold storage. It's like, oh, yeah. Here it is. I have it. That is not... The main thing we're trying to address is that used... There was no way to express that before in a way that wasn't a malformed track, And now it's fine. Now it's like, an object either exists or it doesn't. And so gone can be a permanent state, but you... When the sign... It's not permanent, I think I should say, because you can't transition out of it. Exists and don't exist are the only ones that are permanent. You can't get out of those.
[00:18:43] Mo Zanaty: Okay. Do we run the risk of people interpreting unknown as now you can retry me? Because I didn't think that that was the intent. If someone reports unknown, I I didn't think that the intent was expect to retry a little bit later.
[00:18:58] Alan Frindell: So here's the main use case for unknown, which is, like, the relay has a hole in its cache, and the original publisher is currently disconnected. Then someone says fetch. It's like, well, I don't have that information, and I cannot get an answer for you now. But that... You might ask again later, and I might be able to get an answer for you when the original publisher comes back. So that is, like, a use case for unknown and why that is different than gone. Now if you know that publisher's never coming back for whatever, you could say gone. Don't ask again.
[00:19:31] Mo Zanaty: Okay. I'm sorry. I didn't read the PR. Does... Is gone only a a original publisher state? Only original publishers can can issue Gong?
[00:19:39] Alan Frindell: It doesn't say that.
[00:19:43] Mo Zanaty: Does it need to?
[00:19:44] Alan Frindell: I I guess I could imagine a scenario where I mean, a relay might really know that, but if we wanted to make it, like, that restriction to be a original publisher only, this is okay.
[00:20:04] Martin Duke: So if I purge something from a cache for whatever reason, is it unknown or gone?
[00:20:09] Alan Frindell: It's unknown again. Like, if max cache duration expires, you go back to unknown. Right?
[00:20:15] Martin Duke: Okay. Or... Well, whether or not there's a max cache... If I purge it for whatever reason, it's unknown. Okay.
[00:20:22] Alan Frindell: I mean, I guess that is to say, like... Yeah. If you have... If you don't remember that it was do not exist before because you have no state about it, doesn't it seem like it's an unknown? Like, even if at one time you did know that. So I guess my statement of, like, you can't go back to unknown is wrong. Like, yeah, you could you could lose your reception state, and then you're back in unknown. Okay. Mike is saying things about it should not be exclusive to the original publisher. Yeah. I'm just saying, logically, if you can cache it, it seems like it couldn't be exclusive. Yeah. I think that's... Like, you can certainly receive it from a Relay. Like, the Relay has cached it, and then the subscriber gets it. The question is whether the subs... The Relay is allowed to inject it or not. Magnus?
[00:21:17] Magnus Westerlund: Yeah. I think that's... It's like... I think injecting seems dangerous, but, I mean, clearly propagate it downstream. And I think you have to improve the text on before merging this PR on what gone gone means because I think the current text is insufficient to clarify what you actually meant with it. I understand it now after this presentation. So but... Yeah. You... Peep... It's too easy
[00:21:43] Martin Duke: to
[00:21:43] Magnus Westerlund: take the word gone for what gone would imply, and I don't think that implies correctly on what this state means. So I think we will have to write a bit more about what the that state implies in The UK.
[00:21:59] Alan Frindell: Thank you. We will... If you have specific suggestions, please leave them in the PR. We will address them. Otherwise, we'll just sort of do our best to try to make it more clear. And, again, the the terminology was chosen to align with HTTP. HTTP has this exact... There's, like, a four ten gone maybe, or I forget the status code, but it means exactly this. Like, I don't know anything. I don't know about that. Please don't ask me anymore. I may have known about it in the past. Yeah. Alright. Anyway, leave all your suggestions, and we will add them in. This one's two week period. I would like to get this in for the draft deadline on Monday. And I think with with Victor is currently on vacation, and we'll need his review because he has strong opinions about these things. But he should be back in time. So the goal is to get this one in. K. Thank you for the feedback. Ah, allow parsing fetch stream before. Okay. So we talked... This is... 2005 is the PR. Yes. Oh, Magnus, did I... Did you have something?
[00:23:07] Magnus Westerlund: I was on my way to remind you about the PR number, but you you caught it on.
[00:23:12] Alan Frindell: Okay. Alright. We... Though this is related to an issue we discussed in Seattle, which had to do with mandatory to implement track properties, what they can change, and what the restrictions might be on the receiver who's receiving a fetch stream without having seen the track properties. And we've done our best to document what's okay there. There are some questions on this PR. I think the editors are quite confused about what mandatory... How people intend to use mandatory track properties and, therefore, what the rules should be and how we can document them appropriately in the text. And implementers are likewise confused about how there's... What they're supposed to be doing. So I'm asking for the people who think that this feature belongs in Moq-t extensibility, and I sent this to the list also, I want someone to write it down... Write down an extension that uses a mandatory track property to accomplish a goal. And I would like that to be presented at IETf. If nobody can commit to doing that, I'm gonna make a proposal that we remove this feature or replace it, for example, with just code points that we reserve for... When we figure out what we want to do with these in the future rather than have a half baked feature that nobody can articulate a use for.
[00:24:30] Mo Zanaty: Mo? Yeah. I'd like to hear from Ian whether or not he wants to see a PR for... A draft for the gap extension as an as an MTI... As MTP. I'm not personally... I don't have a use case for my needs for either the gap extension or mandatory track properties. But I can I can understand and accept if other people do, and I'm happy to write the draft if, if if people think it's useful? But I I didn't get a a sense of... Luke Luke said, yeah. That makes sense, but I didn't get a sense if there was enough people that cared to make a... To make it a draft.
[00:25:20] Ian Swett: Ian? I'll go real quick just because... Is that... Would that be an example of an MTI track property, to that?
[00:25:31] Mo Zanaty: Yeah. Yes. It would. Just to recap, it was it was making the core draft only deal with gapless tracks. The core draft that only deal with tracks that have no gaps. The extension would define what gaps are and how they're signaled using the prior gap object properties. And this mandatory track property say that the that the track could have gaps. And so only relays that understand this property would deal with those tracks. Every other relay that wants to be basic and not deal with gap tracks could just not declare it, and it only has to deal with with standard tracks, and they don't have gaps. That was the that was the idea behind it, to remove stuff out of the core draft if that's what you want. But then again, if you're trying to remove mandatory track properties, it doesn't remove that. It removes the other track... The object properties for
[00:26:26] Ian Swett: I... For gas. Important thing is we get this well defined, like, what what the shape of MTI is. Right?
[00:26:34] Alan Frindell: And, like, how you need
[00:26:35] Ian Swett: to handle it properly. So I I don't I don't think removing them is directly a goal.
[00:26:41] Alan Frindell: I... When I was, like, asking my agent about, like, what is... What... Like, look at this thing and tell me... Give me an example of what a useful extension might be that uses it. I think the one that it came up with is, like, optional compression. Like, the objects are compressed, and if you don't understand that they're compressed, we mean there's multiple representations of an object with... In a track with the same name, and you have to understand compression in order to receive the track when it has the... I compress this property. But, like, if somebody thinks that's really how compression ought to work, I wanna see a draft that uses it and that we agree that that's the right shape, and then we can make sure that the core transport draft is... Has the right rules to make that work. But I think compression could also work in... Martin says it's a terrible use case. I don't know. If nobody can give me a use case, I'm gonna kill this feature. Suhas.
[00:27:34] Suhas Nandakumar: I I I think, waiting till the IETF 127 is a good call, because this came all recently, and maybe people need to think through a bit bit bit more. And I and I agree, by the IETF 127, we could not convince ourselves that, this is useful. The only reason... Only thing I could... Well, I thought that would... That this would be useful is, basically, when I... When I'm talking to two different relay providers and, and and I need... Want to make sure my... What success ratio of my calls going through relay provider a versus relay provider b, and that's where I want relay provider to have guarantees in the protocol to say yes. I do I do not understand something like that. But, again, can there be in future we might need? I'm all not sure. But, yeah, like like, Alan, your proposal on, like, if we could not convince current existing properties which can fit into this one, having a block reserve and defining an extension for that means might be a good step forward. I I think giving some time until then would... At least at least for me, I I can think... I can spend some some more time thinking if it makes sense or not. Maybe everyone could do the same thing too.
[00:28:36] Alan Frindell: Okay. I... I'm a little bit worried about not having a particular... Are you saying that you will either come forward with... That you're planning to try to make such a draft by 11:16, and you will ask for agenda to present it.
[00:28:47] Suhas Nandakumar: I I I don't... I... Like, I'm I'm a bit, torn here to write an extension draft rather than coming coming up the presentation if I have something, and see if it makes sense to write an extension post the presentation. I would want... Do not want to spend time writing an extension and and throw away at some point. But if it helps... If if I can come up... Come across something, I'm happy to have a five five minutes presentation. That would be my my next steps on this.
[00:29:13] Alan Frindell: Okay. Does anybody else, like, care deeply enough about this feature that they would... And think that they could articulate a valid use for it that they would like to commit to writing one in the next, what is it, three weeks, four weeks? Three? Okay. Moe? No?
[00:29:41] Mo Zanaty: I I just wasn't clear on whether people had any opinion on the gap as an extension. I still didn't get whether or that's useful to pull out of mock t or not. I Is it a net loss if you keep mandatory track properties and and lose gaps, or is it a net gain if you... Which you want is worse, the mandatory track properties or the gaps?
[00:30:05] Alan Frindell: It... Let me put it this way. If if you could actually write that as an extension, like, I think that's interesting, but I don't know for sure that that's the direction I would go. But generally speaking, I don't know. I mean, I think there are people... I haven't thought enough about mock t with dense object ID and group ID spaces. I've spent a ton of time thinking about it as sparse, and I have a cache that implements things in various... You know, in sparse ways it's written down, which I don't know if anybody's actually gonna use, but, like, that's what the rules say you have to do. So I would be potentially interested in seeing what it looks like in a dense world and then somebody has an extension for sparseness. I don't... So I don't know. I guess I... It's interesting, but that's a big extension. But I think I think I'll echo what Ian said. It's just like, if there actually is a use for the extensibility property of of identifying these properties, then it should be in core mock t kinda whether we do gaps or not. Does that make sense?
[00:31:02] Mo Zanaty: I think the core question is what do you hate more? The mandatory track properties or gaps? Which one would you rather see booted from the spec?
[00:31:08] Alan Frindell: I think what I'm saying is that one of them is an extensibility feature, the MTI. Right? And so I think I've said multiple times, like, we need to make sure that the extensibility features in Mach t one are there that will be very hard to add later. And I don't know. Maybe even gaps fits that description. Like, I don't I don't know. I I can't answer your question right now, guess what I'm saying. But if you wanna, like, sketch out some text, and then I can read it and maybe form an opinion.
[00:31:36] Mo Zanaty: Yeah. I'll write it up, but don't think that it's something that I'm committed to that I that I, you know, that I firmly believe in. It's just as a... As an example, and I don't care about this.
[00:31:45] Martin Duke: No. I mean, if
[00:31:46] Alan Frindell: you have time to to do so, you know, I I would read that. Suhas?
[00:31:50] Suhas Nandakumar: I kind of just want to echo, Alan, or you on that thing that the... We... As much as possible, we want to remove the gaps out. The real systems have gaps, and we need to have some way to identify that. And what publishers do certain gaps, especially when... Again, this is not the conversation of this particular slide. Maybe we should not discuss that and more.
[00:32:12] Alan Frindell: Thank you. No. I think so too. Let's not talk about gaps right now. There's maybe an interesting thread on the list if people wanna keep the the conversation going there. That... That's maybe a good a good place to do it. Okay. So what I heard here, AI notetaker, is that Suhas is gonna think about it. And if he comes up with something good, he's gonna try to write something. But if not, he's gonna bail. And Moe might try to write it with gaps, but it's more... Write one for gaps, but it... It's potentially more ambitious, and we're unsure. So TBD. Okay. This was just when I went to try to write, and then I felt like I needed a little bit more information. So when you're updating cache fields or properties... So we previously decided, like, when you get a new object, you don't update the cache. Is that a must not or a should not? So, I mean, maybe there's some extension property that could benefit from asking Relay to update the cache if it receives another copy of the same object with different properties. So that's one open question. And then the second one is one that Ian tells me that he thinks is already decided, and maybe I just didn't record it in my head, which is like, did we agree that track properties can never change? And if I ever get another copy of the track properties that are different, that's, malformed. And, like, does that mean, like, stuff... Max cache duration or default publisher priority seem, like, a little bit not so critical if they happen to change? So I would like input on these two things so we can write the PR
[00:33:48] Suhas Nandakumar: to us. A clarification question. So if if someone changes a track property, they should send a request update. Right?
[00:33:56] Alan Frindell: No. You can't use... Request update does not offer a way to change track properties.
[00:34:01] Suhas Nandakumar: Some of the track properties had that option.
[00:34:04] Magnus Westerlund: Okay. Sorry.
[00:34:05] Alan Frindell: You can change parameters with the request update, not properties. Got it. Got it. Thanks.
[00:34:13] Mo Zanaty: I believe the confusion came from not changing a track property, but, can a relay ever add a track property to a track? If it can, then, obviously, you could get different things from different relays. If track properties are meant to only be original publisher of things, then we should explicitly say that in the spec and not allow relay to add it. But I thought people had utility for a relay adding a track property like, you know, a geotag or something or, you know you know, authorization. I confirmed, you know, that this this off blob or something like that, or I test to something. So I thought relays would add a track property, in which case, the diff... You know, relays that are not colluding may add different track properties depending on where the track came up. Right?
[00:34:58] Alan Frindell: What is... Okay. It... Let's assume that's true because I think there are... Is utility in letting relays manipulate track properties. What is the cache supposed to do when it receives another copy of the track with different properties?
[00:35:10] Mo Zanaty: I think I think it says right now that you you you take whatever the current track property set is as a whole. You don't try to merge them. It says something like, you know, you have to take this entire blob of track properties from the latest publish, and that is the track properties that you cache, and you throw away the old track properties that... If you had any before.
[00:35:31] Alan Frindell: Okay. Update. But it's up... Update, but it's
[00:35:34] Mo Zanaty: Oh, yeah. Yeah. Yeah. Yeah. I'm talking publishes, not not updates. You have to in a publish, if you could track properties, you take the entire set of track properties and you cache them. If you had the ones before,
[00:35:44] Alan Frindell: you blow them away. Or let me try to state it more simply. New set always wins?
[00:35:49] Mo Zanaty: Like Yes.
[00:35:49] Alan Frindell: Is that what you're saying? Yes. Okay. That makes sense. I do see, a couple of should nots in the chat, but then one must not. Does anybody else wanna help provide? I'm not sure I'm getting a strong signal. Moe, I don't know if you're frozen or if you're still
[00:36:13] Mo Zanaty: No. I'm I'm I'm here, but I... I'm trying to explain why the current text is the way it is because people did not wanna prohibit relays from adding a track property. I thought that was useful. But then they realized that there's no way that the relay network is gonna agree on a common set of track properties across the entire relay network. So if you get two publishers from two different relays, you gotta malform the track and not be able to deliver the track? No. That doesn't make sense either. You just accept the latest version of the track properties. But you don't try to merge them. You just accept the only the latest version.
[00:36:43] Alan Frindell: Are you saying that for object properties too? Because although I think this decision was made in an interim where I wasn't present, it sounded like people were like, don't update the cache if you get another object.
[00:36:56] Mo Zanaty: I forget what it says about object properties, but I would
[00:36:59] Alan Frindell: guess with the text I know the text you're talking about, and I actually thought that it referred to object properties and not track. But it probably ought to have... Let's assume it applied to both because that would have made the most sense. But then I'm... It sounds like people were like, no. Just don't ever update your cache properties. They're in lies madness. And the stale ones all... Whichever the first ones into your cache are just the ones you serve out of cache forever.
[00:37:29] Mo Zanaty: See, I'm thinking off the top of my head. I think it makes sense that it applies to both.
[00:37:34] Suhas Nandakumar: Yeah. I I didn't know if I remember the context from the previous meetings that we had. The... If I... The the idea there was if an... Someone can send a good object and then... With the correct properties and then they send another object with kind of poisons, what that would mean from going forward. And we wanted to kind of avoid that. But but, again, if the Relay can insert a property, then it has to update its cache. If not, it's it's inserting something which does not reflect the the source of truth from that point in onwards. I I think probably the the thing we need to say is that whenever either object or track properties inserted by... A new properties inserted or updated, then it has to also update cache properties to to reflect the new state from there onwards.
[00:38:23] Alan Frindell: Okay. I think what I'm hearing you saying is that you agree with Moe and that the existing text is better than don't update cache. Meaning, when you get a new object or track, you replace... You update your cache wholesale with the new properties from the object or track.
[00:38:42] Suhas Nandakumar: Yeah. I I would I would think so because if... I'm I'm trying to think of, you know, there are really an application which really needs or really just really needs to update for for well behaving, whatever, then then that... That's a... That that makes sense. But but but for a malformed or or non good application, which wants to kind of corrupt it, it... That that has the end to end impact. There's not much we can do at relay level to figure out why something was done right or wrong. All we're getting is an object with new properties. What would be wrong is that every every other object is sent with a total different properties across different relays. And that that would end up becoming hard, especially to to have a coherent state. But also on the other hand, if a property need not have to be... If if an origin publisher wants a a property that should not be changed, then it should include that in some kind of an authentication or other other crypto schemes to make sure to catch some of those things being happened too. We can also make Yeah. Sorry. One more. Like, trying to avoid a lot of burning up, burning in lot of application logic in in in in a relay code.
[00:39:51] Alan Frindell: Yeah. I... We can also let... Potentially let the people who define the properties define what happens. You know, for example, like, I'm thinking about my time stamp draft, which defines both track properties and object properties. And if we say it's okay to update... And and and the track property changes the interpretation of the object the object property. Now maybe that's a poor design on my part. But, like, if the original publisher was like, this track has a time stamp... The time stamps are mapped to the object IDs. And so now I'm interpreting the objects that I received with no time stamp in a particular way, and then it publishes a new version of the properties. Like, actually, just kidding. There's no mapping. Then all these already published objects have, like, a totally different interpretation, and that's not good.
[00:40:33] Suhas Nandakumar: Right. Like, one one counterexample for that would be just, like, I'm saying this property is h two sixty four video stream, and we love this thing you say it's a v one. Again, Relay can't do much about it. Right? At at the end application is the one that could suffer. So I'm trying to see how much of the bells and whistles we need to kind of protect against here.
[00:40:55] Alan Frindell: I mean, some of that... I mean, certainly, Relayers can't be changing properties when the property is defined to not be... To be original publisher only. Right? Like, that's fine. Okay. I think what I'm hearing is sort of a decision to undo the earlier decision and keep the text we have in the spec, which allows update as long as you update... Maybe should update to the newest cop... The newest properties without merging the sets, both object and track. Does anyone wanna say that that's not the right way to go?
[00:41:42] Ian Swett: Ian? I thought we decided the opposite thing before, but now I have no idea why. I don't know. I'm a little bit concerned about, like, thrash back and forth, but I don't have an objection to it, like, conceptually. I'm just
[00:41:58] Alan Frindell: What would your HTTP cache do with the headers?
[00:42:02] Ian Swett: We would update it.
[00:42:04] Alan Frindell: I think we would update it.
[00:42:06] Ian Swett: So I
[00:42:07] Alan Frindell: mean, it depends, actually. I think... No. Or we we... I don't know. Sometimes we update it or sometimes we say, you can't change the headers.
[00:42:17] Ian Swett: So...
[00:42:18] Martin Duke: Yeah.
[00:42:18] Alan Frindell: Yeah. Moe?
[00:42:21] Mo Zanaty: I was just telling Mike that for for the case where you actually want something important to be immutable like signatures, yeah, we have immutable properties do exactly that. So for the other properties that are not immutable, they are immutable. So you can... You know, a relay can change them. That means if the object flew through two different relays for redundancy or something and you got it somehow two different ways, you would have a... You would have two different properties. So I don't think we could ever say should... Must not or should not. I think it's okay.
[00:42:56] Alan Frindell: So immutable raises another question. So you're gonna have immutable. Can I replace the entire immutable block? Like, obviously, the Relay can't add or remove or modify things inside an immutable block. But if it gets another copy of an object that is not byte identical to a previous immutable block, is that okay, Suhas? Suhas, are you there?
[00:43:34] Suhas Nandakumar: I was talking to a muted thing. Like, as as a publisher, if I change something in my crypto that would require my properties to be changed, to have a new set of, new updated versions in mutable immutable properties, then I would expect that to go end to end. If not, every other object that'll be sent, if it was sent to the previous immutable block from the relay down, it will fail my signature verification on the other side. I think that this property of, this thing is that immutable, Reliq should not modify, but it it it it cannot expect, you cannot enforce that. Only enforcing point is at the end when you're trying to verify, if something has modified. Integrate has been modified or not.
[00:44:13] Alan Frindell: I understand that property. My question is if we if we say that you can update the properties of something if you get a new copy, does that also include immutable? Like, if I got a new copy of the object and it had a different immutable properties, I should also replace.
[00:44:28] Suhas Nandakumar: Yes. Yes. If if it came from original publisher, but I... I'm I'm... The RelayHad does not have a way to verify. That's the only... That's that's the challenging part there. If if there are the... If there are chain of relays and all of relays block... Chains that immutable to block and and the downstream really updated it, the only point... And only point you'll know it at the end subscriber.
[00:44:49] Martin Duke: Right. Magnus?
[00:44:52] Magnus Westerlund: Sorry. I don't understand how... What the properties you're talking about could work if the object is immutable itself. How
[00:45:02] Alan Frindell: Right. It it it... I think that... That's sort of what Suhas is saying, which is just like, assuming the content never changed, which is not supposed to in mock t. And if we're talking... And the reason why you're using immutable is because it's part of your AAD in end to end encryption.
[00:45:17] Magnus Westerlund: Yeah.
[00:45:18] Alan Frindell: And there's only one correct immutable properties, and something is going to break.
[00:45:23] Magnus Westerlund: Yep.
[00:45:24] Alan Frindell: But my question is, do you want the relay to enforce that, or do you want the end subscriber to just be like, yeah. Well, this... You screwed up original publisher somehow because this doesn't decrypt.
[00:45:35] Mo Zanaty: Yeah.
[00:45:35] Magnus Westerlund: Yeah. Yeah. Sorry. I I I... Personally, I struggle here a bit with seeing why you would need to have object related properties to actually change here, but that's... Yep. And it seems to be much more simple to have, but that's that's me. I'm not building one of these caches, etcetera. So... And and what you might... If those properties... But... Yeah.
[00:46:01] Alan Frindell: Okay. No?
[00:46:04] Mo Zanaty: I think it... It's simplest and makes the most sense to leave the relays out of this that they just they just see properties. And if they see a change in the property, then they just replace the entire set of properties, whether it's track or object. They are not in the business, like Suhas said, of enforcing the immutability. Immutability is a is a end to end level feature unrelated to the relay network. I'm not even sure why we decided we needed to document the immutability other than just, like, to point people where to go. But how does it actually impact the relay network? I don't think it does. Right? But they can't enforce the immutability, so they they shouldn't, shouldn't care about replacing the entire set. The the endpoints to verify that.
[00:46:52] Alan Frindell: The reason I can answer quickly about why immutability is the way it is, it... Most people take the serialized immutable block and use it inside the AAD. So, like, literally nothing can change there. You can't insert... But properties are delta encoded. So if a real is allowed
[00:47:07] Mo Zanaty: Why did why did we say did we say that's needed to be, in the in the core draft? Why did we say the real is need to care?
[00:47:14] Alan Frindell: The relays just need to know that they're gonna add a property. They can't add it inside this block because that will screw up the AAD.
[00:47:21] Mo Zanaty: Right. But the relay can't mess with any property in general if it doesn't know or understand the property. Right?
[00:47:27] Alan Frindell: Right. No. But just even add... Let's say I have... In my immutable block, I have two properties, a and b or a and c. The relay is allowed to add property b. And if its code point is between a and b, it will get injected in between them, and the bytes will change. So that's why there's a separate section where it's like, this set never changes. This set is changeable.
[00:47:49] Mo Zanaty: Yep.
[00:47:49] Alan Frindell: Think about it. Also, talk to Colin. He's the one who wrote the PR. Martin?
[00:47:54] Martin Duke: Endpoints can't enforce immutability if there are multiple publishers and presumably the relay is sending only one copy of the object. So it has to do something to to protect the relay, every... Its end subscriber.
[00:48:12] Ian Swett: Okay.
[00:48:13] Alan Frindell: I think... Okay. I I think we've converged back to what the... Mostly what the draft currently says, but possibly with a little bit more language around both track and object properties. And... But, again, I'll offer... I don't think anybody has said no that we need to not do that, although there's a lot going by in the chat that I'm not reading. So if anyone wants to articulate a different vision, now is the moment. Okay. AI minute taker. We are reversing the previous decision, and we will keep this sort of update cache logic in the draft. Redirects. This is when they got filed in the middle of the Seattle interim. Said redirect should not be able to change a publisher's track namespace or name. So if we look at, like, e g HTTP, you can send a post to some resource, and the server is absolutely allowed to redirect you to some other path for that resource because it moved those things around for whatever reason. So it can change that, but it it indicates that, like, the underlying resource is the same. It's just in a new place. The question is, can we... Does mock t redirect support the same capability? If you gotta publish for foobar, can the server say, actually, I want you to send that publish again, and then I want you to send it for new foobar. Martin?
[00:50:02] Martin Duke: I can see why this would be useful, but I also see this is potentially like a... Like an attack vector. So... Because you don't authenticate or redirect.
[00:50:17] Asad Saeed: Don't authenticate or redirect.
[00:50:21] Alan Frindell: I think your attack vector probably also applies to HTTP redirects if you have one.
[00:50:26] Martin Duke: Well, if we can all agree, HTTP will never work.
[00:50:28] Alan Frindell: Yeah. There's no way people could ever use HTTP to transmit video. Agreed. I think
[00:50:39] Martin Duke: Like, conceptually, how is it different from a published namespace?
[00:50:43] Alan Frindell: So published namespace is sort of different. Right? Because it's like, I am a publisher, and I have tracks in this namespace. Having the other side say, no. You don't. Your tracks are actually in this other namespace is, like, kind of strange. That's why that seemed odd to me. But publish is like, I'm trying to publish here and being like, oh, actually, we don't put those things there anymore. We put them over here, which is, I think, sort of why post is... Supports redirect.
[00:51:12] Martin Duke: So is this specifically for publish that we're Yes.
[00:51:17] Alan Frindell: That was... The context of the issue is is around, well, I
[00:51:20] Martin Duke: think it
[00:51:21] Alan Frindell: said publishers. So I added clean publish namespace here. Mhmm. Suhas?
[00:51:28] Suhas Nandakumar: Like, I... I'm I'm currently trying to implement a load balancer based on mock, and I think this feature will be helpful there where publish comes to a load balance, and that that can basically say, you know, you you can you can go redirect. And if you can use this namespace there, it might it might be useful. But I've not thought through this. Most of the common use cases is I got... I do... I get a published name search for full slash full slash bar. I say, hey. Full full slash bar, go to relay number three. That's that's the that's the most common one. If if if... Well, it's not not thought through to say a full slash bar, go to bar slash something else or, you know, x slash y. Yep.
[00:52:11] Alan Frindell: Okay. Yeah. I I noticed... Moe, go ahead.
[00:52:17] Mo Zanaty: Sorry. More of a question than an answer or an opinion. Before, we just said, we used to have subscribe, and you can immediately say okay while you waited for subscribes to percolate upstream. Cancel that, and we said, no. You must wait for the the upstream to respond to your subscribe before you do your downstreams. Okay. Does publish have anything like that? Does publish have... If I get a publish in, do I have to do the publishes as a relay downstream and make sure that I get the publish okays before? Or do... Or can I immediately accept the publish anyway?
[00:52:46] Alan Frindell: I believe you can immediately accept the publish without waiting for the... Like, rather than establishing it end to end. I think one reason is that publish can fan out, whereas subscribe fans in. So it... What does it mean that your publish got end to end? You have to wait for every subscriber on that track to, like, acknowledge it before you can acknowledge the publisher. And, also, publish has forward one or paused zero, meaning the the bytes... Like, the objects come immediately anyway. Like, it didn't even... The publisher didn't even wait for the okay before it started sending you the So I don't think you need to wait.
[00:53:21] Mo Zanaty: Okay. Then in those cases, the redirect does seem like it could be useful. If we required the response all the way downstream, it didn't seem like it'd be useful. If it could steer what happens downstream, then then I think it could be useful to do a redirect to a different namespace.
[00:53:38] Alan Frindell: Okay. Suhas, I see a com... I... I'm trying to read your whole comment in the chat, but I see something about e t e e. And then, I mean, I can imagine, like, for ex... I think when I asked my agent about this, it was like, hey. By the way, secure objects uses the full track name as part of the AAD, so you can't... You know, it's possible that the the publishers are... Like, the publisher has made an object under new... Under Fubar, which, like, absolutely has to be under Fubar, and it can't be in a different
[00:54:07] Mo Zanaty: I think that was for the last, last point, Alan.
[00:54:10] Magnus Westerlund: Yeah. That... That's for the
[00:54:11] Alan Frindell: previous ones. Oh, oh, oh, never mind. Okay. Good. I'm lost then.
[00:54:15] Suhas Nandakumar: For... On this one, I would say, like, redirecting it to... I I think the the more common use case I can think of is that I got a namespace for slash foo slash bar. And as a load balance, I'm basically saying anything slash foo go there because I have a much better way to handle that one set of relays. But I'm I'm really not be able to convince myself, at least, at this point in time. Can can enter namespace be flipped around or in a different form to go and handle it? That would basically means that, a publisher who's like Alice Video will have to become like Bob Video. Right? I I... That that that I'm not sure. But any parts of the namespace that's... Matches the prefix, I I I think there's definitely a use case where I... That that that use... That would be useful.
[00:55:02] Alan Frindell: I mean, I think what you're saying is you wanna change the connect URI, but you're not trying to chain... You're not normally trying to change the namespace the track is published under.
[00:55:11] Suhas Nandakumar: Right. Right.
[00:55:14] Alan Frindell: I think that, like, I don't have an immediate use case for it either, but I also think that, like... I don't know. I mean, maybe the answer to that is, like, we should remove the capability entirely. But, like, sometimes... I mean, when people do this in, like, you know, large deployments, it's because they have some legacy thing where they're trying to move... They're trying to reorganize stuff. And they're like, yeah. You're an old client, and you didn't get the memo that the path is new. So I'm telling you where the new thing is. And, like, it's sort of trying to make sure that we keep some of the lessons that HTTP learned the hard way about that.
[00:55:54] Asad Saeed: Is there any, I'm sorry.
[00:56:00] Alan Frindell: Oh, go ahead, Asad. You're fine.
[00:56:02] Asad Saeed: Is there any, protection against who you can redirect to? Like, does the new session know that they were redirected to?
[00:56:17] Alan Frindell: The the session will see the redirect and can obviously choose to forward or not forward, or As as in follow it or not follow it.
[00:56:25] Asad Saeed: Yeah. As in, like, some of the HTTP learnings, right, where you have... You can protect yourself by the client not allowing itself to connect to you, right, because they weren't in... You're not allowed to redirect, right, depending on the type of call. Right?
[00:56:49] Alan Frindell: So it's This is like wandering into CORS territory, which, like,
[00:56:53] Asad Saeed: makes me so so uneasy. Exactly. Right? Like, oh, is is there any any risk here about... Especially around this renaming? I I don't know if it makes sense.
[00:57:06] Alan Frindell: That is a good question. And I think it makes me... It leads me to think that maybe I will table this one into IETf-one 27 and try to go find some HTTP CORS people who can tell me what they wish I... They knew when they started before we forge ahead here. This capability requires a security analysis that cannot happen in this call. Namespaces are tied to authentication. Yeah. I'm somewhat inclined to agree with you, Martin. I'm gonna I'm gonna go seek out more advice on this topic. Moving on, which I believe is also redirect related. Issue 2,000. Congratulations, Michael, for getting the round number. Next up will be issue 3,000. Good luck to all our competitors. So what happens when relays follow redirects? So if a relay gets a redirect that changes the track name from a to b, are the objects it receives cash under a or b? And then I think related to that is, like, malform tracks. How does following a name changing redirect interact with malform track rules, e. G, like, are are they actually the same content or not? And forwarding required. Should relays be required to forward redirects to the subscriber rather than following them themselves when it changes a full track name. So I admit I have not thought deeply about these issues, but I don't know, Michael, if you're on, if you wanna say more about it.
[00:58:49] Michal Hošna: Well, I thought about it maybe a little bit deeper and talked with Victor about it. And we kind of both agreed that we either must do... Must follow or never follow. And as the current redirect is written, kinda never follow and always forward is kinda the only solution, or or we need a way for the the sender to say if this should be, like, followed by the intermediate... Intermediaries. Because, like, the semantics of... Do you want relay to, like, follow a redirect, and do you want... Or do you want it for Wari to be, like, original requester are very different.
[00:59:31] Alan Frindell: Okay. I think I see where you're going. And if I'm... Like, at least in my proxy systems, my proxy's HDB proxies don't follow redirects. Like, if the origin server says, like, this is getting redirected, like, I don't try to follow that internally and deal with all these problems. So I I think maybe I'm coming to the same place you and Victor did, which is, relays don't fall... Don't follow redirects. But then again, what's the... The end subscriber can't do anything about it either because the subscriber came to the relay.
[01:00:02] Michal Hošna: But, yeah, but, like, the sub... Subscriber should... Also, there's, like, different u u... URI and different track name are also, like, very different ways of handling something because, like, one is in session and the other one is Ah,
[01:00:18] Alan Frindell: I see. So you're talking about only for ones that change the name?
[01:00:22] Michal Hošna: Yes. Because, like... Or, like... Actually, it's... The the problem exists for for both, but I feel like we have, like, four different redirects. Like, either follow or not... Or forward and either different URI and different track name, and all four of those states probably need, like, very different handling and not be meshed into... This is one thing.
[01:00:49] Suhas Nandakumar: That's a
[01:00:50] Alan Frindell: lot of things to think about. Mo?
[01:00:53] Mo Zanaty: I think we maybe didn't think about redirect in the right way because there's two main use cases for redirect. There's the content itself, you know, specifying a redirect. The content itself is moved or something like that. And then there's the, you know, go away aspect. You know, the... You're you're you're moving the service to to somewhere else. And those are two very different things, and and they may need very different behavior. Because, certainly, if they... If it's content level, then I don't see how the relay network should be involved in that. The relay network is not making content level decisions. So I don't think it makes sense for the relay to ever, you know, participate in in something like that. That should be out of band end to end somehow. You know, you've talked to some other, you know, thing that that tells you what your content... How did you get the track name in the first place? You know, was it a catalog or whatever? Whatever you... Whatever's ground truth you're using to construct your URIs and your track names, that's the ground truth you need for those content level redirects, not the relay network. But the service level redirects because of, you know, up and down, that does make sense to be in mock, and that does make sense for the relays to be able to resteer you, you know, for load balancing. So I think we need to separate those two things.
[01:02:11] Alan Frindell: Mhmm. Okay. Michal?
[01:02:15] Michal Hošna: There's also... I agree with Moe that the service level is like a... Like the URI and the content one being, like, the full track name are very different use cases, and we should think differently about them. When... I do feel that we need kind of maybe both in the core or many extensions will kinda rally on having the content one. When I was thinking about the... And now we are spinning off, but I think this is the last slide anyway.
[01:02:49] Alan Frindell: You got a couple more, but go ahead. The
[01:02:52] Michal Hošna: issue when the whole immutable discussion and also when we are talking about watermarking. Whenever we talk about we need to follow immutability, but we want some kind of special tracks for each subscriber or group of subscribers for the relay or some kind of application application relay being able to do the content re... Redirect to to be able to follow the immutability rules of mock t seems like very important thing that we kinda need in the core.
[01:03:25] Alan Frindell: Okay. I understand what you're talking about. Actually, the last slide in this deck has a pretty picture that might help people in... Visualize that or or discuss it. I do... I I think the high level bit from this slide that I've taken away is that, like, we do need... The draft does need to call out... First, I was gonna try to kill content level redirect until what you just said, and just say, like, all redirects are just to a new service. But I think we do need content level at least to some sort of extensibility. And so... But the draft should potentially treat them differently. Okay. It may take a while to get through this. I kinda don't wanna skip to the slide that explains it, though, because I think it is the potential to face plant, and I wanna get through the next one first. So I will just... I know I'll jump ahead and show people the picture. Okay. Picture shown. And then we'll we'll go talk about this issue. The end of group bit. Even if we close this issue, Martin will still not be happy, and he'll file another issue about it. I'm sure. The end of group bit on multi object streams. So this was... It was already a little bit tricky, at least from an API perspective, to know when to set this bit. We tried to deal... Address with that. But then Martin found that filters make it a little bit more complicated. So you might be a relay, and you might be like, oh, okay. Like, this stream from the original publisher has the end of group in it. I will open a stream that has the end of group bit set. Then you're sending objects. Then the the subscriber says, oh, actually, I'm changing. I only want the red objects. And the final object in the subgroup is blue or in the group is blue. So it gets filtered out. So now you have problems about how to end that stream. So there's a few options. One is we say, when when when there's a fill... Filters of any kind, all bets are off. You know nothing. So even if you get a fin at the end of your subgroup that had a or g bit in it, the last object was or was not the end of group. No one will ever be able to tell. Next time, don't use filters. That's how fetch works today. Like, fetch tells you about object gaps, but if you put a filter on your fetch, you don't know anything. Was it filtered out? Did it not exist? No idea. That's one option. Option b, terminate that stream with a reset and not a fin. So if the relay sees that the the actual end of group objects got filtered out or the original publisher for that matter, you just terminate that stream with the reset instead of a fin that's consistent with the current definition. So somebody who... You can only interpret the end of group object if you got a fin. That probably works best if you have reset stream at. Hopefully, everybody's getting there. Three, we could scope this feature down to only single object streams. So that was sort of what... Like, we originally put this in for datagrams, then we put it in for single object streams. But, anyway... So we can say, like, oh, if you get a second object on a stream with EOG, that's that's an error. Like, you should have not done that. But the... It's also... I can maybe imagine a case where, like, even your single object, like, case, like, you op... You sent the header, but then all of a sudden the object got filtered for some reason. I don't know. Like, we could say you can't do that, but, like, that might also be a problem. So... But that's the thing. Or we could just take this bit out entirely. And if you wanna send it in a group and a subgroup, you gotta send it in a group status, which is, you know, minimum three bytes, but possibly longer if your object IDs have long gaps. The end of end of group bit. Okay. Here we go. You guys fight. Tell me which one you want. Martin?
[01:07:23] Martin Duke: Alright. I'll go. You already have my feedback, but since no one's talking. I think c would be fine. It seems to solve the worst use case. I don't really care about the use case. I'd be happy to go with d. B is janky. I guess if you really wanna send it, you could always reopen the stream and then without the EOG bit and the send fin if you wanna make sure it got there. A, I I am really unhappy with... Like, here, the... We have this spec... We have mechanism a and mechanism b, and mechanism a and b, like, don't work together at all. So, like, a is totally broken if you do b, particularly because, like, it depends on the filter. Like, I think a location fill... There's, like, very complex logic on whether or I can believe an EOG bit, which seems very bad to me. I really don't wanna do that. Yeah. I've said enough.
[01:08:16] Alan Frindell: Okay. Thanks, Martin. Wait. Let me just make sure I got what you said, which was you... Your preferences are c, d, maybe b, but don't do a?
[01:08:29] Martin Duke: Yeah.
[01:08:30] Alan Frindell: Okay. Steven?
[01:08:33] Mo Zanaty: I'm kinda b. C would break. Currently, we send the whole group in one stream, and we set EOG on it by default. So c would make that malformed.
[01:08:48] Ian Swett: Mhmm.
[01:08:49] Alan Frindell: Yeah. In that case, if we did c, you would have to send an end of group object marker at the end of the group, which is at least three bytes.
[01:08:59] Mo Zanaty: So What? Three, they could change.
[01:09:05] Magnus Westerlund: Yeah.
[01:09:08] Alan Frindell: Okay. Suhas?
[01:09:09] Suhas Nandakumar: I think in the in the Seattle interim when we discussed about the fetch and what's the last object of the fetch if the... We we basically concluded it's not the object with EOG, but it's the object before the... That... That's the real object. That's what's the last object is. If if you apply the same logic here, if if a filter filters was last object, that includes the EOG too because EOG is not a real object. Right? It's it's it's basically saying that it's a marker object. So if if someone does filters... Filter out last object, then that also includes the thing that says the last last object, which is the EOEOG one.
[01:09:46] Alan Frindell: But... Okay. But does that... I think I see where you're going, which is that the EOG bit is a compressed way of saying there's an EOG object at the end of this stream that has a particular form, which you can expect.
[01:10:03] Martin Duke: Right.
[01:10:03] Alan Frindell: And if filters are applied, that object is implicitly filtered out, which is... You're saying a, I think.
[01:10:17] Suhas Nandakumar: I don't think so. Give give me a second.
[01:10:19] Magnus Westerlund: Sorry. Okay.
[01:10:24] Mo Zanaty: Moe? Just to clarify Martin's original concern, what what, is there a problem that, that not knowing the group, being ended causes? Is is there a resource problem, that that we're trying to solve? Not being able to do cleanup or something because the end of
[01:10:46] Alan Frindell: group It's actually not a... I mean, I I... If I can jump in, the end of group signaling is potentially is end to end. Right? Like, if I, the app... If I, the publisher, want the subscriber to know my application my application may need to know the group is now over because it is gonna do resource cleanup or make different decisions based on knowing the group is over. The... There really has minor use of this signal, which is it can prevent it from it knows where things don't exist. Right? End of group means implicitly every object from here to the end of the group is DNE, and I would never need to fetch for that. So, like, it helps relays a little, but it's also an end to end signal. So it's not great to lose it.
[01:11:28] Mo Zanaty: I'm trying to figure out whether or not it's important enough that we need the end of group all the time, in which case you could do something like, you know, every hop always somehow includes the end of the delivered group. I think today, we we mean... By end of group, we mean minted, or not, you know, as minted... You know, as created, this was the end of group object. But we could reinterpret as as for delivery if we need to. If for every hop, it's important to understand what was the delivered group versus what was the originally minted group. We could rethink things. But I'm not clear whether or not there's really a problem that at delivery time, it's critical to know the end of the group.
[01:12:14] Alan Frindell: I think it's more... I think the, like, as minted signal is the one we're trying to convey right now. There isn't the one that you're talking about, which is, like, end of delivery group. I don't know if it's useful or not. I would need to think about it.
[01:12:31] Mo Zanaty: Okay. Then if it's only the minted group number, the object number that matters for each group, then is it acceptable to, oh, it doesn't even work. I was gonna say, can you reinterpret? Like, if the original publisher delivered it as marked on an object, is it acceptable to deliver that as, status object instead?
[01:13:01] Alan Frindell: That... I think those kinds of swaps are okay. Right? This is just another representation. Those two representations are are identical. So the... Those are not know at least one relay out there that always... It never use... I think it never uses EOG bit. It always says status object. So even if you publish to it with EOG bit, it strips that and says, oh, this is the end of group. I'll put a status object on the end of it.
[01:13:28] Mo Zanaty: And what if that what if that object was not delivered?
[01:13:31] Alan Frindell: The end of group status... Like, say, because of delivery time out or something?
[01:13:34] Mo Zanaty: No. No. No. The status was delivered, but does does it have anything in it besides just the stat that this was the end of the group?
[01:13:43] Alan Frindell: No. It doesn't say Just the
[01:13:45] Mo Zanaty: markup number is in here.
[01:13:46] Alan Frindell: Just the odd... It has an object number, which is, like, the beginning of the nonexistent range in the group.
[01:13:53] Suhas Nandakumar: And that that... That's the marker object, Mo. It's it's basically says that this object is a marker object, a tombstone kind of a thing where it's done versus you have an actual...
[01:14:02] Mo Zanaty: Yeah. What I'm saying is is there anything in that object? Is is is there anything No.
[01:14:06] Alan Frindell: We... There's no properties in it.
[01:14:08] Suhas Nandakumar: And payload is just that.
[01:14:09] Mo Zanaty: Signal. And there's no delta. Right? It's just... It's it's It...
[01:14:13] Alan Frindell: I mean, it normally has... It normally uses, like, object... The object ID delta zero, which means one greater than the previous. If you knew the actual end of group object number and filtered it out, you could definitely put the EOG... I mean, maybe that's another option which is not here, and maybe that's That's
[01:14:30] Mo Zanaty: where I was going.
[01:14:32] Suhas Nandakumar: Mean, that's the give
[01:14:33] Mo Zanaty: the exact number even if that number was filtered out.
[01:14:37] Alan Frindell: Yes. That would still work. Although, don't know what the spec says right now about what happens when the EOG is bit bit is there and the EOG object is present, but, like, we should... Maybe we can fix that.
[01:14:50] Suhas Nandakumar: Think I I think anything with filter, if not not just last object, anywhere you filter in between, the subscriber would have no clue when the group ends unless we want to make it very clearly to say that, by the way, the group ends at this point, then really adding that object is useful.
[01:15:10] Alan Frindell: Okay. Does anybody... Maybe Martin, is this something that you're gonna live with, or do you wanna speak against it as an option e?
[01:15:19] Martin Duke: I'm sorry. So the the proposal is that we change the end of group bit to mean, like, something mutable instead of No. Mutable
[01:15:29] Alan Frindell: If you received an end of group bit and you filtered out the end of group object, you insert an end of group status with the correct object ID signaling the beginning of the nonexistent range in the group. So if there are 30 objects in the group, zero to 29, and object 29 got filtered, you would still put an end of the group status with object 30 in that group, and that can't be filtered. What's I think this is, like, the least option. I think you're trying to murder this feature, and somebody just made it more complicated.
[01:16:05] Martin Duke: Well, I I, you know, I don't wanna... I... Well, like, murder it. Like, I... I'm happy with c. I think c is very unambiguous logic. Like, what is what is so I I I... As Alan has hinted, I have, like, two layers of objection to this. Like, one is that there's just a weird... Lot of weird ambiguous... As a receiver of this bit, there's a lot of ambiguous cases that you sort of have to deal with. And and they're hard and they're buggy, and I had a lot of trouble in in Interop dealing with them. So... And then that's not like a deal breaker, but it's super... I think it's it's problematic without being a deal breaker. And now, like, there's... Now that we have filters, there's other thing where, like, the semantics are totally broken. And so... Which is why I filed issue against it. I I don't know what the rules are with filters and these EOG objects. Like, I have no idea what the what
[01:16:58] Alan Frindell: the rules say about. The only thing you could possibly filter... They can't have properties or unique priorities. So the only thing you could use to filter it out is the object ID filter. And we should we should explicitly ban that, which is like, you cannot filter this one out. I don't know, Moe, if you have a thought on that, but I I
[01:17:18] Martin Duke: think Well, so, I mean, like, the object ID filter is the the obvious case that I provided an example in the in the issue where I said, like, okay.
[01:17:25] Alan Frindell: So you you can filter out the end of the last object in the group, but you can't filter out end of group markers.
[01:17:32] Martin Duke: Right. So the object ID filter, the exception is you will still get EOG markers, like, always? So, like, if I have an explicit marker, I get the EOG object any... So say say I have an object ID zero filter. So do I now always get the e... So do I always get that and EOG with some number, or is it just in this weird, like, in a group bit case?
[01:17:57] Alan Frindell: I I think the way I would spell it is filters don't apply to status objects. You cannot filter status objects.
[01:18:07] Martin Duke: That's what I'm status objects regardless of my filter.
[01:18:10] Alan Frindell: I I... That's a proposal that I might write. And then I might say that, like, explicitly when we're talking about end of group, which is, like, if you used EOG bit and the last object in the group got filtered, it really needs to insert... Or publisher needs to insert the end of group status or reset. Like, so it's sort of b plus e. But I can write this down, and you can hate on the proposal if that makes you feel better.
[01:18:39] Martin Duke: Well, I want... The last thing I wanna do is create more work for you, Alan, anymore than I already have. Yeah. Like, are people really, I I just don't understand why people are obsessed about three bytes on a multi object stream, I guess. I wish, like, someone would actually... Rather than building castles on top of castles for this thing, like, can we have a... Can someone make a case for why that's super important to compress away? Because, see, it's... Like, I agree when we have, like, a single audio data game in the group. Like, it is super sad to have an object, so I'm fine with c. Although I could live without it. Alright. Other people in the queue, so I'll stop talking.
[01:19:19] Alan Frindell: Okay. I mean, sounds like d is also fine. This is if you're, like... How... Well, I don't know. Maybe maybe people are using streams... Small streams for audio objects. Ian?
[01:19:28] Ian Swett: I mean, I put this on the issue, but it it feels like this belongs on the object, but we don't have any space to put it on the object. I think putting on the subgroup is freaking weird. Like, I don't know. It's, like, not really a subgroup property at all. It's like a property of the last object on the group to me. Like, it just seems like all the wrong spots. So, like, I kinda think we should do d, and if we wanna do something else to, like, optimize for the single subgroup... Single object per subgroup case or something, do that, like, separately maybe.
[01:20:02] Alan Frindell: Okay. So you said c, Ian?
[01:20:04] Ian Swett: I I I prefer d. And then if we want to go back and optimize for KC, do that separately. But, like, don't put it on the subgroup because it's not really a subgroup property at all. It's really an object property. So, like... Yep. Okay. To me, conceptually, at least. Yeah.
[01:20:22] Suhas Nandakumar: Alright. Suhas? At least, going back to the first principles here, the idea behind this status marker either in the bit or in a status object is for the end subscribers to know when things have completed. And with filters, you you... The way it is defined today or before is that you'll never know if the group entered, and should I cancel up my subscription or not if the filter is for... Or for group ID or object ID for... Within a group. So making making it explicit saying saying that, you know, even... I filter for only object ID zero. And when the group entered, I... If I can get end end of group status object saying that this group entered, that will give a very clear indication for the end subscribers to say, should not be waiting on this group anymore because it's done. Rather than... Right. Today's open ended at some point, we just give up. I I would say any design we go with which is very clear, And this this are the status objects, which are not part of the object stream that you're filtering on is very... And make it very clear and include it regardless of your filter added it or not would be much, much more... Gives gives very clear implementation choices for subs... End subscribers. Okay. And I I don't think... I I do understand single single object streams having a second object that's a status object. It is kind of weird, but a status object is not an object from from that perspective. So I I I... I'm I'm I'm still leaning towards something that's more explicit than than trying to hack the things around here.
[01:21:56] Alan Frindell: Okay. Moe?
[01:22:00] Mo Zanaty: Yeah. I think I kind of agree with Ian that this is weird to have it on the beginning of the subgroup because you don't even know if you can deliver the subgroup. Right? So you're saying the last object in the subgroup is the final object of the group, but you don't even know if you can deliver the subgroup. Right? So it is kinda dicey that we allow that in the first place, in which case b makes the most sense because it's like you try to deliver the subgroup, but, oh, crap. I have to filter this object out that is the last object, or I failed to deliver the, you know, the object for for whatever reason. So it seems like you're failing. You're... You you told it one thing, and now you're failing to keep that contract. And so you do need to reset it because what you said at the beginning of the subgroup is no longer true. And so resetting it would make sense if you don't want to do something like forcing to resurrect it, where they take the bit off of the off of the object... Off of the... Yeah. No. It's a subgroup. It's not even on an object. You take the bit off the subgroup header, and you stick it as a as a status object instead. I I I I just think that putting it on the subgroup is kinda weird because that's a compression thing. Right? So if you if you violate what you signaled in the subgroup header, I think we have no choice but to do b because you're you're
[01:23:25] Alan Frindell: That is What you're saying is true even if you ignore the filter case today. Let's say that a group... If it time... If if delivery time has... Or you can't end with a fin unless it ends with the object. That's already true in the draft. Filters just would expand the set of cases where you might have to do that. I heard a lot of opinions. Here comes Martin Duke with another one. Oh, no. He's gone. I I heard a lot of opinions. I am not sure that I got a strong signal of which one would make the largest number of people happy. Can anyone not live with c?
[01:24:20] Suhas Nandakumar: So, Alan, just to confirm, it's it's basically says that every time you have end of group status and it's filtered out saying open a new stream and include end of group object? Or or,
[01:24:31] Alan Frindell: like No.
[01:24:33] Michal Hošna: Sorry.
[01:24:34] Alan Frindell: C is just saying that the end of group bit is only defined for single object subgroups. All multi object subgroups that contain the end of group have an end of group status object at the end. Okay. And and include sort of the option e either. Right? You can stick that in there even if something was filtered out, and, like, you can put the the marker in there anyway.
[01:24:58] Suhas Nandakumar: Right. But but today, we did not we did not say that, right, if multi object streams should always include end of group status object.
[01:25:04] Alan Frindell: Right. No. It would be the Okay. This would be what is new. Right? Today, you can... There there is one thing maybe that relates to Moe's case why see... Why why doing it that way for multi object subgroups is suboptimal. In applications like Steven was describing, where every group occupies a single subgroup, signaling that at the beginning, even if I don't get the end, I know if that stream gets delivery time out, I know the group is done. Like, even if I never received the end of the group. Now maybe the groups... The whole stream may never got sent in the first place, which is a different problem. So that's maybe one reason to speak against c. Like, it's kind of an... But it it has... But it also means there are different semantics here, which maybe people don't understand. I'm gonna try to write some text for c. I'll let people weigh in on the PR. Steven?
[01:26:02] Mo Zanaty: Yeah. I mean, I can do with c. It is... It's probably a minor change.
[01:26:06] Alan Frindell: But Okay. Thanks. Alright. I think that ate most of the time. There's... I might just spend sixty seconds talking about the last slide, and maybe that will drive some discussion on the issue. So, this is a case which is, I think, not uncommon in in high end broadcast, which is that, like, there's full redundancy so that, like, the same camera be... Feed is going into two totally different encoders, which is producing visually similar content, but not bite for bite identical content. And at least in, like, existing systems, which are, let's say, using HTTP for HLS dash, like, that means a particular group, which is usually represented as a single HTTP object, could be produced by encoder one or encoder two, and the subscriber just keeps asking for it, and it doesn't really know which of the two it's getting. It's just like, let's say, first one to the edge relay wins that, and then the whole group is delivered by one side and another. So this does not work in Moq-t because it would violate the one name... One one track name unique content rule. So the the options that we're talking about in that issue are you use different track names. So the subscriber might have to subscribe to to both or the Edge Relays rather subscribes to both, and then the end subscriber has, like, a unique track name, and the Edge Relay is, like, picking... Similar to watermarking where it's, like, picking one or the other. You can do that same thing using the same track name, but defining the the mock t scopes differently. Like, the ingest gets a different scope than the egress. So they still have the same track name, although you still need to sort of... You need to be a little bit clever about how you define scopes probably. Or if they have... I think what... This is Gwendell who filed this issue. If the if the sort of publisher and subscriber sites all have the same scope and the same track name somehow allow the publisher to opt in to this sort of, like, don't make this track malformed. Just serve me on a group level only from one side or the other. But that would be a big departure from Moq-t's current rules, which say, like, same name, same object, same content. So, anyway, I don't... I don't think there's any time to respond to that in two minutes, but that is what is being discussed on the issue. Please go weigh in, and maybe we'll either bring it up in San Francisco, or maybe it will resolve asynchronously. Who knows? I'll hand it back to you, Martin.
[01:28:52] Martin Duke: Okay. As an individual, that seems like a huge feature request at this stage in the game. But... Okay. As chair, thanks everyone for participating today. There are multiple things. If you you can go back to the the meeting materials and look at the chair slides to see the multiple deadlines that are coming up for various things. Please do look at the minutes as well as as I said a little bit earlier, and, we will see you in San Francisco.
[01:29:21] Alan Frindell: Thank you.