Hello Steve,
Thanks for the comments...
I don't find a lot to like in either proposal.
Compression:
- Most really big data types have integral compression (sound, video,
images, etc) and applying another compression algorithm to them is
pointless or harmful.
+I disagree, LZJU90 in most cases compresses objects further and is never
harmful.
- Even when you can get compression (such as with text), I'm unconvinced it
buys you much. There's so much low-layer compression going on. I would
like to see numbers indicating a solid benefit from application layer
compression in email, a benefit worth the deployment penalty.
++ I have given you source code crunch all the numbers you want :-)
but seriously, LZJU90 has pretty good compression, I (we) have compared it
to binary objects that were encoded in other formats. LZJU90 does a better
job than most.
Keep in mind compression was NOT the major goal of LZJU90.....
++ The compression we were interested in was to prevent an object from
becomming much larger than the file system's objects initial size. LZJU90
achieves this goal and more. It is also quite fast. If the program was
written for a specific platform you would see a speed increase and somehat
better compression.
Remember the example in the draft has been written for clarity and
portability not speed and the best compression possible.
++ Although mentioned in one of the drafts, it may be worthwile for me to
mention that both LZJU90 & FS were designed to work with any mailer that was
able to support the UTF-8 character set and complied with RFC-822.
I will mention more about this later...
FILE/FS:
- 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.
Now the MIME spec says a top level type needs a subtype, since there is now
no subtype
Instead of complaining about the type/subtype requirement, I reworded the
section to read FILE/FS (for now)
Please remeber this is only the first public viewing of the FS draft...
- 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?
You could take an FS media object, open it up in MS WordPad or some other
text editor, 'select all' and then paste the object into a mail message on a
mail program that is RFC 822 compliant (that knows utf-8) and send it on its
way.... If the receiver had a
stand alone FS encoder/decoder they could just feed the object in and the
object would be successfully decoded... If an FS object was split between
parts with MIME control elements in between elements, the FS object would
not be interoperalble with none MIME mailers. Why care? I explain elsewhere
in this email.
- The draft makes an assertion that using file/fs will promote
interoperability between platforms. However, all the data typing,
canonicalization rules, etc, that we now do with MIME are not used.
There are a number of issues here. First and foremost I would like to see
both
LZJU90 and FS on standards track and in the MIME spec.
Please bear in mind that these protocols are currently in use, I am not sure
how widespread.
In my mind, allowing backward interoperability with existing users and
allowing MIME
to use it are important to me.
You must consider that no matter what position I take on this issue, someone
will surely complain to me about my position and about me to others (I feel
loved :-).
MIME diehards will say forget the non-MIME compliant mailers, use the new
robust MIME feature set(s) that MIME has to offer. [you]
While non-MIMEer's will tell me that I'm abadoning them for the MIME world
and leaving them in the cold.
Those that implemented RFC 1505 will ask if they wasted their implementing
RFC 1505 which we the authors of 1505 saw as a lightweight alternative to
MIME.
The answers:
Since FS and LZJU90 are able to function on any mail system that support the
utf-8 char set and RFC 822 , the two drafts were written to allow possible
inter-operability.
This interoperability might not be the slickest, a little cut and paste but
it will work.
So I have elected to select a path that would hopefully not aggrevate
everyone, my success remains to be seen :-)
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.
Your assement is correct on how FS is to work is correct. It does work
though.
I will need to look at the VMS portion again and will rely on help from the
community...
- 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
mention above. I'd be interested to see what Ned has to say regarding VMS
here.) Perhaps specific problems of current filesystems could be coped
with by adding to this draft, but it seems to me that for future growth
we'd wind up needing to reinvent a lot of the registry and standards
process we already have, for use inside this thing.
- Perhaps this is just a first-draft problem, but there are various minor
strangenesses. Section 4.6 seems to forbid using message/partial to
transport file/fs objects; why?
+Answer: nteroperabilty with stand alone FS encoders/decoders and other
mailers.
4.7 mandates that applications use CD:
attachment; why?
+Answer:
I'm not an expert MIME users. The MIME mailer I use is MS Outlook Express.
I have noticed that when CD is set to attachment, it allows the user a
choice of saving the object to disk or to open the object.
A user may want to store an FS object without decoding it or may want to
decode it immediately, this setting seemed to perform this funtionality...
Correct me if I'm wrong.
This is the was FS object should be handled.
4.3 mandates using ".fs" on the end of filenames; why?
Answer:
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?
It seems to me that the proposal throws away lots of good work that's been
done with MIME.
+Answer:
I hope not! This was not my intent at all!!! and I don't see what makes you
think this.
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 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.
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 ....
-Al