Session Date/Time: 28 Apr 2026 19:00
Sure! Here is a full verbatim transcript of the provided video:
Robert Sparks: How are you doing?
Spencer Dawkins: Pretty good. I think Jérôme's going to pop in here, too.
Jérôme Martinez: Hello.
Spencer Dawkins: Hi, Jérôme.
Robert Sparks: Hi, Robert.
Spencer Dawkins: Hi, Spencer. How was your busy day?
Robert Sparks: It’s exactly that.
Spencer Dawkins: Perfect. Are you echoing?
Robert Sparks: I’m on mute when I put my finger down, see if you still get the echo.
Spencer Dawkins: I’m good, I’m good, I’m getting echo.
Robert Sparks: I’ll drop and rejoin with a different WebRTC client and we’ll see if it makes a difference.
Spencer Dawkins: Okay. Cool.
Robert Sparks: Try now.
Spencer Dawkins: Okay. And I’m talking now and I’m not hearing anything, so, except me, I’m not hearing me twice. How do I say this? Yeah. Yeah, okay.
Steve Lhomme: Hello.
Spencer Dawkins: Hello, Steve. How are you?
Steve Lhomme: Good, it’s the end of the day.
Spencer Dawkins: Excellent.
Robert Sparks: Spencer given it’s unlikely to get interrupted frequently, please drive.
Spencer Dawkins: It will be my pleasure, and I am getting slightly organized on one thing still, but we can let people join for perhaps a moment. Yeah, Charles just said in chat that he needed to step away for a second, he’ll be right back. Okay, cool, that’s twice as good. I was putting in stuff for the agenda and I left out one thing that would have been good to put in the agenda, so I’m fixing that now. I had spotted two new errata, but I thought there were three, or sorry, yeah, it turns out there are three, is what I’m trying to say. Anyway, making the last correction here. So I’ll remind everyone on the call, while we’re waiting for Charles, the meeting is held under the IETF Note Well. Spencer put a nice bow on what reading through the Note Well and Code of Conduct say. Most folks here are familiar with the way we have run the CELLAR interims in the past, if you’re able to join and share video, please do, if your bandwidth constrained or have some other reason not to, that’s fine. Do remember that the session is being recorded and will be posted to YouTube and to the IETF self-hosted MeetEcho player site shortly after the meeting is concluded.
Spencer Dawkins: Cool. And I’m trying to, did it sound as if Charles was going to, he’s back. Oh, he’s back! Okay, excellent, perfect. Hi there! So I have finished cleaning up most of the things that I left strewn around. Thank everybody for signing in. Thank you, Robert, for doing the Note Well discussion, and we had posted previous meeting minutes and I had included a pointer to that on the mailing list recently. Do we need to make any corrections to the mailing list for our February meeting?
Jérôme Martinez: It’s fine for me.
Spencer Dawkins: Thank you, Jérôme. If there’s no objections, we’ll call that approved. I want to do something a little bit out of order on the agenda, my apologies, and introduce Charles Eckel, who is our new area director. Charles, please feel free to step down into the CELLAR and say hi.
Charles Eckel: Okay, let’s see if this works. Okay, great. Hey, thanks so much, Spencer, I appreciate that nice introduction and all the help you and Robert had given me as I’ve come up to speed on this working group and the progress of your documents. Seems like the group’s making good progress, I’ll try to help out wherever I can and stay out of the way otherwise.
Spencer Dawkins: We appreciate you a lot. So, just historically, I’ve known Charles for a while, but not as an area director, and I believe Robert has known Charles for a while in different contexts, but also not as an area director. And I know Charles most clearly because of work he’s done with the 3GPP liaison work, if I’m remembering correctly. So, pretty excited to see you take the position. And speaking of the position, if I may project for a second our, where am I doing that? I am sharing slides.
Robert Sparks: Let me slip in a quick comment for Charles, if it matters, you were understandable, but your microphone level is very, very low.
Charles Eckel: Ah, okay, let’s see. MeetEcho might have grabbed the wrong mic for you. That happens to me and it’s not just MeetEcho. But I am sharing my screen and, so, just to clean up some work on previously, on documents that had previously left the working group and are still in the process of leaving the ISG. So the CELLAR Tags document, Charles has reviewed it, now has his yes vote, which since he’s the responsible AD is important for it to have his yes vote. And Charles, you said you wanted to check with the other new ADs to see if anyone else wanted to review it before sending it to the RFC editor, did I get that right?
Charles Eckel: Is my audio any better?
Spencer Dawkins: It’s a bit, I’m not seeing the difference, but I am getting an echo.
Charles Eckel: Now you’re getting an echo.
Spencer Dawkins: Well, I think I was getting an echo both ways. I was also getting an echo and I’m not sure you were on the call yet, so it may not have been you.
Charles Eckel: Let’s see if this is loud enough.
Spencer Dawkins: Yeah, and you can, yeah.
Charles Eckel: Okay, so can you hear me at least somewhat?
Spencer Dawkins: Yeah, absolutely, absolutely.
Charles Eckel: So, yes, so I think the only thing that I think we need to clean up on this is actually IANA had a bit of feedback that I received and I think we need to just clarify something with the language about the requirements of there’s some text in section 3.2.1 and 6.1 around the, oh, I need to look at the details right now, but anyways I’ll come back to the mailing list after discussing with IANA. I think it should be just a pretty small clarification. They were interpreting some of our wording a little bit differently than I think it was meant to be, and so I think they have a good point so we’ll clean that up so it’s more clear and I’ll post a proposal and if everyone agrees that’s good then we’ll need to update the draft with that.
Spencer Dawkins: Okay. Charles is finishing up, I’m sorry, I should go back here so you guys can see, discussion with IANA. And thank you for that, and for CELLAR Codec, you had a question that you sent me on Slack about a downref, and that was specifically that I think I managed to confuse you. I think I replied to your message in Slack and did what I say help?
Charles Eckel: Yeah, it did, thanks for that. So yeah, and I think with that one that hasn’t gone through to the IESG yet, but that’s I think we can go ahead and get that started. I’m just going to re-review the IANA considerations now just to make sure that I don’t let something similar go through, but it’s looking pretty good to me so I think we can get to start that soon and get that on the, yeah.
Spencer Dawkins: Cool. I don’t know how many working groups you’re going to have that put smiley faces in the notes, but you have at least one.
Charles Eckel: Those are good.
Spencer Dawkins: Thank you for both of those updates, Charles. And we have two expired drafts that we had not been focusing on, you know like we still think the drafts matter but other people had other stuff going on, like for instance the drafts that were in with the IESG and with our area director. So do we have any update on those at this meeting? And those being Chapter Codecs and FFV1v4.
Steve Lhomme: Chapter Codecs, no, not yet. Yeah, no, nothing changed. Still don’t know where we discussed Chapter Codecs. Yeah. Yeah, I discussed this week on VLC about the Javascript version of the codec and we’re still not sure we’re going to ship it so I don’t know what’s going to happen to that. Maybe in the browser it’s fine to use Javascript but in a video player, not so much.
Spencer Dawkins: Okay. And was that for Chapter Codecs?
Steve Lhomme: Yes.
Spencer Dawkins: We’re checking on one part of the specification we might not include.
Steve Lhomme: I think the specification is okay. The problem is the implementation but then if you have a specification nobody implements it, it’s a bit useless. And the other part of the document is the DVD1 and we do not have the specs of the DVD so we cannot guarantee we can map a DVD 100% back and forth to Matroska. I think all we can reasonably do in this state is just be honest. You know, say what the conditions are, say that what we’ve got has passed some community review but the open standards process doesn’t have access to the actual specification and just leave it at that.
Spencer Dawkins: Yeah. And we’ve still got Charles, if I’m remembering correctly, this is the document that it’s been entered into a government library in Japan and is not available in machine readable form. I mean like there’s a paper copy.
Steve Lhomme: Yeah, the DVD specification only exists on paper, or maybe someone digitized it in the company but they’re not allowed to share it. And the DVD consortium or whatever their name, ended. They’re not providing the spec anymore. But before doing that they gave the specification to the Japan National Library. But if you want to read the specs you have to go to that library, schedule an appointment, and you can read it but you cannot make copies or photos or whatever. Maybe you can bring a pen and make a copy on paper writing but that’s about it.
Spencer Dawkins: So I think this is where Charles says does this kind of thing happen in archival work, does this happen all the time? This is the first time it’s happened that I’ve seen in a few years, so we’re not doing this every week.
Steve Lhomme: I think we know a lot of archival people, I wonder if we can pull some strings like the Library of Congress or things like that, if they can persuade someone, I don’t know who because there’s no representative anymore, to make the thing more open for preservation because DVD is quite a popular and widely available media. But legally everybody who got the specs are not allowed to share it even if the company is bought, I think there’s some liability that you cannot even share it with people who bought the company or something like that. It’s crazy. So it’s a very strange situation.
Spencer Dawkins: But like I said we will be honest about everything. And do we have a, I think Charles is trying to talk but we’re not hearing him. About FFV1, there is a new proposal for RGB bayer support, it is on FFmpeg-devel, there is a discussion and a proposal from Lynne. I will write the link. There is still a different proposal from Michael for storing raw LSB and I need to review them so it is still pending, so it is not new but still something to do. And also the floating point support is available in FFmpeg, but we didn’t yet update the specification, so we will also, this is something I need to do too.
Robert Sparks: My usual question: what’s your current gut feel for when you would want the group to start reviewing text for publication to the IETF? Is it going to be in the third quarter of this year, fourth quarter?
Jérôme Martinez: I hope this year but I don’t want to promise anything. It is still on my free time and it is difficult to say when we can do it.
Robert Sparks: Yeah, so but I’m hearing fourth quarter at the earliest.
Jérôme Martinez: This year, let’s say.
Robert Sparks: Right. What year is it? 2024.
Spencer Dawkins: Thank you. Jérôme, to be really clear, I wasn’t trying to push it to go faster.
Jérôme Martinez: No, it is just I cannot say a lot of things, so it is on my free time and it is difficult to say. And there is about RGB, it is still, so there is a discussion about that. So I sent, I write the links, so everyone can review it as Michael said on the comments we need some review about them. There is a discussion.
Spencer Dawkins: Okay. So I’m going through recent errata for RFCs and we had, what is that, 8658, which looks like this. And I believe 8658, yeah, that Steve was saying we don’t need to mention that the, that this is a, that the, we don’t need to mention the recurring aspect of the element in the kind of detail that’s suggested in the errata. So and just scooting back to that. So that would be suggested status for our AD is rejected, I think.
Robert Sparks: Spencer, if you had intended to share something other than the notes, it did not work.
Spencer Dawkins: I was going back and forth between, oh, sorry, let me pop over and do this. And this will be much better. So anyway, this is the errata that was reported and this is Steve saying basically that this is not a necessary change. And just to leave that, so it’s if it’s not present or if it’s not set to true was the suggested correction and Steve’s take was that that’s not a helpful clarification.
Steve Lhomme: Yeah, basically if you don’t, if it’s not present then you have to say what’s the default value, what it means, but if it’s present you don’t need a default, it’s written what the value is also.
Spencer Dawkins: Yeah, I was just curious if anyone else feel, have a different opinion on this one. I do not, and I could have an opinion, but I do not have that on this one. Okay. And let’s see. Next one was 8854. And this one, same deal, that this is 8854 there. Yeah. This is another discussion about MaxOccurs being unbounded and the suggested text was to say unbounded and Steve thought that saying unbounded as a value is a bad idea, that basically the way you say no maximum occurrence is you don’t write MaxOccurs, and so the original text even says that not being present is equivalent to being unbounded. So for that one also, we were suggesting rejected. And any objections on that? If there are not, I’ll leave that. And for 8810, Martin said that one is correct. Where is that? 8810 is there. True and embarrassing, and so suggesting verified. So basically this said shifted right by two pads and it should have said shifted left by two pads and Martin says yeah that’s embarrassing is correct. So suggested status for that one is verified.
Robert Sparks: Thanks, those all sound appropriate to me.
Spencer Dawkins: Okay, cool. I will make sure that you see the meeting minutes that have this and I will describe what’s going on. This is the one that I was adding during the meeting because I thought there were only two errata and looking again there were three so I was still typing, sorry. So for additional time together, it’s probably good for us to, so Steve has a couple of things going. One was changing the way we were planning to do what we were calling a Matroska v5, we now think that that is Matroska v4 Additions. And Steve has a PR that creates a new draft with a new draft name. Spencer had one question about this, which is overtime, would we end up with more than one set of Matroska v4 Additions or would we keep adding additions to the document that has the v4 Additions?
Steve Lhomme: No, once we have, because of the process of making a document at some point we have to stop even if there are new ideas and get in the process of publishing but then we can prepare for the next one etc. Yeah, I think as long as we don’t introduce breaking changes, so backward compatibility issues, it remains v4 and we keep adding new things.
Spencer Dawkins: So what I was understanding, or what I was getting at was if there’s any kind of qualifier that we can put in the title of the document to say these are the v4 Additions that cover these, you know, this some set of attributes or some set of sets of attributes, so that then we can publish that and that document can exist and then we can start another document someday if we need to with the same title colon different set of attributes. Does that make sense?
Steve Lhomme: Yeah, last meeting we said maybe we would call it like 2026 or 2027 Additions, that would be one way. The other way for each addition we make a document, but given how long it takes for a document to be published, maybe it’s better to group things. I don’t know, maybe not, maybe it’s better to split. And then while working on that, doing the actual thing and we’ll discuss after for EBML, I realized that maybe the name a revision would be a good idea, like Matroska v4 Revision 1, Revision 2, etc. because basically the new documents and that’s also the case for EBML would be an update in the IETF sense, that it’s marked as an update of that document. So you can keep following all the updates and get the new things and still be based on the original. So I don’t know if it should be called Update 1, Revision 1, I don’t know if there’s a common term at IETF for that. Yeah, I’m not sold on any naming but for now I’m using updates.
Robert Sparks: Using updates would be easier for the rest of the IETF community to understand, having a semantic grouper would be better than a time-based grouper if it’s possible but if not a time-based grouper or just a sequencing grouper.
Steve Lhomme: So Update 1 and then if like the final document is RFC 9347, it’s weird that you have to look at Update 1 that actually updates a document with a different number but could be confusing.
Robert Sparks: At least the IETFers will get that and linkage happens automatically.
Spencer Dawkins: Yeah, that’s the easy part, the in people’s brains is the hard part. And so this is actually related to the next bullet about you know, how do you know that the schema for EBML has changed? So this would have a update, sorry have an added element that would have a value that would be in the EBML schema. Number one, am I just completely confused or is this also helping us figure out how to move Matroska’s specifications forward?
Steve Lhomme: Well that’s exactly the second point is while I was trying to produce the document because we have this big XML document before with all the new things, I put mean version 5, so if you have before version 5 you cannot use these elements. Now it’s still v4 but how do we tell the new elements from the old ones in that XML file? So I turned it into a date, like it was added at that date, and if that date is before or after a certain date you know it’s in that document etc. And then when I finished doing that I realized that maybe adding a revision number like Revision 1 would be much better. Now that would be Update 1. Sorry. Yeah. So basically I already started working on EBML to add new, sorry.
Spencer Dawkins: So my document question is would this be a small document that updates 9559 or would this be a complete document that includes the new attributes and replaces or obsoletes 9559? I don’t think, I have the impression that this isn’t going to happen very often, so and this is, so just because I had to go look for Charles also, this is about a 50-page specification. So you know, if we had to do an obsoletes version every 5 to 10 years, maybe that’s okay. You know, not if it was every 6 months.
Charles Eckel: Yeah I mean I guess my question was why couldn’t this just be a bis version if the RFC, you know since instead of doing an Update 1 and publishing it with that in the title, can we just do a bis and...
Spencer Dawkins: Okay. So we’re talking about EBML which is the extensibility based markup language, that’s like the basis for Matroska and other stuff that we do in the working group. So that’s like our core core specification, and then Matroska and Matroska Additions are building on that. So the EBML specification, what was the last time, you guys are sitting here, what was the last time that you added an attribute to EBML?
Steve Lhomme: Never for EBML itself, never, but the EBML schema was completely new in the spec.
Charles Eckel: So I mean maybe I was misunderstanding but I thought the RFC 9559 that’s specifying Matroska and it’s up through version 4, right? Up through and including version 4. And now these are new things that do we just not know that they were part of version 4 or they’ve been newly added?
Steve Lhomme: They are new elements, new elements, new codec, yeah everything is new but it’s still compatible with v4. So when you add something new basically you can have a default value that means when it’s not in a v4 document you use that value and basically every v4 document even before the element existed know how to interpret it because that’s how EBML works, if you don’t write something you can use the default value as a way to save space. So when you add something even if it’s not written you can still assume it’s there as long as it’s properly defined.
Robert Sparks: So there are two conversations going on and we keep bouncing back and forth between them so let’s try to straighten them out. So what Steve was just answering was Matroska, right? There’s a language that we have that Matroska uses, right? That has open extensibility points where more things can be added but we want to document what those things are and that’s what things have been talking about about adding things to Matroska. EBML is how you say these things and there are some ways to say things if I understand what’s happening that EBML can’t currently support that the group wants to add to EBML so that more things can be built.
Steve Lhomme: Technically it’s a bit more complicated, it’s not EBML the binary format, it’s EBML the schema, the description on how you define an EBML format. It doesn’t change the binary format it’s just adding things to the schema.
Spencer Dawkins: So up here, this first one is actually Matroska specification itself, which actually seems to include a, so that’s a repository that includes several specifications. The second one is a different specification and a different repo. So we’re talking about a PR down here in this repo and we’re talking about a PR up here in this repo. Does that help?
Charles Eckel: Okay, yeah and I think Robert was trying to disambiguate the two and my comment was really meant more for the one above as to doing a bis version for that one instead of doing an Update 1.
Steve Lhomme: Yeah, so I’m not against doing a bis, it’s actually easier for me, but how do we tell people what is new compared to because it’s such a big document, they’ll have to I don’t know if there’s a compare to, but most people won’t look at that so how do they know what’s new and what’s not in that XML file?
Robert Sparks: Typically in bis documents you say what’s new and what’s not, there’s a whole section that says changes from. Right? But there are also diff tools when the thing is being reviewed and even after it’s complete where you can see side-by-side diffs for what changed.
Steve Lhomme: But it’s for the same document or is a bis document considered still the same, it keeps the same RFC number?
Robert Sparks: No, it would obsolete when a bis document is published it would obsolete the document that it is bising.
Spencer Dawkins: Basically if you click on the old document you will end up with the new one if in the right place you would end up with the new one. And what I was what I was struggling with is if we so that’s a 150-page specification and if we do a bis which would replace it the IETF will review the 150 pages plus whatever we added. So it’s less of an impact on the community if we say this is what we’re adding to 9559 and that’s what we’re asking you to review, rather than saying oh well you know it was 150 pages before now it’s 200 pages, how long will this take?
Charles Eckel: Yeah, I mean I guess my question was why why couldn’t this just be a bis version if the right instead of doing an Update 1 and publishing it with that in the title can we just do a bis and okay so we’re talking about ebml which is the extensibility based markup language that’s like the basis for matroska and other stuff that we do in the working group so that’s like our core core specification and then matroska and matroska additions are building on that so the ebml specification who was the last time you guys are sitting here who was the last time that you added an attribute to ebml never for ebml itself never but the ebml schema was completely new in the spec so so i mean maybe i was misunderstanding but i thought the rfc 9559 that’s specifying matroska and it’s up through version 4 right up through and including version 4 and now these are new things that do we just not know that they were part of version 4 or they’ve been newly added they are new elements new elements new codec yeah everything is new but it’s still compatible with v4 so when you add something new basically you can have a default value that means when it’s not in a v4 document you use that value and basically every v4 document even before the element existed know how to interpret it because that’s how ebml works if you don’t write something you can use the default value as a way to save space so when you add something even if it’s not written you can still assume it’s there as long as it’s properly defined so there are two conversations going on and we keep bouncing back and forth between them so let’s let’s try to straighten them out so what steve was just answering was matroska right there’s a language that we have that matroska uses right that has open extensibility points where more things can be added but we want to document what those things are and that’s what things have been talking about about adding things to matroska ebml is how you say these things and there are some ways to say things if i understand what’s happening that ebml can’t currently support that the group wants to add to ebml so that more things can be built technically it’s a bit more complicated it’s not ebml the binary format it’s ebml the schema the description on how you define an ebml format right it doesn’t change the binary format it’s just adding things to the schema yeah so just up here just up here charles this first one is actually matroska specification itself which actually seems to include a so that’s a repository that includes several specifications the second one is a different specification and a different repo so we’re talking about a pr down here in this repo and we’re talking about a pr up here in this repo does that help yeah and i think robert was trying to disambiguate the two and my comment was really meant more for the one above as to doing a bis version for that one instead of doing an update one yeah so i’m i’m not against doing a bis it’s actually easier for me but how do we tell people what is new compared to because it’s such a big document they’ll have to i don’t know if there’s a compare to but most people won’t look at that so how do they know what’s new and what’s not in that xml file typically in bis documents you say what’s new and what’s not there’s a whole section that says changes from right but there are also diff tools when the thing is being reviewed and even after it’s complete where you can see side by side diffs for what changed but it’s for the same document or is a bis document considered still the same it keeps the same rfc number no it would obsolete when a bis document is published it would obsolete the document that it is bising yeah basically if you click on the old document you will end up with the new one if in the right place you would end up with the new one and what i was what i was struggling with is if we so that’s a 150-page specification and if we do a bis which would replace it the ietf will review the 150 pages plus whatever we added so it’s less of an impact on the community if we say this is what we’re adding to 9559 and that’s what we’re asking you to review rather than saying oh well you know it was 150 pages before now it’s 200 pages how long will this take yeah i agree okay but but the downside is you may end up having to repeat some context right that you had in the original document so you have to put that into the new document also not that much but it’s hard to discuss without seeing the current version but the current version doesn’t have a lot of text because also for EBML if you have a new element there’s a path so you know it’s a hierarchical format like XML or whatever it’s a tree of elements but if you have something deep in a level in the tree you’re not going to say this part is this that there’s a path that says it’s in this parent this parent this parent and the element is there and you have to know already all the parent that’s in the other document and then you just so basically you just define that element with its parent and you know exactly how to use it. So the document is actually with a few additions that’s more coming because we’ve been waiting for a while to start it for real. My gut instinct, chair hat off, just individual IETF participant who’s looked at doing these kinds of things before, I think the path of least resistance here is a string of updates documents and if the collection of update documents ever gets to be so large that understanding what the specification format is becomes difficult, then you do a bis that rolls all of those up into one document.
Steve Lhomme: Yes, that could make sense.
Spencer Dawkins: And I want to make sure that I’m agreeing with Robert, which I always feel better if I agree with Robert. So that basically we’ve got 9559 and right now we have two more specifications and we’re planning to publish those as individual documents. This is the Codec specification and this is the Tag specification. We had another one that we’re planning on doing that’s the Chapter Codec specification. That’s not a huge number and let me check this just because I’d like to not lie to the area director on the first call, but yeah, see, that’s the other thing is we this this this specification adds to the Matroska universe but it doesn’t update the Matroska specification, okay? So really, and I think I’m speaking only for me, I’m still getting my head around the thing where we have additions that don’t update the base specification. So basically if you want to implement Matroska all you have to do is the Matroska specification unless you want to do codec you know include codec information and if you want to do that you do those two specifications but you don’t have to do you don’t have to do any other specifications so if there’s four other additions and you don’t need to use three of them, you know well here’s here’s the base Matroska specification and here’s the one or two that you might want to implement. So but these don’t these don’t update they don’t touch the text in 9559. And like I say I think that’s something I’m still getting used to.
Robert Sparks: Mildly frustrated with going around this several times and not landing, I’m again as an individual I don’t understand why updates is wrong. If you are implementing Matroska you don’t necessarily have to use all of the things Matroska can say. If you’ve got a Matroska renderer, if you’ve got a base spec and a bunch of update specs, you can still say I’m doing that part but not this part. There’s still a ton of you know SIP implementations out there that don’t support for example refer and refer updated 3261 and the world didn’t die. Another thing in favor of updates is that it’s a way to show that everything that people used in the first document hasn’t changed. Like they don’t have to go through the document, if they don’t care about the new stuff they know that everything that’s been done for 20 years is still there and they don’t need to think about it. Whereas if there’s a new document they have to think okay what’s different do I need to care about it etc. It doesn’t obsolete the old document, it doesn’t change it, it’s just additions.
Steve Lhomme: Yeah, maybe the term update is a bit misleading as well but that’s what we have. For me it’s addition although I called it revision. You’re not updating any text that already exists.
Spencer Dawkins: Okay so I think I have been misleading the entire group, sorry, I was I am now realizing or remembering that we can have an updates relationship between RFCs that do not touch text in the in the base specification. And with that, my question is should CELLAR Tags and CELLAR Codec have an update relationship with Matroska with the Matroska base specification because I don’t think either one of them do, do they?
Steve Lhomme: No, like it’s orthogonal subjects, like they can completely exist on their own, of course they rely on a few elements that exist in the main document but that’s it.
Robert Sparks: Charles you know my the reason I fret all of this is that whatever we do it’ll eventually get to IETF Last Call and to the IESG and somebody there will want to do it a different way. So and this is right at the cusp of the thing that has caused the Maryanne Suresh’s document that has been attempting to talk about what updates extends see also whatever might look like, is stepping right on the soft squishy edges of of that conversation. So in that sense it’s just extending but I think updates is actually the right thing to do here because it gives a sense of connectivity for the full set of things that you can say.
Spencer Dawkins: You’re thinking like an RFC guy Robert, thank you for that. That’s not where that’s not where I started out. So if we want to do that and I understand why we would want to do that and I would support us doing that, but if we want to do that then we would need to we would need to add update relationships between Matroska and and the Codec and Tag specs, right? And the good news is that neither one of those have gone to the RFC editor yet. But am I getting that right?
Charles Eckel: Yeah and I wasn’t thinking of it in those terms until you mentioned that that those documents were actually updates where you had broken out specific things but yeah now that makes sense so this next one that’s being talked about maybe there’s not a nice name for it so it just ends up being called Update 1 but all three of them would have that relationship if they’re all updating the core Matroska v4 spec.
Spencer Dawkins: Yeah. And I feel like the fact that we are a archival, you know, a technology group, that this is a little bit weird because a lot of IETF working groups don’t kind of assume that people are going to still be connecting to IP version 2. Not that kind of version. Yeah. So time check: we’re about to run over. Yeah. And so the last thing I so I think this has been a good discussion I think we can continue on the mailing list which Steve has sent email to the mailing list asking questions so we have a place to do that but do we can we kind of basically say we’re leaning towards including update relationships between Matroska Additions and Matroska including the ones that are already in progress? And then see if we can like drive that conversation, have some content and enclosure in the next couple of weeks. Yeah.
Steve Lhomme: And we can discuss that on the mailing list also. So for all the new documents they would be update of RFC 9559.
Robert Sparks: Yeah I think that’s the current suggestion.
Steve Lhomme: One good thing I was going to say before of updates is that when you look at an RFC if there’s an update it’s listed at the top so you already know if there are other things you should be looking at whereas if it’s completely unrelated you might not know at all.
Spencer Dawkins: Cool. So I do we have any other business? I should ask, do we have any other business? None noted. So we have some things that we’re going to close on on the mailing list, and that’s making sure we’re making sure we’re there on Tags and on CELLAR that that’s going to happen on the mailing list and Steve has already started discussions on both the EBML specification and the Matroska Additions the next Matroska Additions specification. And we are doing all that on the mailing list and in GitHub. So we might be adjourning on time. Does that sound good?
Steve Lhomme: Yes just in time.
Spencer Dawkins: And thank you so much for joining us Charles, we appreciate having you here, especially for this handoff.
Charles Eckel: Yeah thanks for the introduction at the start and yeah very nice to meet the extended group here.
Spencer Dawkins: They’re good. Jérôme’s trying to break in.
Jérôme Martinez: I just say thank you.
Spencer Dawkins: Awesome. They’re also well behaved.
Charles Eckel: Alright, we’ll take care everyone.
Spencer Dawkins: Thank you, make choices!