[ogg-dev] Peer review draft for the new media types/file extensions

[Ivo Emanuel Gonçalves]

On 10/1/07, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> ok, so instead of editing it directly, I shall make a list of the
> things I'd like to change here

Thank you.  It is much appreciated.

> I think, "application/ogg" makes not much sense without having
> skeleton inside the ogg file. Half the reason for having a generic,
> free-ended encapsulation format is to have headers that can specify
> what is within such that any decoder has a chance to assess whether it
> will be able to do something sensible with it. So, I would like to
> actually prescribe the use of skeleton in application/ogg files. Which
> also means, I would suggest to change the "SHOULD" on
> http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions to
> "MUST". It's not hard to create a skeleton track and it will make all
> the difference of creating usable files.

Alright.  I'll update the Restrictions section on app/ogg to read MUST
have a Skeleton track.

> More generally, I would like to suggest for audio/ogg with oga and
> video/ogg with ogv extensions that skeleton SHOULD be used for the
> same simple reason of being able to identify the codecs inside.

This I'm not so sure.  AFAIK, there's still no official or
non-official tools out there (except a few simple SVN projects) that
deal with Skeleton.  There's no Skeleton RFC either.  We have to push
for both urgently.

> Just to be clear - I would not prescribe skeleton for audio/ogg files
> with ogg extension, which are clearly the old vorbis 1 files only. Or
> to spx files, which are speex files under audio/ogg. But "SHOULD"
> should work for audio/ogg with oga extensions without getting anyone
> into trouble.

This is the other problem.  It would become a mess on what audio/ogg
is supposed to do.  Then, there's also Ogg FLAC, which already uses
.oga (thanks Josh), but I doubt applications that deal with OFLAC can
deal with Skeleton.

> * references are missing

All references are missing.  I'm leaving that to the very end, when we
are all sure what goes in the document and what doesn't.

>   - do not distinguish between the different types of speex

I guess.  I think I saw the distinction on the 3GPP RFC and that's why
I added it there.

>   - replace "video, audio, or text format" with "a/v codec or more
> generally time-continuously sampled data" (stay generic or we will
> have to rewrite the rfc in future again).

That seems to suffer from the same problem, I think.  Better wording is needed.

>   - first sentence: replace "codecs" with "data sources" (stay generic)

I believe I agree.

>   - replace "non-standard visual and audio material" with "generic use"

I do not agree.  This is application/ogg we are talking about.  It's
not for generic use, as far as I understood.

>   - delete last paragraph - in a standard document you do not write
> about possible future revisions of the document, or else it's not a
> standard. We wither have parameters or we don't. At this stage we
> don't.

A similar paragraph exists in both the ECMA/JavaScript and 3GPP media
types RFCs.  I reckon it's needed to allow us room in case that
disposition type thing, or another approach will be needed.  As such,
I think it's important to leave it there.

>   - I don't think the base64 encoding suggestion is correct for Ogg
> encapsulated content; the data in packets is simply a sequence of
> bytes that Ogg deals with; just remove "base 64 is a suitable
> encoding"

It's a suited encoding for e-mail and the "data:" element in HTML.
It's also used on the MPEG, 3GPP, MPEG-4, and even our own RFC3543.

>   - third/fourth paragraph: I don't think we should exclude executable
> content in Ogg by design. I think this may well be interesting in
> future, so we should not unnecessarily restrict ourselves. We should
> however say that receivers should be careful and validate the origin
> of executable content inside Ogg before actually executing it.

Perhaps.  More opinions, please?

>   - in "Restrictions on usage" add a description why the ogg extension
> is being deprecated.

Agreed.

>   - under "published specifications" add the skeleton specification reference

That's one problem: there isn't any, but a wiki page.  Whoever knows
Skeleton in and out needs to write an Internet Draft ASAP.  Really
ASAP.

>   - also: I have a question about the mac file type code - does it
> make sense to call it "OggS" everywhere?

Paging Monty.  I followed RFC3534's lead here.

>   - delete "Note that timed text is visually presented and is
> considered to be visual material." That's not really true - you can
> e.g. have timed text which is just metadata in use for search engines.
> And it's irrelevant anyway.

It's not irrelevant.  It makes an actual distinction between video/ogg
and audio/ogg.  Also, timed text are lyrics or subtitles, which is a
visual thing.  The search engine case you describe would be metadata,
which usually is not visual.

Better wording needed in the document, perhaps?

>   - replace "MAY" with "SHOULD" because audio/ogg should have skeleton

I explained on an earlier message in this thread why I think that's a bad idea.

> might as well
> encourage ppl to create demuxing functionality

I know what you mean, but that would be wishful thinking, similar to
the W3C's XHTML, which went nowhere.  Developers are used to
MPEG-4/MP3-style solutions.  Simple solutions.

If we were more mainstream, this would be a logical demand we could
do, but considering our situation, the less we complicate things to
developers, the better we will be.  Work around this issue somehow,
please.


-Ivo