Re: [Cellar] Zaheduzzaman Sarker's Discuss on draft-ietf-cellar-matroska-16: (with DISCUSS)

[Steve Lhomme <[e-mail]>]

> On 29 May 2023, at 11:14, Zaheduzzaman Sarker <[e-mail]> wrote:
> 
>  
>  
> On 2023-05-29, 10:25, "Steve Lhomme" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> Hi,
>  
> Thanks for your reply. Comments below:
> 
> 
> On 24 May 2023, at 10:54, Zaheduzzaman Sarker <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Steve, Hi Michael,
>  
> Please see my replies below (I hope the formatting holds in your view)
>  
> On 2023-05-21, 13:17, "Steve Lhomme" <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi,
> 
> First of all, thanks for your feedback :)
> 
> > On 18 May 2023, at 20:00, Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > 
> > Zaheduzzaman Sarker via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
> >>    - Top-Level Elements are optional fields in the segment. While
> >> segment is a MUST part in the container but segments values (elements)
> >> are MAY, this to me says one can just put a dummy segment in the
> >> container and it will be fine. is that correct interpretation? however,
> >> there is a RECOMMENDED segment element, so how should we interpret the
> >> statement that Top-level Elements are all MAY?
> > 
> > We struggled a lot with getting this text right.
> > 
> > To make an analogy; when you sit down to eat, it's mandatory that you eat,
> > and you MUST pick something from the menu, no actual individual item from the
> > menu is mandatory to be present. (Distinguish "present" from MTI)
> 
> Actually, the \Segment\Info element is always mandatory (minOccurs = 1, maxOccurs = 1). It is also mentioned in Paragraph 6.1. You can’t have a Segment with nothing in it, the Info element MUST be there and some of its elements MUST be set (mandatory with no default values) like MuxingApp and WritingApp.
>  
> Right, so this also makes the statement – “Matroska defines several Top-Level Elements which MAY occur within the Segment.” not accurate. It seems like we will be in better position if we remove that statement and add MUST, RECOMMENDED, MAY for each of the top-level elements defined. This way we can also make sure the future extensions/versions are not impacted by this specification. 
>  
> I removed the normative MAY in the text. It doesn’t need to be normative. Also this section doesn’t go into detail of what is mandatory and in what context. This is rather part of each element specification to know if they are mandatory or not.
> <781.png>
> Turn the may occur in Segment non normative by robUx4 · Pull Request #781 · ietf-wg-cellar/matroska-specification <https://github.com/ietf-wg-cellar/matroska-specification/pull/781>
> github.com <https://github.com/ietf-wg-cellar/matroska-specification/pull/781>
> 
> 
> That is fine, but then I am wondering if we should also add such statements for each and every element specification in this document or not.

It should really be on a case by case because, for example, this line needs both differentiation between MAY and SHOULD:
A Matroska Reader **MAY** support methods "1" and "2" as possible, and **SHOULD** support other methods.

There are “only” 8 use of MAY in the element descriptions.

> 
> 
> It is true that apart from that you could put nothing in the file and it would be valid, although pretty useless. Originally it was designed to also allow non-multimedia usage, for example using the Attachment part as a .tar replacement. It is also usable from a multimedia perspective to a Segment with just chapters referencing other Segments (Medium Linking) and no content in that one.
> 
> > 
> >>    - Even if the Top-Level Elements MAY be available in the container,
> >> some of the elements has MUST parts when they are present. However, I
> >> have not notices description of the consequences or error handling is
> >> those MUST parts are not available in the elements. I wonder what would
> >> be the course of action if the MUST parts of a certain element is not
> >> there. In general, I was expecting error handling in this specification
> >> which is not there and would like to discuss the reasoning behind it.
> > 
> > Then the file is invalid :-)
> > 
> > Whether it can be played anyway depends a lot upon the goals of the "player"
> > If it's subtitles which are in a format your player can't do, then you don't
> > get subtitles, but you might get A+V.  OTH, if it's a converter from A->B
> > (avconvert, aka "ffmpeg" ) then it could be that you can just copy stuff you
> > don't understand anyway.
> > 
> > If it's a database doing indexing for an archive, then maybe all that matters
> > is that the subtitles are good, and who cares if the V format is something
> > unknown to the indexer.
> > 
> > To make another analogy: some of this is asking what should the
> > *TCP-state-machine* do if the content is flow is a version of Flash that the
> > browser does not understand.  The answer is: they aren't really related,
> > until of course, the browser notices it hates that content and pre-emptively
> > closes the socket while there is still unacknowledged data in the Q.
> 
> The error handling is a good question. And as Michael said, it depends on the goal of the player. We can’t decide for players how to handle the errors, if they are recoverable in their code or not. For example if the checksum of the \Segment\Tracks is invalid some could decide to try to read the data anyway, some will just reject the file, most will not even check it.
> 
> IMO we can tell what is valid and invalid, but we can’t force a certain design on the receivers. Also the format has been around for 2 decades with lots of implementations. We can’t start now telling them they are not handling the errors has they should be.
>  
> Here my point is we completely ignored the error handling part and I think we have enough expertise to say something about it. In fact, a short summery of what you and Michael wrote here is good information to have in this document. After all this container is in use for a long time. Can we add that to this document?
>  
> On the other hand, if this container is there for a long time and everyone knows what exactly to do then one can say there is a very little value of creating this specification now. However, as we are long way here now trying to publish the specification, I would not give that comment much value.
>  
> I tried to write something as you suggested. However it all falls down to rules that derive from EBML error handling. There’s not really something specific to Matroska here.
>  
> Ok, I am however, was suggesting that we write something like below –
>  
>        “Particular error handling is not covered in this specification as this is depends on the goal of the players. It is upto the decision of the players on how to handle the errors if they are recoverable in their code or not. For example if the checksum of the \Segment\Tracks is invalid some could decide to try to read the data anyway, some will just reject the file, most will not even check it”
>  
> That is If this is really player behavior dependent, let’s just write it. (feel free to change the proposed text)

I used your text, in this Pull Request: https://github.com/ietf-wg-cellar/matroska-specification/pull/787
Thanks a lot!

>  
> //Zahed
>