[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Transfer Encoding for MIME

On 9/10/98 at 8:29 PM -0400, Al Costanzo wrote:

+I disagree, LZJU90 in most cases compresses objects further and is never
harmful.

Give us a few examples. (Most of us are too lazy to do this work ourselves.) Take a standard JPEG. Encode it using base64. Then encode it using LZJU90. Tell us what the size difference is. Give a few examples like this (MPEG, zipped files, some sound compressions). It should be easy enough for you to get some files and post some numbers since you've already got the code running somewhere.

If it doesn't cause increases in file sizes and gets some savings, then it starts to be more likeable.

- First of all, I fail to follow the argument about why this needs to be a
top-level type.  Huh?


Well, the FS draft which you see is actually the third attempt to define
FS as a media type object. Feel free to help out here...

The first, which Ned saw, attempted to define it as a top level type called
FS with subtypes being file systems.

The problem with that iteration of the draft (which was pointed out to me)
would be that implementors would most likely use the type definition to help
decode an object for a specific platform. [You'll have to trust me for a
little while on this statement.]

This would cause a problem since FS should be able to deal with this
internally.  The concept is nothing like gzip which uses a value to tell you
from what file system an object came from.  FS written for a specific
platform will handle this properly.

Fine. All that put together argues that FS is actually a container format itself with multiple objects inside of it, similar to tar or StuffIt. If that's the case, then there is no question it should be a subtype of application: It should be application/fs. There is still no explanation here of why it should be a top-level type. Would there be any reason for it *not* to be a subtype of application?

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.

Right. This would lend itself well to current MIME implementations.

I am open to suggestions -but- I would like backwards compatibility and fs
objects recognized as some form of media type. I believe what you just
stated will not allow this to happen so I must oppose it.

You're correct; I don't think there is any way to get backward compatibility with current FS implementations without either (a) making it an application subtype and forgetting about MIME structure information or (b) changing FS to make it MIME like. That is, either you end up with something that isn't internally MIME, or something that isn't internally FS. I don't see any way out of that.

Like Steve, I like the idea of a MIME multipart/fs, but I don't think Al's proposal gets us near that. FS is just another archive format like tar or StuffIt.

pr
--
Pete Resnick <mailto:presnick@xxxxxxxxxxxx>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478
Fax: (217)337-1980 or (619)651-1102