Internet Engineering Task Force Interim Meetings, 23 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CELLAR-20220823-1900

Description

CELLAR meeting session at IETF
2022/08/23 1900

https://datatracker.ietf.org/meeting//proceedings/

A

B

Before I start actually sending audio as well as video right.

A

Oh, jew is good.

B

So how are you and steve.

A

I'm okay still too hot in europe, but we can survive.

B

Has it gotten any cooler.

A

Only a few days and nights back up again.

B

uh It's so in dallas, it's actually raining. So uh so that's so that's a good thing. um It hasn't been for a while.

A

Well, yeah yeah, it's it's.

A

C

A

It's been raining like one or two days in uh like three or four months.

B

B

Just craziness.

B

Well, we are still gathering I'm going to take a quick like a 30-second call. I will be right back.

C

Apparently, a lot of people are having regrets.

C

Maybe that's a mistake.

C

I should be.

B

A

Actually, it says I'm on regrets when I'm here and retro as well.

C

Steve, you are very quiet now, oh sorry, spencer, sorry, spencer,.

A

Do you know if michael is coming.

A

We can't hear you.

B

Is that better? Yes,.

C

That's better much better perfect.

B

um And uh michael is expecting to join us, but was not sure he would be back without from his uh appointments in time to be here at the beginning, so anything that anything that turns out to be critical for his participation.

B

um There may be value to say there may be a couple of things on process uh for matraska that uh he would know the answer to that. I would not, but I think everything else we can. We can just we can just work our way through.

B

A

There was a few things I wanted to discuss with him, but uh yeah. I guess we could start on a flag and that's.

B

B

Okay, cool, um so just working our way through uh our usual stuff, um see I I did this yesterday, I'm so matruska 11-11 was posted. um Did we have any other changes? I have not looked today on uh drafts that were draft updates that were submitted.

B

And we said so for flack we said we could. We could spend a decent amount of time at the august meeting on flac. If we needed to, I did have a update for people as of about 30 minutes ago. Our ad has approved that the october interim meeting will be.

B

Co-Located with no time to wait- and I can actually say that.

C

A

B

And so um so you may you all, may see some uh you may you may see uh a uh cancellation for the uh not in person. Not not co loaded uh october enter a meeting, uh but don't don't uh cancel your tickets.

B

Are they are there people on the on this call who know that they won't be uh at no time to wait in.

C

B

I don't know whether I will be.

C

There three days, but uh I should make the uh october meeting on the co-located meeting.

B

Yeah yeah cool.

A

Yeah I'll be there as well and I suppose, return as well.

A

I don't think michael will be there.

B

A

A

Michael, I don't know, I think he was intending to come.

B

Yeah, that's that's the last I had heard yes, so uh we will. We will see if, uh but uh that the plan was to allow uh remote participation, so I could come so um so no changes, no changes uh to anything. If somebody else is not able to be there in person also.

B

um This is about the time that we would accept our draft minutes from the previous meeting that were uh sent to the mailing list like yesterday. Did anybody have changes that they needed to uh needed us to make.

C

No, I have no objections.

B

Excellent, so uh so would you say no objections on the call.

B

You will spell that, right anyway, cool.

B

That gets us most of the way down to talking about flack.

B

Who would like who would like to uh drive this from github? I I can, uh but but it would be some a tiny bit of a challenge for me to uh to take notes. At the same time,.

C

um I could I guess I I don't know how, but I can try.

B

Oh okay, um so martin uh are you uh logged into the data tracker looking at the um looking at looking at a hedge dock, that looks something like this.

C

B

This one sorry, okay, perfect, uh I think all you really need to do for these is to uh record uh like what issues slash prs. We are uh we need to uh that. We are that we have been able to resolve. You know just the number is fine and.

C

B

Issue need more review.

C

I'm just worried that my computer, my desktop, won't be able to uh cast the screen because it is already having problems with uh meet echo.

B

Oh yeah and that's that's fine. uh We can all we can all uh be watching. uh We can all be watching the uh um actually. I'm sorry, let me let me worry about this and you p, you can pay attention to the technical discussion. Okay, okay,.

C

I'll try, okay.

B

Excellent, so uh if we were going to flack, we would be something like here and.

B

And I will move.

B

My I will move this down to another screen. Okay, so I would like so I can take notes and not distract you guys, and um so you are, you are seeing what I'm seeing in github.

C

B

Okay, excellent, uh so um last call uh we were asking for uh reviews of 138 and 158. I think.

C

