home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / vmsnet / networks / tcpip / multinet / 2770 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  3.3 KB
  1. Path: sparky!uunet!usc!news.service.uci.edu!unogate!mvb.saic.com!info-multinet
  2. From: NED@SIGURD.INNOSOFT.COM (Ned Freed)
  3. Newsgroups: vmsnet.networks.tcp-ip.multinet
  4. Subject: RE: mail problem
  5. Message-ID: <01GTY2RNGRHU8Y4WV9@SIGURD.INNOSOFT.COM>
  6. Date: Mon, 25 Jan 1993 18:44:05 -0700 (PDT)
  7. Organization: Info-Multinet<==>Vmsnet.Networks.Tcp-Ip.Multinet Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 56
  10.  
  11. > The point of such notification messages has never been clear to me.  After
  12. > all, even if I know that my message is queued for delivery somewhere in the
  13. > Australian Outback, there's not a whole lot I can do about it.  So, why
  14. > waste time and resources sending a message with essentially useless
  15. > information?  If the host is reachable, your message will be delivered.  If
  16. > it's not, what's the point of the notification?
  17.  
  18. Counterexamples taken from real-world cases and uses of email and FAX:
  19.  
  20. (1) Notes about reservations on planes, trains, reunions, dates, etc. It helps
  21.     a lot to know when one of these is delayed beyond a reasonable amount of
  22.     time.
  23.  
  24. (2) Stock quotes -- they aren't applicable if delayed.
  25.  
  26. (3) Weather reports and predictions.
  27.  
  28. Now, you can make a case for not sending this sort of stuff via email, and you
  29. can make a case for using explicit expiration dates instead of nondelivery
  30. notifications, but the fact remains that people do use email for this sort of
  31. stuff and rightly or wrongly they depend on temporary nondelivery notifications
  32. to tell them when things are messed up. You may not use mail this way, I may
  33. not use mail this way, but believe me there are lots of people who do, and
  34. they're probably the majority.
  35.  
  36. > (Things are even worse when ill-formed or mishandled headers cause a
  37. > gateway to send the "not sent yet, still trying" messages to a mailing list
  38. > for redistribution, but never mind that for now.)
  39.  
  40. Different problem; completely solvable, but a different problem nevertheless.
  41.  
  42. > The question is related to another old favorite, "How can I be notified
  43. > that my message has been read?"  The answer is, you can't.  At the very
  44. > most, you can be notified that the destination MUA has done something (but
  45. > you can't be sure what) with the message.
  46.  
  47. I'm not sure how this relates in any way to the topic at hand. A delay in
  48. delivery is a delay in delivery; in most cases an agent knows for sure whether
  49. or not it was able to discharge its responsibility for the message. The various
  50. protocols we use for mail are designed to make sure it is possible to do this
  51. cleanly (not as cleanly as I'd like -- there's a case to be made for two-phase
  52. commit mechanisms in mail, but overall we're less concerned about duplication
  53. than with loss). But read-receipts depend on some sort of computer-human
  54. protocol. To put it mildly, these are not subject to standardization (!) and
  55. therefore are always totally unreliable.
  56.  
  57. The only thing that's unreliable about nondelivery notices is the inconsistency
  58. of their generation. However, users adapt amazingly quickly to the nature of
  59. the systems they use, so they usually take these differences in stride.
  60.  
  61. A read-receipt is, at best, a notice that the recipient claims to have read the
  62. message. A temporary nondelivery notice is a fairly confident assertion that a
  63. message has been delayed. They both have problems, but the nature of their
  64. problems are completely different.
  65.  
  66.                 Ned
  67.