Organization: Central Michigan University
Newsgroups: bit.listserv.cw-email
Date:         Fri, 21 Aug 1992 12:01:04 EDT
              <CW-EMAIL@TECMTYVM.BITNET>
From:         David Jelinek <34AAQ77@CMUVM.CSV.CMICH.EDU>
Subject:      E-mail and calendaring recommendations

We are currently running PROFS with PUMP for our administrative staff
and RICEMAIL for our students (All under VM of course). We are on both
BITNET and the INTERNET (and intend to stay on both). Since we will have
to move to VM/ESA from VM/SP HPO, we know that PROFS will not be
supported in this environment. We would like to find a system which will
provide more capabilities than we currently have. The following is a
memo from our Director of Computer Services describing what he would like.

I disagree with him about moving the mail services to a network server.
I think that would be too painful a move. I would like to see users on
our network be able to access their mail transparently and never even
know (unless they wanted to) that it was maintained on the VM/CMS
system.

Does anyone have any good suggestions? Thanks in advance.

David Jelinek                   BITNET:   34AAQ77@CMUVM
Systems Programmer
Central Michigan University     INTERNET: 34AAQ77@cmuvm.csv.cmich.edu
NAD & Tech Rep for CMU

------------------------------ email txt -------------------------------
Date:     21 August, 1992
To:       Dave Jelinek
          Systems Programmer / Staff Specialist

From:     Jim Dening
          Director of Computer Services

Subject:  Electronic Mail and Calendaring

As we discussed, I have been assembling some comments about
electronic mail and calendaring.  I will provide some general
comments, and then get into specifics about notes and calendaring.

                         *_GENERAL COMMENTS*_

- I believe we need to include Officevision in our deliberations,
  if only as a basis for comparison to other systems.  If
  Officevision is the best choice, the University will have to
  consider it seriously even though it carries an additional cost.

- Conceptually, I would like to see electronic mail and
  calendaring removed from the 3090 and placed on a server
  attached to our campus network.  The 3090 clients would access
  this server for mail and calendaring just as VAX, SUN, and other
  campus users would access it.  I don't know if we can achieve
  this, but I think we should consider it and either recommend it
  or reject it based on some sort of cost-benefit analysis.  Of
  course, this server could also be a commercial network, such as
  IBM Information Network or mci:MAIL, but we would have to
  consider the amount of traffic to and from the server and the
  line speed required to handle it as well as validation problems
  in this approach as well.

- The "home-grown" PROFS continuation with MAILBOOK and PUMP seems
  attractive from a cost standpoint, but my enthusiasm wanes a bit
  when I think about the continued maintenance requirements.  I
  believe I would place either of the approaches above ahead of
  this one in order of preference.  I realize though, that this
  approach might be the one that would offer us the most
  continuity and the smallest retraining and implementation
  expense.

- The replacement system chosen should allow people not validated
  on the IBM-3090 as MVS or VM users to still send and receive
  mail and maintain calendars.  A SUN user, for example, should be
  able to use the mail and calendar server without becoming a VM,
  MVS-CICS, or MVS-TSO user.  In other words, the person using
  electronic mail and calendaring might have to be associated with
  the University, but not necessarily be 3090-literate-and-
  validated.

- The PROFS directory we now are using seems to have been
  improved.  I am able to do the searches I like in what seems to
  me a natural and user-friendly fashion.

- All users -- IRMA, 3174-AEA, 3708, 7171, Ethernet, Token-Ring,
  or otherwise, need to be able to print notes, print calendars,
  and download/upload files easily and quickly.  This has not
  always been the case, particularly for IRMA users not co-located
  with a  System Printer .

- Automatic Reminders are not very important to me. If we include
  them in the new system, though, they should be part and parcel
  of the basic system -- not a deal where we have to get out of
  PASF into PROFS in order to establish or receive them.

- I like the  fast track  options whereby a knowledgeable user can
  skip the menus and go directly to and from particular functions
  rather than using the hierarchical menus in all cases.


                               *_MAIL*_


- There should be a shared in-basket capability.  A secretary or
  other designee should be able to review and answer mail without
  logging in  as the supervisor.

- The ability to limit length of notes and length of distribution
  lists should exist.

