To members of the Miami Email project team:
We need to get together to finish up our recommendations with respect to
electronic messaging at Miami. In light of the request from the MCIS senior
staff to John Harlan, reproduced below, we need to reconvene to make a
recommendation on workstation email services to be included in the network
services plan. Our goal is to produce a list of recommended services that
can be recommended to the Network Services planning group identified below.
Linda Rose will be contacting you to set up a meeting.
As a refresher, I have attached the April 24 version of our email
recommendations.
If you have questions or comments in the meantime, please let me know.
Thanks,
Debi
***********************
Text of memo to John Harlan:
***********************
As we have discussed, the MCIS senior staff has assigned you to serve as the
chair for a network services group, with the charge of drafting a network
services plan to accompany the Data and Video Network Plan.
The services plan should outline what services are recommended to be made
available via a network connection, with an indication of the infrastructure
and staffing requirements to support these services. The needs of the
regional campuses and students not residing in Miami residence halls should
be included.
Please consider, insofar as possible, the implications of a student laptop
initiative on these services. As an example, Gartner Group recommends that a
single network communication session should cause several activities to
occur, some unbeknownst to the client (e.g., backup of the client's hard
disk, upload/download of email, transparent software updates).
The MCIS Senior Staff requests the following people to be assigned to assist
with the draft of the services plan:
John Kinne
Peter Murray
Bill Sylvester
John Vaughn
I have spoken with each of them and they have agreed to assist with this
project. It is anticipated that this group will need to meet with various
other individuals as part of the plan's development.
Please target January 6, 1995 as the date for presentation to the senior
staff on Monday, January 9.
[end of memo]
<<<<<< Attached TEXT file follows >>>>>>
This version of the Email project recommendations includes comments and
recommendations added by Barbara Edwards, and includes answers to her
questions/concerns that I have received to date. I am circulating this
version in advance of the July 8 deadline to assist you with further comments
you may wish to add.
Next steps: We need to develop a task list of items to be accomplished, with
responsible person listed and timeframes listed. The resulting
recommendations will be presented to the Microcomputer Committee and then to
Kris Froehlke.
Email Project - Recommendations
March 28, 1994
April 13, 1994: Barbara Edwards comments added
June 28, 1994: responses to Barb's concerns/questions added.
Subgroup members: Debra Allison, Kent Covert, Barb Edwards, John Harlan,
Peter Murray, Rob Pickering
A. Recommendations - Qi server/Ph client; Mail Redirection
1. Qi and In-bound Mail Redirection: up in test this summer; in production
before Fall 1994 on Rose and/or VMS (Technical Services to decide, in
consultation with Client Services (John Harlan) and Instructional Computing
(Barb Edwards)).
2. University Directory Survey: (a) ask for preferred email address on form
requesting directory updates; (b) include Library question [what does this
mean?] or statement on email notices. John Harlan to contact Publications to
get this included.
Barb's comments: Have we requested that a system be built to maintain the Qi
directory?
a. Is there a process being defined for taking the information off the directory
update forms and updating the Qi server? Answer: No, we will be using the
appropriate university databases for student, faculty and staff data.
b. Are we defining a process for coordination between updates of hard copy
and availability of softcopy updates? Answer: There will be periodic updates
from the university databases - typially, one week, but during parts of the
year as often as once per day. This will be scheduled as a production job
with MCIS Customer Services.
c. Are we defining procedures for coordination of the installation of
undergraduate accounts and the updating of the Qi server. Answer: as soon
as undergraduate accounts show up on the mainframe, they will be put in the
Qi server. This will happen daily, coming from the user lists.
d. Will the e-mail addressed be part of the paper directory? Answer: No;
Publications is unwilling to do this due to the additional cost.
e. What is the procedure for documentation and updating of such? Answer: We
will have MCIS documentation for the process. Client instructions will
appear in this fall's directory.
f. What about "unlisted numbers"? Answer: The data going into the Qi
directory is the data that the faculty, student or staff authorizes to appear
in the directory. Anyone who tells the Registrar or Personnel that they do
not want to be listed in the directory will not appear in the Qi server. We
can also remove someone from the Qi directory.
3. Kerberos: Investigate using Kerberos authentication as university-wide
security scheme. Goal: a university-wide security scheme in place by Summer
1995 (we recommend Kerberos). Steve Moore to look at Kerberos on VM.
Barb's concern:
There are several issues with regards security left over from old
discussions. Has John Andrea been involved? Answer: Discussions have been
held, but more work is needed. A security audit needs to be done on Rose.
Currently, no confidential data is being stored on Rose; it is stored on
secure systems.
4. Passwords in Qi database (to allow modifications to data elements in Qi
database): we recommend that the database be (a) modifiable and (b)
authenticated (to be determined by Client Services, Technical Services,
Security, in consultation with Internal Auditing). This is a long-term
recommendation, tied to Kerberos implmentation.
5. Queries to the Qi databaseto be provided via:
a. Gopher and Web (Fall 1994)
b. Ph client (Fall 1994 in test, but unsupported - at Level 3+)
c. Mail packages - ASAP; tied to selection of mail packages.
Barb's concern: Will all this be added to enduser on VM? Will there be DCL
and Scripts written for VMS and UNIX for the clients to use? Is technical
services exploring this issue? Answer: Queries can be made from Miami Root,
which is accessible from the new EndUser. We will be asking Steve Moore
about giving direct access from EndUser. The Ph/Qi package provides for
queries on VMS and UNI.
6. Alias structure in Qi data base recommended to be:
a. unique
b. eight characters
c. same as university-wide account ID (Tim and Barb have different
recommendations on this -- Tim: 1st 6 characters of last name, first initial,
middle initial (to permit sorting by last name); Barb: first initial, middle
initial, 1st 6 characters of last name (to correspond to exisiting IDs).
We recommend that the Qi alias be: first initial, middle initial, 1st 6
characters of last name, except in the case of a duplicate where a digit is
needed to distinguish, e.g.
RAPICKER
RAPICKE1
RAPICK10
RAPIC100
What will "from" address show to the world? Does it have to be the alias,
or do we want it to be? John Harlan to check with Notre Dame, since their
"from" addresses are "friendlier."
Rob to check if Qi and Kerberos ID name limitations are 8 characters; he
will also try to find out about X.500.
We recommend Mail.Name@domain for use by sender when email address is
unknown. Example: [log in to unmask], [log in to unmask],
[log in to unmask] will all cause the message to be sent to Peter E.
Murray's preferred email address. If P.Murray is used and there is more than
one match, information on all matches will be returned to the sender as
bounced mail and sender will choose based upon info in Qi database.
Barb's comments: Please add as a recommendation:
There will be a record in the directory entry that identifies the real
person by full name and Miami Id number (currently social security number is
used). This comment should be consistent with the personnel record or the
student master file record. Answer: The personal data comes from the
Student Master file and the Personnel data base. Neither Miami ID number nor
Social Security number are displayed.
For ids not associated with a single person there will be a person
identified for that mail box and that person will be recorded in the comment
card. Answer: This needs to be part of the account generation policy and
process as it cannot be done within Qi.
This comment and the userid should be in a file or database that is
regularly updated and easily accessed by system management.
We recommend that the lowest character count be used as mail identifiers.
---end Barb's comments for #6---
7. Long-term direction: Our stated long-term direction is to replace the Qi
server with an X.500 server. Qi evolves nicely into X.500 (Ph client can
query X.500 server; Qi server database can be ported to X.500).
Barb's comment for #7:
Please add to the recommendation:
X.500 is a stated goal and will be re-evaluated in 3 years as the technology
evolves. Answer: We intend to be reevaluating this continuously.
IMAP/POP Recommendations
1. Recommendation: Pine (IMAP) as a replacement for Microsoft Mail and
Pegasus Mail,with Eudora (Qualcomm?) as a POP alternative where desirable or
required. Pine is the client of choice where available and where the client
wishes to sign on and read mail from any station. Eudora is recommended when
a Pine client is not available or when a client has a primary need to use a
laptop to which s/he wishes to download mail. Pine has clients available for
VMS, UNIX and DOS. The Windows client is due 3Q94; the Macintosh client is
due 4Q94 or 1Q95.
Justification:
Barb's comments for #1:
Concern: This recommends IMAP as a replacement for Microsoft Mail and
Pegasus Mail. What about Open-VMS and VM mail? Answer: We have a Pine
client up and running on Open VMS; we are checking whether there is a Pine
implementation on VM. Currently there are significant numbers of mail
users on VM and VMS. Please be aware- CPPO has requested VM accounts for at
least sophmores and juniors and maybe first year students by January, 1995
and will continue their request for all seniors for August, 1994.
---end comment---
Timeframe: IMAP - test group of 100 faculty/staff/students July-Dec. 1994.
Hope to have Qi server available at start of test.
Test participants require:
a. Reliable (added by Barb) Network connection to desktop, or at a lab for
students (LTCs or divisional labs)
b. IMAP/POP-accessible account on one host (Technical Services to decide
whether ROSE or OCEAN, in consultation with Client Services (John Harlan) and
Instructional Computing (Barb Edwards)).
c. Start with core test group and ask them who they email (workgroup
commonality); then include them.
Barb's comment:
Start with a small test group that is computer as well as e-mail literate.
Expand this test to workgroups of the initial group.
d. We want a variety of clients (MS Mail, PMail, new users (Bill Slover?);
high-volume users).
e. IMAP/POP software (1/2 using public domain client; 1/2 using commerical
client). Debi and Kent to solicit vendors for evaluation/test copies.
f. Way to re-route mail to new address for MS Mail, etc. since test
participants won't want to tell the email world that they have a new address.
We need:
a. Solicit eval client software from vendors
b. Ask for volunteers. Do they want IMAP or POP client?
c. Documentation for test participants on all platforms
Barb's comments:
Criteria for IMAP or POP selection
Software installation procedures
Directions on how to use software
Directions on how to update records in central databases
d. Help Desk involvement in the test (preferably including interaction by
e-mail via Target->Hotline, so that we can test the software with Hotline)
e. Involvement from Instructional Computing, Networking, Technical Services,
Client Services (including Help Desk).
Barb's comments:
Please add these recommendations:
f. Procedures for installing mail boxes for users.
g. Licensing and distribution issues to be part of the evaluation process
h. Training and documentation for support staff in areas where tests will
be conducted.
---end comment---
C. Critical Success Factors - How will we know we've succeeded, and what
factors are most likely to determine whether we're successful?
1. Client Services says installation/maintenance concerns are easier with
this set of solutions.
Barb's comments:
Please add these Factors.
a. Ease of use to include
How quickly the software installed
Clients ability to update records
Ability to determine another persons address
Ability to inform someone else of users address
---end of comment
2. Mail gets delivered reliably (probably the #1 CSF)
3. Survey of client satisfaction.
a. Ease of use?
b. perception of reliability
c. perception of usefulness
d. comparison with old sysem
e. would client continue to use/recommend this solution?
4. During test, check with clients. Are they still using the new solution,
or did they revert to their previous product?
5. System benchmarks - performance monitoring, server sizing.
6. Total cost/scalable cost comparison (added functionality, freed
resources?)
Barb's comments:
6. Please add this to the evaluation:
(... ,installation of volumes of mail boxes, distribution of software and
collection of fees)
Calendaring/Scheduling
Our project began due to a request from Sarah Baker for
calendaring/scheduling recommendations. We began investigating available
software, but it quickly became apparent that Miami does not have the
infrastructure to support university-wide calendaring/scheduling. We then
backed up and began to address the infrastructure issues, and the above
recommendations are the result.
Calendaring/scheduling software has not yet evolved to where there is a
product to meet our needs. We identified the following needs:
1. Scalability to 21,000 clients, on multiple platforms and multiple
networks.
2. Ability to chose that an individual's unavailable time can be shown
without displaying to others the purpose.
3. Selective ability to give a secretary access to the manager's detailed
schedule.
4. Meeting not scheduled until invited people confirm their attendance.
Confirmation of the meeting to be sent following all confirmations.
5. Ability to schedule conference rooms, and equipmenet, with ability to
restrict authority for scheduling these resources to the responsible people.
6. Ability to print daily, weekly, monthly schedules for use by the
individual and the secretary. Preference given to software that provides a
variety of format choices.
7. Ability to designate who may access an individual's calendar. (or restrict
who may access it?)
8. Ability to schedule recurring meetings -- weekly, monthly, first/last work
day of the month, first and third Tuesdays, etc. for one year beyond the
current date.
9. Requirement that messaging services be an integral part of desktop
applications. Must span applications, platform, network environment.
|
