On 9/12/98 at 6:22 PM -0400, Al Costanzo wrote:
Application/FS:
I'd have to disagree, The very fist draft of FS defined it FS _Exactly_
the way you are describing. I was told and told and told (you get the
idea).... that Application was definitely the wrong place for the thing
called "FS"
By whom? I cannot imagine that anyone in the MIME community would have said
such a thing. So far, I have only heard Nathaniel say, "If that's the goal
of the exercise -- i.e. to permit the gradual *evolution* of file system
wrappers -- then a top-level name might make sense. Otherwise, if we're
really trying to standardize on a single one for all time, I'd argue for
application/fs", but I have yet to hear anyone say that application would
be a bad idea.
Here, I'll quote an RFC, 2046 to be specific:
application -- some other kind of data, typically either uninterpreted
binary data or information to be processed by an application.
Welp (my word for Well with a sigh),
It's not necessarily binary, it's specific (not some other kind) and most
likely, if we get FS defined properly will _NOT_ be processed by an external
application....
Note the word "typically" in the 2046 section you cite. There is nothing
that prevents MIME interpreters from also interpreting the content of
things which are subtypes of application; many mail applications in fact do
just that. But like these other application subtypes, there is no further
*MIME* information to be found in the middle of these FS parts. It is data
that is dealt with outside of the context of this being a MIME message.
Let's take a look at some of the things you say later in your message:
FS - is like a file archive _BUT_ its not a file archive for the purpose of
archiving a file system set of objects.
It is a collections of file system objects wrapped in an "FS" container.
This container is in itself a file system object. "somename.fs"
This is increasing support for it being an application subtype. If FS *is*
a container that is a file system object with no MIME structure in it, then
it is something to be acted upon by a piece of code that considers the
structure of the FS object, not the MIME structure of the message.
Getting away from an external application is the whole concept of putting FS
into MIME!
This is where the multipart stuff makes sense, but let's look at that below.
Therefore, unless someone really convinces me otherwise, to rewrite the
draft the way it originally was ........
***Application/FS*** is not even going to be thought about (again)
You have yet to present any reasoning other than "it doesn't sound like an
application subtype according to 2046." I've given you reasoning why it
clearly is. Please give some other explanation before you dismiss this
idea. I did not see the discussion regarding the first draft, but I'd like
to hear other explantions that people gave to reject the application
subtype. According to what you've said, you thought it was a good idea too,
so I'd like to hear why you changed your mind (other than, "people said it
a bunch").
As for Multipart, I have heard from people who want it there Multipart/FS
and people who say it does not belong.
Again, which people have said it doesn't belong. I'd like to hear their
reasoning.
In my mind, convince me otherwise, if FS items exist as a file system object
they are in fact a media type, correct?
Sorry to repeat my point above, but if you are saying that there are
currently existing applications outside of the mail system which interpret
FS items as file system objects, then that justifies it as a subtype of
application, not a top-level type.
Now, if this media type to be defined is truly going to transport entire
file system between computers of like and unlike types....
Is it too much to ask for a new type to define this thing?
A new type itself is not a problem. But there is already a great deal of
machinery within MIME to do this sort of thing. If we can reuse this
machinery, it would be much better than reinventing the wheel. Again, I'd
like to hear argument that the current machinery is insufficient for the
task at hand.
The reason I selected FILE/FS is that the level type FILE was going to
contain file system objects that are not defined elsewhere in MIME or
defined well.
Let's start with an easy example: GIF images. GIF images may be stored as
file system objects, or may be dynamically displayed and never stored in a
file system. There are two mechanisms in MIME to deal with GIF images.
First, there is a Content-Type describing the type of data, which in this
case is image/gif. Then there is a Content-Disposition, which describes how
the data is to be dealt with, which might be as an file system object
(i.e., attachment), or as a dynamically displayed image (i.e., inline). It
might have file system attributes, which also appear in the
Content-Disposition, like creation date, etc. MIME deals with these objects
very nicely.
As a second example, take an HTML page with embedded GIF images. MIME has
(newly defined) machinery for this: The HTML part, and its embedded GIF
images, are put together in a MIME multipart/related object. The
multipart/related object is an object to hold related objects that will not
only be displayed together, but refer to each other within the context of
the multipart MIME object. There is a sense of tree structure when needed;
there is reference information like Content-ID and Content-Location, etc.
But notice that each object within the multipart has a type (text/html,
image/gif, etc.) that is represented by a MIME Content-Type, could have a
Content-Disposition with further information about the object, and all of
this at a MIME-interpretable level.
It seems no mental stretch at all to create a multipart container type
which, instead of "related to eachother" semantics, or "digest of messages"
semantics, had a "collection of file system objects" semantics. Each object
could have it's own *MIME-interpretable* type information, it's own
*MIME-interpretable* file system attributes, etc.
how is an AVI file defined?
A Real Media clip? Are you going to stick all these into Multipart? (yuck)
Actually, both of those, since they are normally dealt with as single
units, go under the video top-level type. And like other media types, their
Content-Disposition can be specified too.
To quote the same RFC:
multipart -- data consisting of multiple entities of independent data types.
The two types I have just mentioned are of a mixed data type but they in
themselves are a single media type. They are not multiple entities.
Could it be, that these two types are being misused? I think so.
Nope. This is why 2046 also specifies:
A media type of "video" indicates that the body contains a time-
varying-picture image, possibly with color and coordinated sound.
The term 'video' is used in its most generic sense, rather than with
reference to any particular technology or format, and is not meant to
preclude subtypes such as animated drawings encoded compactly. The
subtype "mpeg" refers to video coded according to the MPEG standard
[MPEG].
Note that although in general this document strongly discourages the
mixing of multiple media in a single body, it is recognized that many
so-called video formats include a representation for synchronized
audio, and this is explicitly permitted for subtypes of "video".
Ask any of the MIME RFC authors about me, I complained about MIME when it
was introduced, I'm not complaining NOW -but- I may wonder about the MIME
spec if its not flexible enough to handle the introduction of new types and
things somewhat easily.
It is exactly the flexibility of the multipart top-level type that I am
defending here. It is quite flexible enough to handle the subtype of "fs".
MIME is certainly flexible enough to take new top-level types, but
hopefully it should also be flexible enough to not require a new one when
something fits very smoothly into a current top-level type.
I still see no evidence that multipart/fs is a problem.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102