[standards-jig] sending mime-type during filetransfer

Richard Dobson richard at dobson-i.net
Tue Jan 13 09:36:57 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.

I wasnt saying do away with if you read the emails correctly (see below).

> 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).

Just for the record, asking the user if they want the file loaded is not
really anything like what a browser does, the browser loads it into itself
automatically and will often not have a reliable file extension to look at,
an IM client will most likely just start up the application that handles the
file type it has received, there is no problem with needing to guess the
file type of a file from the file extension because that information is
built into the majority of operating systems, even those that support meta
data, also if the operating system does not support meta data to define what
file type the file is if the file extension is wrong when the user comes on
to later open the file they wont be able to whereas first time they might
have been able to, so the client will still need to change the file
extension to be correct if it wasnt already. Also if the file extension is
correct for that type of file the there is no need for the client to guess
what it is or what to open it with, certainly on windows (not sure about
linux) you just literally tell the OS to open the file, you certainly dont
need to define the application.

> 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.

I wasnt saying omit, I was talking about not adding it (see below), although
for those few OS's that can take advantage of it you will still have to have
a mapping from the mime type to the native file identifier, e.g. on Mac the
resource forks are not mime types, they are proprietory 4 letter codes if I
remember correctly last time I poked around in that on my Mac, and as ive
said MacOSX actually moves away from using these as the primary method of
determining the file type in some cases.

> 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).

Ok thats fair enough I was under the impression from I think Tomasz that
mime types were not already in file transfer, and he was arguing for them to
be added, for which I was trying to show that it isnt really worth the
effort or fuss (at the current point in time), especially since it is
already in Draft.

Richard




More information about the Standards mailing list