[standards-jig] sending mime-type during filetransfer

Matthew A. Miller linuxwolf at outer-planes.net
Tue Jan 13 00:21:06 UTC 2004

Correct me if I'm wrong, but what you are asserting is that everyclient 
will be implemented to simply save the file and be done with it.  You 
are also asserting that since so few operating systems actually store 
the mime-type, we should just do away with it.  Both of these assertions 
are wrong.

It is quite possible for a client to present an options dialog asking 
the user if they do want that file rendered (think of what your browser 
can do).  In fact, it's probably on the feature-request lists for a 
number of clients.  Without this information, the client needs to guess 
by extension, which has a number of serious issues (not the least of 
which is that some extensions map to multiple mime-types).

And as for the argument to omit the mime-type because "not all operating 
systems will make use of it" is ridiculous.  It is akin to saying "no 
one will ever need more than 640KB of RAM."  A number of posts have 
already shown that there are in fact OSes that can take this information 
into account.

We placed mime-type in SI (JEP-0095) to allow for these cases.  It's 
also why its listed as a SHOULD requirement, and why SIFT (JEP-0096) 
does not modify this usage.  When putting together those JEPs, we had 
(unanimously?) decided that the mime-type was A) potentially useful for 
all SI use-cases, B) easily ignored, and C) not a serious burden to 
provide, especially since there is a possible default 
("binary/octect-stream" IIRC).

If your client doesn't want to use it, then ignore it[1].  Just because 
*YOU* don't want to use this information does not mean *NO ONE* wants to 
use it.

-  LW

[1] If it's not "your client" (i.e. someone else is implementing it), 
then talk to your client's implementor to ensure you have the 
appropriate options "by default".

Richard Dobson wrote:

>>Majority operating system have system to use mime/types. Mime type is
>>required and used for all file transfer (http/ftp/mail) not for store
>Yes but you still dont seem to be getting what I am saying, the mime type is
>useless unless you are going to do something with it, which in normal file
>transfer where you are just transferring a file to be saved to disk between
>to people you dont need to use the mime type (since you are not
>automatically rendering the file afterward), and since the OS does not yet
>save it to disk (by your own admission) and make use of this mime type it is
>never used and thus not needed and pointless to include. Mime types are used
>in HTTP and mail (not ftp btw) because the browser/email software need to
>automatically render the data themselves which we are not required to do in
>normal file transfer, the files are just saved to disk for the user to later
>open at their leisure (at which time the mime type will have been lost so is
>>Storing data is OS problem... and Longhorn WinFS store mime type
>>in database...
>Thats all well and good but Longhorn is far from ready for release, ive
>tried the beta.
>>This discussion is senseless.
>I agree, since the OS cannot store the mime type for the file it is
>Standards-JIG mailing list
>Standards-JIG at jabber.org

More information about the Standards mailing list