home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / networks / tcpip / multinet / 1842 < prev    next >
Encoding:
Text File  |  1992-07-30  |  2.9 KB  |  61 lines

  1. X-Gateway-Source-Info: INTERNET
  2. Path: sparky!uunet!usc!elroy.jpl.nasa.gov!ames!network.ucsd.edu!mvb.saic.com!tgv.com!info-multinet
  3. Date: 30 JUL 92 15:06:49 GMT
  4. Newsgroups: vmsnet.networks.tcp-ip.multinet
  5. X-Return-path: <info-multinet-relay@TGV.COM>
  6. X-RFC822-From: Ned Freed <NED@INNOSOFT.COM>
  7. From: Ned Freed <NED@INNOSOFT.COM>
  8. Subject: Re: RFC 1339 support: Remote Mail Checking Protocol.
  9. X-VMS-To: IN%"skapur@ccmail.sunysb.edu"
  10. X-VMS-Cc: IN%"info-multinet@tgv.com"
  11. Organization: The INFO-MULTINET Community
  12. Message-ID: <238063CF30JUL92150649@TGV.COM>
  13. Nntp-Posting-Host: Mvb.Saic.Com
  14. Lines: 45
  15.  
  16. > Most users are more interested in the presence or absence of new mail and for 
  17. > them a simple check of the VMSMAIL profile should be good enough.  The time 
  18. > stamps are more or less optional and I do not see any way of implementing them 
  19. > in VMS.  The section "Server Implementation Notes" in RFC 1339 provides for a 
  20. > way of not implementing time stamps.
  21.  
  22. Sorry, in my opinion the notion of a simple check of the information in the
  23. profile file is a nonstarter. The idea behind this protocol is to see if any
  24. new mail messages have arrived _since you last checked in and read your mail_.
  25. The only information in the profile file is whether or not there are any
  26. messages you haven't read. This is a very different beast.
  27.  
  28. > A client makes a request and sends the username.  The server asks for the 
  29. > password (unless the ipaddress/port/maildrop triple is stored) and checks 
  30. > the SYSUAF for password and existence of account.  If the account does 
  31. > not exist, zeros are sent back.  If the account exists, the VMSMAIL profile is 
  32. > checked for new mail.  If new mail exists or the number of records in the 
  33. > user's MAIL.MAI is more than one, an appropriate response is send back for New 
  34. > mail or Old Mail.
  35.  
  36. My count of new mail messages hasn't been zero even once in the past five
  37. years. In my experience most users who get mail even intermittently have
  38. nonzero mail counts.
  39.  
  40. Another problem is that certain kinds of delivery to VMS MAIL don't increment
  41. the new mail count. So it is possible for mail to arrive without the the
  42. profile file knowing about it.
  43.  
  44. This protocol is very carefully specified to avoid use of unread message counts
  45. and instead uses time stamps to obtain its information. I cannot help but think
  46. that there are good reasons for this (I've mentioned a bunch of the ones that
  47. apply on VMS), and that an implementation that uses message counts to obtain
  48. its results is violating the intent of the protocol.
  49.  
  50. > The current POP protocol has too much overhead which includes a process 
  51. > creation and much more work on the part of the server.
  52.  
  53. No argument. I think this protocol is a good idea. However, I think that
  54. without some meaningful support in both the delivery and user agents there is
  55. no way to return useful information from VMS systems. Please note that I don't
  56. think this is necessarily an impossible thing to do; it just requires some
  57. coordinated development work.
  58.  
  59.                 Ned
  60. 
  61.