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

Ivo Emanuel Gonçalves justivo at gmail.com
Wed Oct 3 08:01:23 PDT 2007

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.


>   - 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

>   - 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,


More information about the ogg-dev mailing list