home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / mail / mime / 116 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.2 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!sgiblab!nec-gw!nec-tyo!wnoc-tyo-news!hoffman!jmasgw!green!samrat!erik
  2. From: erik@poel.juice.or.jp (Erik M. van der Poel)
  3. Newsgroups: comp.mail.mime
  4. Subject: Re: Using MIME without extra mail headers
  5. Message-ID: <C0r35G.9zC@poel.juice.or.jp>
  6. Date: 12 Jan 93 16:58:28 GMT
  7. Organization: sometimes
  8. Lines: 63
  9.  
  10. In the following, I defend a point of view that I'm not sure I hold
  11. myself, simply for fun.
  12.  
  13.  
  14. > > This is a gross hack but it would be of practical benefit to those 
  15. > > people who are in the same position as Alasdair.
  16. > 
  17. > No, it will not be of benefit to such people, at least not in the long
  18. > term.  Such a kludge would do two things:
  19. > 
  20. > 1) Remove the incentive to get the broken gateways fixed.  Once
  21. > established, such an "interim" convention would never go away.
  22.  
  23. A convention that never goes away?  Hmmm...  Sounds like a solid
  24. standard to me...
  25.  
  26.  
  27. > 2) Encourage people to generate messages of this form.  Such messages
  28. > are not in MIME format and will not be interpreted by many correct
  29. > MIME implementations.
  30.  
  31. I'm not sure if the story went exactly like this, but:  A while ago,
  32. the author of the "make" tool wrote the first version of his program
  33. and distributed it among a few colleagues.  It turned out that he had
  34. made the unfortunate choice of requiring a tab at the beginning of a
  35. line containing the "action" part of the rule.  Some programmers found
  36. this confusing when spaces were rejected by the program.  However, the
  37. author discovered that he had as many as 7 users, so he refrained from
  38. changing the spec.
  39.  
  40. Look where that got us today.  (I should add, though, that "make" was
  41. a great accomplishment and I use it a lot, like it, etc.)
  42.  
  43. Now, the fully anticipated reply to this is that there are too many
  44. MIME programs out there _and_ being used already, and that it is
  45. easier to change the "small" number of installations of programs that
  46. violate the set-in-stone MIME spec.  (Though it's still in the
  47. "Proposed Draft" stage.)
  48.  
  49. Easier?  Easier for whom?  Exactly how many such "broken" and
  50. unupgradable systems are there out there?  How do we know which is
  51. easier to upgrade: the "broken" gateways, or the relatively new
  52. MIME implementations?  It's mostly just a matter of convincing people.
  53.  
  54. Alasdair, if you feel strongly about this, I suggest you keep pushing,
  55. perhaps even on the MIME mailing list (to join, send mail to
  56. ietf-822-request@dimacs.rutgers.edu).  If people still don't agree
  57. with you, you can still give it a shot anyway, and get the people that
  58. _do_ agree with you to install programs following your spec.  If it is
  59. successful, you have created a de facto standard.  That's the way it
  60. works.
  61.  
  62. By the way, I think you have pointed out an actual flaw in the MIME
  63. spec (though it has been pointed out before).  I mean, it's a clear
  64. contradiction: Base64 was designed to be transmissible through any
  65. system, but the headers identifying it as such were _not_ designed to
  66. be transmissible.  (I have actually experienced header stripping in a
  67. mailing list server.  I.e. a program that I cannot control directly.)
  68.  
  69. Disclaimer: I do not represent "juice".  The above are my opinions only.
  70. -
  71. -- 
  72. Erik M. van der Poel                               erik@poel.juice.or.jp
  73.