home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / bit / listserv / cwemail / 98 < prev    next >
Encoding:
Text File  |  1992-08-22  |  10.2 KB  |  232 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!CMUVM.CSV.CMICH.EDU!34AAQ77
  3. Organization: Central Michigan University
  4. Message-ID: <920821.120104.EDT.34AAQ77@CMUVM.CSV.CMICH.EDU>
  5. Newsgroups: bit.listserv.cw-email
  6. Date:         Fri, 21 Aug 1992 12:01:04 EDT
  7. Sender:       Campus-Wide Electronic Mail Systems discussion list
  8.               <CW-EMAIL@TECMTYVM.BITNET>
  9. From:         David Jelinek <34AAQ77@CMUVM.CSV.CMICH.EDU>
  10. Subject:      E-mail and calendaring recommendations
  11. Lines: 219
  12.  
  13. We are currently running PROFS with PUMP for our administrative staff
  14. and RICEMAIL for our students (All under VM of course). We are on both
  15. BITNET and the INTERNET (and intend to stay on both). Since we will have
  16. to move to VM/ESA from VM/SP HPO, we know that PROFS will not be
  17. supported in this environment. We would like to find a system which will
  18. provide more capabilities than we currently have. The following is a
  19. memo from our Director of Computer Services describing what he would like.
  20.  
  21. I disagree with him about moving the mail services to a network server.
  22. I think that would be too painful a move. I would like to see users on
  23. our network be able to access their mail transparently and never even
  24. know (unless they wanted to) that it was maintained on the VM/CMS
  25. system.
  26.  
  27. Does anyone have any good suggestions? Thanks in advance.
  28.  
  29. David Jelinek                   BITNET:   34AAQ77@CMUVM
  30. Systems Programmer
  31. Central Michigan University     INTERNET: 34AAQ77@cmuvm.csv.cmich.edu
  32. NAD & Tech Rep for CMU
  33.  
  34. ------------------------------ email txt -------------------------------
  35. Date:     21 August, 1992
  36. To:       Dave Jelinek
  37.           Systems Programmer / Staff Specialist
  38.  
  39. From:     Jim Dening
  40.           Director of Computer Services
  41.  
  42. Subject:  Electronic Mail and Calendaring
  43.  
  44. As we discussed, I have been assembling some comments about
  45. electronic mail and calendaring.  I will provide some general
  46. comments, and then get into specifics about notes and calendaring.
  47.  
  48.                          *_GENERAL COMMENTS*_
  49.  
  50. - I believe we need to include Officevision in our deliberations,
  51.   if only as a basis for comparison to other systems.  If
  52.   Officevision is the best choice, the University will have to
  53.   consider it seriously even though it carries an additional cost.
  54.  
  55. - Conceptually, I would like to see electronic mail and
  56.   calendaring removed from the 3090 and placed on a server
  57.   attached to our campus network.  The 3090 clients would access
  58.   this server for mail and calendaring just as VAX, SUN, and other
  59.   campus users would access it.  I don't know if we can achieve
  60.   this, but I think we should consider it and either recommend it
  61.   or reject it based on some sort of cost-benefit analysis.  Of
  62.   course, this server could also be a commercial network, such as
  63.   IBM Information Network or mci:MAIL, but we would have to
  64.   consider the amount of traffic to and from the server and the
  65.   line speed required to handle it as well as validation problems
  66.   in this approach as well.
  67.  
  68. - The "home-grown" PROFS continuation with MAILBOOK and PUMP seems
  69.   attractive from a cost standpoint, but my enthusiasm wanes a bit
  70.   when I think about the continued maintenance requirements.  I
  71.   believe I would place either of the approaches above ahead of
  72.   this one in order of preference.  I realize though, that this
  73.   approach might be the one that would offer us the most
  74.   continuity and the smallest retraining and implementation
  75.   expense.
  76.  
  77. - The replacement system chosen should allow people not validated
  78.   on the IBM-3090 as MVS or VM users to still send and receive
  79.   mail and maintain calendars.  A SUN user, for example, should be
  80.   able to use the mail and calendar server without becoming a VM,
  81.   MVS-CICS, or MVS-TSO user.  In other words, the person using
  82.   electronic mail and calendaring might have to be associated with
  83.   the University, but not necessarily be 3090-literate-and-
  84.   validated.
  85.  
  86. - The PROFS directory we now are using seems to have been
  87.   improved.  I am able to do the searches I like in what seems to
  88.   me a natural and user-friendly fashion.
  89.  
  90. - All users -- IRMA, 3174-AEA, 3708, 7171, Ethernet, Token-Ring,
  91.   or otherwise, need to be able to print notes, print calendars,
  92.   and download/upload files easily and quickly.  This has not
  93.   always been the case, particularly for IRMA users not co-located
  94.   with a  System Printer .
  95.  
  96. - Automatic Reminders are not very important to me. If we include
  97.   them in the new system, though, they should be part and parcel
  98.   of the basic system -- not a deal where we have to get out of
  99.   PASF into PROFS in order to establish or receive them.
  100.  
  101. - I like the  fast track  options whereby a knowledgeable user can
  102.   skip the menus and go directly to and from particular functions
  103.   rather than using the hierarchical menus in all cases.
  104.  
  105.  
  106.                                *_MAIL*_
  107.  
  108.  
  109. - There should be a shared in-basket capability.  A secretary or
  110.   other designee should be able to review and answer mail without
  111.   logging in  as the supervisor.
  112.  
  113. - The ability to limit length of notes and length of distribution
  114.   lists should exist.
  115.  
  116. - The ability to imbed sound, graphics, and animation in a note or
  117.   calendar should exist.
  118.  
  119. - Encryption and decryption should be available for confidential
  120.   notes.
  121.  
  122. - A directory should exist which includes a usage-sensitive
  123.   designation.  (We have referred to this as an  active user
  124.   designation.)
  125.  
  126. - A  Return To Sender  function should exist for undeliverable
  127.   mail or mail left in a mailbox longer than a specified amount of
  128.   time.
  129.  
  130. - An  Unsubscribe  function should exist whereby a user can remove
  131.   himself from all LISTSERV subscriptions and mailing lists.  This
  132.   would cause an immediate  Return To Sender  for any internal CMU
  133.   mail sent to this user.  The  Return To Sender  would include
  134.   the annotation that the user had requested that his/her mail not
  135.   be delivered.  Naturally, a  Resubscribe  function should also
  136.   be available.  We could also consider the possibility of
  137.   forwarding mail temporarily.
  138.  
  139. - An  approval tree  and  buck slip  capability including
  140.   electronic signature should be available.
  141.  
  142. - The mail system should have conversion filters to allow
  143.   uploading and downloading of word processing documents including
  144.   graphics, sound, and animation.  Currently, we lose too many
  145.   attributes converting word processing files to ASCII.
  146.  
  147. - We should be able to EASILY staple multiple notes together from
  148.   note logs under a new cover note to provide a new reader
  149.   background on a given topic.
  150.  
  151. - The acknowledgment provided when mail is opened should actually
  152.   indicate that the individual note was opened, by whom, and at
  153.   what time.
  154.  
  155. - The Originator or his designee should be able to withdraw mail
  156.   sent in error up to the point where it is opened by the
  157.   recipient.
  158.  
  159. - The ability to handle Internet addresses should be basic to the
  160.   system -- we should not be limited to eight-character node and
  161.   eight-character user names.  We should be able to send and
  162.   receive to full personal names, like
  163.   "Jim.Dening@cmuvm.csv.cmich.edu".
  164.  
  165. - The ability to share in the construction of a single document,
  166.   note, or outline should exist.  I might ask three people to put
  167.   together an implementation plan.  They might then break up the
  168.   work and all work on portions of a common document that they
  169.   should all be able to see simultaneously.
  170.  
  171.  
  172.                              *_CALENDARS*_
  173.  
  174. - Different core hour time blocks should be accommodated --
  175.   Facilities Management works on an 07:30 - 16:00 schedule for the
  176.   day shift.  We work 08:00 - 17:00 in the winter and 07:30 -
  177.   16:30 in the summer, and so on.  The system should allow each
  178.   Division, at least, to specify its core hours available for
  179.   appointment scheduling.
  180.  
  181. - The Originator and all recipients of a Meeting Notice should be
  182.   able to review a system-maintained roster of the meeting, to
  183.   which documents associated with the meeting might also be
  184.   attached.  The roster would indicate who had been invited,
  185.   whether each potential attendee had opened his/her Meeting
  186.   Notice, and whether he/she had agreed to attend by placing it on
  187.   her/his calendar, or said,  No, I cannot attend.   The Recipient
  188.   should be able to change her/his mind later by adding or
  189.   removing the meeting from her/his calendar. In this case the
  190.   roster will be updated.  The Originator should be able to change
  191.   the time of the meeting, in which case the original meeting time
  192.   would be removed from each Recipient's calendar and a new
  193.   properly-annotated Meeting Notice would be sent to each
  194.   recipient indicating the original meeting had been canceled and
  195.   a new Roster should be established.  The Originator should also
  196.   be able to cancel a meeting with similar results, except that
  197.   the new  Meeting Notice  would actually be a  Cancellation
  198.   Notice .
  199.  
  200. - I like the way PROFS handles meeting scheduling, except that it
  201.   lacks the capability described above.  There should be, however,
  202.   a way for a person to designate someone else as the Originator.
  203.   For example, I might ask my secretary to set up a meeting for me
  204.   that she would not attend.  In this case, I should be designated
  205.   as the Originator.
  206.  
  207. - We should be able to remove, as well as establish, repetitive
  208.   meetings.
  209.  
  210. - A mechanism should exist to load a faculty member's schedule
  211.   into his/her calendar.
  212.  
  213. - Meeting time increments should be smaller than 15 minutes.  We
  214.   should be able to schedule a block of time down to the minute
  215.   level.  I should be able to check calendars for a meeting that
  216.   starts at 08:23 and goes for three minutes, for example.
  217.  
  218. - Retention and projection of calendars should be individually
  219.   adjustable.  Each user should be able to override the system
  220.   default.  I might want to keep one year forward and two years back
  221.   from today's date, for example.
  222.  
  223. These are my initial thoughts on the subject.  I've probably
  224. overlooked some import points, but at least I am hopeful this
  225. document will serve as some initial specifications for our search.
  226. By copy of this memo, I am asking that others receiving copies
  227. share with you and me any views they have on the subject.  We need
  228. to resolve this so we can get the replacement VM-ESA Guest
  229. Operating System installed by December 1993, since PROFS is not
  230. supported under VM-ESA.
  231. --------------------------- End of email txt ---------------------------
  232.