home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / networks / tcpip / multinet / 1836 < prev    next >
Encoding:
Internet Message Format  |  1992-07-29  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!swrinde!sdd.hp.com!usc!noiro.acs.uci.edu!unogate!mvb.saic.com!tgv.com!info-multinet
  2. From: NED@SIGURD.INNOSOFT.COM (Ned Freed )
  3. Newsgroups: vmsnet.networks.tcp-ip.multinet
  4. Subject: Re: RFC 1339 support: Remote Mail Checking Protocol.
  5. Message-ID: <23805F4E30JUL92030200@TGV.COM>
  6. Date: 30 Jul 92 03:02:00 GMT
  7. Organization: The INFO-MULTINET Community
  8. Lines: 30
  9. X-Gateway-Source-Info: INTERNET
  10. X-Return-path: <info-multinet-relay@TGV.COM>
  11. X-RFC822-From: "Ned Freed (Postmaster)" <NED@SIGURD.INNOSOFT.COM>
  12. X-Envelope-to: info-multinet@tgv.com
  13. X-VMS-To: IN%"skapur@ccmail.sunysb.edu"
  14. X-VMS-Cc: IN%"info-multinet@tgv.com"
  15. Nntp-Posting-Host: Mvb.Saic.Com
  16.  
  17. The problem with RFC1339 is that it is very difficult to implement correctly
  18. on VMS. The protocol returns two pieces of information to the caller -- the
  19. time when a given user last read a mail message and the time when that
  20. user last received mail.
  21.  
  22. On VMS using VMS MAIL both of these numbers are very hard to come by.
  23. Consider the problem of finding out when mail was last read. I know of
  24. no way to do this. The revision time on the user's MAIL.MAI file is no
  25. help, since it is updated by deliveries and in any case is not updated
  26. until you exit from VMS MAIL! (Some users, such as myself, stay in VMS MAIL
  27. for weeks or even months at a time. And the revision date gets changed
  28. to whatever time you exited regardless of when you last read a message.)
  29.  
  30. The last delivery time is also a problem. Again, the file revision date
  31. is not a useful source of this information. About the only thing that
  32. could know when delivery was last done is the delivery agent itself. I suppose
  33. we could all get together and support a common place for putting this
  34. information. Of course, local mail would not update this information since
  35. it only passes through VMS MAIL itself.
  36.  
  37. There's a limited version of the protocol that is slightly more implementable
  38. in the VMS environment, but not overly so.
  39.  
  40. If you can come up with a reasonable way to deal with these issues in the
  41. VMS environment I'd love to hear about it. I had serious thoughts about
  42. implementing this protocol in PMDF until I started to consider how the
  43. actual implementation would have to be done.
  44.  
  45.                 Ned
  46.  
  47.