**Session Date/Time:** 25 Aug 2026 19:00

[00:00:55] **Steve Lhomme**: Hello.

[00:00:58] **Robert Sparks**: Hey, Jérôme. How are you doing?

[00:01:00] **Steve Lhomme**: I'm fine. Thank you. Hello, Steve?

[00:01:15] **Spencer Dawkins**: Robert, are you hearing me okay?

[00:01:17] **Robert Sparks**: Yes. Yes. Perfect. Thank you.

[00:01:21] **Spencer Dawkins**: I apologize for running later than usual.

[00:01:26] **Robert Sparks**: It's alright. People are still gathering.

[00:01:29] **Spencer Dawkins**: The cool people are almost here. Steve, thank you very much for responding to, the emails earlier today.

[00:01:45] **Steve Lhomme**: You're welcome. I didn't have much time before. I've been busy. But yeah.

[00:02:06] **Spencer Dawkins**: Cool. So what are we doing?

[00:02:13] **Robert Sparks**: Charles is just starting to join. You might as well wait let him get fully connected.

[00:02:19] **Spencer Dawkins**: Cool. I am still I am having a minor wrestling match trying to get my camera working on my cool cell phone. Sorry. On my cool computer slash cell phone. Don't ask. And and we'll talk. Okay. Cool.

[00:03:26] **Robert Sparks**: Charles, we're still waiting for giving giving people a few more minutes to join. Spencer's also arguing with his camera.

[00:03:47] **Charles Eckel**: Oops. Okay. Yep. Thanks. Just getting myself signed in on the notes. Good to see folks here.

[00:03:59] **Spencer Dawkins**: Yeah. That's what I that's what we use to distract people distract people.

[00:04:05] **Charles Eckel**: That's a good way to pull people to the notes.

[00:04:50] **Robert Sparks**: We're about five minutes in, Spencer. I think we should start. We can just deal with having your avatar instead of the great online video experience.

[00:05:02] **Spencer Dawkins**: Absolutely. So let's see. So what I what I was planning to do, and I'm always happy to discuss alternatives, of course, is to work our way through a couple topics on the agenda instead of through the emails and stuff like that. I think the topics kind of map onto that. Is that okay for people?

[00:05:38] **Steve Lhomme**: Yes.

[00:05:39] **Spencer Dawkins**: Okay. Cool. So I should welcome everyone to the meeting. I should ask if there I should remind ourselves that this is a ITF meeting covered by Note Well. I should ask if there are any corrections to the minutes from our last meeting. Who has read who has who has has read who has read them, who agrees with them?

[00:06:16] **Steve Lhomme**: I have read them, and I agree. I agree.

[00:06:21] **Spencer Dawkins**: Okay. Thank you. Thank you both. And and pardon me while I finish signing in to be able to make change corrections to the minutes. Anyway, I have to to our minutes. So that was Steve and Jerome. Agree. So approved. Okay. Excellent. So that gets us to our working group documents. And the cellar-codec document is sorry. The cellar-tags document is still in the RC editor queue, and cellar-codec is in IESG IESG evaluation. And I am just doing a quick nose check. We still have two discusses to resolve from Eric and from Roman. And let's see. So I checked those.

[00:07:48] **Steve Lhomme**: And the ones we see there, I checked those. The first one, he agrees. I don't know if it's still discussed, but I did change to add a reference to the, I think, it was RFC.

[00:08:08] **Spencer Dawkins**: Yeah.

[00:08:09] **Steve Lhomme**: So I changed that, and it was okay with the change. And the other one is the pull request I did earlier today, which is 1128, which is ready to merge.

[00:08:27] **Spencer Dawkins**: Yeah. And thank you for the work that you are doing, and thank thank people who are reading reading the work that you're doing for reading it. So we had some topics.

[00:08:45] **Robert Sparks**: Now there's there are things that I want to talk about about Yes. Discuss in particular. I'd like to spend some time on that. Is this the appropriate time to do that?

