MIME info spec: Handling containers/multiple MIME types per glob pattern

Dave Cridland dave at cridland.net
Tue Nov 15 13:11:54 PST 2005

On Tue Nov 15 20:44:29 2005, Rodney Dawes wrote:
> On Tue, 2005-11-15 at 21:12 +0100, Christian Neumair wrote:
> > [1] proposes to introduce application/x-foo MIME types for the 
> various
> > contents, and use application/ogg as a their parent, thus using
> > application/ogg as container type, but - if there was an API for
> > determining whether multiple patterns are associated with a 
> particular
> > file name - informing that further investigation (sniffing) is 
> required
> > for determining the contents type. One of the x-foo types will 
> match, et
> > voila, we got the type.
> Can we please avoid adding more application/foo types for things 
> that
> aren't appllications? audio/x-ogg and video/x-ogg-theora would be 
> much
> better.
Or: application/ogg; x-subtype="theora"

Indeed, there's nothing stopping you from writing an RFC which 
defines the parameter you actually need.

There's quite a few MIME types that already need handling on a 
per-attribute basis anyway. My major concern with going with 
application/ogg is that non-XDG systems which use MIME may rely on it 
being application/ogg, and made-up MIME types will leak.

Extending this, all the source-code types that don't have registered 
MIME types could become text/plain; sourcecode="perl" etc.

           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

More information about the xdg mailing list