Session Date/Time: 22 Sep 2026 19:00
[00:00:04] Spencer Dawkins: Typing on some of it, but I think it's I think it's in good enough shape for us to have the meeting. Let let me ask you. While people are gathering, let me ask you a stupid question. If I was sharing my screen. Yes. I'm gonna share that entire screen.
[00:00:29] Robert Sparks: Hello. Jerome.
[00:00:32] Spencer Dawkins: How are you?
[00:00:33] Jérôme Martinez: Fine. Thank you. Excellent. Time to wait then.
[00:00:39] Spencer Dawkins: Excellent. It's good good to see you as always. I was just asking Robert a silly question, which you you you're welcome you're welcome to kibbitz or ignore us while you're waiting for other people to show up. Robert, so Steve put in the guidance for designated experts
[00:02:14] Jérôme Martinez: What is important is to have a codec ID identifier for one format and not two formats, or there is no conflict. The specification itself is not important. It is more to to reserve the codec identifier. So I I don't really get the issue there.
[00:02:40] Spencer Dawkins: So so cheating. And Steve will show up here and defend this his work at any moment, of course. But yeah. What we said was these. Mhmm. A yes. So that was that's that one. A the codec mapping does not already exist in the directory and then corresponding down here. Yeah. But So so I may be asking I may be asking, and we can talk about this actually during the meeting in a couple minutes.
[00:03:32] Robert Sparks: Yeah. We're officially we're past past the official start time, but we should wait for more people to join.
[00:03:39] Spencer Dawkins: Okay.
[00:03:40] Jérôme Martinez: So I am checking the text directly.
[00:03:45] Robert Sparks: So so let me check. Jerome, part of the part of this is that we've got a culture of if we're defining a standard and we've got a registry that people should be able to know what the standard is doing and be able to get to the things that define stuff. So that's just some cultural background.
[00:04:07] Jérôme Martinez: But what is the issue there with the current text?
[00:04:14] Robert Sparks: Well, it's entirely about the guidance to the what what Spencer is trying to call out is is whether or not we need to say more to the person that is going to be doing expert review for the registry on whether or not to say yes, this request for a point should be accepted or not.
[00:04:42] Spencer Dawkins: Yeah.
[00:04:45] Robert Sparks: So
[00:04:47] Spencer Dawkins: I should also mention that part of this is assume that Steve and Dave and Jérôme are not the designated experts in twenty years.
[00:04:58] Jérôme Martinez: Yeah. Yeah. In the future.
[00:05:04] Steve Lhomme: So it's
[00:05:05] Robert Sparks: Well, in the near future, right, you know, if AI wakes up and decides to exhaust the the whole point space, What's what is our designated experts supposed to do?
[00:05:21] Spencer Dawkins: That that may be what that may be how we wipe out humanity. Speaking of wiping out humanity, Steve has just joined.
[00:05:30] Steve Lhomme: I was there for a few minutes. I was just listening.
[00:05:35] Spencer Dawkins: Hi, Steve.
[00:05:38] Steve Lhomme: Hello.
[00:05:41] Spencer Dawkins: I I should I we we should we should we should back up and, actually start a meeting at you know, with with the meeting probably. The agenda. Yep. Yeah. But reminding people that this is an ITF activity, and please feel free to sign yourself in if you have not otherwise. And that that note well applies, and please be kind to each other, which has never been a problem for us yet, and I'm proud of you all. And our working group document two okay. Two things that we're we're saying here. One is we do have additional PRs from Steve about a dash 21. We will discuss those in today's call, Steve Lhomme. And for FFV1 v4, we I think the the answer on this was that we did have PRs for this that were that have been merged. Is that true?
[00:06:55] Jérôme Martinez: Yes. But I have pending PRs. I want to be merged before I do a new release.
[00:07:03] Spencer Dawkins: Oh, yeah.
[00:07:04] Jérôme Martinez: Sure. So my my target is next month. We have no time to wait, and we do a presentation about FFV1. So I am super motivated that
[00:07:14] Spencer Dawkins: Oh, abs absolutely.
[00:07:16] Jérôme Martinez: I I published something at this moment. So I am still finishing some of my next peers, and I would send new peers to to GitHub. And and then when it is merged by Michael, I will publish a new version. So before before so mid October. So before yeah. In a couple of weeks.
[00:07:56] Spencer Dawkins: Perfect.
[00:07:58] Jérôme Martinez: So so yeah. So my text is nearly ready, and I hope to send something this weekend to have a review and that might merge that.
[00:08:12] Spencer Dawkins: Perfect. So that will happen. And it's it's good for us to look at reported errata from time to time. We have two error errata. We have two for ported errata on the base specification. And and what am I looking at here? Yes. Yeah. Both of them looked reasonable to me. Both of them are from Steve, I believe, is correct. And both of them looked reasonable to me. Is
[00:08:53] Steve Lhomme: there
[00:08:53] Spencer Dawkins: a reason we don't ask our area director to go ahead and mark these as approved, or do you need to do you need to do you need to remember what they are?
[00:09:06] Steve Lhomme: I don't. I I never really fully understand, I mean, what we do with errata, how they are published, seeing they're visible already. But
[00:09:21] Spencer Dawkins: Yeah. So so I think, like I say, these these things should move these things should move past reported, I think. So we so the way we would do that is we look at them and say, is this something we would actually have done if we were is is it actually an error that we left something out when we published the specification, or is this a new idea? And I don't think either one of these were new ideas, particularly. They they were Yeah.
[00:09:53] Steve Lhomme: Well, that one that you're showing, it's clearly a bug that's it's very almost obvious to anyone who would use attachment that you could have more than one. So the max occur was just wrong.
[00:10:10] Spencer Dawkins: Yeah. So I think so I think our our my question is really do we want to do we want to tell the area director that we we we would have done this except these two errata except that we didn't think to before the RC was published. And so, this is the right answer, and we should move them to approved.
[00:10:37] Steve Lhomme: Sounds good to me. Yes.
[00:10:40] Spencer Dawkins: Good. You can think of something else for me to do because I actually did do a couple of action items this time. That's accepted. Right. Yes. Okay. Cool. One of these days real soon, we can we can look and see what eighty seven ninety four reported is, but we can do that we can do that another time. So the two things from this week the two things from the last meeting that I have in my mind, Spencer had an action to send out a summary of document changes and an indication we expect other changes to land in another ID revision and strongly invite the working group participants to review the changes, say that they have reviewed them and that they agree. I started that here, and the link to that is in the is in the document. But, anyway, most of these are pretty minor kinds of things. A lot of them are we get with from should to must and things like that. I Robert asked that I called out especially the additional text here because this additional text happened during it happened in the working group while the document was under discussion at the ISG. So so the working group hasn't really said good job yet on this text, but I but, basically, I call that out in my in my notes. And then so I can if if this looks like a reasonable thing for me to send to the mailing list, and then people can say, yes. I agree. Yes. I agree. Yes. I agree. That would be great.
[00:13:19] Robert Sparks: Why why why do you have question marks? There are several places where you, in parentheses, have this for clarity.
[00:13:31] Spencer Dawkins: We're changing from should to recommended. Okay. So that that means the same thing. Right?
[00:13:39] Robert Sparks: Yeah. But
[00:13:40] Spencer Dawkins: but this was like the previous the the the earlier text in this paragraph was this is not recommended, so this is now recommended. If if it
[00:13:52] Steve Lhomme: Shouldn't recommended. For me, they're not the same because should, usually, you have to explain in which case you shouldn't. Well, if it's a recommendation, this it just says, well, it's good to do that, but, you know, it's not mandatory. So right. Give you a particular reason.
[00:14:15] Spencer Dawkins: Yeah. So so what I'm saying is that in the help me out, Robert. BCP 14, is that is that the one that does basically what what normative language means? Should and recommended are synonyms in that in that in that in that document.
[00:14:36] Jérôme Martinez: Yeah. Still, I don't get the difference you do because, yeah, in the RFC, shouldn't recommend it the same. Yeah.
[00:14:44] Spencer Dawkins: Yeah. That's that's that's that's what I'm saying. So the changes in there
[00:14:49] Steve Lhomme: changes anyway. So I don't remember what Yeah.
[00:14:56] Spencer Dawkins: But I'm I'm I'm fine doing this for clarity. So my question marks could go away before I send that to the mailing list. But because to me, it's clear to say this is yeah. A couple more. I'll find I I'll make sure that there aren't any more. But anyway, before yeah. Okay. There are several. Anyway but I think that that's a fine change because it it basically reflects the language that's earlier in each. And that's true for each one of these. It's true in each case that that this was a this is now a recommended that was a should. So and it matches was not recommended pre just previously. So that's you know, it's not it's not that the normative text changed. It's just clearer that this matches that, basically. So I was fine with that. And thank you for asking that, Robert, because those question marks did need to go away before I sent it out. I have down here two changes, one twenty eleven twenty seven and eleven twenty eight. Just and these are this was changing codex to be the cloak codex to be plural codex, And this one was we had a must must not in the Ayanna considerations that we are turning into lowercase to not be normative language in a Ayanna consideration section. That and then Steve has one what is it, what, 11:30, which is we're now including all the bytes in the t 35 header.
[00:17:03] Steve Lhomme: Yeah. Basically, it's not from me. It's someone from developer.
[00:17:10] Spencer Dawkins: Okay. Okay. Right. Right.
[00:17:12] Steve Lhomme: Right. Who just found the the change on the t 35 with more descriptions. But, apparently, the specs are really tricky. And so, basically, the fields that were were in the document that I had, then it's very clear that there are these field, these field, these field. But in the real world, it's little more complicated. Some can add bytes and things like that. So he proposed the rewording to just use all the bytes in what is considered the header. So, basically, what we said, but more general because I'm in the original text I did, it was the first bytes. But it's like first bytes in the header, but, actually, it was all the bytes in the header, except all the bytes can be spread in different ways. So it's probably better to just say the bytes in the header and people understand what that means.
[00:18:24] Spencer Dawkins: Cool. So I think my so this gets us to okay. This gets us through the first part of this where I had the action. So the question that I wanna ask now is what this what this list says right now is these everything from here up is in dash 20. These are not in dash 20. Correct. Steve was planning on doing a dash 21 that included these two.
[00:19:12] Steve Lhomme: Yes. But then there was this comment, so I think it should be in the 21 as well if we agree.
[00:19:22] Spencer Dawkins: So do people need to look at this one?
[00:19:26] Steve Lhomme: Yes. If possible. If GitHub work works. Mhmm.
[00:19:34] Jérôme Martinez: But for for me, it is fine. I I had no comment on it.
[00:19:40] Robert Sparks: So we could see So were you saying there was more than what was in on Spencer's mail?
[00:19:49] Spencer Dawkins: No? No. This is this this is down at the bottom of my mail of of my proposed mail, which you guys might have seen that I put the link to my proposed proposed mail here. You might have seen that earlier today, but you probably haven't. So what my proposed mail was was basically, here's everything that's in dash 20. And starting starting here, this is all new. So this so I think what we're saying is these three would be we would put these in in dash 21. Is that right?
[00:20:39] Steve Lhomme: Yes. I already sent a mails about these earlier, but before merging these two and most and I mentioned after I merged them that there would be 21 soon. And then I sent an email when I did the 11:30 to send that we should we will do 21 when this is approved or in the correct form.
[00:21:09] Spencer Dawkins: Yeah. So, Steve, are are you okay with dash with eleven thirty?
[00:21:19] Steve Lhomme: Yes.
[00:21:20] Spencer Dawkins: Okay. And Jerome Jerome said he was okay with 11:30. So I would I would suggest that we go ahead and merge that one and then do '21 that includes these. And then I then I will change this email to say, these changes are in dash 21 from here down. And then that's what I'll send to the mailing list for, people to reply to. Does that make sense?
[00:21:53] Steve Lhomme: Yes.
[00:21:55] Spencer Dawkins: Okay. Cool. So I started a discussion with Robert, and Jerome clicked in, and it became spirited just before Steve got here. So so let's let's so let's rewind to that. For the section, we said Steve was going to propose text, that's happened in dash 20 now. And Spencer's question was, do we want to provide examples of what seller might be considered to be a usable specification for a codec file format. And typically typically, what this is okay. This is a standards track document at the IETF. Normally, that would mean that there's certain expectations around a around a normative specification. Cellar is different because we are supporting legacy stuff. And so for us, oh, there's an open source implementation might be very reasonable for us even though ordinarily that would not be true. But my question was, do we wanna put something in the document that is advised to advised to the designated experts saying and I believe I'm quoting Jerome correctly. Basically, the only thing that really matters more than anything else is that you have not reassigned a codec ID. Mhmm. So so so that's what really matters. But if you know, so it's like, okay. So that's that's solved the problem for Matroska. But for anybody that's trying to use Matroska for a for a legacy codec, it might be useful for the IANA registry to say, oh, and they're the best implementation the best specification for this is an open source implementation here or something like that. Do we wanna do we wanna put anything like that in the document as additional guidance for a designated expert, or do we wanna just stay away from that?
[00:24:32] Robert Sparks: Did the ADs ask us to
[00:24:37] Spencer Dawkins: The ADs so so my my my recollection is that we had several discusses and comments that might have not have been in discusses about specific references and saying, is that a good reference? Is that the best reference you can come up with? Things like that.
[00:25:04] Robert Sparks: So I So we've got we currently have that if a reference if a reference document is provided, it's publicly available with the stable URL. Yeah. Right? So we don't we're we are not currently broaching what the content of that reference document is. Right. I unless you think we've got a agreement with the ISG that we haven't fulfilled, I think that that's a third rail that we should not touch.
[00:25:39] Spencer Dawkins: I I I asked the question so that you could tell me I'm nuts. You have now done that, and you've done you good job. So I
[00:25:51] Steve Lhomme: agree also. And, like, basically, you for pretty much all the codec we have, we could say, oh, you can have a look at Libavcodec codec, and it's in there. But, for example, if you take JPEG, which we support, which one is a good implementation. Our people are just reading the code and capable of understanding how the format works and how to put it inside the container. Mean, that's my day job all day long, and I think it's not the case. You cannot choose an implementation, and they'd use the the way to use the format most of the time.
[00:26:41] Spencer Dawkins: Yeah. So I I
[00:26:43] Steve Lhomme: don't think being that specific would help because in the end, it's going to be just more trouble.
[00:26:50] Robert Sparks: Then Got it. I think it it would be just asking for trouble to try this to write anything down.
[00:26:57] Spencer Dawkins: And and that would be better trouble to ask for if the document was still in the working group.
[00:27:04] Robert Sparks: Yeah.
[00:27:04] Spencer Dawkins: So so now that everybody's already belated on it to say, oh, and we've have other thoughts, not a good plan. So, no, we will not do that. So I think what we're doing is that we will let Steve we will let Steve submit a dash 21 with the three new PRs.
[00:27:38] Robert Sparks: Yeah. I think that's the right thing to do. I do have a follow on discussion before we leave the topic, though. Of course. Particularly of this expert guidance to the experts. And I'm not asking for any change to the document. I just like to plant this idea into people's minds and have them think about whether or not we should do anything at all or just be aware. There are a lot of conversations bouncing around the ITF right now about the impact of AI on standardizations, and one of the variants of this conversation that has happened in a few places is concern for both FCFS and expert review registries that AR group of AIs come along and make up a reason to fill the code space. Right? What would we expect to to to make this concrete for us, for this document, If a fleet of AIs came along and invented more codecs than we've got code space for and came to register them in this registry, what should our expert reviewer do?
[00:29:14] Steve Lhomme: So, technically, they cannot exhaust it because it's almost infinite.
[00:29:21] Robert Sparks: Okay.
[00:29:23] Steve Lhomme: The number of ASCII characters on 64 bits amount, I don't know how billion, trillions. I don't know.
[00:29:38] Robert Sparks: Alright. So let's let me change the premise to overwhelm us with a ridiculous thing.
[00:29:45] Steve Lhomme: Get the idea of, like, a lot, And that's actually a very real possibility, actually. I mean, there's there's no text to explaining how to refuse something because the idea here, I think the main issue is that you should refuse, is just spam. I mean, the idea of having a common codec idea is that everybody would use the same codec idea. But Yeah. You can have 10,000,000 codec, and everybody is using each of them. It's basically having one codec for one purpose and one person. It's not very the goal is not really to share it for everybody else to use it.
[00:30:46] Robert Sparks: So and, I am not trying to open the current document up and Right. To explore thinking is that we've got an expectation perhaps that we've not written down that an expert should evaluate whether or not this code point is actually likely to be used.
[00:31:14] Steve Lhomme: Yes. Yes. That sounds like a good way of saying it, then we'd need a proper way of putting that in the documents. But yeah.
[00:31:33] Robert Sparks: Well, I and I encourage us not to try to put it in this document. I just wanna have a discussion to help me inform other discussions because I think that the ITF's gonna say something about this in general and that we should just wait for the ITF as a whole to say a thing and then wait a thing.
[00:31:52] Spencer Dawkins: Yeah. If if I was going to try and use an an analogy from past history in the ITF, this I think that this is sorta like when somebody said, how many of our specifications can we use with I p v six? Because we we because we had a lot of specifications that assumed v four, and there you know, some of them some of them accommodated v six. A lot of them didn't. And so there was, an all out tiger team to go through the specifications looking for things that only supported v four. But it was that was not that was not like we're gonna change a specification or even we're gonna tell a working group to to change specifications, it's like the IETF needs to do something different. And I think that's kind of what Robert is talking about, that kind of a thing now. If if the ISG if this is something the ISG is talking about, it would be talking about it for all the specifications in all the areas.
[00:33:05] Robert Sparks: Yeah. And and I really wanted to talk about it here just to hear Yeah. Steve's reaction and and anyone else that, you know, has immediate reaction to it for what that eventual guidance should say.
[00:33:23] Steve Lhomme: Different opinions on this because, basically, you could have someone who created the codec on his own and wants to share it and makes nice specification and say, I want to use that. And maybe no one will ever no one else will ever use it, but why should we refuse it? If it's correctly specified, why not? Especially if the second person wants to use it, then it's better if they don't step on each other, I don't know, whatever. But then if it's an AI and then say, I in my data center, I've created 1,000,000 codec. I have made nice specifications. And in case someone wants to use them, what's the criteria to say, oh, for this guy, it's okay. And for the millions AI, it's not what's the criteria? I actually don't know. Mhmm.
[00:34:31] Robert Sparks: That's where a lot of people are at the moment. So
[00:34:37] Spencer Dawkins: I'm just where am I?
[00:34:43] Steve Lhomme: And you it's you saw tricky because it's not like you could say, oh, come back when you have 10,000 new users and etcetera. Yeah. If they have 10,000 users, that means they already used the idea. And then because someone else could come and steal it for another codec and they're in trouble, so it's not nice either. So, yeah, I don't know don't really know. My for me, the main question here is not really do we accept or not. Well I mean, for if all the criteria are met and just there's a good spec, etcetera. For me, it should be okay. The question here is more about spam than than actual valid technical merit. Mhmm.
[00:35:49] Spencer Dawkins: So so I'm I'm just counting. We have some number like 11. We we have something something like well, okay. How many? +1, (234), 567-8910. Yeah. We have something like ten ten registries with designated experts. So is it, you know, just as a background hobby for us to look at those and say, any of those going to be exhaustible registries?
[00:36:37] Steve Lhomme: Well, the element ideas that you have there, that would be the tricky one because especially for the small numbers. Basically, they are supposed to be used only for elements that are found often in the files to not use too much space. And so, I mean, someone could come in and could use everything from 80 to f f or f e. So, basically, all the remaining ones and and say I want this, I want that in Matroska and EBML, and then nobody else can have a nice, small IDs. That that would be but it's still a spam, but that's in this case, you could have a good reason to say no because, for example, if you use a small idea for something that's not very useful in general, it's a waste. So, yeah, you have a criteria that says your spam is not very useful.
[00:38:08] Robert Sparks: Alright. Cool. Spencer, I'm a restructure where you put your note, I think you should move on to the rest of the
[00:38:20] Spencer Dawkins: Cool. And I worry.
[00:38:24] Jérôme Martinez: We could say that the small IDs are reserved, or is it stupid to say that?
[00:38:31] Steve Lhomme: I think we probably did already. I don't remember.
[00:38:38] Robert Sparks: And, Spencer, you might hit shift reload or and or make a copy of what you've got in that edit buffer first and then hit shift reload and make sure that you haven't lost the connection with the server because I'm not seeing it in my copy.
[00:38:56] Spencer Dawkins: Do I put that in here.
[00:39:01] Robert Sparks: Yeah. I would I would control a and copy that whole document off somewhere else, not just that new text. Just the whole thing.
[00:39:12] Spencer Dawkins: You're good like that. Wow. That's It's missing a lot.
[00:39:32] Robert Sparks: Yeah. So that copy you just made, just paste it back.
[00:39:36] Spencer Dawkins: Yep. Are you seeing that now?
[00:39:43] Robert Sparks: Yes. Now it's showing up for me.
[00:39:45] Spencer Dawkins: Okay. Cool. Thank you. Thank you for noticing before we finish the meeting.
[00:39:49] Robert Sparks: Yeah. So this is a bug with HedgeDoc that they keep claiming is fixed, it keeps not being fixed. So I will report that we observed it again. Cool. I am happened so what happened was your browser lost its connection, but it just happily went along and kept taking input from you anyhow.
[00:40:14] Spencer Dawkins: I I I like friends like that, just not just not applications. Cool. So I have been focused on that to the when I've been thinking about solar, I've been thinking about that more than rechartering. And so I think I don't really have anything to say about the rechartering. Do we have anything any other business to talk about?
[00:40:44] Jérôme Martinez: I don't think so. We already spoke about FFV1. Oh, fine for me.
[00:40:53] Steve Lhomme: Same here. Cool.
[00:41:00] Spencer Dawkins: Fabulous. And in that case, we have two more meetings this year, and I think I can give you all about twenty minutes back. Awesome. Thank you guys so much for your help. And, Steve, I will be I will be watching for dash 20 '1.
[00:41:23] Steve Lhomme: Not today, but maybe tomorrow. Otherwise, this weekend.
[00:41:28] Spencer Dawkins: Thank you so much, and thank you for all you do.
[00:41:33] Steve Lhomme: You're welcome. Thank you too.
[00:41:36] Spencer Dawkins: Bye bye. Bye.