- The ability to imbed sound, graphics, and animation in a note or
  calendar should exist.

- Encryption and decryption should be available for confidential
  notes.

- A directory should exist which includes a usage-sensitive
  designation.  (We have referred to this as an  active user
  designation.)

- A  Return To Sender  function should exist for undeliverable
  mail or mail left in a mailbox longer than a specified amount of
  time.

- An  Unsubscribe  function should exist whereby a user can remove
  himself from all LISTSERV subscriptions and mailing lists.  This
  would cause an immediate  Return To Sender  for any internal CMU
  mail sent to this user.  The  Return To Sender  would include
  the annotation that the user had requested that his/her mail not
  be delivered.  Naturally, a  Resubscribe  function should also
  be available.  We could also consider the possibility of
  forwarding mail temporarily.

- An  approval tree  and  buck slip  capability including
  electronic signature should be available.

- The mail system should have conversion filters to allow
  uploading and downloading of word processing documents including
  graphics, sound, and animation.  Currently, we lose too many
  attributes converting word processing files to ASCII.

- We should be able to EASILY staple multiple notes together from
  note logs under a new cover note to provide a new reader
  background on a given topic.

- The acknowledgment provided when mail is opened should actually
  indicate that the individual note was opened, by whom, and at
  what time.

- The Originator or his designee should be able to withdraw mail
  sent in error up to the point where it is opened by the
  recipient.

- The ability to handle Internet addresses should be basic to the
  system -- we should not be limited to eight-character node and
  eight-character user names.  We should be able to send and
  receive to full personal names, like
  "Jim.Dening@cmuvm.csv.cmich.edu".

- The ability to share in the construction of a single document,
  note, or outline should exist.  I might ask three people to put
  together an implementation plan.  They might then break up the
  work and all work on portions of a common document that they
  should all be able to see simultaneously.


                             *_CALENDARS*_

- Different core hour time blocks should be accommodated --
  Facilities Management works on an 07:30 - 16:00 schedule for the
  day shift.  We work 08:00 - 17:00 in the winter and 07:30 -
  16:30 in the summer, and so on.  The system should allow each
  Division, at least, to specify its core hours available for
  appointment scheduling.

- The Originator and all recipients of a Meeting Notice should be
  able to review a system-maintained roster of the meeting, to
  which documents associated with the meeting might also be
  attached.  The roster would indicate who had been invited,
  whether each potential attendee had opened his/her Meeting
  Notice, and whether he/she had agreed to attend by placing it on
  her/his calendar, or said,  No, I cannot attend.   The Recipient
  should be able to change her/his mind later by adding or
  removing the meeting from her/his calendar. In this case the
  roster will be updated.  The Originator should be able to change
  the time of the meeting, in which case the original meeting time
  would be removed from each Recipient's calendar and a new
  properly-annotated Meeting Notice would be sent to each
  recipient indicating the original meeting had been canceled and
  a new Roster should be established.  The Originator should also
  be able to cancel a meeting with similar results, except that
  the new  Meeting Notice  would actually be a  Cancellation
  Notice .

- I like the way PROFS handles meeting scheduling, except that it
  lacks the capability described above.  There should be, however,
  a way for a person to designate someone else as the Originator.
  For example, I might ask my secretary to set up a meeting for me
  that she would not attend.  In this case, I should be designated
  as the Originator.

- We should be able to remove, as well as establish, repetitive
  meetings.

- A mechanism should exist to load a faculty member's schedule
  into his/her calendar.

- Meeting time increments should be smaller than 15 minutes.  We
  should be able to schedule a block of time down to the minute
  level.  I should be able to check calendars for a meeting that
  starts at 08:23 and goes for three minutes, for example.

- Retention and projection of calendars should be individually
  adjustable.  Each user should be able to override the system
  default.  I might want to keep one year forward and two years back
  from today's date, for example.

These are my initial thoughts on the subject.  I've probably
overlooked some import points, but at least I am hopeful this
document will serve as some initial specifications for our search.
By copy of this memo, I am asking that others receiving copies
share with you and me any views they have on the subject.  We need
to resolve this so we can get the replacement VM-ESA Guest
Operating System installed by December 1993, since PROFS is not
supported under VM-ESA.
--------------------------- End of email txt ---------------------------
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU