Right. That's what fs is all about, so I think application/fs is the only
justified type for what Al wants.
Pete,
Here are some points and tanks for the comments!
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"
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....
Getting away from an external application is the whole concept of putting FS
into MIME!
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)
To reiterate a few other points: (and not to sound like a broken record)
Compression:
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 object is "somewhat compressed" super compression was not the goal
_but_ there is a way to Tweak LZJU90 to compress much more if you rewrite
the code for a platform specific mailer/application.
The code example does fair compression, we wanted to make sure it would
always compile. If you tweak it, and someone else does not, it still
functions, no worries there...
With any compression algorithm depending on the file, type etc, LZJU90 will
do better in some cases and not as good in others.
The goal of LZJU90 was to prevent objects from becoming very large to have
enough compression to prevent this from happening but to be fast as well, we
don't want to wait for the object to be compressed....
Multipart:
As for Multipart, I have heard from people who want it there Multipart/FS
and people who say it does not belong.
In my mind, convince me otherwise, if FS items exist as a file system object
they are in fact a media type, correct?
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?
Can I at least get consensus on this small point?
Nathaniel writes:
A general container for OS-independent files is a GREAT and CHALLENGING
idea. >Putting "fs" in the top level allows us to punt all the hard
decisions to the second
level
I agree... The original FS spec. did not need a second level type, FS as
defined has no need of it but it may very be useful... I am currently
contemplating this. Look closely how the spec is written now, but with
various rewrites who knows....
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.
how is an AVI file defined?
A Real Media clip? Are you going to stick all these into Multipart? (yuck)
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.
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.
But,,,, if we are going to do something, let's do it right, I'm open for
suggestions but to put FS into either Application or Multipart, in my mind
anyway, is a misuse of them.
Putting AVI files and RM files in there is wrong as well (only my opinion),
unless this RFCs definition was changed or I am misunderstanding what the
RFC says.
Regards to all,
-Al