Communications Protocol:
Return to Index
TCP/IP is a requirement at MIT.
See 'Transport Mechanism' in
A Glossary of Calendaring and Scheduling Terms
Multiplatform Servers:
Return to Index
Solaris support is an operational requirement for an institute wide
system.
SunOS and HPUX support are also desired.
Multiplatform Clients:
Return to Index
For a C&S product to be considered a possible solution,
it would need to provide Clients for the following platforms:
UNIX - Solaris and IRIX are requirements for use in the Athena environment.
The following versions of Unix are also widely used at MIT:
HPUX, SunOS, Linux and NetBSD (SCO support will meet this need.),
Ultrix, AIX, and OSF/1 support are also desired.
MacOS 7.0x or above - on 68K and PowerPC hardware
Windows3.x
Windows95
OS/2
System Exits:
Return to Index
To allow local system level customization, 'Exit' points should be provided in
both the Server and Client code. Included here would be ability to execute
AppleScripts, UNIX shell commands etc. on the Client side.
An example of where exit points should be provided would be:
Initialization, Authentication, Notification, e-mail, access level processing,
Directory Access (People Database).
Adequate Security:
Return to Index
To accommodate authentication and verification, Client code needs to be
Kerberos compliant or provide an Exit point for local customization.
Proxy Capable:
Return to Index
Grants another person access to your calendar.
Needed by people who have an assistant/secretary/coordinator tracking their appointments.
Proxy will require the use of 'Access Controls'.
Users must be able to set security levels of access for other users to their
personal Calendar.
Users must also be able to set privacy levels on calendar entries in their
personal calendar.
See 'Proxy Agents' in
A Glossary of Calendaring and Scheduling Terms
Find Free Time:
Return to Index
Automatically finds a time when all attendees and resources
are available for an event or meeting.
Report Customization:
Return to Index
In addition to standard reports/views, i.e. daily, weekly, monthly etc.
users should be able to create their own
and/or customize the standard ones.
Proactive Notification:
Return to Index
The system should be capable of real time notification of upcoming and imminent events.
Notification to be either visual or sound or both.
Ease of Use:
Return to Index
To make the application more appealing to users and to aid in the acceptance
of and to promote the use of an institute wide C&S application,
the Client interface must be easy to use and intuitive. 'Easy to use' is meant
to mean, a computer literate person should be able to navigate through the
system with little or no training.
The interface should 'lead' the user around the application
and have easy access to a help facility.
Compliance with GUI standards for client platforms:
Return to Index
The user interface should be consistent with the
standards for the operating system being used.
System Management:
Return to Index
The C&S system performance should be manageable. System administrators
should have monitoring tools available to check on the health of the system. i.e.
how well is it performing,
how busy is the system,
how big and how fast is the database growing
(might indicate a projected need to split servers),
discover bottle necks,
query statistics on user usage (how many active user in the last x time period).
Tools to aid in fixing performance problems, should be available.
It should also provide plain
text backup and restore utilities for the back end database, whether
proprietary or not.
The vendor should provide a robust environment, it should be fault tolerant.
(Does it provide data replication or is RAID compliant
hardware required.)
Manual Conflict Resolution:
Return to Index
Client code needs to be able to automatically detect
appointment/schedule conflicts, display the conflicts and
allow the user to manually reschedule items.
E-Mail Support:
Return to Index
The system should have the ability to let non C&S users participate or at
least be notified about meetings and agendas via email. If this capability
is not provided by the server then it is desired that the client be able to
interact via more than one email application. (e.g., Windows applications
may support OLE and or MAPI, Mac clients may support Applescript or OpenDoc,
Unix client may support shell scripts, each providing the ability to send
message through a variety of email applications.) If the product has its own
built in SMTP support then it at least needs to provide some configuration
of the From, X-Sender, and Reply-To fields. Mail originating from
"user@host".mit.edu is not acceptable.
Reasonable License:
Return to Index
The application must not be licensed and administered on a node locked
basis. Our environment is too large and dynamic for MIT to afford this
administrative overhead.
The application should not require connectivity to manage the licenses. A mobile user
must not be required to initiate a PPP connection just to verify the license
if they are using the application in a disconnected mode, using their to-do
list, or just checking the current meeting list.
Restricting the use of the application based on IP address is very bad. It would
preclude users that may work at home and access the MIT network via third
party carriers. It would also preclude the use by some travelers who may be
given connectivity privileges at other sites while visiting or away on
business. It may also preclude the use by MIT members at the Whitehead
Institute, WHOI, LL, and AI Lab.
Import/Export Functionality:
Return to Index
There are operational reasons why we want data import and export features.
If we use a system which requires a proprietary database we wish to be able
to dump the data in ASCII form and reload this into the database. This
serves two purposes. It provides us with the ability to perform some data
validation tests independent of the vendor provided tools. It also
provides us with the ability to migrate to another system if we so choose.
Additionally this ability is required for initial acceptance of a C&S system.
Many users and departments are currently using a diverse set of C&S tools,
a means to migrate these users to the new system is strongly desired.
The ability to easily re-export this data into older systems
is also strongly desired. Some departments may have a need to run parallel
systems for some undefined period of time.
Support for Disconnected or Mobile Users:
Return to Index
If the network is down or a user is going on a business trip and may not be able to connect
from wherever they are going. They need a way to take a copy of their schedule
with them (Export), and be allowed to alter their schedule off-line.
Upon return of the net connectivity or from the trip, the user needs
to be able to upload(Import) their changes to the Server.
TTY Support:
Return to Index
The MIT environment consists of a very diverse set of operating systems and
needs. We do not believe that any one product will possibly be able to
provide native GUI interfaces for all necessary platforms. Strong preference
will be given to vendors which also provide an interface for users limited to
simple TTY or telnet access. We feel this would be an acceptable interface
for current VM and VMS users as well as users that use the present Athena
dialup machines.
Because some users will be accessing the system via PPP links the
application should continue to perform well over a 14.4kbps connection. This
includes native GUI clients as well.
It is understood that TTY versions of the Client may lack some functionality
when compared with GUI Clients.
Extensive Proactive Notification:
Return to Index
User selectable notification methods and order of preference.
The user should be able to choose methods of notification and should
also be able to set a priority for the methods chosen.
See 'Notification' in
A Glossary of Calendaring and Scheduling Terms
Notification via... Real time message window
Real time sound/voice
E-Mail
FAX
Phone call
Set message on Voice Mail/Pager etc.
Resource Scheduling:
Return to Index
Access to an inventory of resources and equipment.
Automatic Conflict Resolution:
Return to Index
A system that could, after detecting a conflict, 'automatically'
present the user with a list of non-conflicting alternatives
would be desirable.
Choice of back-end Database:
Return to Index
Expertise on a number of databases already installed at MIT is currently
available within IS. It would be nice to be able to choose one we already know or
one we might consider to excel in functionality and performance.
Extensive Import/Export:
Return to Index
If the vendors involved are willing to cooperate, Client code could have a utility to
read the users favorite calendar data and upload(Import) it to the C&S Server.
The reverse should also be true.
This would require limiting the support of local calendars to a predetermined list of calendars.
The most popular calendars used by the MIT community would be nice, however
vendor cooperation would be the determining factor.
Contact Database:
Return to Index
Address Book and Directory Services Support would be nice.
Support for XAPIA:
Return to Index
World Wide Web Interface:
Return to Index
A World Wide Web user interface would be nice. Privacy and security issues
are a concern to MIT.
It is mentioned here for completeness.