ietf-822
[Top] [All Lists]

Re: Transfer Encoding for MIME

1998-09-10 19:55:02
Al,

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.

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

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

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.

It is better to create something that more easily fits within MIME (i.e.
existing parsers SHOULD treat unknown multipart types as
multipart/mixed) and would provide implementors a simpler development
route.  Backward compatibility can be achieved as above.

I have had this discussion over and over.  I read the MIME specs. In my
mind, FS objects are media types they are not encodings. They are however
encoded.
AND so are Zip files and JPEG's and Real Media and ARJ  files ....

They are media types but you would not expect a MIME implementation
written on a particular platform to understand the intricacies of an
existing FS object containing a VMS stucture, instead you would want to
hand that off to something that does.

Rgds

-- 
Antony Bowesman
adb(_at_)to(_dot_)sel(_dot_)fujitsu(_dot_)co(_dot_)jp