[00:08:57] **Spencer Dawkins**: Let let me do one thing before you do that, and then then you go, and then we will work our way through the rest of the conversation. I did want to mention the thing, and this is actually I just ended up in the in the agenda. Remind just reminding the group that our documents are working group documents, means that they represent working group consensus. And we are a close enough group with people talking to each other and things like that that we we are usually fine with working group editors making decisions that we talk about as a group. But but this document is now outside the working group and so we need to make sure the changes that are being discussed during IESG balloting and even IANA review that those changes have consistence of the working group. So we're gonna be talking about those kinds of things today. Mechanically, that probably means that it's good for us to not submit a new version before we before we've had a chance to talk about pull request once a document leaves the leaves our working group and goes off to the IESG. Robert, I think this is over to you.

[00:10:39] **Robert Sparks**: Yeah. I feel a little less sensitive to issuing new versions. The real trigger is that there's evidence that the group agrees with all of the changes before Charles pulls the approved trigger. Right? And I think Charles is, capable of of of watching for this. So if if it makes sense to actually have new versions instead of having the group talking about PRs, just looking at the actual submitted thing, I have no problem with the even multiple versions appearing, in order to facilitate that conversation. So what I wanted to talk about in Romans Discuss was two two different things, one technical and one procedural. I'll start with the procedural. Roman has noticed, again, that this group is very different than most IETF working groups. And he's not seeing the evidence of group participation in the places that we say in the ITF that we gather the evidence of the group consensus and participation. I would like to have for this document a short round of email participation from everybody. I'm thinking Spencer the best thing that can happen is Spencer can send out a summary of the changes in the document, and everybody replies to the summary that with the they agree with these things or they want to see something change. But that we have as many voices as are still participating, showing themselves on the mailing list with the content of those changes. This leaves artifact in the, mailing list archive, which is ostensibly the place where we are supposed to be doing our work. Right? The GitHub repos, the PRs, I know this particular group has a lot of its decision making in those places, but we need to carry what happened onto the mailing list and leave some evidence that the group has thought about it and agrees with it. The shape of the working group is different than it was when this work started. When Matroska, in particular, first came in, there were many more participants that had a stake, wanted to see the base Matroska document published, and we're actively participating in in its initial shape. We were happy with that shape at this point. We're now more or less a maintenance group and evolving the larger work that was already laid down. And as with other groups, they have shifted into this mode. The number of participants is smaller and the cadence of participation is slower. The the the amount of time that goes by between ticks is is longer than it was when we first started. It's easy for someone who hasn't been participating to interpret this as a lack of interest or a lack of participation. And we need to be careful to, again, lay down artifacts that there are still people here. This is still a reasonable thing for the ITF to be spending its effort on, and it's not just one person yelling into a vacuum. Right? Before I move on to my technical conversation, Charles, do you have anything that you wanted to add to what I just summarized?

[00:15:10] **Charles Eckel**: No. I think thanks a lot for for that summary. I would agree. I think just having that that evidence and the mailing list is the best way. You know, people participating, like, on this call or in GitHub, we we just need to that's great. We just need to always briefing brings things back to the mailing list. And, you know, I think even just when version 21, you know, comes out, I guess that one hopefully will have addressed all the discusses. Just having affirmation there that, yeah, people did take a look at it, that they're fine with all those changes, you know, that would be great. But to actually have that email, you know, evidence is, I think, gonna go a long way towards addressing this this concern.

[00:16:03] **Steve Lhomme**: Would that be before or after it's published? Because, basically, before it's published, like, for dash 20, there was, like, 15 pull request of various changes. Should they send the list of pull requests and then people read the changes? The problem is that, like, not everybody is comfortable reading patches. You know, you only see a part of a document and not the rest. So maybe I should send the text version as an attachment or, like, before permission 2170.

[00:16:44] **Charles Eckel**: I think it's also sorry. Sorry for interrupting. I I think it's it's fine for you to actually go and post version 21 or post a new version. Right? Because the people they can then use their favorite tool, whether they like looking and and having the the GitHub pull request is great too. Some people will wanna go look at that. Other people will use the dev tool within

[00:17:07] **Spencer Dawkins**: Is is Charles breaking up for other people?

[00:17:10] **Steve Lhomme**: Yeah. I can I can hear your voice, but the words are are weird?

[00:17:16] **Charles Eckel**: Ah, okay. Let me try turning off my video. And

[00:17:22] **Spencer Dawkins**: That that is much better. That's much better. Thank you.

[00:17:24] **Robert Sparks**: Thank you.

