Bug#605254: mime-support: compression schemes inconsistencies

2010-11-30 Thread Christoph Anton Mitterer
On Mon, 2010-11-29 at 22:52 +0100, Brian White wrote: > If an application stores information about the original file (like > it's filename) rather than just act without thought on a data stream, > then it's more than just an encoding. Yes that's what I've meant... > > > Especially >

Bug#605254: mime-support: compression schemes inconsistencies

2010-11-29 Thread Brian White
> Guess I was wrong with some of the above: > All of them, whose _decompressed_ data is more than just any raw data > (i.e. all archives which can have multiple files, or so) > can have their own (un)official mime type. > If an application stores information about the original file (like it's file

Bug#605254: mime-support: compression schemes inconsistencies

2010-11-28 Thread Christoph Anton Mitterer
Guess I was wrong with some of the above: All of them, whose _decompressed_ data is more than just any raw data (i.e. all archives which can have multiple files, or so) can have their own (un)official mime type. Especially application/x-gtar-compressed tgz taz however not (don't

Bug#605254: mime-support: compression schemes inconsistencies

2010-11-28 Thread Christoph Anton Mitterer
Package: mime-support Version: 3.51-1 Severity: normal Hi. In the notes you describe, that compression schemes are not erally mime types but encodings of types. I understand that you include such types when they're official (like "application/zip"). But why do you include unofficial stuff like