This message contains updated requirements and meeting notes.  Please note
our upcoming meeting schedule:
 
Wed. Jan. 19 1:30 in 2 Hughes, SoftSwitch presentation
Wed. Jan. 26 1:30 in Hoyt conference room, IMAP/POP team presents
Wed. Feb. 2 1:30 in Hoyt, Joe to present Microsoft solution.
 
Anyone receiving this message, and other interested people, are invited to
attend any of our meetings.  Contact Debi Allison or John Harlan with
questions or comments.
 
Miami University Electronic Mail Meeting
held 29 November 1993 ; updated for 15 December 1993 meeting.
 
Present:  Chris Allison, Debra Allison, Sarah Baker, Kent Covert,
               John Harlan, Steve Moore, Peter Murray, Joe Simpson,
                Steve Thole
 
 -->  indicates additions/changes
 
Terms:  IMAP -- Interim Mail Access Protocol;  client/server;  all mail
                          resides on server but can be retrieved by client
from
                          desktop or remote locations (via dial-in or
Internet
                          connection)
             POP --  Post Office Protocol;  client/server;  all mail is
                          downloaded from server to desktop, where it is
stored
                          and manipulated; can only be retrieved from desktop
                          (or via fancy connection to desktop via AppleTalk
                          Remote Access or similar software for other
operating
                          systems?)
 
Required / Desired Features & Functionality
  [E denotes enterprise-wide applicability;  C denotes client]
 
E     1.  Interoperability, standards-based (currently SMTP)
            - clients need to interoperate with enclosures
 
E      2.  Server stores mail and address lists
 
E      3.  Ability to forward (i.e., redirect) mail automatically (i.e.,
             the enterprise server is capable of redirecting e-mail to the
             user's desired client)
             - presently possible with Pegasus Mail but not Microsoft Mail
 
E      4.  Ability to read e-mail from anywhere:
             - desktop
             - dial-in from remote location (home, while traveling, etc)
             - Internet connection (ditto)
 
E      5.  Universal directory service, including:
             -  easy way to look up addresses
             -  distribution lists on server to free up desktop / client
                 resources
             -  ability to build own distribution lists
             -  ability to activate / deactivate a directory address, at
                 the request of a user
-->         - Directory synchronization, so that someone added to a
departmental/divisional server automatically appears in the university
directory.
 
E+C   6.  'Rich enclosure' capability
             -  easy to use
             - MIME compliant
 
             [Note:  SoftSwitch, which converts/translates document
               from sender's preferred application format to recipient's
               preferred application format]
 
  C    7.  Common platform support;  not --> (necessarily) a single solution,
but multiple solutions which support all client targets, including:
               -  Macintosh
               -  Windows & Windows/NT
               -  DOS
               -  OpenVMS
               -  VM/CMS
               -  UNIX
               -  OS/2
--> We should not have multiple solutions per platform; fewest possible
products and vendors to contend with, even at the cost of some bells and
whistles.
 
  C    8.  Notified mail (i.e., desktop notification of mail arrival)
             [Desired:  choice to "disturb recipient" or "do not disturb
             recipient"]
 
E      9.  Scalability (the ability to handle up to 20,000-30,000
               potential users)
 
E     10.  Account administration / management (and ease thereof):
              -  batch capability for adding and deleting users
 
       11.  Ability to request acknowledgement that message has been
                read
 
       12.  Ability to print hardcopy of unread messages and send to
                recipient (i.e., for persons who have not activated their
                e-mail accounts)
-->   13.  Efficiency (in terms of delivery) and cost for hardware/software,
implementation and maintenance.
 
-->    14.  Strategy for dealing with student mail.
                Concerns:
                - account administration; roving students; transient nature.
                -  student services needed: distribution of class lists.
                -  Students don't have a single point of entry.
                -  Training
                -  What will students not be able to do that faculty/ staff
can?  What will differentiate faculty/staff services from student services?
                -  Requirement for ability to send students' projects to
faculty.
In general:  -  want tighest possible coupling between e-mail directory
                      service and mail client software
                  -  ability to make environment look the same in office or
                      at home (i.e., through use of AppleTalk Remote Access
                      type software)
 
Client (desktop) Issues:  -  sequential routing with branches to allow
                                           parallel processing
                                       -  mail filtering rules (services
available in
                                           the client environment that are
not
                                           available on the enterprise level)
                                       -  acknowledgement generated when
message
                                           is received and/or read
                                       -  shared calendaring
 -->                                 -   Ease of use at the desktop
 
Next steps:  -  flesh out and refine these requirements, and meet again
                   -  one group to examine client solutions as measured
                       against enterprise solutions
                   -  another group to examine enterprise services
 
Parting thought:  'Mail is an action I can perform on anything on my
                            desktop'
 
-->  Notes from 12/15/93 meeting:
 
- SoftSwitch for MVS, VM and UNIX - X.400 store and forward system.
Directory services - keep data base in sync on each email server.  Can handle
large address databases.  Provides document conversion and preserves
formatting.  Doesn't store email on the server (no IMAP capability).  Unique
features: document translation; gives enterprise-wide directory services to
each of our mail packages.  Can cooperate with POP and IMAP.
 
--> Results from 12/15/93 meeting:
 
Sub-groups will research and present various options to the entire group.
 
1.  IMAP/POP - Post Office centrally for university with IMAP and POP clients
where possible, and mail forwarding to VMS and other places where not
possible to have clients.  Issue: add POP later?  Just look at IMAP for now.
PHQUE for directory serviceds and any good UNIX mail forwarder?
 
Layers:  IMAP as central server; PMail Server; VM mail server; MS Mail
server; desktop.
 
IMAP/POP Team: Peter Murray, Kent Covert, John Harlan.  Will present this
option at our Wed. January 26 meeting at 1:30 in Hoyt.
 
2.  Microsoft solution or a pure P-Mail solution: Joe Simpson to present at
our Feb. 2 meeting at 1:30 in Hoyt.  He will try to get Doug Brennan and
Microsoft tech person to attend.
 
3.  SoftSwitch Team: Steve Moore.  He will have SoftSwitch rep come to our
Wed. Jan. 19 meeting at 1:30 in 2 Hughes.
 
4.  X.400 and X.500 Solutions:  We need to designate someone to research
this.  Steve will send out latest FAQ on X.400.
 
This committee will come up with a recommendation to present to the
Microcomputer Committee, Kris Froehlke,  and the Policy Committee (?) as
deemed by Kris.