Previous     Contents     Index          Next     
iPlanet Calendar Server 5.0 Programmer's Reference



Chapter 1   Architecture Overview


iPlanet Calendar Server 5.0 is a powerful and flexible cross-platform solution using open Internet standards that lets service providers of all sizes host personal and group scheduling calendars for their customers.

Topics covered in this chapter are:



What is iPlanet Calendar Server?

iPlanet Calendar Server is a readily deployable, LDAP-based solution that lets the Internet service provider and Telecommunication service provider offer group scheduling features, as well as host personal event calendars, to their base of subscribed customers.

iPlanet Calendar Server 5.0 is a system of servers that can be configured to fit a variety of needs. It can stand in isolation as a stand-alone calendar server, or it can be configured with many instances, having the various services duplicated or split between them as was discussed earlier in this chapter. See Horizontal Scalability. iPlanet Calendar Server 5.0 stores and manages calendars, calendar properties, access control information, events, todos, and alarms. It does not manage storage for user information. The minimal system requires a directory service. It makes use of plug-ins to obtain external services. It uses a directory service to perform operations such as authentication, and storage and retrieval of user preferences. iPlanet Calendar Server ships with plug-ins to perform directory services using LDAP services. You may use your own plug-ins to support non-LDAP directory services.

Figure 1-1 shows a minimal iPlanet Calendar Server (iCS) 5.0 system. It consists of a single iPlanet Calendar Server instance, a directory service, and support for event notifications.

Figure 1-1 Minimal

iPlanet Calendar Server System

Table 1-1 is the key to the abbreviations in Figure 1-1.

Table 1-1 iPlanet Calendar Server System Key to Terms

CLD

 

 Calendar Lookup Database

 
CUA

 

 Calendar User Agent

 
ENS

 

 Event Notification Server

 
iCal

 

 iCalendar-RFC 2445

 

iPlanet Calendar Server is scalable both vertically and horizontally. On a single machine it can run in multiple processors, or it can be split up to run on multiple machines. Figure 1-2 depicts three iPlanet Calendar Server HTTP "front end" services, using three other iPlanet Calendar Server "database" services. All six of these instances can run on separate machines. The abbreviation "dwp" in this figure stands for Database Wire Protocol. For further information on this new protocol and the various configuration possibilities using horizontal scalability, see Horizontal Scalability.

Figure 1-2 Scalable System



Summary of Features

Built from the ground up to provide native support for the emerging set of internet calendar standards, iPlanet Calendar Server 5.0 provides the following benefits:

  • Group Scheduling-Organizers create an event, and invite attendees. Attendees accept or decline invitations. If the attendee is not on the calendar server, the group scheduling engine can send the scheduling message by email as an IMIP message (as described in RFC2447).

  • Internet Calendaring and Scheduling-Native support for iCalendar calendaring standards ensures events are in a format that is easily shared across the internet.

  • Low Cost of Ownership-Native support of LDAP lets a service provider centrally manage its entire customer base in a single user directory and minimizes the costs of administering the server while also providing a platform for extending the enhanced services a provider can offer its customers.

  • Massively Scalable-iPlanet Calendar Server 5.0 is scalable both vertically and horizontally.

    Scaling vertically to the requirements of the largest service providers, it supports a hosting environment of up to several million personal event calendars. It runs on a single machine in multiple processors to take advantage of all the machine's processing power.

    Scaling horizontally, it also splits up to run on several computers in many combinations. For example, there could be three Calendar Server HTTP services utilizing three other Calendar Server database services, each running on a separate machine. For further information on this new feature, see Horizontal Scalability.



What's New in Version 5.0?

iPlanet Calendar Server 5.0 adds several new features:

  • Group scheduling-In addition to keeping personal calendar information, users can now invite other calendar users to meetings who in turn may accept or decline the request. For more details on this new feature, see Group Scheduling.

  • Horizontal scalability-The server can run on a single machine or its processes can be divided across multiple machines with a wide variety of possible configuration options. For more details on this new feature, see Horizontal Scalability.

  • New default client user interface-Calendar Express, the bundled calendar client UI, now uses SHTML which achieves quicker browser rendering and response times as well as faster and easier customization that you can tailor to your site.

  • Migration from iPlanet Calendar Server 2.x-A bundled utility that allows an administrator to import data from an existing iPlanet Calendar Server 2.x installation. The migration process is accomplished by running a separate program after the installation of version 5.0 has been completed successfully. For more details, see the iPlanet Calendar Server Installation Guide.