Yeah, yes, 138 has been merged that had been reviewed by um jerome and that was uh that had been in had been. I asked for a review quite a while but ago, but yet didn't have time, but he did just in time to have it merged for the upload of the new document to the data tracker.

C

Okay, so then 158 still remains we're. Now at the issues, can you open the.

B

B

And see that was a pr right.

C

B

Yeah, um so there yeah, so this.

B

B

We did have, we did have a a couple of things here um with a change requested. Is that something we need to look at.

C

No well I'll, just uh okay.

B

C

Something written down for this and the thing is we at some point. The question was: should we um add in encapsulation specifications.

C

For flock to be uh encapsulating, orc or matroska, or uh mp4 so, and the encapsulation spec specification for oak, do I pronounce it right org, um it's rather short it's on the flock website and it's only well less than a page, but it could be. It was already. I could compress it even more less text. So it's in the document um why there's still a change requested is well you're. Looking at it now, jerome asked: why is former's comments metadata block mandatory, and why is the order important? Well, it's in the specification. That's already there.

C

I don't know why it's important, apparently, software counts on. It so seems best to me not to change, but I left it open anyway. Okay,.

B

C

But the question I would have here is well orc isn't already in there. It's a well short short piece and there's a reference to matroska, there's of the matroska codex.

C

Part that will the matroska specification is now in, I don't know which stage, but it's further up the chain than flock at this moment point um if flock references to the other truss document. I don't know what, when that will be published, um would it be a problem if flock goes out first, because if it's, uh I read that if it's not an informative but a normative reference, then they need to be in the queue at the same time or something.

B

um And- and we can, we can reasonably talk about that. Can you uh catch me up on um my um so I've? I have one question here: uh are we talking about uh the black uh referencing matraska.

C

Well, specifically, the codex part, so.

C

Specifications.

B

I was just trying to make sure I had the direction right.

C

A

I think the codex part of the matroska, so it's a standalone document, that's not the one that has been submitted, so it will be most likely published after flak and from I mean they won't even probably be in the queue. At the same time, my understanding is when you reference that document you put like a link to the draft.

A

We do that internally, also with our documents and from I think what michael said once once the the document is not draft anymore, but it's the published version like it's automatic that the reference in the other documents are updated or something like that.

B

Right right, right.

C

But it's an easy.

B

C

When there's an informative, I read something in some itf document that that can only happen if there it is referenced as an informative reference and not if it's referenced as a normative reference. So I don't know what that the right term, but uh apparently.

B

Well, those are the right terms.

C

Apparently, when it's a normative reference, they do have to be at the same time in the queue. Otherwise they can't reference each other or something or.

B

C

So the question is.

B

The idea is basically basically that if a document has not been approved by the isg, the contents can change. So they don't want to publish an rfc which says you're finished, but you have to read a document that still could change in order to implement it. Does that make sense.

C

B

C

B

You know you don't have to read the document that is still subject to change in order to implement the you know, the first document you can you you can publish it with a uh informative reference to a draft.

B

uh That would be a conversation with our ad, but the the process allows us to do that and I've I've. You know I've published and I've approved documents uh with uh informative references to draft so.

C

A

In your case, do you need uh yeah? Do you need a normative reference or an informational reference to uh well.

C

That's right, that's the question I have really because the flag document in itself is well, it doesn't depend on the matraska codex part. Obviously it's only that for the encapsulation we say: okay for the encapsulation. Look at that document, then you can ask yourself. The question is the encapsulation, something that really needs to be in the flag document? Does it need to be a normative reference?

C

Well, I don't think so, because it's well not an indispensable part of flock to be embedded in matroska, but I well. I really value your opinion on this.

A

In my opinion, my preference is that basically, every codec should have its own document of how it's it should be put in whatever container my reference is the av one, the video codec and basically there's a document for how you put it in mp4. There's one on how you put it in matroska.

A

For matroska, because historically we had a large document with lots of codec how you put them in matchoscar. We will do that, but it would be very possible that you take the text for flag in matrix from that document. You put it in yours, I don't know if it's big or not, and then that's the normative part or how you put it in matroska.

C

Okay, yeah. That would be fine too. It's just.

A

Yeah we, if the only thing we would do in the mattress codec document, is to put a link to your rfc to say if you need to put flack you just look at that document. It says how you do it.

C

Okay, so we take out the parts: okay, yeah.

A

Because from what I understand, you already do it for org. Yes,.

C

