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

[Silvia Pfeiffer]

Ivo,

ok, so instead of editing it directly, I shall make a list of the
things I'd like to change here - some of which are actual changes to
the rfc3534's wording so not something you introduced.

First though let me start a discussion on skeleton here, which is
fundamental to this rfc and for which I'd like to get more input from
everyone.

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.

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. I
thought about this for a while and I think this is the right moment to
introduce it since the change of mime types and file extensions gives
us a chance to make the files themselves more concrete, too.

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.

Opinions anyone?


Now for the more mundane changes:
* references are missing
* section 1, para 3:
  - add a reference to dirac
  - do not distinguish between the different types of speex, since
that's not necessary 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).
* secion 1, para 4:
  - first sentence: replace "codecs" with "data sources" (stay generic)
* section 3:
  - replace "non-standard visual and audio material" with "generic use"
  - replace "also" in third paragraph with "newly"
  - replace "should" in third paragraph with "SHOULD"
  - delete "defined as" in third paragraph
  - 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.
* section 4:
  - insert "an" into first sentence
  - 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"
  - delete the paragraph "Note that most Ogg encapsulated...". It has
no relevance to the specification of the mime types.
* sectoion 5:
  - first paragraph: finish sentence before "This format..."
  - 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.
* section 8.1
  - in "Restrictions on usage" add a description why the ogg extension
is being deprecated. For example: "The reason for deprecation is that
traditionally .ogg has been in use for Ogg Vorbis I files only. Use of
.ogg for other encapsulated codecs will confuse applications."
* section 8.2
  - under "published specifications" add the skeleton specification reference
  - also: I have a question about the mac file type code - does it
make sense to call it "OggS" everywhere?
  - under "Restrictions on usage" delete ", audio, or timed text" with
"data in conjunction with audio and possibly other data tracks."
  - also add a descriptions why video/ogg is necessary aside from
application/ogg, e.g. "video/ogg is a specialisation of
application/ogg and hints to an application that the Ogg file contains
audio-visual content."
* section 8.3 in "Restrictions on usage":
  - 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.
  - replace "MAY" with "SHOULD" because audio/ogg should have skeleton
in there and thus multiplexed decoding is necessary - might as well
encourage ppl to create demuxing functionality
  - reformulate the ogg and spx extension description to describe that
they are specialisations of oga but without skeleton

Uff, that's it for today. Hope you can make sense of it. If not, get back to me.

Cheers,
Silvia.

On 9/30/07, Ivo Emanuel Gonçalves <justivo at gmail.com> wrote:
> On 9/30/07, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> > Do you have a source document for this or
> > are you directly writing a txt file?
>
> Text file.  Yeah, I've been told I should have gone with the XML, but I didn't.
>
> I guess I'll convert it at the end, to make sure there's no problems
> with the formatting.
>
> > Also, how far are you with references?
>
> I haven't updated anything since the last message as I'm not at home
> and there's no SVN client around here.  I'll get back to it in two or
> three days.
>
> > I just want to know before I attack the doc and give it a good work-over.
>
> While I do appreciate the help, I wish you would be more clear in what
> you wish to change, or think it's wrong, because I'm taking the
> opportunity to learn how to better write these Internet Drafts so that
> I may use such knowledge in the future to help out more and faster.
> And, well, if you do not specificy what I did wrong, I'll have to
> manually do a diff and try to learn from there, which is not optimal.
>
> -Ivo
>