Re: Transfer Encoding for MIME

["Al Costanzo" <al@xxxxxxx>]

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