[00:17:25] **Charles Eckel**: Okay. That's good. You guys didn't wanna see me anyways. But but yes. So if you go ahead and and submit the the draft, you know, you go ahead and put it in the data tracker, that that's that's fine. And then people can either they'll look at that new version. They can use the diff tools within the data tracker if that's the way they wanna, you know, look at it. If they have a problem, they can always say, okay. This is what I think needs to change, and that just means you're going to have to, you know, have a pull request and submit version 22. But but, yeah, I wouldn't be maybe this was getting back to Robert's point. I wouldn't be hesitant to to post a new version of the draft thinking that you need to get everyone's consensus before you do that. Actually, posting that new version of the draft is is a good way for then people to be able to review and and give their, voice their consensus that, yeah, those changes look good. So so so, yeah, that that'd be totally fine.

[00:18:26] **Steve Lhomme**: Okay.

[00:18:27] **Spencer Dawkins**: So I I I think what I was I'm sorry. What I what I think what I was saying and probably not saying it very well is that I was hoping that posting a new a new version would mean that I agreed with with the changes. And it's it's it's fine it's fine if if I it's fine if that's not what that means. Like I say, it's just basically I'm trying to equip the responsibilities of a document shepherd well. And if if I need to equip those responsibilities better or in a different way, I'm fine with that.

[00:19:18] **Charles Eckel**: No. No. I mean, certainly, Spencer, you're you're doing a a fantastic job as Document Shepherd. I've been it's made my life much easier, and I I appreciate that. I can tell you not all Document Shepherds are is on the ball. In fact, I don't think any of them are. So I really appreciate the way you've been chiming in and following up on these these threads. No. It's fantastic. Keep doing what you're doing, please.

[00:19:44] **Spencer Dawkins**: Thank thank you for your kind words. You may need to, you may need to raise your sights.

[00:19:51] **Steve Lhomme**: It's recorded.

[00:19:55] **Spencer Dawkins**: But yeah. So so and if you if you guys look at what I'm capturing in the notes, it's basically we're talking about now that we would submit new version newer versions as a basis for review of consensus within the working group. And I think that's I think that's a that's a fine model also. Robert and I both serve the working group, so we are we are we we we want to be making doing what we can to make things easier on the process front for the working group to succeed. I should say then Spencer is fine submitting new versions as the basis for consistent reviews as well.

[00:20:47] **Robert Sparks**: I think the right thing to do right now is to go ahead and submit a new version.

[00:20:51] **Spencer Dawkins**: Yeah.

[00:20:51] **Robert Sparks**: And then provide a summary, provide a draft link, and call out if there are any other known changes that are still in flight that are before we're done. If there aren't any, that's fine. Say there aren't any.

[00:21:08] **Steve Lhomme**: Yeah. I was going to say what we could do is half and half, like, before for publishing, send a link and a list of all the changes that we're going to include if people want to see that, and then wait and publish if everybody agrees. The problem is that how long do we wait?

[00:21:32] **Robert Sparks**: Yeah. Don't wait. Just go ahead and publish it.

[00:21:35] **Steve Lhomme**: Yeah. I will it

[00:21:36] **Robert Sparks**: if it's wrong.

[00:21:37] **Steve Lhomme**: It's going to be never ending. I mean, at work, we have that kind of process that we have set some amount of time for reviewing and things like that, and it's just more more complicated than anything.

[00:21:57] **Charles Eckel**: Yep.

[00:22:02] **Robert Sparks**: Alright. So my vote is that, you know, we publish, we write a summary, we ask for comments from the list, and, you know, that Spencer and Charles can gauge when enough time has gone by for those comments. It's not we're not it's not a formal last call or anything. It's just a

[00:22:22] **Steve Lhomme**: Yeah. Chat with the

[00:22:23] **Robert Sparks**: working group. Right?

[00:22:24] **Spencer Dawkins**: Yeah.

[00:22:25] **Steve Lhomme**: Yeah. The thing is that I mean, in my head, it yeah. If it needs, like, automatic, that it should be automatic that something is sent to the group when it's published. Because even on Mastodon, there's a bot for the cellar group. Anytime a new document is published, there's a post that we post and a few other people. So for me, it's like, okay. It's there's a new document everybody knows, but, apparently, it's not automatic for the cellar mailing list. Yep.

[00:23:01] **Spencer Dawkins**: Yeah. So so and just to so let me mention one other thing that's probably worth me mentioning. What I'm talk what what I'm really focused on now at this moment is this draft, which has already been through the IESG balloting once. So that that's, like, one model for me, And it's not my intention to be having this conversation about what we do with drafts that are still under under working group change control, you know, and even even drafts that have gone up to our area director for AD evaluation. What I'm talking about is, you know, specifically now this stuff has left the IESG and just making sure that I understand what's going on with that. I would be more comfortable if we we did not submit changes now and then end up making those changes out. I should mention that, like, all this stuff is at least Robert, correct me, but my my theory is that this stuff is at least visible to area all the area directors if they're looking. So if they get curious and say, what did they change? And if the answer is that the work the working group is still adding things and then deleting them and or changing them to something else, that does not inspire confidence.

[00:24:41] **Robert Sparks**: And as long as it's in the general vector of what the the discussion was talking about, then I don't think there's a problem. Right? There's an opportunity for this to be as a corrective process if it doesn't land perfectly on the on the first step. Now I think that it's gonna land just fine on the first step and that there's not going to be spin Yeah. Afterwards.

[00:25:06] **Spencer Dawkins**: Perfect. And, thank you for helping to calm me down on this topic. I couldn't do it without you, Robert.

[00:25:18] **Robert Sparks**: No worries. So now I'm a make it worse and start talking about, you know, the technical concerns that that I'd like to to at least discuss. I don't know if if any of this needs change. Some of it, I think, is just the first thing is gonna be me trying to get Dave and and Steve, in particular, to help restate some things that they told me in the past so that Charles can get a stronger understanding and can represent the group better to the IESG when it when this comes around. So the other part of Roman's discuss, he asks about how we achieve interoperability if there are code points that point out to a place that isn't a public record, right, effectively. His his his wording was, if we've got a registration policy that isn't specification required, if people can point into things like DVD forum, which is gone, and nobody can get that, how's interoperability achieved? And I think the answer to that question is the audience. What what what interoperability means in this case is can an archivist read back something that the archivist wrote down? This is a tool for creating an archival record. It is not a tool for one archive that's creating a record and some other archive is then being able to read it. That is nice to have if there's enough advertisement about what's supporting and what's going on. Dave, you really should jump in here if I'm in the leads. But the archivist that's laying down a record will know what private things they have access to, and the container should be able to signal about these things that they have access to. And they know that the future player will be able to to read this. Do I have this right in my head?

[00:27:42] **Dave Rice**: Sorry. I'm trying to remember back to some of the original motivations, but I I think at the at the time we were forming this working group, there was a lot of sort of concern amongst archivists and museum conservators about audio visual files that are in particular not self descriptive. Like, it it's very feasible to make an AVI file that says nothing about its own aspect ratio or its own interlacement or its own color space. You know, so there was a lot of intention to be as specific as we can so that the media player doesn't have to do some guesswork, you know, because because I I remember we take, like, various media files and we play them in in QuickTime and mPlayer and VLC and others. And and, like, the color would look different each one. And this would be the files that say nothing about their own color data. It's just tools that are having to presume their way around poorly described files. So Right. We were trying to make an effort to not be too presumptive. Like, obviously, like, a lot ton of the vocabularies in Matroska include a value to say, we don't know what the answer is here. Usually, that's reserved as a value too. But but yeah. We yeah. We wanted to have something that was very self descriptive and self contained, which was a motivation for us to, like, gather some more of these metadata elements into Matroska. Obviously, like, there were sort of dozens of different factors that were bringing various people together at the time. So that's sort of just one of one of many. But, you know, but compared to what was happening in in, like, the SMPTE group of of MXF, like, I don't know. I think archivists were just looking for a place to sort of invest in the conversation and and participate in the in involvement. I think this working group's been a good success of having, like, people from various user communities, like, working with the developers and original authors to sort of extend and maintain and evolve the format onward. But I but I get what you're you're saying that a lot of our conversation is often, like, behind the scenes or in pull requests and needs to be more present in the ITF circles themselves just so we're sort of presenting a a view that we're actively working on this, you know, so that we're not keeping too much of it hidden.

[00:30:15] **Robert Sparks**: Let me let me let me aim the focus at one particular thing, and and thank you for all of that. That one particular thing is I'm gonna use the DVD forum references as a poster child because it's an easy one to just talk about since that spec isn't easily available. We still want to be able to, like, wrap things that were encoded into the DVD spec and add extra metadata around it, but there is no expectation that we are defining or providing easy access to the definition of the DVD stuff. That is something that is assumed to exist separate from our specifications and the and and again, I'm gonna say it this way, and you can challenge me if I'll get it wrong. An archivist that chooses to create an archival file that encodes some things in the DVD specification is doing that with the knowledge that they have access to something that can play the DVD part of the specification. And encoding it with Matroska gives them additional information to help inform that player to do the right thing.

[00:31:32] **Steve Lhomme**: So there are many aspects to that. I think for an archive, if they want, like, what you say, being able, like, encode or keep something and being able to play back, My understanding of how they work is that right now, they're all picking f f v one and flag and things like that. And and just one format, they're not going to use, like, d b, DVD, blurrier, m p four.

[00:32:06] **Robert Sparks**: So they're choosing to transcode.

[00:32:08] **Steve Lhomme**: They only use one because they focus on one that has all the features they want, and they can use it back. The idea is not to be able to reconstruct the original context from it. It's just the way they preserve it is that way. But then on the mattress side, we so we didn't want the original goal of Matroska was to be able to be the container for everything, streaming and disk. So, basically, we wanted to support everything, including what will be popular at the time. I've lost Ready? Hello? Can you hear me?

[00:32:57] **Spencer Dawkins**: I I'm hearing I'm hearing Steve.

[00:32:59] **Steve Lhomme**: Okay. So yeah. So we have to basically, we support everything, but that's another side of Matroska that is not for archival. It's for everybody usage. And but then, like, just last year, I think the GD forum just disbanded. And then if we publish the documents one year ago, we could have said, oh, but if you need the documents, you go there. And if you pay them, you can have it. Just like for ISO specifications, you don't most of them, you don't go on their website and download. You have to pay and get them. If tomorrow, ISO closes and you cannot buy the documents, you're exactly in the same situation that we're referencing a document that you cannot buy anymore. So for me, it's not really different to reference a document that's existing and was act an actual standard. Like, for the edit was known to be the standard. And a lot of people probably have them in some office all over the world because it was popular, and a lot of people make hardware and software from it. So it's not like referencing the niche document that nobody knows. It's the same files where they close tomorrow, they might still be able to get the documents.

[00:34:31] **Robert Sparks**: And so instead of the specification is gone, let's focus for, again, at at the specification is not free. So the parts of ISO that you're talking about where you have to pay a chunk of money, but you have that option to pay that chunk of money. But if you don't pay that chunk of money, you don't get to see the spec to do do do the implementation. Yeah. Is the the ITS got a history of allowing references to those things. And I think that that fell under if they were normative references, though, there were some concerns about review reviewers being able to review the the the the thing and arrangements would have to be made to get at least a copy of them. What I'm trying to do is I'm trying to get at Roman's concern about whether or not the registration policy for the registry that's being created be specification required. Right? And I was trying to build an argument that that's not necessary. I'm only marginally comfortable with my argument holds. I I still think it's the right argument to build, but I'm looking

[00:36:11] **Spencer Dawkins**: I I I agree with you that it's the right argument to build, Robert. I agree. And I apologize for interrupting.

[00:36:28] **Robert Sparks**: No. No. No worries. Yes. Charles, what do do do you have a a feel for what since you've been talking more closely with Roman for what we need to say in response to this?

[00:36:51] **Charles Eckel**: No. I I don't have a real good feel. I I think what you're describing makes sense. Certainly, know in the past, we've talked about having, say, normative references to things that require, say, payment or a membership and the membership requires payment that that we can request like, we can send an LS to get access to those, and those can be made available on a limited basis. So so, I mean, they're

[00:37:26] **Robert Sparks**: Leon, he's on

[00:37:26] **Charles Eckel**: That's obviously not a deal, but that's that's not a showstopper.

[00:37:32] **Spencer Dawkins**: Yeah. So the and I I just wanna say for people who don't know, that's a really common thing to do in working groups like AVTCORE AVTCORE, where it's like, you know, it's like we're we're we're and it's it's almost it's almost the same situation where we're doing encodings for we're doing encodings for bitstreams that we don't sorry. We're doing containers for for bitstream formats that we don't we don't control. So they're done at ITU or someplace like that. So, basically, you know, it is normal for us to have our liaison to the ITU of T say, can, you know, can we get a copy of this for reviewers to use? And they say yes. So so, yeah, that is a that is a very normal thing at the ITF.

[00:38:30] **Charles Eckel**: And then if I understand correctly, there's also the case where there's simply no specification for something, and someone have a, say, a a player or a recorder. So so you have the ability to produce these media formats, and maybe over time, some some readers were developed and and they more or less work, but there's no no written down specification of it. And yet we wanna be able to allow people to indicate that when Metroska made one of these records that that that that's what the format is. And in that case, we would have an IANA rep you know, there'd be a code point for it in IANA, but there is no spec to point to because one doesn't exist. And I think in that case, it still seems useful to me to have that code point in in IANA. But perhaps that's you know, I think that's a concern that that Roman raised as well. And to me, it's this is just, you know, kinda best effort. We're we're doing the best we can with it. It's better to have the code point than to not have it. Yes. It would have been better to have a specification, but you can't really say specification required because in some cases, there will be no specification. And then so in that case, we really just leave it up to the designated expert to use their judgment. And and perhaps you need to write that in the document that something about what the designated expert is expected to do.

[00:40:08] **Spencer Dawkins**: Yeah. And and, Charles, I I I wanted to just mention, you're you're talking about the one right thing to think about, which is what what is the IN instructions for designated experts. I'm also thinking about this from the standpoint of what are implementers supposed to do, and I'm thinking in terms of we've had we have a few formats that we've tripped over where the best the best specification is probably an open source implementation. You know, there's there's no there's no written description of it, but that that we can observe that there are implementers to, you know, now who go look at an open source implementation or something and figure out enough of how how it works to where they they can write their their new implementation. So it's, you know, it's we you know, my my list of possibilities are the specification is gone, that it's not available for free, but it's somewhere in the middle. You know? And that all of those all of those are relevant to implementers. And you are now reminding me, Charles, that that's also, that's also relevant to the, to the, drugs and vagrant experts. Thank you.

[00:41:32] **Robert Sparks**: So with what I was hearing Charles saying, I think that, Charles, you're in a you're actually in a pretty good position to to finish the argument. And as long as we provide a little bit of text that is guidance to the designated expert on what to do in the situations where the specification isn't fully available.

[00:41:57] **Charles Eckel**: Yeah. I think so.

[00:41:59] **Robert Sparks**: Okay. Yeah. So Steve, I will take

[00:42:02] **Steve Lhomme**: I was just checking the document, and the media document is actually not a normative reference. It's an informative reference. There there is no normative reference that doesn't point to an actual document, and it's the only one that doesn't actually have a document that basically a URL.

[00:42:28] **Robert Sparks**: The the the thing we're talking about here though, Steve, isn't what's in this document. It's what's in what people have to provide for future code point registrations in the

[00:42:38] **Steve Lhomme**: Yeah. Yeah. For the designated expert, but I was just thinking that these I mean, there's the that I made that can be also the case that for the designated expert, there's a difference between the normative reference that you need to be able to read the the contents and the informative that's you should like, if you have information about the format, but it's not enough to read the content. But it's still good to have a pointer to where you need to look at.

[00:43:23] **Robert Sparks**: So I think we're on the same pages. Yes. Do do Steve, do you I think we're asking for an additional sentence or two in the document as guidance for the designated experts. Do you feel like you could propose that text?

[00:43:45] **Steve Lhomme**: I mean, if anyone wants to propose something, I'm open, but, yeah, otherwise, I'll do

[00:43:51] **Charles Eckel**: it. Yeah.

[00:43:58] **Robert Sparks**: Oh, I I I think we'd prefer that you propose it. Okay. Alright. So that's the the primary technical issue. The when we do have the new version of the draft and the summary to the list, I would like that summary well, I'd like for it to be comprehensive, but in particular, I would like for it to point pretty hard at the the changes that were made in PR eleven eleven. Of all of the PRs that went in, there are pretty good hooks back to conversations with the IESG or whatever for why we did these things. This one is a little bit more just coming in from space. So having the the the the summary of the differences, call out what it is, and why it was there, and asking everybody agrees with it would give us a good, on the ITF, archive fabric evidence that this was something that the group discussed and agreed with.