I don't know no not for mp4, because the mp4 document is really really large uh several pages, and I think that should be a reference to a document somewhere on github, um because there's I can't abbreviate it it's it's really. It would take tens of pages to get it in there and I think that's not appropriate.

A

Yeah, I understand that's the same for everyone and it's even worse, because it's a video codec within one more parameters but yeah. That's the idea. That's in my opinion, that's how it should be done for each codec and each container. It should be one document.

A

uh So if that exists for mp4, you can just put a link to that and that's enough.

C

Yes, I found it fascinating that the part for org and the part format is just a few lines and the part for mp4 is many pages for some reason.

A

Yeah, but in fact I think the either org and metroska it's they are the wrong way to do the specification, they're, probably too short, to really explain all the edge cases or whatever like, for example, you're supposed to say the bit rate, not the bit rate. The sampling rate of your flag file in found in whatever field of your flag headers should match the header in the flat sampling rate in the matroska audio track, the same thing same thing for big deaths, etc.

A

I'm sure these documents don't do that. But technically you should do it. If you want to do it properly, it's implied that people know what they are doing and they have to map the fields from one to the other. But a normative document should say it.

C

A

C

Okay, uh that was pretty much the questions I had for this pull request. Thanks for for the input, um I had two more questions that aren't linked to any pull request. So.

B

Okay, uh just to close this, uh just to finish this one up, uh sir, you are you, do you think you know you have what you need to uh merge this now.

C

uh Yes, I'll change some things and then I can merge it, but I now know in which direction I should go.

B

Yeah that that's that yeah, that's that's! That's that's what we shoot for.

C

Okay, um next item of discussion, I was wondering uh at some point uh I think about half a year ago I sent in a pull request for well. It wasn't merged because it was a bit out of place, but um I was thinking of a section on development history. I called it past changes at some point and the problem is: there is flux software around that when asked can create files that are not complying to the current spec.

C

The spec was changed in at some point, just a tiny detail at some point in 2007, but there is still software around that you can. It's actually shipped with debian um that you can, if you put in some option, creates files that are not spec compliant.

C

I was thinking about putting in a small short section on what changed in 2007 and how these files should be interpreted. It's just about the coded number. Actually does that make sense, or does it not have not have placed in a normative document.

A

C

Think it makes sense.

A

Just I mean in matroska, for example, we have like, I think, 80 elements that have been uh deprecated over time that nobody uses. We still put it in an annex at the end of the normative documents because they still have an id type etc.

A

So people who might create new elements, they should rather not reuse ideas that existed in the past, so we just list them there. So yeah. In my opinion, it's a good idea to put it, especially if there's some special values that have been used in the past, that people might find or try to avoid using okay.

B

C

B

This is what we've done with matraska, so we and we think it makes sense to do it with black as well.

C

It's the best to have that, as steve has said in the special section. Yes, in.

C

B

Yeah, that was what I was going to say was. You can have usually they're an appendix and labeled non-normative, but I mean like examples and things like that. um You know that. That's that's a perfectly fine thing to do. um You know if, if you all think it's helpful.

C

Okay, yeah, I think I might be helpful, uh especially as we're looking at archival. uh Well, that's the market is the wrong term, but obviously seller is geared towards archival usage and I would think if one comes across an old file and finds it odd that something doesn't match with this pack. It makes sense to put it in the section why it doesn't.

B

Yes, absolutely I I would you guys are the pros, but I would agree absolutely.

C

Okay, um well, let's uh for that question I had one final one: um okay, it's it's another non-normative uh thing um at some point during uh well also about half a year ago, we created the flock test files repository in the itf wwg seller organization, and that contains files with well all 60 files, which um cover all the aspects of the flag format, and I used these files on several hardware and software decoders and found out that some features of the flock format are not well supported.

C

um I could also in an appendix write something about if you really want the to create flock files with the highest possible compatibility, you should you you should not use these in these in these features, but that's really subject to age badly. I guess right um so would that be something I should put in or should I leave the house.

B

I'm typing real quick, so you guys talk and then I will talk.

A

I don't know uh we have also the same situation in metro scale where we say like there's some elements that have to be there, that everyone has to support and some others that, like tags, for example, most of the programs don't handle it or to just write it and never read it properly.

A

So yeah in the introduction of some elements of the format we say this is not commonly used or this is commonly used and you should be prepared to handle it but yeah. Of course it's. It can change over time and the document might be weird in the future that something says it's not common and everybody's using it. So.

C

Yeah, maybe that's why it should be in an appendix, as well um maybe put in a warning that it might.