iPlanet Calendar Server 5.0 builds on the consumer focus of iPlanet Calendar Server 2.x with the introduction of multiple-machine horizontal scalability as the design focus.This new architecture allows group scheduling capabilities using notifications. To implement notifications, iPlanet Calendar Server ships with Event Notification Service (ENS). A key benefit of this architecture is that you may customize many of the components, or even develop your own applications based on your customer's needs.

These new features required fundamental changes in some of the interfaces and tools described in this reference. Additional customization interfaces have been added to this reference. New this time is the Proxy Authentication SDK.

For continuity, you can still use WCAP, which supports all iPlanet Calendar Server 2.x data formats. For further information on WCAP, see Chapter 9 "Web Calendar Access Protocol (WCAP) Overview" and Chapter 10 "WCAP Commands".



Calendar Server Services


The iPlanet Calendar Server 5.0 system consists of several running processes that include multiple calendar server daemons which can run on a single machine or be divided to run on multiple machines. The specific combination of modules for a given running instance are defined in the server configuration information stored in the file ics.conf and can be modified using command line administration tools. The administration design supports a single service on a single machine or multiple services on multiple machines. The administrator can also issue commands remotely from a machine other than where the calendar service is running. Table 1-2 lists the Five iPlanet Calendar Server 5.0 daemons.

Table 1-2 iPlanet Calendar Server Daemons

csadmind  

Administration service. Includes the Group Scheduling Engine (GSE), and monitors for alarms.  

csdwpd  

Interprocess database service.  

cshttpd  

HTTP service. Services SHTML and WCAP requests.  

csnotifyd  

Notification service. This is required in instances where the database resides.  

enpd  

Event Notification Service.  


csadmind

This service provides alarm notifications, group scheduling requests, database checkpointing and deadlock detection, as well as disk usage and server response monitoring.


cshttpd

iPlanet Calendar Server 5.0 uses HTTP as its primary transport. This service listens for HTTP commands and retrieves and returns data to the caller. For the new 5.0 user interface, commands received with the default .shtml extension returns data formatted in HTML. Alternately, for requests received with the .wcap extension, data can be formatted either as raw calendar data in standard RFC2445 iCalendar, XML, or JavaScript embedded in HTML.


csnotifyd

The notification service (csnotifyd) sends calendar-based notifications of events and tasks and utilizes the Event Notification Server (ENS) as the broker for events. It subscribes to alarm events. When an alarm event occurs, it sends an SMTP message reminder to the recipients. For more information, see Event Notification Service (ENS), Chapter 4 "Event Notification Service (ENS) Overview", and Chapter 5 "Event Notification Service API Reference".


csdwpd

This service allows multiple machines within the same system to be linked together to form a distributed calendar store. The service can run in the background on any machine on which iPlanet Calendar Server 5.0 is installed. It acts as a service accepting requests that abide by the Database Wire Protocol (DWP) for calendaring information.

This service should be run only on a server that:

  • Has a local calendar store.

  • Must provide network access to its calendar data from other iPlanet Calendar Server installations.

    Note This should only be done on a fast network. If the pipe (network) between the various databases is slow, it can seriously degrade overall system performance.



enpd

This is the other half of the Event Notification Service. It acts as the broker for event alarms. It receives notifications of alarms from the csadmind daemon, checks for subscriptions to this event, and notifies the event's subscribers by passing the subscribed-to alarm notifications to csnotifyd. It also receives and stores subscriptions and cancellations of subscriptions (unsubscribe) from csnotifyd.


Start Order

The iPlanet Calendar Server 5.0 daemons must be started in a specific order:

  1. enpd-A generic event registration and notification service that can be shared by other iPlanet servers

  2. csnotifyd-Calendar Server Notification Daemon

  3. csadmind-Calendar Server Administration daemon (installation required on every server machine)

  4. csdwpd-Calendar Server DataBase Daemon (only started with remote database configuration)

  5. cshttpd-Calendar Server Daemon (at least one is required)



Group Scheduling

In version 2.x, you could schedule events and todos on your own calendar and share your calendar with others, but with iPlanet Calendar Server 5.0, you may now make scheduling requests for other calendars. You may schedule events and invite attendees and they may accept or decline the request. When an attendee accepts or declines, the server updates the calendars of all attendees, as well as the event organizer. Attendees not in the installation's database are notified by email.


