Session Date/Time: 08 Sep 2026 16:30
[00:00:09] Martin Duke: Okay. It is sixteen thirty UTC. We will begin. Welcome to our virtual interim, our penultimate, virtual interim before the inter for the, hybrid interim. It's September 8. The session is being recorded. Here's the IETF Note Well. Most of you are familiar with this, but it does talk about the private the intellectual property implications of you participating as well as the code of conduct. If you're unfamiliar with it, please scan a QR code or search for IETF Note Well in your favorite search engine. You're in MeetEco. You've obviously figured out how to do that. If you are speaking, remember to mute yourself, and it takes about a second latency wise. So please unmute yourself a little bit before you plan to talk. If you do plan to talk, I strongly advise you use a headset. The echo cancellation of MeetEcho is not good, and we'll have to mute you aggressively if you're in a in a in a conversation to avoid just unacceptable echo to everybody else. Other than that, you can use the raise hand button at the bottom of your screen to enter the queue. Or if we have a show of hands, there'll be a window for that. Bunch of upcoming dates. We just completed the virtual interop. Thanks to Mike English for his work on that. And to everyone who participated. I just started a consensus call on draft 19, on the diff between draft 18 and draft 19 under the assumption that now that you guys are mostly done with 18, you can look at 19. Please take a look and file an issue for any concerns you have with that diff. After the September 18, any issues filed with that diff will have a higher bar for consideration. Our final virtual interim of this segment is gonna be the September 21. We're back to our Monday schedule, sixteen thirty, UTC as always. I've added a deadline to register for the hybrid interim. This is if you want to attend in person so our hosts can get information about that. I will in that same wiki page, I will add, kind of logistical information about hotels and so on. But there's no recommended hotel, and it is in the center of Downtown Seattle. So, there's essentially infinite hotel options within easy walking distance. So I would just encourage you to just book in that in that locale, really, wherever you whatever brand you you most prefer. And then finally, our actual hybrid interim in Seattle in Seattle Way is, 12-15 October. The first two days are going to be interop, and if and we'll talk about that today. And, fourteenth to fifteenth will be issue discussion. This is page one of the agenda. You are in the administrivia, and then we're gonna hand the rest of the time to the editors. We've got a he's got a few kind of overview items, and then there's a series of of open issues and PRs. Would anyone like to batch this agenda? Okay. Hearing nothing. Alan, go ahead.
[00:03:28] Alan Frindell: Sorry. Late entry. I I did I I mean, I miss and I didn't see your slide before this. If you if Cullen is here or Suhas Nandakumar and they wanna talk about the URI draft at all, happy to put that in either either at the beginning or the end or the middle or, if folks wanna talk about that.
[00:03:49] Martin Duke: Would I Will, go ahead.
[00:03:54] Will Law: Yeah. This was just Magnus had said he wanted to raise the issue of the liaison out
[00:04:01] Martin Duke: That's the that's the next slide.
[00:04:03] Will Law: Oh, it is? Okay.
[00:04:04] Luke Curley: Yeah. Sorry. I thought it was.
[00:04:06] Martin Duke: Would Suhas or Cullen like to speak up? Do do they want some time for the URI draft?
[00:04:13] Suhas Nandakumar: I I think we can put it towards the end. Well, I'm I'm sure Cullen is planning to join today too. If not, can talk give brief update on that.
[00:04:21] Martin Duke: How much time do you need?
[00:04:23] Suhas Nandakumar: I would say five to ten minutes and and see what people think about it.
[00:04:27] Martin Duke: Okay. I'm gonna cut it at 10:50 then, Pacific. Cut off the editors. Alright.
[00:04:32] Alan Frindell: Sounds good.
[00:04:33] Martin Duke: Unless there's any objections to that bash. Excellent. Okay. Magnus just lost audio, which is very unfortunate. Oh, Magnus, why don't you type furiously, and I will share it with the group? I will read your stuff to the group because I don't know what he was talking about here, but I can read the slide, I suppose. Okay. So well, I mean, you can read this as well as I can, I suppose? But go ahead, Will.
[00:05:09] Will Law: Yeah. Everyone can read it. It's just just one comment. CMAF has not doesn't actually yet have a normative dependency on block math. We have an open PR that will make it a normative dependency. So there's that clarification. And, Magnus, this is raising this is administrative issue. Should IETf send a liaison statement to MPEG to tell them that we are going to be doing something to improve their compression format. I don't think they have a monopoly on innovation, but they they I certainly believe that they think they are the ones who should control anything to do with it. And they would much prefer that we submit it to them, that they standardize it, and then we adopt their standardized version. I expect that to be the outcome. Yeah.
[00:06:04] Martin Duke: Yes. But you you do you agree that we should send a liaison statement about this?
[00:06:08] Magnus Westerlund: I agree.
[00:06:09] Martin Duke: Okay. Does anyone have any, okay. Magnus is back. Maybe. No. Okay. Does would that does anyone have any concerns about this course of action they would like to raise now?
[00:06:37] Alan Frindell: Victor asks in the chat, what is a lockmath?
[00:06:44] Martin Duke: All I can say is what is in the link and the def definitions on the slide. Torbjord?
[00:06:53] Alan Frindell: Yeah. Maybe Torbjord has the answer.
[00:06:56] Torbjörn Einarsson: Yes. Since I have done this thing, written the draft, I know a lot about it. I made this special website called lockmath.dev, which should give you a very easy sort of instructive way of understanding what it is. But, basically, every once we're trying to do very low latency CMAF and put every audio frame in the the in a mock object, we have an overhead of more than 100 bytes. It's special it's essentially the same 100 bytes of the all the time, or you can calculate them. So you basically just need somewhat more information in the first object, and then the rest of the object can be delta delta encoded or or calculated. So, actually, you just need basically two bytes. So you just tell no information. Just calculate the whole thing. So it's a very good way of getting down the bit rate for that that that especially for audio. And the point is that then what you at the receiver, you should reconstruct the full CMAF again. So it's not doing all CMAF, but CMAF is very constrained, so it's working quite well. And it's working the the the the the for for encryption as well, which lock doesn't do. So
[00:08:16] Martin Duke: Thanks, Torbjeon. Last call for any comments about this for Magnus fires it off. Okay. Hearing nothing. We will hand the next seventy two minutes to the editors.
[00:08:43] Alan Frindell: I uploaded a recent version of slides. I see another question from Victor in the chat about the topic, though. Have we already formally adopted this draft? Do we wanna go back and cover that, or do you wanna
[00:08:56] Martin Duke: I I don't believe so because I'm, I'm calling incorrectly.
[00:09:09] Alan Frindell: Okay. I mean, I think yeah. It's I don't know what the policy is for a draft that is adopted by the working group taking a normative dependency on an unadopted draft. Maybe Cullen knows.
[00:09:23] Cullen Jennings: Well, I I mean, I I think it's fine for us to have a normative I mean, we often have working groups where where a draft that is, a working group draft has a normative dependency on a nonworking group draft or even an individual contributor draft. It's just it's you know, that draft has to be finished before it's gonna come out of the RFC editor queue. Right? But, you know, I guess the the the the question here is, is is really about yeah. I I guess, Magnus says, no. We haven't adopted this. But, I mean, I guess the question is is, you know, it it seems like, if we're gonna reply to this liaison, we need to know whether we're going to adopt this as a working group draft or not. Seems to be point a. Right? Like, we need to go through that process. Mean, that's Magnus, what you said?
[00:10:09] Magnus Westerlund: Yes. Apparently, now it worked. I had audio issues, but, yes. So, basically, this comebacks to what we basically said to do in in London with the CMSF format, and where we said we would actually incorporate lockmath into the, into the CMSF specification. But that's not particularly practical. So the suggested path here is to adopt the lockmath draft instead and have the lockmath as a separate draft, normally dependent on CMSF, but it's, and I don't want to adopt it formal or saying that we can do. I would like to have an agreement that we will adopt it, which I think was basically assumed by the London discussion and agreement what was discussed there. But I would like to not adopt it formally until I actually sent this analyst and see how given them time to as supposed to respond if they actually scream about it, which I don't hope and I don't expect.
[00:11:10] Martin Duke: So Okay. So the Magnus your order of operation then is to send the LS saying that we have an intention to do this. We've not adopted it yet. Yeah. And then based on response to that, then have a call for adoption.
[00:11:21] Magnus Westerlund: Yeah. But I I use I assume, so to say, that we will need to adopt it based on that we want this functionality in in the CMSF. Yeah.
[00:11:30] Martin Duke: Okay. Does anyone else anything else about this topic? Alright. Alan, it's all you.
[00:11:44] Alan Frindell: And Ian. Okay. So you may have noticed draft 20 has been cut, and that was cut last Monday. It was done because we wanted to make a large editorial pass, and we wanted to make it possible for people to find the non editorial changes more easily. So you can diff 20 versus 19 and see sort of what was the state there. And then since we cut 20, we have knocked Humpty Dumpty off the wall and attempt to put them back together again. So the editor's copy has been reworked in terms of ordering. If you try to take a plain text diff between either the editor's copy or any draft from now back against 20, you will probably have a hard time. Although, I suspect your agent can probably do a fine job of figuring it out. We were very careful to make sure that we did not lose any normative language in reordering. You can talk to Victor about his mathematical script that
[00:12:44] Martin Duke: we used to make
[00:12:45] Alan Frindell: sure we didn't lose anything. That said, we do make mistakes. So that is where we currently are, and I wanna talk about well, this is just an overview of what it looks like now. So number one, if you have an open PR, you'll need to rebase it or close it and reopen it because it probably won't merge cleanly anymore. This is the new organization of the document. So the first half, it contains all the semantics that we have, and that involves hoisting a lot of semantics that were embedded in various message descriptions into, like, sections that don't talk about WARF, bioformat at all. They only talk about how does this thing work, what can you do with it. And I think that's I think there's a big improvement there. I do think we are in the middle of we were we're trying to update that section for namespace discovery. It hasn't quite that hasn't made it in yet. We have not cut 21 either. So we may yet do it. Then there's sort of the second section, which is all the wire format. So, for example, like, the Variant definition does not appear until section eight now, and there's no references to any wire formats anywhere in the first half of the doc. So if you are making a PR, keep that in mind. Please don't try to introduce wire format stuff earlier than section eight. And then we try to group all the wire format things together, and then we have sort of this, like, code of sections of, like, securities considerations, dynamic considerations, etcetera. So any any questions on the new document structure?
[00:14:17] Cullen Jennings: Cullen? This is look. I'd love to see that they were refactoring all this. I just wanna make sure I understood correctly that from so from '20 to '21, it's like huge reorgs, but no no text changed. It just
[00:14:29] Alan Frindell: That is okay. No. Yeah. I mean is not the case. Oh, well, I shouldn't say '21 has not been cut yet. So Okay. Let let's not say what 21 is or isn't. The current state of the editor's copy contains both. The first commit in that is a pure move with no text change. There have been commits since then that are doing things like taking a section that had a mix of wire format and semantics, pulling them up. There's other parts of the semantics that have been done. There's other editorial only issues that have been addressed. So Oh, okay.
[00:15:01] Cullen Jennings: But it it's it's it's it's the the goals of the auth the goals of the editors is it's it's only editorial changes between '20 and '21, which you're not gonna be able to diff. But, like, we didn't change okay. Okay.
[00:15:13] Mo Zanaty: I should
[00:15:13] Cullen Jennings: be you to publish 21 as soon as possible before you start making even as as soon as we start moving into changes that are diffable, publish 21.
[00:15:23] Alan Frindell: So I think that ship has partially sailed. However Maybe you should go.
[00:15:28] Cullen Jennings: I think if we wanted to,
[00:15:29] Alan Frindell: we could go back and tag the move only thing and call that '21. Yeah. That is not that's that's still a possibility if that was what people would like to see. I don't know. I mean, different numbers like, numbers are sort of cheap and they're sort of not. So I I don't I'm I'm a little bit ambivalent on whether we do
[00:15:48] Cullen Jennings: it or not. Well, I mean, I find it really difficult to review the changes in this document, and I am willing to totally accept that there's a set of changes that were just all reorgs. That's the only way you can do it. I totally support the others doing that, But I really rather not merge that with stuff I'd like to review as much as possible humanly possible.
[00:16:10] Alan Frindell: Okay. There that's fair. Victor?
[00:16:13] Cullen Jennings: Yep.
[00:16:15] Victor Vasiliev: Yeah. I I think so far that it should not have normative changes. It does have some new text that we believe is an improvement and clarification of our old text.
[00:16:30] Cullen Jennings: Look. I I I get that. I'm fine with that. I just prefer to be able to review as much
[00:16:33] Luke Curley: of that text as possible. Right? That's what
[00:16:35] Ian Swett: I'm asking.
[00:16:35] Alan Frindell: It it is still diffable even depend regardless of where we cut the actual draft. In GitHub, it is still diffable against like, there's if you go from the only the only undiffable thing is, like, the pure move diff, the the pure move commit, which I think actually, if I'm correct, Victor, it might have I forgot if we squashed it or if it landed as, a series of commits. But, anyway, there's a point, and we can tag it
[00:16:57] Martin Duke: this was where what? Did you get squashed?
[00:17:02] Alan Frindell: We can tag that point. And so you can always diff editor's copy versus that point, and you will get something
[00:17:08] Cullen Jennings: that you need to do. That in less time than you've spent discussing this on this call. Just take those points in GitHub. I can't find them. I can't diff them. I don't know what they are. Just take them and publish the damn draft. You can publish five drafts in a single day, two minutes apart if you want.
[00:17:24] Alan Frindell: Okay. Noted. Martin?
[00:17:26] Martin Duke: Plus one to Cullen. Our entire consensus process is based on me publishing, like, draft diffs. So, like, let's just have the one that people are gonna have to eat. And I can put out a consensus call saying, like, you know, you just trust us. This is fine, but this is a consensus call on this draft rather than have any sort of ambiguity about diffable or about, you know, new text or whatever. So, like, just just cut 20 on that on the undiffable on the minimum, like, quantum of undiffable, and then we can go back to regular programming.
[00:18:00] Alan Frindell: Okay. I hear that. Does either Ian or Victor or Suhas wanna weigh in? Yeah. I guess I was thinking we
[00:18:10] Ian Swett: were gonna cut the next draft based on the set of editorial changes that were the move plus the subsequent changes to make, like, the move, like, make sense. Because once you do the move, like, you have a bunch of stuff in, like, completely wacky orders. But I don't have a super strong preference. We could
[00:18:29] Martin Duke: Yeah.
[00:18:29] Ian Swett: Cut one for the pure move PR and then another one for something that makes sense later.
[00:18:35] Martin Duke: Look. If there if there's, like, just obvious editorial cleanup where, like, things are in the wrong order now well, I mean, speaking personally for me, that's fine. You know? And if you wanna be, like, super careful about it, you could even give, like, the the the p I could I could we could have a a because it was called that has a diff plus couple PRs if, like, that's if that is better. And I could just explicitly if people really are interested in that, that's fine. But, like, actual changes that add that are not strictly about reordering or, like, the the text cleanup from reordering, I think, should be separate. Like, if we're if having new explanatory text, like, there's always a possibility that, no, I thought that meant something completely different, and we should probably have that be a separate thing.
[00:19:29] Alan Frindell: Suhas?
[00:19:30] Suhas Nandakumar: Yeah. I I was just trying to kind of think, what Martin is saying as well, which is we we do have that move only that we took to date, and and that gives a clear cut on the new organization that we have. And then we can probably get the rest of the PRs into the '21. That way, '21 will will have all the nice clarifications that we which are which are editorial in nature, though, but we added as part of that. That way, 20 will be just more, and 21 would be, like forget the numbers, but I'm just that would be helpful, probably.
[00:20:01] Alan Frindell: Okay. Yeah. I I mean, I think I'm hearing that people would rather have a diff point in data tracker than a draft that makes sense, And we can do that. Like, we can we can we can make that like, it won't make sense. It's just reordering, but it will be very difficult.
[00:20:20] Martin Duke: I I can live with not making sense. I would I prefer that it makes sense. As I said, like, some basic if I make sense, you mean, like, the ordering like, the text does not point to stuff that's, you know, before it when it's after it or something like that. But I think, like, additional explanation of concepts and clarification of things that are ambiguous has qualitative impact, right, where, like, people may not like, the reason we had clarification is that somebody is, like, somebody could misinterpret it. So if, like, I'm coming around thinking that, like, time out means something and it means something else, like, I think that should be reviewable separately. But, like, strict but I'm not like, you can change text if it's just a if it's just a reflective reordering. That's fine.
[00:21:06] Alan Frindell: No. I think it's I think at this point, the jelly cannot be unstirred. Like, either you're gonna get pure moves and you can't read the doc from front to end without being really confused, or you can take the moves plus some, like, some hoisting of text and mechanicalish moves and other that were, like, things were actually explained. And we found old stuff that was, like, clearly vestigial that we just excised because it was clearly just old and non
[00:21:31] Martin Duke: I I I'm not dying on this hill, but if if you would like to do that, I'm fine. Just please send me an explicit list of PRs that are incorporated in that that make those changes, and I'm happy to include, like, a a reasonably finite list of PRs that in a consensus call. So people say, draft 20, like, most of this is just cut and paste. Don't worry about it. But here are three PRs that went in, and people can read those, and that's fine. Either way is fine.
[00:21:56] Cullen Jennings: So so so, look, I mean, Alan, my preference would be just, like, publish both those drafts at the same time. Just publish the move one along with a note on the top. This document makes no sense. It hasn't been reflected in the moves. And instantly, a second after that, publish the next one that's, like, a document you can read that includes a lot more, but is difficult diffable against the previous one where the one with the move only is not gonna be diffable against anything.
[00:22:18] Alan Frindell: Okay. I'm I'm largely fine with that, although it's gonna it will break our recent 2026 convention of, like, only of making even numbers interrupt targets, but we're gonna talk about interrupt targets on the next slide. So I'm happy to do what you suggest, Cullen. And at at least I it's
[00:22:33] Cullen Jennings: mean, publish a fake odd number if you wanna interrupt target. I mean, numbers are free. Stop pretending like these numbers somehow matter. They don't. Right? Okay. Fair. You can still keep with even numbers. Publish two documents in the same minute. I mean, whatever. Yeah.
[00:22:45] Alan Frindell: Okay. Okay. I'm gonna move on to the next slide. I I think I have the signal, which is that people, like, having this people want would prefer diffability to readability. You know? It's okay to have a slightly unreadable draft. Okay. So the next question now maybe this slide is outdated, but we just talked about but there's the the question is what do we wanna interrupt in Seattle? So we're gonna there will be multiple drafts. There's we're at 20 now. It's been minted. 18 is still our nominal interrupt target. 20 has a lot of changes in it. There if we were gonna cut a 22 or if we were gonna cut another draft that contains non design changes, not just editorial changes before Seattle, I would like to give implementers at least three ish weeks to, like, react to it, which means the number of things that we could merge into that that are wire changing is small. It's something like maybe three PRs, maybe around when we'll talk about them today, one is about how forward is expressed, one is about parameters in, the namespace message, one of them is about priority compression. Like, it's a small set. We don't have to do it. There's plenty to do in 20. So I guess that's kind of the signal I want here. Like, should we just say, whatever, folks, 20 we cut 20. It's the interrupt target. Go and and turn people loose now, or do people want to squeeze a few more things in before Seattle?
[00:24:17] Martin Duke: Martin? As an individual, I have a knit and a substantive comment. The the knit is, like, we I guess and you've you've stated the beginning here to be 20, not 21 even though they're the same, but we need to make sure we converge on one or the other. The more the more, important thing I I do wanna like, I I neglected to have Mike give an interop report from the second because that's that's on me. But, like, option c is 18 was kind of a did not go great, and we should just do 18 again. I know it's an ancient spec, but at this point. But, I I think we should put that I mean, so just from my personal perspective, we are still behind. We are still trying to get 18 done, and, like, I think we could plausibly do it by Seattle. And so from our perspective, that would be great because we're behind. But, like, if everyone else is running out what they're gonna run out of 18, then then, like, you know, we shouldn't be the that's fine. We'll
[00:25:15] Alan Frindell: we'll just have to look at it. I'm perfectly I'm I'm willing to admit that that is an option c. So do you can we should we just put up a quick, like, informal show of hands what people wanna do? Like, eighteen, twenty, or something more than 20, and we can just call it that?
[00:25:31] Martin Duke: I'm I'm happy to do that. We can't do three way things, though. Right? We have to do this in a painful way.
[00:25:37] Alan Frindell: Right? Can
[00:25:38] Martin Duke: I? I can't remember.
[00:25:39] Alan Frindell: Maybe no opinion could be 18.
[00:25:41] Martin Duke: We'll find out in a second. Oh, no. It's just a yes, no question. Okay.
[00:25:46] Cullen Jennings: Maybe we can just hear from each one of the major implementations where where they are versus a vote, and then maybe I'll be clear what
[00:25:52] Martin Duke: we should do.
[00:25:54] Alan Frindell: Well, I mean, I was definitely involved in last week's interop. I can say that there are fair number of relays anyway that are 18 ish or close. Right? Like, the meta one, the open mock one are the Cloudflare one. We didn't do the fetch tests with with Cloudflare, but, like, bidirectional streams are, like, largely there, which is the biggie. The Nokia one, Lorenzo's are all, like, I think we were we couldn't test Luke's, but that I think he had to fix that we were gonna be able test this week. So I don't know. It's not everybody. There's lot of implementations out there, and I'm only talking about relays, not clients. So Suhas?
[00:26:41] Suhas Nandakumar: I got I I think, like, for example, in, both of our clients and our internal relay implementation both are on 18. But at the same time, what I felt from last week's interrupt is that we have I'm not sure if got everyone most of the features tested. We like, if they put the metrics, at least my field was some features for some of the lesser tested versus the may interpreted well versus some did not. That that would be the reason why Martin is kind of thinking we should have default as 18 target. And and then anyone comes with, like, 20 or 22, we can we can work work through that at the interim.
[00:27:20] Martin Duke: I'm not advocating.
[00:27:20] Alan Frindell: I'm so sorry, Zafer. Moq-transport also at at 18.
[00:27:23] Martin Duke: Yeah. To be clear, I'm not necessarily for anything. I just wanna sort of put the put the hat in ring for, like, Google. Like, we are way behind and would not mind another eighteen. But, you know, I'm I'm happy to be if everyone else has gotten what they're gonna get out of this and wanna move on, like, that's great.
[00:27:41] Ian Swett: As an editor, not with my Google head at all, I would love to have some people start interrupting fill fetch and make sure that that chunk of functionality, like, doesn't have some disastrous problems that we haven't anticipated because that it would finding that out sooner rather than later would be enormously valuable to me.
[00:27:59] Martin Duke: So that and filters are the big rocks. Right? Okay. I mean, that's not that's not nearly as egregious as the 18 diff. So
[00:28:10] Alan Frindell: Yeah. I I think I'm inclined to agree with you in there. Like, I I'm like, Phil Fetch probably has problems we did not anticipate, and nobody has tried it yet. So
[00:28:21] Martin Duke: Well, of course, the other alternative is you could do virtual interop. I the the the question is, are people, like, happy with the 18 result or not? That's really what's what's relevant. I agree. It could
[00:28:34] Alan Frindell: have been better, but, like, time marches on, man. It's mock. Like, okay. Let's move on. Let let let's make a decision we want. We have issues to talk about. So what do people
[00:28:45] Mo Zanaty: want?
[00:28:45] Martin Duke: Wait. Do do we wanna so, do we wanna have a poll? Do we wanna just have did did we cover all the implementations that are in playing in Interop with your summary?
[00:28:59] Alan Frindell: Opt in 20. What how let me offer this, and maybe people can just say if they have a problem with it. Why don't we say it's, like, 18 or 20, pick your flavor. Like, there I will still have an 18 implementation in Seattle. So if people wanna test their 18 against it, you can. And we don't add more on top of 20.
[00:29:19] Martin Duke: Here. Here's what I'm gonna do. See if we have critical mass that think they can get this.
[00:29:55] Alan Frindell: I will not be able to support draft twenty in Seattle.
[00:29:58] Martin Duke: I will be able
[00:29:58] Alan Frindell: I will be able to support draft twenty.
[00:30:00] Martin Duke: Yes if you can get the draft twenty by Seattle, if that's what we decide to do. Because that seems to be what the editors want. That's great. But if no if everyone's, like, host, then alright. I'm okay. I I think that's just already a strong signal. I guess the record can show that five people say yes, and, oh, all of a sudden, the numbers are getting worse. Five people say yes. It's okay. It's taking a while.
[00:30:25] Alan Frindell: Give give it a minute to stabilize. Yeah. People have to find where the button is.
[00:30:37] Martin Duke: Oh, somebody changed their mind. Alright. Woah. And if you're clear, when I say I, I mean you, not me. I think I've made it clear that Martin will not be able to support draft on me and and see if we're we're not having a poll on that. Alright. Going once. Does anyone need more time? Raise your hand if you need more time with the little raise your hand tool at the bottom of your screen. No. Okay. So, seven people say yes, five say no. I think that's probably enough for you to get what you want out of a draft-twenty three interrupt. So, like, let's make draft 20 the target. Okay. My in my opinion, I think we probably have enough draft 20 to make that worthwhile. And yet those of us those of us laggards will probably have something to do, with draft 18.
[00:31:53] Alan Frindell: Yeah. I'm happy to like I said, I think and I'm probably not the only one who's still gonna have a draft 18 implementation that's workable. So for people who wanna come in 18, do 18. And for the seven folks who are like, let's charge ahead and do 20, I think that's great. So why don't we just Okay. Why don't we say that? And I'm gonna say we don't like, the stuff the the few design changes that are hanging out that are not in 20 that might make it before Seattle, we're not gonna interrupt on those unless is that gonna give anyone serious heartburn, I guess, is the question. But I don't I mean, I'm I'm I don't think it should because there's plenty to do in '20.
[00:32:25] Martin Duke: Okay. I I think okay. So our Alan was articulated what I think is a reasonable course of action for this. Does anyone, does anyone have some serious issues? Say so now. Okay. I think I think we're I think we have our answer.
[00:32:40] Alan Frindell: Okay. That that's great. Thanks. See your implementations in Seattle. Okay. I think this came out, but just in case you were missed it, Phil Fetch landed in '20. If in case you you can go read sixteen seventy three if you wanna see what the final form of it was that editors and authors spent, I don't know, an hour or two on Monday morning, like, closing out all the issues, and we were all in agreement that it was ready. So, it is in, obviously, still subject to consensus call. But implement and please file the issues because there probably are some. A c 25. So for stuff that's outstanding, we we've mentioned this a couple times. I don't know how many people have gone and read it. So it removes the forward parameter, and respells the concept of pausing and resuming a subscription, with a location filter that is unsatisfiable. Regardless, the the PR is a terminology win because it's less awkward to talk about forward zero, forward one just instead of that that PR rephrases all those statements to say the subscription is paused or you pause the subscription, and there was actually a second issue somewhere that somebody filed about that particular thing being awkward. So there are a lot of different location filters that are unsatisfiable, though it just recommends a particular form that starts at object one and ends in object zero. So we could land that as is, or we could separate out the editorial bit and leave the forward prem in. Have does anybody have opinions on on what we should do here? Forward's been baked into our terminology here for a long time. Victor?
[00:34:29] Victor Vasiliev: Yeah. So there is an issue I filed regarding forward, and it's pausing sessions. The issue I have is that we have many reasons we pause streams. Like, some of them are defined in the draft, like, explicitly starting with forward two. Some of them are defined in extensions, and it is not entirely clear to me how this interacts. Like, at least currently, we have, like, all of those, like, competitively flips the forward bit. And with this, I don't even know what will happen. And, also, there are, like, questions. Okay. When I unpause, what happens to my location filter? Do I reset it to previous value? And which one?
[00:35:24] Alan Frindell: Victor, is that a vote for this needs more thinking?
[00:35:27] Victor Vasiliev: Or I think the terminology change definitely should just let now. But we need to think more about what actually like, how those things actually interact. Like
[00:35:41] Alan Frindell: Okay. Cullen?
[00:35:45] Cullen Jennings: So, oddly, I think mine is the same as Victor's almost. I just wasn't quite sure how this worked. I tried to read it. Maybe it's in it, but I didn't get it out of the PR, is we have a lot of things that turn that, like, switch. Things where not the end not the end receiver, but the relay, something logic in the relay is causing forward to be changed on and off. And when that happens, particularly when it gets turned back on, when forward gets turned back on, does the value of the filter get restored to what it originally was before it got turned off and on again? And so that was the part I didn't understand of how this worked. I I mean, I understand if the end client changes, it probably knows how it originally set the filter so I can reset it to the same as it was before. But when it's a server side algorithm that's doing it, do we have to sort of keep track of the old filter and then restore it or something like this? I didn't see any text along those lines. So I was just wondering how those parts of it worked. I think I'm basically sort of in favor of this. It was just like there seemed to be these edge conditions. I didn't quite understand how they work yet. That's all.
[00:36:47] Alan Frindell: I think that actually, I hadn't thought about it, but I think that's a good point because it it is a little bit it it puts requirements on the publisher to remember what your old filter was so that you can put it back. And that also because of the way filter because these are the and sets work. Like, there may be multiple places where you need to do that. Mo?
[00:37:10] Mo Zanaty: Yeah. I've I've already put this in in the PR, but I I think we need to remove all of the stuff talking about other filters except the location filter. I think we need to remove the stuff about handsets and all that. This should only be a location filter. All the text should only talk about location filter. And, also talk to Suhas about this. The the it should not require it to be end less than end less than start. It should just say end in the past or this because the plan is for real real scenarios where you know where you wanna end to specify the actual end. Like, for example, track filter switching, we wanna specify where the actual end is in that end location filter. And then you know you're paused because you're past the end. That's the right way instead of a instead of a nonsensical encoding.
[00:38:06] Alan Frindell: I will say, Moe, just setting your end before largest object does not mean that you're not gonna get anything because things can be reordered and come from the past. They still pass your filter, which forward does not pass those. That's the difference.
[00:38:19] Mo Zanaty: That that that that's true. And that that nuance about whether you want to receive old objects or not is is something that we introduced by the largest object filter, and I don't think anybody still has any valid use case of when when it should be on and when it should be off. The Oh, well, forget
[00:38:40] Alan Frindell: about largest object. Just if I set ends to group 10 and because I've seen largest because I've seen group 11, that doesn't mean I'm not gonna get objects from before group 10. It just means if they show up, I'm gonna get them.
[00:38:53] Mo Zanaty: That that's that's right. And that's what we need to that's what we need to understand. Why did we ever add the option to not to filter out old objects, out of order
[00:39:04] Alan Frindell: I I mean, if forward is I mean, this is an important distinction in this PR. Right? Setting forward zero means I don't want anything on this track. Setting my end location to some period which I think is in the past does not mean I will not get no I will get zero objects from this track. Do we want that to be to to to be a concept or not?
[00:39:23] Mo Zanaty: Yeah. And to clarify, there's another filter that that the setting the end to be in the past, there's also another filter that that's implicitly not allowing anything in the past, and that's that special location filter. I don't think we ever have ever had a use case for that special location filter other than to not receive duplicates on a fetch and a subscribe. And I think people have limped along thinking that we need that largest object filter, and we don't. The only use case that ever came up that we needed it was this case of having a fill fetch before it was fill fetch, just a regular joining fetch, and a subscription not having duplicated objects because of things coming in the past going on both of those streams.
[00:40:12] Alan Frindell: Okay. I think that you may be right, but it's also our third orthogonal to what we do with filter with forward.
[00:40:18] Martin Duke: Okay. Ian?
[00:40:21] Ian Swett: I don't have that strong of preferences to whether we do one or two. I definitely think it's a good editorial improvement. I will say that on things like Suhas and, like and I I think I've said this before, but, like, if you're doing track switching, the right thing to do, I would argue, is to, like, change the filter. So, like, you explicitly tell the peer, like or the client, basically, you know, subscriber that you are going to end at group 10 on this track and start at group 11 on the other track and use filters to, like, indicate that as well as implement that kind of seamless switch and, like, clean switch. And using forward is I would argue, like, unless you're just killing it subscription at light with, like, hard switch, it's probably the wrong thing to do anyway. Right? Like, most of the time, you would like to, like, end at a group boundary and start another group boundary, assuming you can get alignment. And so that's how I would expect people to do that.
[00:41:12] Cullen Jennings: Just to clarify, Ian, what you're saying is when an algorithm running on the Relay changed the filter, the end client would get notified of what the new filter is. Is that what you're yeah. Okay. That that solves my issue. Yep.
[00:41:23] Ian Swett: Yep. Yep. Yep. And I and I think we we wouldn't be using forward typically if you were doing it in a clean way because you would use the the the location filters itself. Yeah.
[00:41:33] Alan Frindell: And that's what we added publish date notify for. It was like, for an extension that's going to change the filter, it now has a way to note like, tell the other side, like, by the way, I just changed your filter because you asked me to. Okay. Victor?
[00:41:48] Victor Vasiliev: Yeah. So the reason I said there are multiple things is, like, it's not entirely clear whether we even want, like, only one forward because the behavior I'm like, imagine they explicitly want to turn a stream off and then something like top end filter turns back on. That would be really weird.
[00:42:10] Alan Frindell: We we do have like, the top end text does talk about for example, if I subscribe explicitly to a track, it becomes pinned. And so even if it falls out of the top end, it doesn't get it doesn't get kicked out by the by the relay. So but so we could we could try to say forward work similarly, maybe. Okay. Ian, are you still in the queue, or you have something else to say? Okay. What I'm hearing is maybe we wanna split this PR in two no matter what. So let's do one that's just the sort of tax terminology change because that seems like it has more support. And then continue iterating, I think, on the the bits that are removing the parameter and see if it can address like, Suhas, you sort of own this one. Do you feel like you got the signal you need to move it forward?
[00:43:12] Suhas Nandakumar: Yeah. But I think splitting it into two is fine. And, also, I I just want to kind of clarify that as Ian was specifying. You using the forward versus this location filter to explicitly say where something stops and something start is kind of more kind of cleaner way. If forward was much easier to reason about, but if we really start thinking about what the location filter is doing, it's basically trying to say that on particular track, I want to not get anything more. That's that's what we're trying to use in one machinery to kind of achieve the same thing that we had with forward with which was two different ways. But sure. And I think the the points raised on do we do we do we open up any new gaps with switch, something like a switch or or top end? I I don't think so, but but happy to kind of split it into the the second PR and work through those things to make sure we are fine there and see. Then then we can revisit and see if if it's worth planning or not.
[00:44:04] Alan Frindell: Okay. Alright. Hopefully, the AI minute taker captured that. Switch. I feel like Switch is gonna take a long time. Are people up for it? I also don't see Gwen in the meeting. We could if people are like, you're gonna talk about where where the current state of switch from is, we can, or we can punt it. Does anybody have a live feeling about it? I am gonna skip over it and see if we can maybe take it again in two weeks and and have Gwen present because he's, like, our our switch expert. Feel free to review the slides, or I did push a version of the PR. It hasn't been rebased. So, like, it it it's changed a little bit. I'll just give you a high an overview if people wanna go read it. One of the big con complaints about it was what motivated publish date notify, which was that it used to delay getting a request okay until the switch actually happened. Now you get the request okay as soon as you can, which is as soon as largest object is known, and then you get a publish date notify when the thing actually changes. And it's also been updated to use the location filters. So if you wanna take another read, there's like I went through there's a lot of oh, this is the sale. This there's a there be an updated version of the slides that has about seven questions from open threads on that PR, which we can talk through maybe in two weeks. Okay. Coming back to updating publisher priority. We talked about it a month ago. Not everybody was here just to, like, review the current state of play. Like, the PR is written, has some races. The specific race it has is that objects old objects that got sent without a priority might get interpreted with a new priority. We talked about, like, ways we could fix that. Nobody wanted to, like, add more complexity to, like, resolve that race. We then we said, okay. Does anybody want this feature at all? And nobody did, but I think that may have been either people weren't here or people didn't understand the question. So we the chairs send it out on the list, and, then more support came back. I think this might also be a stale version of the slide. Anyway, the receiver logic is not difficult to implement. It just means that, like, there's times when you can have the wrong priority. Like, do people are people okay with that? Can we merge it in? Or is somebody who's like, no. Either the design is bad. We need to keep working on it, or I don't want this feature at all. Ian, you're still at the head of the queue here. Ian is no longer at the head the queue. Cullen.
[00:46:40] Cullen Jennings: Okay. So I I do want this feature. Well, I think we have a bunch of use case where we do need to be able to change but I don't mind in the slightest that there's, you know, a small period of time where they can be wrong out of sync. Like, every use case I can think of, that doesn't matter in the slightest. We'll get sorted out soon. And if anyone thinks publishers meet or priorities mean anything, you're already sort of dreaming in how they work. So I'm I'm I'm fine with that solution of, like, yes. There's a well known racy condition here. We don't care about it. Have a nice day, but you can't change them.
[00:47:12] Alan Frindell: To be clear, you could always change the priority. This is only about being able to chain get compression of changed priorities.
[00:47:18] Cullen Jennings: Yeah. But for the thing I wanna do it for is audio, and so, like, sending it on every audio object's not really realistic. So yeah. Okay.
[00:47:25] Alan Frindell: Got it. Okay.
[00:47:26] Martin Duke: Martin. As long as we're super explicit that publish priority is no longer a a, like, immutable property of objects, that's fine. Although, was it would it be the only object property that is not?
[00:47:40] Alan Frindell: So if you I forget if the next slide has a redux of the original slide, but, essentially, we would be this change is taking default publisher priority, which is currently a property, and moving it back to being a parameter. So and then we would also relax the malform track rules that say, you can if you happen to get the same object and it has two different priorities, just take the higher one and move on with life. It's not a malform track. So, yeah, that would that that's essentially the shape of it.
[00:48:15] Martin Duke: And so we don't have to answer
[00:48:17] Alan Frindell: your question about, like, is this property you know, is this there's one property that's mutable and then the other ones are. We just, solve that by saying it's params instead of a property.
[00:48:29] Martin Duke: But objects don't have parameters.
[00:48:31] Alan Frindell: So we're talking about Correct. This becomes a message parameter, and it's effectively becomes hop by hop, which means which kinda makes sense for compression potentially. Like, you could conceive of different hops having different values of this, although it doesn't it I don't know that there's a huge use case there. Like, I think it would be we could say and I think there was a question. Like, we could say you may, should, or must forward the same whenever you get an Sorry.
[00:48:55] Martin Duke: So, like, I I think you're completing two things. So there's the default publisher priority, which is currently a property. And if you wanna make it a parameter, that's fine. There's the actual property of any given object slash subgroup, which is which is, today immutable, and I I think cannot be immutable with the if given what you said previously.
[00:49:17] Alan Frindell: That's correct. Okay. I hear you saying.
[00:49:19] Martin Duke: Yes. That's right. Certain like, in mid subgroup, like, the the published priority could change because, like, you get the message on the control stream and you're halfway through the subgroup. Like, all that stuff is just gone, which is fine. It's a little if if I think it's the only object property that's of that nature, object metadata that's of that nature, maybe I'm forgetting something else, which makes it a little annoying. But but this will certainly work as long as you are diligent about clearing out these, like, mount for track issues.
[00:49:52] Alan Frindell: Okay. I I I I think that that is the intention. Okay. Steven?
[00:49:59] Steven Riedl Riedl: Yeah. We're interested in mainly audio as well. Something about only holds up the effective priority preserved, and today it isn't. So I'm still looking into it a bit, but I I think we are interested in having it.
[00:50:15] Alan Frindell: Okay. Thanks. Victor?
[00:50:22] Victor Vasiliev: Yeah. I am almost skeptical of this unreliable priority delivery because I can see it's leading to edge cases that are unpleasant to debug. I guess the question is, like, do we really and there are there are two families of edge cases. One of them is a race condition, and two is like, there is a race condition, but now you have to reorder. And, like, what if your messages arrive out of four turn, and get stuck with wrong priority and things like that, and you have to think about that.
[00:51:06] Alan Frindell: I'm maybe confused about what you're are you saying the reordering is between the data plane and the control plane?
[00:51:13] Victor Vasiliev: Well, both between data plane and control plane and also with control plane.
[00:51:19] Alan Frindell: I don't see how the messages are all on a single stream, so I don't see how there's reordering in the control play.
[00:51:27] Martin Duke: K.
[00:51:38] Alan Frindell: Okay. Are you still thinking about that or no? Okay. Luke.
[00:51:44] Luke Curley: It's it's a it's a single byte. I mean, I would keep it simple. But that being and I'm mostly worried about, like, VODs being nondeterministic. You know? You know, it's the based on when you receive the live objects, it, like, saves the priority of an object in a recording, and now it's racy. But, like, it's a single byte, so it doesn't matter either way.
[00:52:08] Alan Frindell: Okay. I mean, I guess I heard some people say they the the question on the previous slide, does anybody have jacks? I heard Victor and Luke say no, or they they would sort of prefer not to do anything here. I think this PR also needs to be updated against the more recent draft. So I think we will attempt to soldier on with it. Mo? Yeah.
[00:52:33] Mo Zanaty: Just a question about whether or not you still wanna have guidance about when the publisher does make this change. Is it still waiting for the okay? Does it does it tag all the objects explicitly until it gets the okay? Are we saying we don't really care about the transitions that much, and it can just be, you know, best
[00:52:52] Alan Frindell: out a good question. The the way the PR the PR was written pre published state notify, so it uses request okay request update. So we'll get a request okay, acknowledgment from the peer when it changes its default. And I think that's useful because it can that's when it knows it can when it gets a priority change, it sends a request update and starts tagging everything explicitly. When the okay comes back, it can drop it. So I think it's still a reason to use request update instead of publish date notify.
[00:53:20] Mo Zanaty: My question is really, do we add that guidance as informative guidance or normative guidance or not even mention it? Because we don't really care about the transition as much as we used to.
[00:53:29] Alan Frindell: Are you saying, like, you would rather let the publisher do it either way?
[00:53:34] Mo Zanaty: I I personally feel I don't I don't I don't think we need the guidance. I think, you know, let the let the publisher if it wants deterministic, you know, guaranteed priority, you know, unambiguous priorities on every object, it can use this algorithm. If it if it's best effort, then, you know, just let it let it not do this. Do the request update and and
[00:53:56] Alan Frindell: then I think
[00:53:57] Mo Zanaty: change it instantly.
[00:53:58] Alan Frindell: I get you. I think we can amend the PR so that it could work either way. But it doesn't address, like, Luke saying, I don't want any of this complexity and Victor saying it might be hard to debug.
[00:54:09] Mo Zanaty: I would just make the and the guidance normative informative instead of normative if it is there at all.
[00:54:13] Alan Frindell: Yeah. Okay. That makes sense. Cullen?
[00:54:16] Cullen Jennings: Yeah. I'm I'm just on the like, we can say, you know, if you care about this deterministic, here's what you should do as a sender. You can do this. But if you don't care, you don't need to do it. Right? And I I I mean, that's sort of what we've had forever, right, somehow.
[00:54:29] Alan Frindell: Yeah. Actually, I think if you really wanted it to be deterministic on the receiver side, you can do it with some additional state.
[00:54:38] Cullen Jennings: I I mean, I guess the thing is I'm perfectly happy if we don't have a a way that solves the deterministic problem, and we certainly don't have to dissolve the deter we don't need the complexity of solving the deterministic problem by default. Right? Yeah.
[00:54:50] Alan Frindell: I mean, I hear that other people are saying that they
[00:54:52] Cullen Jennings: no big deal. Yeah.
[00:54:53] Alan Frindell: That is but that it bothers them. So I'm just trying to figure out where we're going. Okay. I I think we have we'll we'll make a rev of this PR, and we'll see if if if we can get it over the hump or not. Mike asks, is there anything that falls out of this with object canonicalization? I I think the answer is yes, and I think that was Martin's question, which is, like, there's sort of a canonical idea of an object. Like, its ID you know, the object ID can't change, but you could be looking at the object two versions of the same object, one which has priority a and which has priority b. And we're we're trying to we're basically gonna the this PR will have to say, like, that's just okay. Like, the canonical well, if that happens to you, the canonical version is the one with the higher priority and and move on with life.
[00:55:44] Martin Duke: Okay.
[00:55:47] Alan Frindell: Enough on that.
[00:55:48] Mo Zanaty: Ian, you wanna
[00:55:49] Alan Frindell: talk about this one? Oh, go ahead, Moe.
[00:55:50] Mo Zanaty: Yeah. I have one more question about Martin's point about if you get this mid subgroup, do you need to downstream, you know, reset the subgroup or not, and and start it on the on the new priority? It's just best effort. Right? So if you get this mid mid mid subgroup, you're fine to just continue that subgroup on with its current priority or propagate the control message if you if you want to. But there's no requirement to stop the subgroup and re reset the subgroup and start another subgroup with the right priority with the new priority.
[00:56:20] Alan Frindell: Right? That would be terrible outcome.
[00:56:22] Martin Duke: No. You definitely don't wanna do that, but you might reprioritize the stream. But right now, there's all this text about you cannot do you cannot change this. And, like, if you fetch something and the subgroup like, you can't express a change mid subgroup published priority today. But, like, if you have a if you have a fetch and you're delivering this information, like, that that's that's today a malform track if you change mid sub. Like, I I don't know if she even been sending publish priority and fetch anymore, but it's maybe a different PR.
[00:57:01] Mo Zanaty: Well, just to clarify, we're not gonna have any mention of that aspect in this PR about a changing subgroup mid subgroup. No guidance about what to do if it No.
[00:57:11] Martin Duke: No. No. Like, we have to we have to delete the part that says that's a malformed track.
[00:57:17] Mo Zanaty: Okay.
[00:57:17] Martin Duke: That that is a complete showstopper for this. But other than that, yeah. Like, mean, maybe if it's a femoral thing, maybe it doesn't even go in fetches anymore. But that yeah.
[00:57:27] Mo Zanaty: But the malformed track is if you're getting two of them. That never happens anyway. So I don't think No.
[00:57:31] Martin Duke: No. No. If you get a fetch where the you have two object for the same subgroup of different publisher priorities, that is a malform track today.
[00:57:41] Ian Swett: I have a question about this. Should we be restricting this to group boundaries or something? Because, otherwise, we're doing a bunch of stuff we said we would shouldn't do. I don't know.
[00:57:53] Alan Frindell: I don't know. I mean Is that at least, like, fixes lot stuff? The big use cases here, or maybe, Steven. Like, if we restricted it to group boundaries, does that break you? And it doesn't make it any does it actually make it easier?
[00:58:05] Ian Swett: Well, I mean, it avoids us dealing with this this question of, like, now you can change the priority of a subgroup, mid subgroup sort of stuff that
[00:58:14] Alan Frindell: That does help.
[00:58:18] Cullen Jennings: I haven't really thought about that much, but it seems like the case I care about this for is audio where every packet is a new group. So I I don't think that matters to me. I think I think I think that sounds fine what you're proposing and saying you change, of that, but probably needs a little bit more thought.
[00:58:34] Alan Frindell: Okay. We'll we'll go think about it. Okay. You wanna talk about Fetch okay?
[00:58:39] Martin Duke: Sure.
[00:58:42] Ian Swett: After Fetch landed, that makes fetch and fill fetch both very similar, but, like, there are some differences in one. Notable one is that fetch okay has end location and end of track still. End location is kind of, like, largest object, but not quite. It could maybe allow you to, like, express an end location that, like like, conflicts with largest objects in the worst case scenario. But, I mean, the main the main thing is it seems to me, like, it would be nice to have fill fetch and, like, regular fetch be as similar as possible, and these are two spots where, like, they are dissimilar. I think requiring end of track can also potentially delay fetch okay. Like, you could end up with a weird circumstance where you can actually deliver the entire fetch. And because you have to go upstream to figure out if the track has ended, you might not be able to send the fetch okay until, like, after you've delivered all the objects. I don't
[00:59:38] Alan Frindell: think that's right. I think you only need to set that bit if the largest object or if the end location is the largest objects in the track.
[00:59:47] Ian Swett: Oh, is that how it's okay.
[00:59:49] Alan Frindell: I think.
[00:59:52] Ian Swett: Okay.
[00:59:53] Alan Frindell: So if you if you have if the you don't know if the track has ended, you have some largest object, and the range is you get a request for ranges lower than that. You don't have to go upstream.
[01:00:02] Ian Swett: Okay.
[01:00:03] Alan Frindell: But if you get a range that's past the largest object, and you don't know and you don't the track's not live and you don't know if it's the end of track, you have to go upstream to find out if there are more objects in the requested range or not.
[01:00:15] Ian Swett: Right. Right.
[01:00:16] Alan Frindell: Does does that make sense?
[01:00:18] Ian Swett: Yes. I think so. Anyway and large subject is and and location are largely kind of redundant to each other today anyway. You can kind of given you we have failed patch networks, you know, you should be able to replace all the functionality of end location with largest object. End of track is a little bit more unclear. I guess, like, there's a use case where end of track bit allows you a cache to avoid going upstream if you don't include an end of track object. Although I question, like, do we really want two ways to do something? One where you have to remember the thing from the control plane to figure out the track, and the other one where, like, the end of track is in the data plane. I'd rather have only one. That's that's me. Anyway, this is mostly, like, trying to polish off some potential edge cases and make fetch more like fill fetch. So that's feedback.
[01:01:13] Alan Frindell: Martin. And, Steven, you might still be in the queue. Stay on hand.
[01:01:28] Martin Duke: No. Never mind.
[01:01:33] Ian Swett: Go for it, man.
[01:01:36] Mo Zanaty: For I think we we always keep talking about these VOD tracks, which may not even been in the thoughts when we started Mock. But the VOD tracks that are never gonna be live, always gonna be fetched, should we just have a property for those? Should should should you have, you know, first object and last object as track properties of all the VOD tracks? And so you know when you get a track, oh, this is a VOD track. It has a first and last object. I already know end end end location. I already know start location of the entire track. And that way, we don't have this guessing game for these VOD tracks. It doesn't help us with the live edge case. The the the live case, you still you don't know the the when the track is gonna end, so you still need some way to indicate when it actually does end. But I think for these VOD only tracks, maybe it's useful to have a property that says the start and end locations of of the track, and then we don't need it in fetches.
[01:02:35] Ian Swett: That's that's an interesting point. I I hadn't thought about that, but that's basically making it a track property and add it when it terminates.
[01:02:44] Suhas Nandakumar: But don't don't we have in fetch okay if it's the track is active or not to basically say if it's a a track that entered, like, walk track, for example. I think we have a bit to express to say
[01:02:54] Mo Zanaty: that today.
[01:02:55] Alan Frindell: No. Oh, that's the bit we're talking about, Suhas, but it doesn't mean that. It means the bit means that the location in the okay's end location is the largest object in the track, which can be cached, which means if that cache gets a fetch that extends beyond that, it does it knows it doesn't need to fetch for it. It knows that all objects beyond that do not exist. That is the purpose of that bit. So I think Mo's idea is interesting, except it doesn't I I don't see how it works when something transitions from live to VOD where the property gets added and how how does the cache learn about that. Otherwise, it's a good idea. And the other thing is that in terms of replacing large end location with largest object, there are times when they're not the same. Right? So that would mean, like oh, I guess I guess when they're not the same well, okay. There's one one case they're not the same. It's like, I'm fetching in the past, in which case the end location is the end location I specified, and the largest object is just informative. There's a case where I fetched past the largest object. Largest object is now my end location, and so I realized not to mark things as nonexistent past largest.
[01:04:12] Ian Swett: So Yeah. It's identical logic to whatever code you have to write for fill fetch. You just use that same code here.
[01:04:19] Alan Frindell: I feel like maybe we just need to wait until we implement fill fetch and then see what shakes out here.
[01:04:25] Ian Swett: That's
[01:04:25] Alan Frindell: fine. I think that may be the the way to go. I'm I like the end of track bit for the reason I just said, which is I I can definitively cache things, but Ian's correct that, like, fill fetch doesn't have it, and it's a little weird that it's in one more place and not the other. Victor also opened a very interesting issue yesterday about times when the largest object and the largest known location are actually different. Which further complicates this. Because you might have, like, received only you've like, you had an end of group bit in a subgroup, and then you saw an object, but but then you also know information about that group for objects you haven't actually seen. I don't know. We don't talk about that now.
[01:05:18] Ian Swett: Yep. I'm I'm happy to check this for
[01:05:20] Alan Frindell: Let's park this until after
[01:05:21] Ian Swett: draft 20 interrupt. Maybe we can talk about it again at the Seattle interim.
[01:05:26] Alan Frindell: In Seattle would be good.
[01:05:27] Ian Swett: Yeah. In as Martin so eloquently said.
[01:05:30] Alan Frindell: Western Australia? Okay. Okay. Revisit prohibition on overlap and subscribe namespace and tracks. This kinda came up during our interrupt call on Tuesday Wednesday. Although it came up in the context of published namespace, but it's a it made us think about subscribed namespace. Because of bydie so right now, we were it says if it's it's an error if you try to send a subscribed namespace or a subscribed tracks that has a prefix that overlaps with an existing one. But because bydie the way bydie works, you can't do this reliably anymore. So if I send a subscribed namespace for a particular one, then I cancel it. I have no idea when I can send the next one because I don't know when the peer recognized that I canceled it. And we had the original rule in there because subscribed namespace used to solicit published namespace messages. And if you actually had overlapping namespaces, you would just get multiple copies of the same message in the control stream, which were, like, absolutely useless. Now bydie kinda makes that different because the namespace messages come on the bydie streams. So they're not it's not like the strict duplication case. And if you think about subscribed tracks, because of the way filters work, you might there might actually be a use case for having overlapping subscribed tracks with different filters and forward flags. So, like, I want all the tracks in namespace view that are have red objects, but I don't I just wanna prewarm that track. That's a forward zero, but I have these other but the blue objects in there, like, I want those to be forward one. Martin's question, does subtracts create a duplicate publishing? Yes. It does.
[01:07:11] Martin Duke: So, like, this seems this, like, overlapping is a whole data structure for me. So I would love to see it gone and vanished. But I think the subtracts problem is really bad because we have this other thing where, like, the the publish the subscribe namesake gives you the parameters for the publish.
[01:07:31] Alan Frindell: Subscribe tracks will put the will copy the parameters into publish. Yes.
[01:07:35] Martin Duke: Yes. So, like, if I have two subscribed namespaces and then a track is published for it on some other byte stream, I have to identify which a sub NS, like, led to it because that's how I know what the parameters are.
[01:07:50] Alan Frindell: You mean on the subscribe side? Are you trying to the publisher needs to know or the subscriber?
[01:07:58] Martin Duke: Well okay. Say I have two subscribed tracks that have different parameter sets and follows for both of them. So do I publish it twice? And if so, how do both sides know what parameters to use? If not if if I publish it once, like, which parameter set do I use? Like, I I I I don't hate this idea, but, like, I think this needs to be baked quite a bit more.
[01:08:28] Alan Frindell: Okay. I think I tried maybe I answered part of that. I didn't read the key part.
[01:08:33] Martin Duke: Maybe it's all in there.
[01:08:36] Alan Frindell: Well, no. It's fine. And the deck wasn't available early enough for you to have thought about this in advance. But I think you're talking about published lacks a correlator to the a direct correlator to the subscribed tracks that generated it. Yes. To what degree would adding that if we added a subscribed tracks request ID or something in publish, would that actually help you or or not?
[01:08:58] Martin Duke: That would solve the problem. I guess it has to be parameter because in general because publish can be without a subscribe track thing. Like, adding parameters is cheap, I suppose. I I think that works. There's still the question of do I publish it twice or just once? I guess you could have different filters for
[01:09:21] Alan Frindell: the two. If you added a parameter, the answer is clear. Twice? You publish it twice with the with the subscribe tracks. Those subscriptions have different filter sets on them potentially. Right? So
[01:09:35] Martin Duke: Yes.
[01:09:39] Alan Frindell: I think.
[01:09:40] Martin Duke: Yeah. I mean, logically, that works. I I don't I don't I'm not in love with that, but I could live with it, I think.
[01:09:52] Alan Frindell: Okay. Cullen?
[01:09:54] Cullen Jennings: This does seem like it needs a little bit more baking, but I I think I come around to it's really difficult to try and filter everything.
[01:10:02] Martin Duke: But the like, we should
[01:10:03] Cullen Jennings: just go, like, if clients ask for the same thing three times, like, we'll give them what they asked for. We'll send it to them three times. I I think it's where we're gonna end on this, but maybe we need some other stuff too. So I I think this needs a little bit more thoughtful.
[01:10:19] Mo Zanaty: Mo? If I understood correctly, the only motivation of this was for updates. Why wouldn't you do that? Why would you do an update instead of a stop sending?
[01:10:29] Alan Frindell: Well, I decided I didn't want it, and then I changed my mind. And then I decided I do want it. Or I didn't want this old thing, and then later I decided I wanted a new thing, which happened to be recursively under the original namespace. Originally, we tried to solve this problem by sending request update. It's like, never never cancel one of these, and you'll never have this problem. But I think it may not be practical.
[01:10:55] Mo Zanaty: So you're saying that some cases you may wanna cancel and then turn around and resubscribe immediately before before the other subscription has been torn down? That's the that's the use case?
[01:11:07] Alan Frindell: That is the race condition that we we're not saying I'm not saying there's a use case where, like, I definitely need to do this in my application or it's going to break. What I'm saying is, like, we're designing a protocol that will fail sometimes if some application chooses to do that if we don't give them some other mechanism. But I think it's like a general consequence of moving to buy die streams is that, like, we sort of have to allow duplicates. And I think, like Cullen said, if you ask for it three times, you might get it three times.
[01:11:33] Mo Zanaty: My my my gut feel is that trying to close that little window of of canceling and then resubscribing, trying to close that little window with something like this will cause many, many more problems because now now I have to have rules about what tracks actually go to what subscriptions. Would it go to all three? If something is, you know, three levels of hierarchy, would would the top level get every track all the time, and then the bottom level only gets its own track? We can so you get three publishers in in in on that first subscription all the time. It it just makes it makes so many more holes to me in the protocol than what it is trying to fix. I don't think the thing it's trying to fix is actually a problem, And it seems like it's gonna actually create more problems or at least require more text to close the ambiguities that it creates.
[01:12:23] Alan Frindell: And you don't think that there's use cases where somebody would subscribe tracks with, like, different totally different parameter sets and want but in the same namespace?
[01:12:32] Mo Zanaty: And you're you're saying you want to deliver the same you want two publishers for the exact same track
[01:12:38] Alan Frindell: with different Maybe. Maybe I want. Oh my god. I guess I didn't give the example of here, I used object properties, but I could have used track properties, which means the set of publishes I'll get is different.
[01:12:55] Martin Duke: Well, I just came in to say, like, with top end, you could have subscribed tracks with I I can't remember if we have ends in that structure or not. But, like
[01:13:03] Magnus Westerlund: Mhmm.
[01:13:03] Martin Duke: If you want the top three, like, loudest people and then top three people with the most green backgrounds or whatever, you could have completely disjoint sets of publishers for those with the risk of having a duplicate if, you know, the loud person also has the green background. But do we have ends in top end? I don't remember. We
[01:13:25] Alan Frindell: I think we implicitly do because we have ends in all our filters. Right?
[01:13:28] Martin Duke: Okay.
[01:13:30] Mo Zanaty: The subscribe your so subscribe tracks allows arbitrary range filters, so you could put whatever range filter you want on a given namespace. Subscribing twice to the same namespace with different filters, that's the use case you're talking about?
[01:13:47] Alan Frindell: Yeah. Maybe. I don't know. If I invented this, like, I mean, in like, in people I mean, I hear what you're saying, Mo. So, yeah, like, let it be a race case. Let people fail sometimes, and we'll just say it's never gonna happen in practice and sleep at night.
[01:14:00] Mo Zanaty: I I would like to see the use case written down so that we can clearly understand the ramifications. I still don't see I don't see any use case for this. I don't see when you can already subscribe to a namespace with any arbitrary set of filters that you want. So why would you subscribe twice to the same namespace with different filters? You can already give a single filter that gives all of the criteria that you want on the namespace. So why would you do it twice? It doesn't make any sense to me.
[01:14:28] Alan Frindell: So I I think a lot of us are implementing not applications, but generic libraries, and so we don't know what the application's going to do. And so but from writing a generic library, you want it to, like, work. So But I don't have I don't have a use case, and I'm willing to, like, let it be ugly if people want it that way.
[01:14:45] Martin Duke: So so the the problem here is if I subscribe foo and then unsubscribe and then subscribe foo bar. Right? Like, that's the one
[01:14:54] Alan Frindell: Or or foo again. Yeah. Okay. Okay. We have Ian Swett, Luke Curley. And I we said we're gonna save ten minutes to talk about the resolution draft.
[01:15:09] Ian Swett: Yep. I wanna say that one thing is it seems like subscribed namespace has limited, if any, issues, at least that I can think of, whereas subscribed tracks has, like, a lot more complicated issues. So, like, we we can decide separately to, like, just allow overlapping subscribe namespace because, like, it doesn't really cause any problems and, like, the racing thing is annoying and think more about the subscribe tracks thing. Initially, I was also gonna say that you could use the set functionality to, like, to do the example you have for subscribe tracks and and, you know, update the filter to say, like, now I wanna subscribe tracks to, like, you know, this or this. However, then the top end filter was thrown out, and I'm like, oh, that doesn't work for that. So
[01:15:57] Suhas Nandakumar: I don't
[01:15:58] Alan Frindell: know. It doesn't work for to forward on the different things either. Right? Some of them are, like, the query, and some of them are the action.
[01:16:10] Ian Swett: Sorry. For what?
[01:16:12] Alan Frindell: Some of the fill some filters may be selecting what publishes you get, and some parameters may be selecting what happens after you get them. That's right. What the subscribed priority is or forward flags or filters on the track.
[01:16:24] Ian Swett: Alright. Anyway, subtrack seems, like, complicated. It was about like, it'd be nice to avoid it, but subscribed namespace seems eminently safe. And so I'd probably be in favor of allowing it because why not? And I think there are use cases. Like, I want to subscribe to the more narrow thing before like, maybe before break. I wanna subscribe to the more narrow namespace before I, like, kill the, like, wider namespace subscription or something.
[01:16:49] Alan Frindell: Yeah. Okay. Luke?
[01:16:53] Luke Curley: I was just gonna ask a question about I think if you update a filter, does that apply retroactively? Like, Like, if you have subscribed namespace foo and you say that same connection and you also want bar, it wouldn't give you bar from the past. It was only giving you new namespaces.
[01:17:08] Alan Frindell: It's explained in the draft. Basically, what you're setting is, like, the parameters on a factory. So the widgets that were already made do not get changed.
[01:17:15] Luke Curley: Yeah. Whereas a separate subscribed namespace, you would get the stuff in the past.
[01:17:21] Alan Frindell: Subscribed namespace would you a separate subscribed tracks. Yes.
[01:17:25] Luke Curley: Well, even subscribed namespace, you you it's not only new publishers you get. Right? You get historical stuff too.
[01:17:32] Alan Frindell: Well, subscribed namespace doesn't really have any of the things you're thinking about, but subscribed tracks does. And so that would be a difference, I think.
[01:17:40] Luke Curley: Yeah. And, anyway, this is, the classic race condition where you don't know when the stop sending or the the fin was received, so you kinda need to have overlapping even just for that race. But Okay. I I do I do know. I'll I'll chat with you offline, Alan, just to make sure I understand the subscribe namespace.
[01:17:57] Alan Frindell: Yeah. Okay. Sounds good.
[01:18:00] Ian Swett: Martin? Oops.
[01:18:05] Martin Duke: Yeah. Like, I just put it in the comments, but, clearly, this can't be a protocol error anymore. Like, I I think I don't remember what where we settled on the duplicate duplicate subscribe exactly, but I I think I think what we do is we allow it, but we also allow publishers to just terminate one after a while if
[01:18:28] Alan Frindell: I think it's more like we just we let you do it, and you might be getting duplicate objects until you cancel one of them. It's like, if you're stupid, be stupid.
[01:18:38] Martin Duke: Yeah. I mean, this is it was just a May, I guess, but and servers are gonna do. But, like, if I sort of sense that you're being stupid, I could just, like, kill one of your your old subscribe or something, which is kind of the same for both subscribe and this the the subscribe duplicate issue in this one. But, I mean, I don't know if we need normative text about that because I think they're gonna
[01:19:02] Alan Frindell: be I don't know. Like, you can ask the h t the same HTTP server for the same object over and over and over again. We do we use it for load tests. Like
[01:19:12] Martin Duke: like Oh. Copies of it. Yeah. I I guess. Well, I mean, I guess that maybe we should like, if you think it's important that publishers not do this, we can tell them not to do it because there's an important use case, like, load testing. If there's not an important use case, I think we should call out as like, that's kind of a stupid DoS attack and and, like if okay. If the only reason this happens is because we are in a race condition, right, and, like, there's just a problem where, like, there's an old subscribe and a new subscribe, and there's a lag in the unsubscribe, Then we should encourage publishers to, like, nuke the the old subscribe. Right? If if there's a legitimate use case where you want two things open indefinitely, then we should say that publishers really should not do that because there's a legitimate use case. Like, we should be really clear what the intent here is. It isn't just the I'm
[01:20:07] Alan Frindell: in the later camp. We just, like we just say you can't like, it's not an error anymore. You're just gonna get duplicates, and it's not really great to be you if you're doing that. But at least nothing's broken.
[01:20:17] Magnus Westerlund: It's ten minutes left.
[01:20:19] Martin Duke: Yeah. Yeah. Thanks thanks, Magnus. I sort of disagree, but, you know, I we're not gonna figure it out today. Okay.
[01:20:27] Alan Frindell: Okay.
[01:20:28] Martin Duke: Feel feel free to jump in sometimes
[01:20:29] Alan Frindell: in the issues. Yep.
[01:20:31] Martin Duke: Yeah. Suhas or Cullen, are you ready to go on this?
[01:20:58] Cullen Jennings: Yeah. Sure. I'm I'm ready to to talk about this here for a second. So, let me a screen share. I I should have tried this ahead of time. I'm sorry. Okay. Window. So okay. So look. We I I have this as a separate draft right now that that talks about a bunch of things, but I think the the key things but I originally started writing this as a PR for the for the the current draft. And I think this PR is actually the easiest way to talk about the things that we sort of need to to solve as a working group. In fact, let me make this window smaller, see if that shares in a larger font. Okay. So there's a bunch of questions we need to sort of sort out in, like, our DNS resolution and things. DNS and then how that matches to the TLS security certificates. This draft has more than that, but, like, we can talk about that later. I think what we need to get some signal on is the key things. So the first one really here has to do with what type of DNS records do we require clients do a lookup on and are capable of supporting. So there's the obvious ones, you know, trip you know, quad a, CNAME, that that's all fine. The one that's I think the one that we should do is this service binding. Now why I think that we should require so this is the one we could have a discussion on and get some input. Should we require this or not? The problem is if we don't require it, it's very hard to add later because you never know whether you can use it or not because some clients might support it, some clients might not. And it's really useful for managing load balancing on servers. So this is one of the first things we're gonna have to do as a working group is figure out where we're going to support this type of DNS record or not. There's some other ones we could talk about, like SRV URI, DName, which I think are far less important than the service bot. So let me just stop there. Victor.
[01:23:03] Victor Vasiliev: How much of the capital must since the draft are actually implementable in a web browser client?
[01:23:11] Cullen Jennings: Well, 100% of them are implementable in a web browser, but the browser might need to change. So, like, I don't I I think that, like, that's a that's a very easy thing to resolve over time. And I've been very care so, actually, I think what we should do is, first of all, frame this conversation around raw quick access, not WebTransport. Because the answers for WebTransport might be slightly different, and part of the reason why is WebTransport has so many backwards compatibility. It's more historic. It might not have all the support that we have for the raw quick implementations. When I went and read all the WebTransport things, everything I'm proposing here seemed like WebTransport was allowed to do that. It wasn't denied from doing that. But actually seems that WebTransport doesn't actually require a mandatory to implement security scheme at all as far as I can tell. But I could be wrong about that.
[01:23:56] Mo Zanaty: I don't I
[01:23:56] Cullen Jennings: don't really know. I tried to dig through it. It's not easy.
[01:23:59] Victor Vasiliev: Wait. What what do you mean by security scheme?
[01:24:02] Cullen Jennings: I mean a scheme where you are guaranteed that a man in the middle cannot reach your packets. I understand all browser implementations of it do deliver that, but I could not find
[01:24:16] Victor Vasiliev: There is definitely capital Send must. Since the overview draft that you have to use TLS one tour equivalent in security.
[01:24:25] Cullen Jennings: Right. I couldn't find anywhere that said the name had to match.
[01:24:30] Victor Vasiliev: That is more complicated. That is actually not specified anywhere as we've Yeah. Exactly. Tried to change that. But that's also not specified for regular HTTP.
[01:24:40] Cullen Jennings Jennings: Right. Yeah. And I understand why it's not specified for regular HTTP. But what I'm saying is for mock, it should be specified, or at least mock over raw quick. Maybe mock over web transport, choose not to specify. But, I mean, I think for this. So, really, I mean, if you got any feedback on service binding DNS? Okay. So the next question we come at is what certain names in the TLS or what in the certificate fields, there's there's common name, there's a subject alternative name, there's these various things. I'm proposing that the only place we should look at for names is SAN. Now Firefox and Chrome have only looked at SAN for, like, about the last ten years as far as I can tell. So this is not a really, you know, controversial proposal I'm saying that we should ignore a common name. But there's all kinds of things that get really complicated if you try and include common name and it's buggy as crap. So I'm proposing only subject all name. Let's see. Now let's see. The next thing that we get to is inside of the subject alt name, there's a bunch of different types of fields that can be proposed inside that can be used inside of here, and we need to say which ones make sense and we could use. So DNS name, we absolutely have to use. Right? Like, that's where you put, you know, example.com. Okay? So we have to have that one. Uniforce URIs are also very useful. They're used in some of the more things where you're trying like, let's say that you wanted to be able to provide a different service for, like, let's say a CDN is providing a a base URL, you know, akamai.com/webex, and that's one cert, and slash zoom is a different cert. So with URIs, you can you can narrow the scope down to those types of things. So that has a bunch of uses in the higher security environments. It's prompt becoming a better practice in certs in general, but we we definitely we, you know, we need to sort out whether we allow that, don't allow that, or require that as implementation. And then there's IP address as well, which is also very much used in some types of deployments. But if you wanna be able to put an IP address in your URL, like 1.1.1.one, you pretty much you need to support that for it to map in the certificates. There's one that's a little bit more complicated. It's on the difference. This this SRV name one probably maps back to if we do the service bindings, then we probably need to have these here as well or not. I think that it takes some more thought and considerations on that. So that's one of the other decisions we need to make as a as a group, sort of come up where we are on these. I don't stop seeing any questions. So then on all of this stuff, you have to decide how to canonicalize the names.
[01:27:33] Victor Vasiliev: I think that we can
[01:27:33] Cullen Jennings: do the I I think the answer is exactly the same as HTTP does it for almost everything. But, you know, we need to just sort of check that that's that's specified. And then the the the next one is wildcard matching. So can you allow certificates like wildcard certificates generally have a name like star.example.com to match, you know, everything there, any sub domain of ofexample.com. I think those have generally been proposed has turned out to be a bad idea in in general, and I think that we should and it's it's been part of the problem is explaining how to match them. So I think that we should say that wildcard matching is not allowed in mock use cases. So, you know, that's but, you know, that's that's one of the other decisions we have to make. So with all these decisions, we then come to the question of do we put this in the main draft? Do we put this in a a separate draft? Alan had said he really didn't want you know, if it was gonna be more than 1,800 words, he didn't want it in the the draft, you know, as a starting point. It's definitely gonna be more than 800 1,800 words by the time this
[01:28:39] Martin Duke: is
[01:28:39] Cullen Jennings: done. So I started as a separate draft, and that's that's where we are. So let me let me pause there and get feedback on the whole situation.
[01:28:49] Alan Frindell: So first, let me say thank you because I don't really understand this scope this part of what we do very well, and so thank you for taking it on and and getting it started. My question is actually more high level, which is, like, should we move a little bit more into this draft, which is, like, should we move the whole URI scheme definition into this draft alongside the resolution bits, or do you still think it makes sense to keep the URI defined in my transport?
[01:29:19] Cullen Jennings: I I I think it would probably make more sense to move that as well. I'm happy to do that. I just didn't I mean No. It's Obviously, I just
[01:29:28] Martin Duke: did a fine place.
[01:29:29] Magnus Westerlund: Yeah. Yeah.
[01:29:31] Alan Frindell: That's great. Otherwise, I don't have I'm not gonna be the one to provide useful feedback on this draft probably, but you'll get it from lots of people.
[01:29:38] Cullen Jennings: Yeah. Well, I'm I'm I'm looking for a careful review from Magnus.
[01:29:45] Alan Frindell: I did see a question in the chat. Why no wildcards?
[01:29:51] Cullen Jennings: I mean, I guess on wildcards, what we'll what we'll have to do, the general so I think that what we need to do on this is line up with the guidance from the security area at IETf because whatever they're going like, if we go against that, we're just going to get yelled at them during the last call as well and just gonna slow us down. So the general feeling on why no wildcards is because often there's been quite a few security vulnerabilities around people not use realizing they were using a like, issuing a wildcard certificate to somebody thinking like, oh, that's fine. They can have a wildcard certificate for star.cisco.com, not realizing that was gonna give them a certificate to email dot cisco dot com, which is gonna allow them to do a password reset on every person at Cisco. So there was you know, I think that that's some that that that we should just find out what the security area's feeling of what the best practices is around wildcard certificates and then follow it, and I suspect it will be no.
[01:30:50] Martin Duke: Alright. Cullen, thanks. It's quitting time. If you have thoughts about this, go to the list or go to, what is this, PR1901. And that discussion could continue, and I'm sure we'll talk about this again. We will see you all in thirteen days for our final interim of the period, and then after that in Seattle. Have a good day, everybody.