Re: (not an) RFC: mailbox format

Thread View: comp.mail.misc

4 messages

[T] Back to Threads [V] Tree View [G] Group Articles

4 total messages Started by Mark Crispin Sun, 24 Jan 1993 06:24

#3865

Author: Mark Crispin
Date: Sun, 24 Jan 1993 06:24

38 lines
2473 bytes

The problem with the AT&T/SUN half-assed Content-Length: mbox format
is that it is half-assed.  The *only* advantages of mbox format are:
 1) being able to edit the mailbox with an external text editor
 2) being able to port the mailbox to a system with a different file
    representation (e.g. record-based files, or different newline
    conventions) difficulty.
AT&T/SUN mbox format has destroyed these advantages for very little
gain.

AT&T/SUN format requires a combinination of two delimiter searches and
a count parse/skip.  Because it is done in the originating UA, a
plethora of failure modes are introduced.  Their scheme can't work
unless absolutely every agent in the path is a Unix machine running
their software.

Even more damning, there are other existing and well-understood
formats which offer greater gain at no additional cost.  One is left
with the feeling that AT&T/SUN hired a bunch of kids out of high
school who lacked any real understanding of the issues.

The MIME archives are filled with discussions on how binary data is
represented in mail.  It seems that AT&T/SUN have paid no attention to
this at all.

Perhaps there is a good reason why they ignored cross-platform
interoperability.  If their e-mail infrastructure won't work in a
multi-vendor environment, then you have no choice but to buy all your
equipment from them.

If you are going to go to a count-based format, you might as well use
tenex (mail.txt) format which does it right.  The tenex format has a
number of other advantages over mbox format, including the ability to
use random access I/O to update status (it reserves space for status
flags).

Personally, I've come to believe that a directory-folder (with each
message occupying a single file) format such as mh is probably the
overall best compromise.

Re: (not an) RFC: mailbox format

#3875

Author: John Stanley
Date: Mon, 25 Jan 1993 14:39

16 lines
1215 bytes

In article <MS-C.727914241.1103527590.mrc@Ikkoku-Kan.Panda.COM> mrc@Ikkoku-Kan.Panda.COM (Mark Crispin) writes:
>The MIME archives are filled with discussions on how binary data is
>represented in mail.  It seems that AT&T/SUN have paid no attention to
>this at all.

Since you bring it up . . .

Is there any good reason why MIME chose to go with its own version of
binary encoding instead of using UUENCODE?

While there are some systems that can't pass UUENCODEd data (converting
one ASCII character to something else, as I recall), UUENCODE IS almost
universally available, while MIME is not. 

It is rather counterproductive to require a user to know that the
recipient's mailer is MIME compatible before sending a binary.

Re: (not an) RFC: mailbox format

#3876

Author: Christopher Davis
Date: Mon, 25 Jan 1993 16:25

34 lines
2277 bytes

JS> == John Stanley <stanley@ruby.OCE.ORST.EDU>

 JS> Is there any good reason why MIME chose to go with its own version of
 JS> binary encoding instead of using UUENCODE?

Yes.

 JS> While there are some systems that can't pass UUENCODEd data
 JS> (converting one ASCII character to something else, as I recall),
 JS> UUENCODE IS almost universally available, while MIME is not.

The systems in question (including EBCDIC-ASCII conversion tables and the
like) *break* uu*code.

To quote from RFC1341:
            NOTE:  This subset has the important  property  that  it  is
            represented   identically   in  all  versions  of  ISO  646,
            including US ASCII, and all characters  in  the  subset  are
            also  represented  identically  in  all  versions of EBCDIC.
            Other popular encodings, such as the encoding  used  by  the
            UUENCODE  utility  and the base85 encoding specified as part
            of Level 2 PostScript, do not share  these  properties,  and
            thus  do  not  fulfill the portability requirements a binary
            transport encoding for mail must meet.

 JS> It is rather counterproductive to require a user to know that the
 JS> recipient's mailer is MIME compatible before sending a binary.

At the moment, this is true.  However, since source for base64 encoders
(and decoders, of course) has been made available, we will hopefully start
seeing them on more and more operating systems (and even a program loader
or two :).
--
 * Christopher Davis * <ckd@eff.org> * <ckd@kei.com> * [CKD1] * MIME * RIPEM *

Re: (not an) RFC: mailbox format

#3879

Author: Marc VanHeyningen
Date: Mon, 25 Jan 1993 16:54

14 lines
1178 bytes

Thus said stanley@ruby.OCE.ORST.EDU (John Stanley):
>Is there any good reason why MIME chose to go with its own version of
>binary encoding instead of using UUENCODE?
>
>While there are some systems that can't pass UUENCODEd data (converting
>one ASCII character to something else, as I recall), UUENCODE IS almost
>universally available, while MIME is not. 

This is exactly why.  It doesn't do much good for the recipient to
have uudecode available if the data was munged somewhere along the
way.  By the way, MIME didn't invent base64 encoding out of thin air,
but borrowed it from the PEM RFCs.

Followups set to comp.mail.mime.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads