home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / mime / 112 < prev    next >
Encoding:
Text File  |  1993-01-12  |  2.7 KB  |  68 lines
  1. Newsgroups: comp.mail.mime
  2. Path: sparky!uunet!eco.twg.com!twg.com!news
  3. From: "David Herron" <david@twg.com>
  4. Subject: Re: Using MIME without extra mail headers
  5. Message-ID: <1993Jan12.190354.19406@twg.com>
  6. Sensitivity: Personal
  7. Encoding:  48 TEXT , 4 TEXT 
  8. Sender: news@twg.com (USENET News System)
  9. Conversion: Prohibited
  10. Organization: The Wollongong Group, Inc., Palo Alto, CA
  11. Conversion-With-Loss: Prohibited
  12. Date: Tue, 12 Jan 1993 19:09:10 GMT
  13. Lines: 53
  14.  
  15. kosta@blues.kk.sub.org (Kosta Kostis) == >
  16.  
  17. > The MIME-headers should be in the headers only.
  18.  
  19. Well, they aren't.  There's an earlier RFC for multi-bodypart called
  20. RFC-1154.  It used a single line in the header to describe the bodyparts.
  21. It has many problems:
  22.  
  23. - Obviousness.  To a recipient who doesn't have an 1154-aware UA it isn't
  24.   obvious that there are many bodyparts in the message.  All the information
  25.   is stuck up in the header which most people don't look at.
  26.  
  27.   Since MIME scatters headers among the body parts it is much more
  28.   obvious where they are.
  29.  
  30. - Lack of expressive power.  There isn't a lot of room to put a good and
  31.   adequate description of the content.  In fact 1154's only description
  32.   is a line count and one or two words.  A more powerful syntax for
  33.   describing content (on a single header line) is possible, at the cost
  34.   of a more complex parser.  It would be very hard to achieve the same
  35.   descriptive ability which MIME has.
  36.  
  37. - Reliance on line counts.  Line counts have been known to change due to
  38.   software bugs mostly.  At one time I installed something in the ukma 
  39.   news system to compare actual line counts against the ones claimed
  40.   in the header.. it was amazing how often it was different.
  41.  
  42. > Well, "my ideal" MTA would only analyse the headers of a message
  43. > needed for routing (if at all), transfer everything without changing
  44. > any bit (except adding "Received"-lines perhaps) and forward the
  45. > message to next next MTA on the way to the receipient.
  46.  
  47. > It's the MUA's job to interpret the content of the message, only,
  48. > but the MUA must know about the encoding used and stuff like that.
  49.  
  50. My what a rosy picture...
  51.  
  52. First, as you noted in the next paragraph RFC-821 insists in chopping
  53. off a bit.  This certainly requires analyzing the content.
  54.  
  55. Second MTAs frequently act as a UA and do UAish things.  Three examples:
  56.  
  57. - Mailing lists.
  58. - Gateways to foreign mail systems or FAX or printers.
  59. - List/information servers.
  60.  
  61. In all three cases the entity which does the work lives within
  62. the MTA.  All three must analyze the content to some extent.
  63.  
  64. <- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
  65. <-
  66. <- "That's our advantage at Microsoft; we set the standards and we can change them."
  67. <- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.
  68.