Directory Server Services

By default, iPlanet Calendar Server supports users that are defined and maintained in an LDAP directory, such as Netscape Directory Server. iPlanet Calendar Server also supports the use of CSAPI plug-ins that you create to enable access for users defined in non-LDAP directories, such as those stored in a standard Unix authentication format, or in a Windows NT User Manager database.

If your users are already stored in an LDAP directory, the simplest solution for deploying iPlanet Calendar Server is to upgrade your directory server to Netscape Directory Server 4.12, and iPlanet Calendar Server installation will do the rest. Otherwise, you can modify your directory schema manually to allow your users to access iPlanet Calendar Server data. For more information on how to modify a directory schema for iPlanet Calendar Server, see "Installing and Configuring an LDAP Server" the iPlanet Calendar Server Installation Guide.



Horizontal Scalability


Horizontal scalability may be achieved by spreading an installation over several machines. iPlanet Calendar Server consists of the daemons cshttpd, csadmind, csdwpd, csnotifyd, and enpd. These daemons may be run in different configurations to allow you great flexibility and scalability.

To facilitate horizontal scalability in iPlanet Calendar Server 5.0, the system employs an internal proprietary protocol, Database Wire Protocol (DWP), csdwpd. It was necessary to implement this protocol because the iPlanet Calendar Server 5.0 product uses a default Berkeley DB, which is not a networked database. The DWP protocol uses HTTP as it's base. The implementation is simply an HTTP POST or GET command, with a single binary MIME part that contains serialized binary database information.

In a future release, the calendar database API will be published. It can be implemented using any database technology. DWP will not be needed by any implementation that supports a networked database.


Configurations

To achieve horizontal scalability, you install various instances of iPlanet Calendar Server 5.0 across your machines. The basic requirements for every system are:

  • Each instance must have csadmind.

  • All of the other daemons are required to be installed at least once.

    The exception to this is the case of a single-instance installation using a local database connection. In this simple case, the csdwpd daemon is not necessary.

Table 1-3 indicates three possible configurations and the services you need to install for each instance. The figures that follow the table illustrate these configurations. Other configurations are possible. You must determine what combination addresses your specific needs.

Table 1-3 Instance Configuration of Required Services 

Instances

Required Services

csadmind

cshttpd

csnotifyd

csdwp

enpd

Simple Single Instance installation with a local database. See Figure 1-3 that follows.  

Y  

Y  

Y  

N  

Y  

HTTP Service-only instances. (Used only in conjunction with Database Service-only instances.)

     Examples: See boxes on left side of
     Figure 1-4, Network Front End, Database
     Back End, and Figure 1-5, Multiple Front
     Ends, Multiple Back Ends  

Y  

Y  

N  

N  

N  

Database Service-only instances. (Used only in conjunction with HTTP Service-only instances.)

     Examples: See boxes on right side of
     Figure 1-4, Network Front End, Database
     Back End, and Figure 1-5, Multiple Front
     Ends, Multiple Back Ends  

Y  

N  

Y  

Y  

Y  


Simple Single Instance

This is the simplest configuration in which iPlanet Calendar Server 5.0 can run. As illustrated in Figure 1-3, it consists of cshttpd to handle incoming SHTML and WCAP requests, enpd and csnotifyd for event notification, and the required csadmind. The entire database is local.

Figure 1-3    Simple Single Instance Configuration




Network Front End, Database Back End

In this configuration, illustrated in Figure 1-4, browsers and other clients connect to the calendar server at the HTTP Service front-end, labeled cal.example.com in this example. All requests for calendar data are routed to the Database Service, labeled caldb.example.com in this example. Notice that the front end requires only cshttpd and csadmind since it is not doing any database processing. The back end, conversely, does not need cshttpd, but does require csdwpd, enpd, and csnotifyd.

Figure 1-4    Network Front End, Database Back End


Multiple Front Ends, Multiple Back Ends

In this configuration, illustrated in Figure 1-5, clients are routed to one of the front end HTTP Services by some external mechanism that you provide. Please note that the session ID returned at login is valid only on the host where the login occurred. All requests for this session ID must be routed to the same host or the user will be forced to log in again. In this example, the database has also been split, with calendars A-M on the caldb1.example.com server, and calendars N-Z on the caldb2.example.com server. A CSAPI plug-in handles mapping between calendar IDs and the name of the server on which it can be found. The default CSAPI implementation provided in iPlanet Calendar Server 5.0 uses an algorithm to associate a calendar ID with a server name.

Figure 1-5    Multiple Front Ends, Multiple Back Ends



New Default Client UI: SHTML


iPlanet Calendar Server 5.0 no longer implements the default client UI with the WCAP protocol as it did in version 2.x. The WCAP protocol generated a mixture of HTML and JavaScript, and passed it to the client for processing. Using the new SHTML commands, the server now does all of the processing, and generates and sends only formatted output (HTML) to the client. The new SHTML commands use XML prototype definitions and XSL style-sheet templates to generate HTML. For each view and dialog displayed in the UI, there is one or more corresponding pairs of text files. Each pair consists of one .xml, and one .xsl file. You may alter or replace one or both of these files in order to customize the UI.

If you already have a custom user interface that was developed for version 2.x, you may continue to use it without change. iPlanet Calendar Server 5.0 is fully backward compatible with iPlanet Calendar Server 2.x.

WCAP remains the only way to retrieve unprocessed calendar data. Clients that need raw, unformatted calendar information should submit requests in WCAP format.



Architecture Basics


iPlanet Calendar Server 5.0 is implemented by way of a collection of shared libraries. These shared libraries are bound in various combinations to produce the executable daemons cshttpd, csdwpd, csadmind, and csnotifyd.

The Event Notification Service (ENS) daemon, enpd, is a separately installed service shipped with iPlanet Calendar Server 5.0. For further information on ENS, see Event Notification Service (ENS) in this chapter, Chapter 4, and Chapter 5 of this Reference.

The shared libraries fall into three main categories, called subsystems:

  • Protocol

  • Core

  • Database

Figure 1-6 represents the logical flow through these subsystems. A section follows on each of the subsystems.

Figure 1-6    Server Architecture



SHTML and WCAP

SHTML and WCAP are based on HTTP. Requests enter through the HTTP protocol layer. This is a minimal HTTP server implementation, streamlined to support calendar requests. Clients use either SHTML or WCAP to submit requests. WCAP is an open protocol that can perform all server commands (except for certain administrative commands). It can be used by clients that need raw, unformatted calendar information. It can also be used to obtain a JavaScript based user interface. This user interface was the only one available in iPlanet Calendar Server 2.x, but in version 5.0, it has been replaced with a new SHTML-based user interface. This new approach, based on XML and XSLT specifications, generates a user interface in response to commands. In response to an incoming request, the UI generator uses an XML specification to build a document tree with calendar and user data, subject to access control. The XSLT specification then traverses the document data tree and emits HTML. One of the benefits of this design is that it results in fewer interactions between the client and server and fewer bits being sent overall. Previously, in iPlanet Calendar Server 2.x, the system returned embedded JavaScript, which generated HTML at the client. The XML/XSLT approach generates output that is rendered faster by browsers.

For backward compatibility, the iPlanet Calendar Server 2.x design will continue to work, with WCAP requests returning a combination of HTML text and JavaScript as the default. As in iPlanet Calendar Server 2.x, commands using the .wcap extension may also request output as XML wrapped in HTML, or as iCalendar wrapped in HTML.

For a description of the WCAP protocol, see Chapter 9 "Web Calendar Access Protocol (WCAP) Overview".


Core

Inside the Core subsystem, other divisions include the Access Control subsystem, the UI Generator subsystem (either SHTML, using XML and XSLT, or WCAP, using data translators), and a Caldb Subsystem. CSAPI plug-ins reside in the Core.

