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

[Ian Malone]

Ivo Emanuel Gonçalves wrote:
> Following thread's feedback, I'm updating the file, and I'll soon
> commit the revised version to SVN.  From there, I guess final
> fixes/patches may be applied by anyone instead of reporting.
> 
> Some thoughts:
> 
> How to better describe executable content and security considerations
> regarding it?  Trust only content that is certified through SSL/TSL?
> 

"Be very careful."  Executable content can be all types of things;
some font formats are 'executable'.  I don't know if it's practical
to try to foresee the problems.  RFC3534 was pretty terse here:
"It is possible to encapsulate even executable content in the
bitstream, so for such uses additional security considerations
must be taken.  Ogg bitstream files are not signed or encrypted
using any applicable encryption schemes.  External security
mechanisms must be added if content confidentiality and
authenticity is to be achieved."
(section 2)

Much more than that is probably not needed unless you are
specifying particular types of executable content.

RFC4288, section 4.6 (extract):
"  o  Complex media types may include provisions for directives that
       institute actions on a recipient's files or other resources.  In
       many cases provision is made for originators to specify arbitrary
       actions in an unrestricted fashion that may then have devastating
       effects.  See the registration of the application/postscript media
       type in [RFC2046] for an example of such directives and how they
       should be described in a media type registration.

"  o  All registrations MUST state whether or not they employ such
       "active content", and if they do, they MUST state what steps have
       been taken to protect users of the media type from harm."



> Mac Type Code.  I've been reading about it, and it seems to be a
> pre-OS X standard that is to be/has been replaced by Uniform Type
> Identifiers[1].  No idea then if it's worth to keep the four letters
> Type Code in our registration proposal.  If it is, I guess OggX, OggV,
> and OggA will do.
> 

It seems they are needed: RFC4288 4.11(abridged);
"4.11.  Additional Information"

"  Various sorts of optional information SHOULD be included in the
    specification of a media type if it is available:

...
"  o  Mac OS File Type code(s) (4 octets) used to label files containing
       a given media type."


> More below.
> 
> On 10/4/07, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
>> It is expected that .oga will break players that
>> interpret them as .ogg files - but that's not a problem because they
>> will not even want to open a .oga file. As soon as .oga support is
>> implemented in the player, it will parse the skeleton track and know
>> what's inside and then use the appropriate audio decoder.
> 
> Then is it expected that oggenc will be updated with a -oga switch
> where a Skeleton track is added?  Instead of music.ogg, it would
> output music.oga with a Skeleton track?
> 
> Speaking of Skeleton, what is the correct way to define it?  As in,
> "this file has a Skeleton track".  Is Skeleton presence in Ogg always
> described as a "track"?
> 

The Annodex bitstream specification uses the term 'Skeleton bitstream',
having described it as a 'logical stream' (the strict Ogg terminology).
'track' could be a little misleading to someone not familiar with
Skeleton as it does not continue past the secondary headers and does
not itself have a temporal component.

-- 
imalone