A

C

A

We have a section called your guidelines and basically, in there we say what people should do and or might do or I'm not necessary. So maybe you could have some guidelines saying these features are very common yeah you should handle it for sure, and these are not command.

A

So you might prioritize your work on the other ones.

B

Could I show you guys um something that is um you know I can just. I can just stick it in. I can just stick it in the notes, but um so we had this problem with a specification that got approved last week in the mops working group, and uh it was basically you know we have information, that's valuable and that we don't think it will age. Well.

B

C

B

Go so is that what.

C

B

C

B

So what we ended up with was a uh we put a separate uh dot md file in the right place in the uh in github, and uh put the information that we wanted people to know in that and then uh created a informative reference to that separate md file or every you know what whatever you guys are using but yeah where basically, uh the working group can continue to or even a community of interest uh can continue to update the information that's likely to not uh age. Well, okay,.

C

Well, I can put the.

B

I could put the uh link to that in a comment in the in the minutes. Just so you all can you all can see that to consider it.

C

Yeah well actually, this I I didn't think of that, but it makes sense because we already have a section implementation status that also doesn't age well and that references to the github uh wiki. I can add that as well there. Of course, I can just head to the implementation section status, uh look for implementations here and maybe for which features are well supported and then edited in the wiki yeah makes sense.

C

B

So you guys wonder why I'm around and sometimes sometimes sometimes it's okay.

B

Cool um are there? uh Are there any other things that we need to talk about with flack.

C

um No, I don't think so, at least not from my part.

B

A

Not from my side.

B

If you guys can, if you guys, can give me about two minutes, uh let me ping uh michael and uh see if he is able to join us at this point.

C

Yeah no problem sure.

B

Okay, uh I will be right back as we say.

B

B

B

B

B

We can give him, I guess we can give him a couple of minutes and and then we'll turn. If we haven't heard anything back.

B

Oh, that's right. You guys can see what I typed.

B

B

And while we were waiting, I guess I should also ask if there's anything for uh ffv1 and version four, that we should talk about.

A

And that's the thing that I wanted to talk about. Is that there's two things I would like to be merged in the document before it's submitted or finalized or whatever, but I think we'll do some edits in the meantime.

A

Also they it's probably okay, that we can merge them before. I wanted some input and if we do it now, if we do a bit, do it a bit later.

B

um I would think you could do it now.

A

One of them was changing the layout of the documents, there's actually a bug that one of the field of some elements was missing from the document, so basically there's a lot of elements that are not fully described properly, so we definitely need to fix that.

A

I also changed a bit the layout to make it uh cleaner and shorter.

A

So I, but the problem is that then the you know they have the div tool when you submit a document and they can see what you changed like the whole document will look a lot different. Well, not.

B

A

So they will think everything has changed. So I don't know if it's cool or not.

B

So um spencer's answer, uh because this happened- this happens so uh in some other working groups, uh a practice that they do is uh so you remember how we adopted documents for um uh for a as working group documents, so yeah like like once, we've done like once, we've done in the past. um So uh what what a lot of times people will do is they will say uh here is this document that reflects all the technical changes?

B

Okay and that's what you need to be able to diff and then the next version is only format, changes.

A

B

Okay and uh the work, so uh I am not as smart about this in github as I am about on the in the data tracker, but in the data tracker it it's easy to say, compare version 15 with version 13., you know you're not limited. You you're not limited to an adjacent uh version, so so yeah.

A

That would be my question.

B

Would be to do two updates and I would say, like do the first one as the technical updates and then uh do the second one is only rearranging.

A

Yeah, okay, I see what you mean. I can do that. I can split the because there's one uh pull request, but I can split it in between formatting and editing and we'll keep the formatting for when we publish the next update, we'll publish one and then we'll publish another one with the formatting change.

B

That that sounds perfect to me and anything anything that I say you can blame on me later right.

A

It sounds reasonable.

B

Just got back adjourned.

A

B

And I said yes, okay.

B

Perfect, so we will adjourn um our our next meeting will be in september at the usual time and place, and then the um the fun meeting after that will be at a in october at an unusual time and place.

A

Yes, well uh yeah. I didn't check the time if it's so unusual or not yeah, probably because otherwise it's in the evening but yeah.

B

C

It two in the afternoon.

B

Have a great have a.

C

B

Great day and um enjoy any part of your uh next 18.

C

A

You too, thank you, bye-bye.

B

Bye-Bye bye.

C

Thanks and see you next time.