The protocol processes the command and sends it to the Core for execution. There are four types of commands:

  • Calendar manipulation-For Calendar manipulations requiring database actions, the protocol sends requests to the Core's Access Control subsystem. The Access Control subsystem uses the generic Caldb subsystem to perform calendar read and write operations.

    The Caldb subsystem uses a database-technology-specific subsystem to perform its operations. For this version of iPlanet Calendar Server with the Berkeley database implementation, this subsystem is capable of dealing with a local database file or making Database Wire Protocol (DWP) requests to the appropriate machine.

    The Database subsystem returns data in a low-level format. The Core UI generator (either SHTML or WCAP) translates the low-level data into the desired output. Commands with the .shtml extension always default to HTML. Commands with the .wcap extension return the output format requested. WCAP remains the only open protocol the server supports. Use it to retrieve unformatted calendar data.

    Note HTML/js, which was the default UI output for iPlanet Calendar Server 2.x, has been deprecated in favor of HTML for iPlanet Calendar Server 5.0.


  • User attributes-Requests for user attributes go to the Core's directory service. iPlanet Calendar Server 5.0 makes use of plug-ins to obtain external services, such as directory services. The product ships with a plug-in for LDAP services. To customize your installation, you can write other plug-ins to support non-LDAP directory services.

  • Authentication-Requests for authentication go to the Core's default LDAP directory service. iPlanet Calendar Server 5.0 ships with three different authentication options:

    An API for customization exists for CSAPI authentication and the Proxy Authentication SDK.

  • Miscellaneous-Requests for miscellaneous services go to other Core subsystems.


Database

iPlanet Calendar Server 5.0 uses the csBerkeley subsystem using the Berkeley DB from Sleepycat. The database API is not public.



Calendar Data


This section describes various aspects of calendar data:


Calendar Data Format

Calendar data format is modeled after the IETF iCalendar standard RFC-2445. The Access Control layer maintains calendars, which are collections of iCalendar components. The components include events, todos, and alarms. A calendar has one primary owner, and may have other owners. User attributes are maintained by an external mechanism. The default mechanism is LDAP.


Groups

Groups are named list of calendars. Users subscribe to calendars. A user can view and modify a subscribed calendar, subject to access control. Additionally, users can create groups. They can then work with groups of calendars, rather than having to re-specify or select a list of calendars every time they wish to view them side-by-side, or invite their owners to an event.

Groups allow multiple calendar sources to be aggregated into a single calendar for display purposes. A user can, for example, have a default calendar view made up of his or her own calendar, the department calendar, the holidays calendar, and the "latest action video releases" calendar, all of which is called a "calendar group".


Event Feeds

This infrastructure makes it possible to feed real-time event data into the database using import formats such as iCalendar or XML. Event data can be fed in from calendars such as the local sports team's season schedule, convention center schedules, concert schedules, or any schedule of events that may be of interest.

iPlanet Calendar Server provides tools for retrieving calendar data from event feeds and from the database, so that users can view and retrieve event information. The user can layer these events onto their own calendar views, providing rich event information that is maintained by third parties.


Calendar Data Exchange

All calendars and events can be referenced as URLs. Users can embed these links in email messages and web pages. Users can click on a link to see a monthly calendar view, a weekly view, a daily view, or a specific event. If the calendars are publicly readable, users will not be asked to log in.

iPlanet Calendar Server supports server-side email alarms, which can be sent to a list of recipients. The format of the email message is completely configurable. It is maintained as a server attribute, rather than as a user or calendar attribute. iPlanet Calendar Server 5.0 has limited support for the ITIP/IMIP standards [RFC-2446, RFC-2447]. It supports ITIP methods PUBLISH, REQUEST, REPLY, and CANCEL for events.


Calendar User Preferences

iPlanet Calendar Server customizes the display of calendaring information for each user according to attributes called user preferences. User preferences, as opposed to calendar preferences, refer to the user interface representation of information. User preferences include such things as email address, user name, and preferred colors to use when rendering calendar information. For a complete list of preferences, see the get_userprefs and set_userprefs command descriptions in Chapter 10 "WCAP Commands".


Calendar Access Control

In iPlanet Calendar Server 5.0, access control is the mechanism that determines who can access a calendar when performing group scheduling. An Access Control Entry (ACE) string specifies the type of access privileges to a calendar that are granted to a user. These strings are stored in the access control calendar property acl (Access Control List) and collectively determine the access control of a calendar. Only users with write access to a calendar's properties can successfully change these strings. By default, only the Calendar Server administrator and the primary owner of a calendar have write access to its properties. The iPlanet Calendar Server access control model also supports the ability to act in behalf of others. For example, with this type of access granted to them, administrative assistants can invite, cancel, and reply to events on behalf of people they support.

Access control is described in more detail in the following sections:


Supported Format Encoding

For data being stored, the Core translates the input into the binary form that Caldb uses. iPlanet Calendar Server supports the following format encodings:

  • HTML (the default)

  • HTML/JavaScript

  • XML

  • iCalendar

You can add other formats by developing your own XSL translations for the UI views and dialogs, or, using CSAPI, you can develop a translator DLL or shared library for the WCAP protocol. (See Chapter 2 "Calendar Server API (CSAPI) Overview".)