[00:45:21] **Steve Lhomme**: Okay. So, basically, this was a request from Google because they want to put a new metadata as the T_cert5. And the but and they wanted to submit something to, but they didn't want to do it before it was we agreed on something, and they proposed various technical solutions that were not good. And we came up with that, and they have proposed it on GitHub. And Yep. Yeah. Maybe they should have sent an email as well.

[00:46:11] **Robert Sparks**: Alright. That's what I had. So, Spencer, do you wanna pick up with the rest of the agenda? We've got about fifteen minutes left.

[00:46:38] **Spencer Dawkins**: And we probably have fifteen minutes worth of agenda left. We've we've managed to pull almost everything, that was on the, starting out agenda up into either, the IANA section discussions or to, Romans Romans discuss. So, you did a you did a terrific job of of, moving that forward. Thank you. I was gonna so the the other things that were on our list, I added this one earlier today, I think, actually. We have an email from Sam basically updating us on work he's doing with a, you know, with a an application for, and I don't know if people have had a chance to look at that yet. And I just ask people if there's any anything that the working group needs to say in response to Sam, please do that on the mailing list. That would be a fine thing to do.

[00:47:44] **Steve Lhomme**: Yeah. I saw it, but I didn't have time to reply yet.

[00:47:48] **Spencer Dawkins**: Yeah. Okay. And then the other thing that was on the list was that I had a this is slightly updated from the our last meeting, but I had an action, which I did not do, to move the Google Doc contents from our last meeting discussion proposed new charter into into GitHub so that we so that we could manage it more easily there. I will do that this time, I promise. And let's see. And, yeah, and Steve has you have submitted have you I'm trying to remember. Did you submit the individual drafts that we were talking about? The ones that the ones that we did the file name change for?

[00:48:44] **Steve Lhomme**: For today?

[00:48:45] **Spencer Dawkins**: No. I I I was just asking if you had done that. The the the so the ones that we owe the the new new specifications for the new charter

[00:48:55] **Steve Lhomme**: I know.

[00:48:56] **Spencer Dawkins**: You you you had you had starting point drafts for a couple of those. Did did did you did you submit those as individual yet?

[00:49:07] **Steve Lhomme**: I did send the update one if that's what you're asking for.

[00:49:12] **Spencer Dawkins**: But Yeah. Yeah. Yeah. So so that that that is that this this last thing on the on the action item list there is is that is in in progress already. So cool. And that that I think that takes us to any other business. Is there anything else we need to talk about?

[00:49:41] **Steve Lhomme**: No. I think I said I did not

[00:49:43] **Charles Eckel**: have one question. Is Yeah. You want me? My assumption is there's no plan to meet in San Francisco. Instead, we'll just keep with our with the interims. Is that correct?

[00:50:01] **Steve Lhomme**: Yes.

[00:50:03] **Spencer Dawkins**: I think that's I that's I think that's my assumption for the working group

[00:50:07] **Steve Lhomme**: working group. K. Yeah. I was going to say there is actually an automatic mail every week that's sending to the mailing list of the GitHub activity. I don't know who did that. The problem is that the last one we received, there's just numbers and the author, but there's no title. There's no link. So it's a bit

[00:50:38] **Robert Sparks**: Yeah. That's the way Inbox tool worked. We may have an older version hooked in. I I can I can go chase down?

[00:50:49] **Steve Lhomme**: Yeah. Our How to

[00:50:51] **Robert Sparks**: installation is.

[00:50:52] **Steve Lhomme**: So Up to July, it worked fine, and August 9, it's not useful. Mhmm.

[00:51:02] **Charles Eckel**: And I

[00:51:03] **Robert Sparks**: still think that there's a lot of value in a a an actual human curation summary as opposed to Yeah. The automaton. Yeah.

[00:51:21] **Spencer Dawkins**: Well, cool. So is there anything else we need to say?

[00:51:29] **Steve Lhomme**: Not from you.

[00:51:30] **Robert Sparks**: I'm good.

[00:51:31] **Spencer Dawkins**: Thank you. Thank thank you all very much for your help. It is always a pleasure. And, I I look forward to, I look forward to talking with you all on the mailing list. Make good choices. Okay.

[00:51:51] **Charles Eckel**: Great. Thanks all.

[00:51:52] **Steve Lhomme**: Thank you. Thank you, everyone. Have a good day. Bye.

[00:51:55] **Spencer Dawkins**: Thank you all.