FEATURES FOR A CAMPUS-WIDE
CALENDARING & SCHEDULING PRODUCT
Prepared by the Electronic Scheduling Advisory Group
University of California, Santa Barbara
============= Updated 10/1/97 =============
Legend:
================================================
F - Filter Feature (only products with this feature will be considered)
1 - Most Desirable Feature
2 - Desirable Feature
3 - Least Desirable Feature
================================================
COMMUNICATIONS
F o Client/server based solution (see glossary).
F o TCP/IP (server to server and client to server).
F o If Email notification is utilized then SMTP must be used for mail
delivery.
1 o Fully functional over a PPP connection (intended for remote access).
2 o System shall efficiently use network resources.
SECURITY
F o Login Authentication.
1 o Encrypted passwords.
1 o User can change his/her password.
2 o Supports DCE (Distributed Computing Environment) authentication
DCE support must be in production or in company's statement of
direction.
2 o Kerberos version 5 compatibility.
2 o Encrypted client/server communication.
OVERALL PRODUCT FEATURES:
2 o Ability to import/export data from/to non-calendaring applications.
3 o Ability to migrate from existing calendaring & scheduling systems.
F o Proxy capable and provides various levels of security for
access/control managed by administrator or user/client.
2 o Ability to schedule events for multiple years.
1 o Ability to perform free or busy time search. Client displays
conflicts and allows meeting invitee to manually reschedule items.
F o Year 2000 compliant.
2 o To-do lists integrated with calendar functions.
2 o Ability to schedule rooms and resources.
3 o Worldwide time zone conversion.
2 o System administrator should be able to create campus information,
and individuals should be able to include these events, notes, or
templates into their own calendars.
3 o Ability to incorporate attachments into meeting invitations.
CLIENT OS
F o Macintosh (system 7.0 and higher).
1 o Windows 3.1.
F o Windows 95.
1 o Windows NT v3.5 or higher.
2 o Web user interface (in production or in company's statement
of direction).
3 o Support of the X protocol.
SERVER OS
The server software runs natively under the following operating systems:
F o UNIX (may include: HP, Solaris, Sun/X.86, Digital Unix, IRIX, AIX).
1 o Novell
F o NT Server either in production or in the company's statement of
direction.
3 o Alpha NT.
SERVER REQUIREMENTS
F o Accommodation for all faculty and staff accounts (10,000) and can be
scaled to support faculty, staff, and student accounts (30,000).
1 o Server to server busy time searches.
3 o Ability to interoperate with other calendaring & scheduling systems.
3 o Ability to perform free or busy time searches across various
calendaring systems.
F o Calendar and access control data stored on the server.
1 o Calendar information may reside on one or more servers, but will be
accessed by users transparently; i.e., users do not need to know on
which server their schedule is stored.
2 o Limits by user ID on server storage space; ability to monitor
amount of storage used by individual users
2 o Currently supports 5% of all accounts making simultaneous server
connections (is there an inherent software limitation to
simultaneous actions?).
1 o Distributed servers (is there a maximum number of servers?).
1 o The vendor should provide a reliable environment. It should be fault
tolerant (e.g., does it provide data replication or is RAID
compliant hardware required?).
2 o Efficient administrative tools for handling large numbers of
accounts (e.g., automated account generation, mass account
terminations, ability to customize tools).
2 o Ability to move calendars from one username to another.
2 o Backups can be performed without disruption of service.
2 o Tools for performance monitoring and system tuning.
3 o Ability to audit administrative tasks, standard connection
patterns, transaction records.
3 o Ability to control which users are connecting to which servers (by
client address or user ID).
3 o Convenient format for user ID (perhaps matching user's Email
address).
2 o Doesn't require a proprietary directory service, i.e., can use
one of the existing or planned campus directory services
(e.g., LDAP, X.500).
2 o The server (not the client) should provide directory data to locate
where a user's calendar data are stored.
1 o Preference shall be given to vendors who are committed to
conforming to calendaring & scheduling open standards.
2 o Reasonable recovery from lost connections, requiring no
intervention on server and minimal work loss on client end.
CLIENT REQUIREMENTS
1 o After a client meets vendor's minimum hardware requirement, the
application shall be robust (i.e., should not crash a normally
configured computer) and responsive.
2 o Ability to download authorized data for local manipulation and
subsequent upload to server for data synchronization.
2 o Client software supports full functionality via low-speed IP
connection.
3 o Ability to archive data for easy retrieval.
1 o Meeting initiator can send an invitation for a meeting regardless of
invitees prior commitments (free or busy time search first not
required).
1 o Ability to view schedules for day, week, month, and selected day
sequences.
1 o Ability to accept, view, and manage multiple events scheduled for
the same time.
1 o Schedule, move, and cancel recurring meetings (weekly, bi-weekly,
monthly, quarterly, etc.).
1 o Automatic conflict detection (after a conflict is detected, the
system automatically presents the user with a list of
non-conflicting times and displays individual conflicts).
2 o Option to notify meeting initiator automatically when user cancels
attendance.
1 o Ability to identify groups and view their schedules.
1 o Ability to print calendars with different format customization.
3 o Report customization (data extracted from prior or future meetings,
(e.g., how many meetings have been held in the past six months with
person x ?).
1 o Ability to provide notification of proposed or scheduled meetings
via audible alarm, e-mail, or other reminder.
1 o Intuitive user interface with on-line help access.
2 o Ability for meeting initiator or meeting invitee to notify
non-invitees of meeting information.
2 o Ability to invite or notify non-calendaring & scheduling users of
meetings.
1 o Upon receipt of an invitation, again upon acceptance of meeting,
and upon cancellation of a meeting by meeting initiator, user
calendars are automatically updated.
3 o Configuration supports multiple users in a public access
environment.
3 o Spelling checker.
LICENSING AND SUPPORT
1 o Simple, campus-wide licensing; easy distribution of (and upgrades
to) software with minimal reporting required (no per-system or
per-user registration).
2 o Technical resources and documentation to allow support staff
to better understand, customize, or extend the system (source
code or application programming interfaces [API]).
1 o Scalability of technical support contacts and distribution media
related to number of servers and clients.
Glossary
Client/Server:
Client/Server based solution - a process running on the client and an
associated process running on the server system which does not require
that the client establish a remote file system mount on the server.
The client and server are communicating via some access protocol
instead of a file sharing access protocol (e.g., NFS, Appleshare).
Our objective here is to maximize efficient communication between the
the client and server and to minimize system demand on the client,
server and the network between them.
Please send any questions about the display of the above
information to webcontact@ucsbuxa.ucsb.edu
Last Modified By: JAS, 10/06/97