Calendar Server API (CSAPI)


CSAPI is a COM-like interface that allows programmers to implement customized parts of the server. Use CSAPI to modify the following areas of functionality:

For example, the server's default mechanism for authentication uses LDAP, and user preferences are stored in LDAP by default. If you have an existing infrastructure for authenticating users and saving user preferences that is not based on LDAP, use CSAPI to override the default mechanisms and use your existing authentication and directory services. In addition, there are three other customizable interfaces:

  • csIPlugin. Upon startup, provides information to the server about your plug-in modules.

  • csICalendarServer. Provides version information for the running server instance.

  • csIMalloc. Memory allocation scheme.

CSAPI is described in detail in Chapter 2 "Calendar Server API (CSAPI) Overview" and in Chapter 3 "CSAPI Reference".



Event Notification Service (ENS)


In iPlanet Calendar Server, the primary use of the Event Notification Service (ENS) is as an alarm dispatcher, which detects events on an alarm queue and sends notifications of these events to its subscribers. The ENS API allows programmers to modify publish and subscribe functions used by iPlanet Calendar Server 5.0 to:

  • Subscribe to events.

  • Unsubscribe to events.

  • Notify a subscriber of events.

For an overview of ENS, see Chapter 4 "Event Notification Service (ENS) Overview".

For a detailed description of the functions in each area, see Chapter 5 "Event Notification Service API Reference".



Proxy Authentication SDK (authSDK)


The authSDK is one of the three tools iPlanet Calendar Server 5.0 offers for user authentication. With authSDK, you can integrate your existing portal service with iPlanet Calendar Server 5.0, thus allowing your users to access various applications without the necessity of re-authentication. The authSDK consists of five functions packaged in a DLL/shared-object library, libicsexp10, and a header file, expapi.h. These functions perform three simple tasks:

  • Initialization

  • Lookup

  • Cleanup

In addition, two other functions allow you to use a non-standard port, and to get the authSDK version number for troubleshooting.

Note Once a connection has been established between iPlanet Calendar Server and the authSDK, the relationship set in place is one of trust. Therefore, once a user has logged in and has successfully authenticated to the authSDK, Calendar Server accepts the certificate generated by the proxy for all of its applications.


For further information on the authSDK, see Chapter 6 "Proxy Authentication SDK Overview" and Chapter 7 "Proxy Authentication SDK Reference".



Single Sign-on (SSO)


Single Sign-on (SSO) is one of the three authentication mechanisms offered by iPlanet Calendar Server 5.0. To use Single Sign-on, the client browser must support cookies and your server must support HTTP. Single Sign-on is independent from any other authentication mechanisms, session management, and resource access control.

With Single Sign-on, applications form circles of trust that share cookies and accept each others' user authentication. Each application can have its own verification interface, if necessary. Each verification authority, however, stores a cookie that is understood by the other applications' verification authority routines.

There are some limitations to this mechanism. The primary limitation is that each application must implement the verification protocol. Also, all trusted applications need to be in the same domain. And, finally, to switch to a different identity, the user must restart the browser because each browser session can support only one user ID.

For further information on Single Sign-on, see Chapter 8 "Single Sign-on Authentication".



Web Calendar Access Protocol (WCAP)


WCAP is a command based system consisting of client requests and server responses for transmitting calendaring data. WCAP 2.0 returns calendaring data via HTTP. With WCAP commands, you can get, delete, and modify calendar components, user preferences, calendar properties, and other calendar information like time zones. All times, strings, parameters, etc. follow RFC2445, RFC2446, and RFC2447 specifications, unless otherwise specified.

One of the three user authentication mechanisms offered by iPlanet Calendar Server 5.0 is the WCAP default of plain-text passwords and user names. You may replace or augment the authentication mechanism that WCAP uses. See Chapter 3 "CSAPI Reference" for the section csIAuthentication.

WCAP supports the following client request and server response data formats:

  • Calendar data in plain text format (HTML only). This is the new default format for the UI.

  • Calendar data in text/calendar format (iCalendar).

  • Calendar data in text/xml format. An XML-style version of iCalendar.

  • Calendar data as text/js with embedded JavaScript objects. This was the default for the iPlanet Calendar Server2.x user interface.


Previous     Contents     Index          Next     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated February 20, 2001