Changes to ISOBMFF

[cconcolato]

This PR is related to bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=26929
It adds application/mp4 and rephrases the requirements about handler_type.

[boblund]

Fine with application/mp4.

What is the added value in rephrasing the handler_type? It is already stated which box it is in. The ISOBMFF spec states where the the handler box is. Restating referenced spec language just raises maintenance issues.

I would like Silvia's opinion about using code font for field names instead of the single quote style. If she agrees, then the entire spec should be changed.

Agree with the ExtendedLanguage box, given the caveat of the font comment above.

[cconcolato]

Regarding the rewrite of handler_type, there are 2 aspects:

• The text should use entire sentences. Current text is like "video track: the 'handler_type' value is "soun"". Aside the fact that it should be "vide" not "sound", it is not clear that it means that it actually indicates that track is created. Thus my rephrasing. Actually I'd like to do the same across the entire spec.
• ok for simplifying the language regarding where the box is. I just tried to follow the HTML spec style ("the first stsd box of the first stbl box of the first minf box of the first mdia box" see https://html.spec.whatwg.org/multipage/embedded-content.html#sourcing-in-band-text-tracks)

Regarding the use of <code> that's how the HTML spec does it. So I thought it'd be better. I agree with waiting for Silvia.

[boblund]

This section is about how a UA determines the type of a track, not whether the UA will actually create the track. In fact the suggested shall statements contradict your addition to the intro stating "If a UA exposes a track". The current wording is appropriate, except for the error about video being 'soun' and audio being "vide". That needs to be fixed.

[boblund]

I filed a bug on the soun/video issue.

Regarding style edits, this should be done across the whole document, not a piece at a time. This should also have discussion and is probably best proposed as a bug.

[cconcolato]

fine, then cherry pick the 1st and 3rd comment for merge.

[silviapfeiffer]

That is much harder to read. I prefer we keep it the other way around.

[cconcolato]

@silviapfeiffer I understand. The idea was first to have the normative statement. I'll rewrite the PR to keep the readability but improve the normative part.