home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / mail / misc / 4488 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  2.4 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!uwm.edu!ogicse!news.u.washington.edu!news.u.washington.edu!news
  2. From: mrc@Ikkoku-Kan.Panda.COM (Mark Crispin)
  3. Newsgroups: comp.mail.misc
  4. Subject: Re: (not an) RFC: mailbox format
  5. Message-ID: <MS-C.727914241.1103527590.mrc@Ikkoku-Kan.Panda.COM>
  6. Date: 24 Jan 93 06:24:01 GMT
  7. Article-I.D.: Ikkoku-K.MS-C.727914241.1103527590.mrc
  8. Organization: University of Washington
  9. Lines: 38
  10. NNTP-Posting-Host: ikkoku-kan.panda.com
  11. To: "Ronald S. Karr" <tron@Veritas.COM>
  12. In-Reply-To: <1993Jan24.075759.4771@Veritas.COM>
  13. MIME-Version: 1.0
  14. Content-Type: TEXT/PLAIN; charset=US-ASCII
  15.  
  16. The problem with the AT&T/SUN half-assed Content-Length: mbox format
  17. is that it is half-assed.  The *only* advantages of mbox format are:
  18.  1) being able to edit the mailbox with an external text editor
  19.  2) being able to port the mailbox to a system with a different file
  20.     representation (e.g. record-based files, or different newline
  21.     conventions) difficulty.
  22. AT&T/SUN mbox format has destroyed these advantages for very little
  23. gain.
  24.  
  25. AT&T/SUN format requires a combinination of two delimiter searches and
  26. a count parse/skip.  Because it is done in the originating UA, a
  27. plethora of failure modes are introduced.  Their scheme can't work
  28. unless absolutely every agent in the path is a Unix machine running
  29. their software.
  30.  
  31. Even more damning, there are other existing and well-understood
  32. formats which offer greater gain at no additional cost.  One is left
  33. with the feeling that AT&T/SUN hired a bunch of kids out of high
  34. school who lacked any real understanding of the issues.
  35.  
  36. The MIME archives are filled with discussions on how binary data is
  37. represented in mail.  It seems that AT&T/SUN have paid no attention to
  38. this at all.
  39.  
  40. Perhaps there is a good reason why they ignored cross-platform
  41. interoperability.  If their e-mail infrastructure won't work in a
  42. multi-vendor environment, then you have no choice but to buy all your
  43. equipment from them.
  44.  
  45. If you are going to go to a count-based format, you might as well use
  46. tenex (mail.txt) format which does it right.  The tenex format has a
  47. number of other advantages over mbox format, including the ability to
  48. use random access I/O to update status (it reserves space for status
  49. flags).
  50.  
  51. Personally, I've come to believe that a directory-folder (with each
  52. message occupying a single file) format such as mh is probably the
  53. overall best compromise.
  54.