If you are looking for bacward compatibility for standalone en/de coders
why not just register application/fs and tunnel an existing fs object
through MIME. The whole fs object can be contained in a part and can
still be cut/pasted for decoding by a standalone decoder. With the
reverse the encoded FS object is simply added as an attachment.
Iteration two of this draft tried to define FS as "application/FS". As I
reread the
MIME spec. it became clear that FS really did not fit properly in this
definition.
- Why isn't this multipart/fs? Lots of good things would come from
using
multipart. I get the feeling the author has some reason he doesn't want
to
use the multipart construct, but the draft doesn't say what it is.
How right you are! I thought I mentioned this in the draft?
Is it only a backward compatibility issue for non MIME mailers. This
doesn't sound like a reason to invent a new top level type.
It's more than what I mentioned, basically I'm pondering a method of
registering
all file system objects in the namespace FILE, the FS draft you see skims
the
top of a deeper concept for future work. The concept is still in its birth
stage, it
has been rewitten quite a few times.
There are many objects that are currently not defined in MIME, if you going
to do work that deals with all the objects that define a FILE system, it
would seem to be prudent to begin discussing a methodology to register all
these types.
LZJU90 and FS are just two drafts, hopefully there will be others that build
upon this work, truthfully the definition of the top level type will most
likely be an entire I-D by itself but I want to put the concept out to the
community now, the simple definition in FS draft was a way to circulate the
concept and see how it was received.
fact, all the interopability onus seems to be put on the receiving
system.
Eg, I send you a Macintosh filesystem, one of the files has Macintosh
type
'ttro'. From this, a receiving UNIX (eg) mailer is evidently supposed
to
intuit that this is a text file and apply text canonicalization on
unpacking. Seems hard.
The onus IS always on the receiving system to be more flexible in what
it accepts than it generates. The same issues would apply to the UNIX
mailer if it received a multipart/appledouble, unless or course the
sending mailer were to generate a suitable multipart/alternative
suitable for all recipients. (Using up lots of bandwidth in the
process!)
- I am skeptical that the type can adequately represent current and
future
filesystems. In current form, I don't see how it can represent critical
items from the Macintosh filesystem (for example, the Macintosh filetype
I
And many other bits of information available in the resource fork.
4.3 mandates using ".fs" on the end of filenames; why?
Why do Zip files end in .zip text files end in .txt, etc. Since FS
objects
are actually a collection of file system objects that may be stored as a
file. It needs a file hook
designation for registration purposes like on Windows NT/98/95, ".fs"
seemed
to be a logical choice. Don't you agree?
Another reason against the top level, if you require a hook it shows
that you are looking for an external function to decode the type.
Therefore why not application/fs
This was not my intent. It was only so that a standard naming convention
would be used.
The concept behind FS is to get away from the concept that an external
function would be used. The desire is that the mailers user interface would
have the fs software built into it to handle all of this but windows
NT/95/98 and others need a file hook to know they need to activate the
mailer software to deal with this type of object.
Just like an .htm or .html file invoke the internet explorer when these
files are laid down on your desktop.
I agree that it would be nice to have a way to transport
filesystems, but I think we would be better off working on something
like
multipart/fs along with some new Content-Disposition parameters or
something.
I agree that using nested multiparts is a better way of going forward.
Certain mailers already implement the ability to attach directory
structures as nested multiparts. It is the directory/file structure
information that is missing. There are a number of CD attributes in
Steve Dorner's (+others) RFC2183 that match what you propose for the new
entity and these would seem better suited to enhance a multipart/fs.
These could be extended to include some of the attributes you propose.
I'll read the RFC....
Thanks for your advise!
-AL