Previous      Contents      Index      Next
Sun Java System Calendar Server 6 2004Q2 Developer's Guide

Chapter 6
WCAP Common Topics

This chapter contains topics of common interest that span multiple commands.

The topics are listed in alphabetical order. The table that follows lists and contains links to these topics:

Access Control Entries	Freebusy Calculation for Private Events
Application IDs (appid parameter)	Group Scheduling
Changing Language or Character Set	Output Format
Encoded Characters	Recurring Components – Overview
Error Handling	Recurring Components – Creating, Modifying
Fetching Component Data	Recurring Components – Deleting
Fetching Component State Data	Recurring Components – Fetching
Fetching Deleted Data	Time Zones
Fetching Recurrence Data	Updating Parameter Values
Formatting Standards	X-Tokens
Freebusy Calendars

---

Access Control Entries

Access Control Entries (ACE strings) determine access control for calendars. There may be multiple ACE strings that apply to a single calendar. Collectively, all the ACE strings that apply to a calendar are called an Access Control List (ACL). As the system searches the ACL list for a calendar, the first ACE encountered that either grants of denies access will be used. Thus, the ordering of an ACL is significant. ACE strings should be ordered such that the more specific ones appear before the more general ones.

Some access is “built-in”. For example, primary owners have access to everything in their calendars. The system does not need to perform access control checks for primary owners accessing their own calendars.

The set_calprops command uses the acl parameter to facilitate storing of ACE strings to a calendar. The acl parameter is a semicolon-separated list of ACE strings. You may set the default acl in the ics.conf file by changing the calstore.calendar.default.acl preference, or by using the cscal command line utility. See the Calendar Server Administration Guide for further information on configuration settings.

The get_userprefs command will fail if any node does not have “allow anyone” access rights for reading and searching. For example, the following LDAP modify record for an ACI entry gives the correct privileges to make the command work correctly.

dn: o=usergroup changetype: modify add: aci aci: (targetattr="icscalendar || cn || givenName || sn || uid || mail")(targetfilter=(objectClass=icscalendaruser))(version 3.0; acl "Allow calendar administrators to proxy - product=ics,class=admin,num=2,version=1"; allow (proxy) groupdn = "ldap:///cn=Calendar Administrators,ou=Groups,o=usergroup";)

Due to a limitation on the user interface, do not add ACE strings for more than 75 users per calendar.

Here is an example of an ACE string:

jdoe^c^wd^g

The string has four elements separated by three “^” characters. The four elements are:

The first element of an ACE tells who the ACE applies to.

This could be an individual user (specified by user ID), a domain, or a class-type of user. There are four types of classes for users:

All users, represented by the string “@”.
Primary owners of a calendar, represented by the string “@@p”.
Owners of a calendar, represented by the string “@@o”.
Non-owners of a calendar, represented by the string “@@n”.

The second element of an ACE indicates what the ACE applies to.

The ACE can be applied to:

The entire calendar.

Applies to both components and calendar properties. To indicate the entire calendar, pass in the value a.

The components of the calendar only.

Applies to calendar components (i.e events/todos). To indicate just the components, pass in the value c.

The calendar properties of the calendar only.

Applies to calendar properties (i.e display name, ownerlist). To indicate calendar properties only, pass in the value p.

The third element of an ACE indicates what access values the ACE applies to.

Multiple values may be specified at the same time. To do this, the caller must pass in a string to indicate which bits to check.

Table 6-1 lists the Access Control characters used in ACE strings. The third element contains a string with one or more of the Access Control characters.

Table 6-1  Access Control Characters

Access Control Characters	Description
c	(not implemented)Grants the user act-on-behalf-of cancel access. With cancel access, a user has the right to cancel components to which attendees have been invited on behalf of the calendar’s primary owner.
d	Grants the user delete access.
e	(not implemented)Grants the user act-on-behalf-of reply access. This grants a user the rights to accept or decline invitations on behalf of the calendar’s primary owner.
f	Grants the user free-busy access.
i	(not implemented) Grants the user act-on-behalf-of invite access. This grants a user the right to create and modify components in which other attendees have been invited on behalf of the calendar’s primary owner
r	Grants the user read access.
s	Grants the user schedule access. This means that requests can be made, replies will be accepted, and other ITIP scheduling interactions will be honored.
w	Grants the user write access. This includes adding new items, deleting items, and modifying existing items.

For example, to grant read access, the value r is passed in. To grant write and delete access, the value wd is passed in.

The fourth element of an ACE indicates whether to grant or deny access.

The ACE can either grant or deny access.

To grant access, set the value to g.
To deny access, set the value to d.

ACE Summary

Here is a quick summary of the order of an ACE:

who ^ flags ^ how ^ grant

Where:

who = A string, type (str).
flags = One of the characters c, p, or a.
how = An access-string composed of one or more of the access control characters described earlier in Table 6-1.
grant = One of the characters g, or d

Extended Examples

Here are some examples of circumstances and how the ACE would be set in the acl parameter for jdoe’s calendar:

To grant john read access to both components and calendar properties (acl=john a r g), and to grant susan write and delete access to components only (acl=susan c wd g), the entire command is:

set_calprops.wcap?id=${SESSIONID}&calid=jdoe&acl=john^a^r^g; susan^c^wd^g

To grant all users in a domain schedule, freebusy, and read access to a calendar (@domainname a sfr g), to grant owners write and delete access to components only (@@o c wd g), to grant owners self-admin, schedule, freebusy, and read access to both components and calendar properties (@@o a zsfr g), to deny susan all access to both components and calendar properties (susan a zsfdwr d), and to grant read access to all users (@ c r g), the entire command is:

set_calprops.wcap?id=${SESSIONID}&calid=jdoe&acl=@domainname^a^sfr^g;@ @o^c^wd^g;@@o^a^zsfr^g;susan^a^zfsdwr^d;@^c^r^g

Note	An administrator can override the access control of all WCAP commands if he is logged in as administrator and the server configuration preference service.admin.calmaster.overrides.accesscontrol is set to “yes” in the ics.conf file.

Mapping User Interface Operations to ACLs

Table 6-2 shows the ACLs necessary to achieve the desired user interface operation.

Table 6-2  Mapping User Interface Operations to ACLs

User Interface Operation	ACL Required	Example	Description
Delete Events and Todos	Modify Events and Todos + Delete Components or Delete Calendar	c^d^g or, a^d^g	To delete events or todos, you need modify permission, and either delete components or delete calendar permission.
Freebusy	Freebusy Components or Freebusy Calendar	c^f^g a^f^g	To view a freebusy representation of a calendar (the events and todos), you need freebusy components or freebusy calendar permission.
Modify Events and Todos	Read Events and Todos + Write Components or Write Calendar	c^w^g a^w^g	To modify components of a calendar (events and todos), you need read permission, and either write components or write calendar permission.
Read Events on a Calendar	Read Calendar	a^r^g	To read components, you must have read calendar permission. Note that read components permission (c^r^g) will not work.
Schedule (Invite)	Schedule Calendar	a^s^g	To invite someone, you need schedule calendar permission.
Subscribe	Read Properties	p^r^g	To subscribe to a calendar, you must have read properties permission.

---

Application IDs (appid parameter)

The following WCAP commands accept the appid parameter:

deletecomponents_by_range – (ENS notifications not yet implemented)
deleteevents_by_id
deleteevents_by_range – (ENS notifications not yet implemented)
deletetodos_by_id
deletetodos_by_range – (ENS notifications not yet implemented)
import – (ENS notifications not yet implemented)
storeevents
storetodos

This WCAP command parameter is used to set the value of an X-Token that ENS returns with notifications.

Applications passing this parameter in with the appropriate WCAP command can detect which ENS notifications they originated by checking the value of the X-Token X-NSCP-COMPONENT-SOURCE. Note that this X-Token is not returned by WCAP commands, only ENS notifications.

This parameter is a runtime parameter. That is, nothing is stored in the database.

If appid is present, the Event Notification Service (ENS) returns the value of appid as the value of the X-Token X-NSCP-COMPONENT-SOURCE. If the appid parameter is missing, ENS assigns one of the standard values to the X-Token (WCAP, CALENDAR EXPRESS, ADMIN). (Note that ADMIN is not yet implemented.)

Table 6-3 shows the effect of the presence of the appid parameter on the value of the X-Token X-NSCP-COMPONENT-SOURCE. For more information about ENS, see the Sun Java System Communications Services Event Notification Service Guide.

Table 6-3  Presence of appid and Value of X-Token X-NSCP-COMPONENT-SOURCE

appid Present?	Value of X-Token X-NSCP-COMPONENT-SOURCE (with Request Origin)
no	WCAP (default) CALENDAR EXPRESS (from UI) ADMIN (from Admin tools) – Not yet implemented
yes	Value of appid

Note	For the Calendar Server, ENS notifications are only returned for some of the commands (as noted earlier). The other commands will be implemented in a later release.

---

Changing Language or Character Set

To insert a request for data to be returned in a language other than the system default, set either the lang or charset parameter. Note that the system default for language is now a server preference that you set in the ics.conf file. See the Calendar Server Administration Guide for details. The login command uses only the lang parameter.

For the set_calprops command, in most cases, specifying the lang parameter is enough. However, it may be necessary, in some instances, to use the charset parameter instead of the lang parameter. For example, if the user wants the requested data returned in a specified character set, then the user must specify it using charset. One possible charset value is: iso-8859-1. For more information on formatting specifications, see the RFCs referenced in Formatting Standards in this chapter.

Please note that when the user requests data in iCalendar or XML format, data always returns in UTF-8 format, per the RFC specification. Setting charset will not change this.

Here is a list of the valid lang values:

de	German
en	English (the default)
es	Spanish
fr	French
it	Italian
ja	Japanese
ko	Korean
ru	Russian
sv	Swedish
zh_CN	Chinese/Simplified Chinese
zh_TW	Taiwanese

Note	This does not mean that all of these languages are currently supported by the server. Please check with your Sun Java Enterprise System representative to find out which languages are currently supported by the server.

For example, enter the following if you want to insert an event into the calendar:

storeevents.wcap?id=${SESSIONID}&calid=id&summary=summary& location=location&desc=desc&charset=euc-jp

As another example, suppose that the location value is two Japanese characters whose unicode values are \u3068\u30889. In this case, the location value is %A4%C8%A4%E9. Note that all non-ASCII characters should be URL-encoded according to the charset parameter, which in this case is euc-jp. The following command is an example of same data sent in Shift_JIS:

storeevents.wcap?id=${SESSIONID}&calid=id&summary=summary& location=location&desc=desc&charset=Shift_JIS

In the above example, the location value is %82%C6%82%E7.

WCAP uses the value of the charset parameter to convert the data from the URL-encoded value into UTF-8 before storing it into the database. It is stored internally in UTF-8.

The charset parameter in this command have the same role as in the storeevents.wcap because the set_calprops command takes non-ASCII data. The charset parameter in this command does not have any other special meaning.

If charset is not specified, WCAP expects the data to be URL-encoded in UTF-8.

---

Encoded Characters

In the example, the encoded list of parameters for cal includes some encoded characters. Here are some examples of encoded characters:

%3D	=	’=’
%26	=	’&’
%22	=	’”’

The %XX is the hexadecimal ASCII value of the character. For example, the ’&’ character is 26 in hex (38 in ASCII).

---

Error Handling

Each call to a WCAP command that returns component data (fetch, delete, and store commands) also returns an error number.

Error String

The error string, errno, returns the non-zero error number for the transaction. The value is 0 if the command succeeded.

Error Codes

Table 6-4 list some of the error codes returned in the error number array.

Table 6-4  Error Names, Values, and Meanings 

Error Name	Value	Meaning
LOGOUT	-1	Logout successful.
OK	0	Command successful.
LOGIN_FAILED	1	Login failed, session ID timed out. Invalid session ID
LOGIN_OK_DEFAULT_CALENDAR_NOT_FOUND	2	login.wcap was successful, but the default calendar for this user was not found. A new default calendar set to the userid was created.
DELETE_EVENTS_BY_ID_FAILED	6	Command failed.
SETCALPROPS_FAILED	8	Command failed.
FETCH_EVENTS_BY_ID_FAILED	9	Command failed.
CREATECALENDAR_FAILED	10	Command failed.
DELETECALENDAR_FAILED	11	Command failed.
ADDLINK_FAILED	12	Command failed.
FETCHBYDATERANGE_FAILED	13	Command failed.
STOREEVENTS_FAILED	14	Command failed.
STORETODOS_FAILED	15	Command failed.
DELETE_TODOS_BY_ID_FAILED	16	Command failed.
FETCH_TODOS_BY_ID_FAILED	17	Command failed.
FETCHCOMPONENTS_FAILED_BAD_TZID	18	Command failed to find correct tzid. Applies to fetchcomponents_by_range, fetchevents_by_id, fetchtodos_by_id.
SEARCH_CALPROPS_FAILED	19	Command failed.
GET_CALPROPS_FAILED	20	Command failed.
DELETECOMPONENTS_BY_RANGE_FAILED	21	Command failed.
DELETEEVENTS_BY_RANGE_FAILED	22	Command failed.
DELETETODOS_BY_RANGE_FAILED	23	Command failed.
GET_ALL_TIMEZONES_FAILED	24	Command failed.
CREATECALENDAR_ALREADY_EXISTS_FAILED	25	createcalendar.wcap failed; calendar with that name already exists in the database.
SET_USERPREFS_FAILED	26	Command failed.
CHANGE_PASSWORD_FAILED	27	Command failed.
ACCESS_DENIED_TO_CALENDAR	28	Command failed; user denied access to a calendar.
CALENDAR_DOES_NOT_EXIST	29	Command failed; calendar does not exist in the database.
ILLEGAL_CALID_NAME	30	createcalendar.wcap failed; calid passed in was invalid.
CANNOT_MODIFY_LINKED_EVENTS	31	storeevents.wcap failed; event to modify was a linked event.
CANNOT_MODIFY_LINKED_TODOS	32	storetodos.wcap failed; todo to modify was a linked todo.
CANNOT_SENT_EMAIL	33	Command failed; the email notification failed. Usually caused by the server not being properly configured to send email. This can occur in storeevents, storetodos, deleteevents_by_id, deletetodos_by_id.
CALENDAR_DISABLED	34	Command failed; calendar is disabled in the database.
WRITE_IMPORT_FAILED	35	Import failed when writing files to the server.
FETCH_BY_LAST_MODIFIED_FAILED	36	Command failed.
CAPI_NOT_SUPPORTED	37	Failed trying to read from CS&T calendar data.
CALID_NOT_SPECIFIED	38	Calendar ID was not specified.
GET_FREEBUSY_FAILED	39	Command failed.
STORE_FAILED_DOUBLE_BOOKED	40	If double booking is not allowed in this calendar, storeevents or storetodos will fail with this error when attempting to store an event/todo in a time slot that was already filled.
FETCH_BY_ALARM_RANGE_FAILED	41	Command failed.
FETCH_BY_ATTENDEE_ERROR_FAILED	42	Command failed.
ATTENDEE_GROUP_EXPANSION_CLIPPED	43	An LDAP group being expanded was too large and exceeded the maximum number allowed in an expansion. The expansion stopped at the specified maximum limit. The maximum limit defaults to 200. To change the maximum limit, set the server configuration preference calstore.group.attendee.maxsize.
USERPREFS_ACCESS_DENIED	44	Either the server does not allow this administrator access to get/modify user preferences, or the requester is not an administrator.
NOT_ALLOWED_TO_REQUEST_PUBLISH	45	The requester was not an organizer of the event, and, therefore, is not allowed to edit the component using the PUBLISH or REQUEST method.
INSUFFICIENT_PARAMETERS	46	The caller tried to invoke verifyevents_by_ids, or verifytodos_by_ids with insufficient arguments (mismatched number of uids and rids).
MUSTBEOWNER_OPERATION	47	The user needs to be an owner or co-owner of the calendar in questions to complete this operation. (Probably related to private or confidential component.)
AC_ERR_DWP_CONNECTION_FAILED	48	GSE scheduling events failed to make connection to DWP.
AC_ERR_DWP_MAX_CONNECTION_REACHED	49	Reached the maximum number of connections. When some of the connections are freed, users can successfully connect. Same as 11001.
AC_ERR_DWP_CANNOT_RESOLVE_CALENDAR	50	Front end can’t resolve to a particular back end. Same as 11002.
AC_ERR_DWP_BAD_DATA	51	Generic response. Check all DWP servers; one might be down. Same as 11003.
AC_ERR_BAD_COMMAND	52	The command sent in was not recognized. This is an internal only error code. It should not appear in the error logs.
AC_ERR_NOT_FOUND	53	Returned for all errors from a write to the Berkeley DB. This is an internal only error code. It should not appear in the error logs.
AC_ERR_WRITE_IMPORT_CANT_EXPAND_CALID	54	Can’t expand calid when importing file.
GETTIME_FAILED	55	Get server time failed.
FETCH_DELETEDCOMPONENTS_FAILED	56	Fetch deleted components failed.
FETCH_DELETEDCOMPONENTS_PARTIAL_RESULT	57	Success but partial result.
WCAP_NO_SUCH_FORMAT	58	Returned in any of the commands when supplied fmt-out is not a supported format.
COMPONENT_NOT_FOUND	59	Returned when a fetch or delete is attempted that does not exist.
AC_ERR_BAD_ARGUMENTS	60	Currently used when attendee or organizer specified does not have a valid email address.
GET_USERPREFS_FAILED	61	get_userprefs.wcap failed. The following error conditions will return error code 61: ldap access denied no results found ldap limit exceeded ldap connection failed
WCAP_MODIFY_NO_EVENT	62	storeevents.wcap issued with storeytype set to 2 (WCAP_STORE_TYPE_MODIFY) and the event doesn’t exist.
WCAP_CREATE_EXISTS	63	storeevents.wcap issued with storetype set to 1 (WCAP_STORE_TYPE_CREATE) and the event already exists.
WCAP_MODIFY_CANT_MAKE_COPY	64	storevents.wcap issued and copy of event failed during processing.
STORE_FAILED_RECUR_SKIP	65	One instance of a recurring event skips over another
STORE_FAILED_RECUR_SAMEDAY	66	Two instances of a recurring event can’t occur on the same day
BAD_ORG_ARGUMENTS	67	Bad organizer arguments. orgCalid or orgEmail must be passed if any other org parameter is sent. That is, orgUID can’t be sent alone on a storeevents or a storetodos command if it is trying about to "create" the event or task. Note, if no org information is passed, the organizer defaults to the calid being passed with the command.
STORE_FAILED_RECUR_PRIVACY	68	Error returned if you try to change the privacy or transparency of a single instance in a recurring series.
LDAP_ERROR	69	For get_calprops, when there is an error is getting LDAP derived token values (X-S1CS-CALPROPS-FB-INCLUDE, X-S1CS-CALPROPS-COMMON-NAME).
GET_INVITE_COUNT_FAILED	70	Error in getting invite count (for get_calprops.wcap and fetchcomponents_by_range.wcap commands)
LIST_FAILED	71	list.wcap failed
LIST_SUBSCRIBED_FAILED	72	list_subscribed.wcap failed
SUBSCRIBE_FAILED	73	subscribe.wcap failed
UNSUBSCRIBE_FAILED	74	unsubscribe.wcap failed
ANONYMOUS_NOT_ALLOWED	75	Command cannot be executed as anonymous. Used only for list.wcap, list_subscribed.wcap, subscribe.wcap, and unsubscribe.wcap commands.
ACCESS_DENIED	76	Generated f a non-admin user tries to read or set the calendar-owned list or the calendar-subscribed list of some other user, or if the option is not turned on in the server
AC_ERR_BAD_IMPORT_ARGUMENTS	77	Incorrect parameter received by import.wcap
CDWP_ERR_MAX_CONNECTION_REACHED	11000	Maximum connections to back end database reached. As connections are freed up users will be allowed to connect to back end.
CDWP_ERR_CANNOT_CONNECT	11001	Cannot connect to back end. Back end machine may be down or DWP server is not up and running.
CDWP_ERR_CANNOT_RESOLVE_CALENDAR	11002	Front end cannot resolve calendar to a particular back end.
CDWP_ERR_BAD_DATA	11003	Bad data received from DWP connection. This is a generic response formatting error. Check all DWP servers. One might be down.
CDWP_ERR_DWPHOST_CTX_DOES_NOT_EXIST	11004	For the back end host, context doesn’t exist in the context table. Solution is to add back end host to ics.conf and restart front end.
CDWP_ERR_HOSTNAME_NOT_RESOLVABLE	11005	DNS/NIS/files or hostname resolver is not set up properly or machine does not exist.
CDWP_ERR_NO_DATA	11006	No data was received from reading the calprops from the DWP connection.
CDWP_ERR_AUTH_FAILED	11007	DWP authentication failed.
CDWP_ERR_CHECKVERSION_FAILED	11008	DWP version check failed.

---

Fetching Component Data

The component_type parameter directs WCAP to return either only events, only todos, or both events and todos. The keyword arguments, respectively, are: event, todo, or all. The parameter is not required. Its default is all, returning both events and todos. If an unrecognized value is passed in, the default value is used.

This parameter is found in all the fetchcomponents_by_* commands.

In addition, deleted components can be retrieved from the deletelog.db in the calendar store using the fetch_deletedcomponents command.

---

Fetching Component State Data

All fetch commands, except fetchcomponents_by_attendee_error, have the ability to fetch by component state, using the parameter compstate. The default (compstate=ALL) is to fetch all component states, Use this parameter to limit the type of components fetched.

If the parameter is not specified, the default value is ALL.

Table 6-5 lists component state values. A component state pertains either to the attendee or the organizer.

Table 6-5  Component State Values for compstate Parameter 

Value	Organizer/ Attendee	Comment
REPLY-DECLINED	Attendee	The event or todo is an invitation from another user and the current user has declined the invitation.
REPLY-ACCEPTED	Attendee	The event or todo is an invitation from another user and the current user has accepted the invitation.
REQUEST-COMPLETED	Organizer	The event or todo is an invitation from the current user to other invitees, and all invities have replied.
REQUEST_NEEDS-ACTION	Attendee	The event or todo is an invitation from another user and the current user has not replied to it yet.
REQUEST-NEEDSNOACTION	Attendee	The event or todo is an invitation from another user and the current user is not required to reply.
REQUEST-PENDING	Organizer	The event or todo is an invitation from the current user to other invitees, and is currently in the process of sending out invitations.
REQUEST-WAITFORREPLY	Organizer	The event or todo is an invitation from the current user to other invitees, and is currently awaiting replies from all invitees.
ALL	N/A	(Default) All event and todo component states.

---

Fetching Deleted Data

If you have deleted component data and need to reconstruct it, you can use the fetch_deletedcomponents command, which causes the system to process the Delete Log Database (ics50deletelog.db in the csdb directory). However, it is not possible to recreate the entire component data since not all of it is logged.

When non-recurring components are deleted, the server removes it from the component database and writes it to the Delete Log database.

When individual instances of a recurring event or task are deleted, the server writes each deleted instance to the Delete Log database. When all instances of the recurring event or todo are deleted, the server deletes the master entry for the component from the component database and writes it to the Delete Log database. A master entry in the Delete Log database contains the rrules, exrules, and exdates recurrence parameters.

In a single fetch_deletedcomponents command, either individual instances can be retrieved, or the master entry with its exceptions, but not both.

For more information on the Delete Log database, see the Calendar Server Administration Guide.

---

Fetching Recurrence Data

The compressed parameter allows you to retrieve a reduced amount of recurrence data. The parameter defaults (compressed=0) to the compressed format, which returns data without the rrule, rdate, exrule, and exdate properties as the default. To receive all the recurrence data back from the following commands, use compressed=1.

This parameter is used by all the fetchcomponents_by_* commands, the fetchevents_by_id and fetchtodos_by_id commands, and the store* commands.

Note	This parameter has been deprecated for the current release and may be removed from the future releases.

---

Formatting Standards

Find the exact format and definition for all times, strings, parameters, etc. by referring to RFC 2445, RFC 2446, and RFC 2447. Unless otherwise noted, all WCAP commands follow these specifications.

The RFC’s may be found at the IETF web site:

http://www.ietf.org/rfc/rfc2445.txt
http://www.ietf.org/rfc/rfc2446.txt
http://www.ietf.org/rfc/rfc2447.txt

Note	As a reminder, the maximum parameter value length is 1024 characters.

For more information on time zones, see Time Zones,which follows later in this section.

---

Freebusy Calendars

Calendars can be displayed in freebusy format instead of showing details of scheduled events and todos. Freebusy calendars are used to facilitate scheduling of events or todos in the event and todo creation dialogs in the user interface. They can also be used by calendar owners to prevent other users from viewing the details of their calendars.

This can be accomplished in two separate ways that are not mutually exclusive:

Freebusy access rights can be granted to users in the calendar’s properties.
Freebusy access can be assigned to the calendar as a whole using the calendar property fbinclude.

If fbinclude is set to 0, it overrides any access rights granted to users. That is, if fbinclude=0, then the calendar will not be included in freebusy calculations, no matter what the acl parameter specifies.

If the fbinclude is set to 1, which allows the use of the calendar for freebusy calculations, then the acl access rights will be used to determine if the user can see the details of the calendar, the freebusy representation only, or neither.

In freebusy calendars, instead of event or todo details, just the word “Busy” appears by the time block. Blocks of time without any scheduled events are listed also, with the word “Free” next to them.

For example, a calendar called jdoe has the following events:

100:00-11:00	first meeting
12:00-1:00	lunch
3:00-4:00	second meeting

If user john has only freebusy access to the calendar jdoe, user john will get only a freebusy version of the calendar. The freebusy time for jdoe (from 9:00 to 6:00) would appear as the following:

9-10		Free
10-11		Busy
11-12		Free
12-1	:	Busy
1-3	:	Free
3-4	:	Busy
4-6	:	Free

Notice that john does not know the details of why the user is busy, but simply knows when the user is busy.

The get_freebusy command allows selection of which calendars to use in the calculation in two ways: using the calid parameter, or the mail parameter. One of the parameters is required, but not both. If both are present, the calid value is used.

When an email address is passed in using the mail parameter, all calendars, for which this user is the primary owner and which have fbinclude=1 in their calendar properties settings, will be included in the freebusy calculation.

When the calid parameter is used, specific calendars can be named rather than using all of owners calendars. Note that the calid parameter can take an email address (by specifying mailto:ref822address, where rfc822address is any valid email address that maps to a single calendar in the local LDAP directory).

The command returns the busy data only. The rest of the time slots are presumed to be free.

---

Freebusy Calculation for Private Events

When a freebusy calendar rendition is requested using the get_freebusy command, private events and todos will be included or excluded depending on the value of the transparent parameter stored with the events and todos when they were created or modified.

Using the store* commands, set the event or todo transparent parameter to 1 to keep the event truly private, and set it to 0 to allow it to be included in the freebusy calculation.

As opposed to regular events, all-day events (isAllDay parameter is set to 1) default to private and opaque (transparent=1). For the all-day event to be included in the freebusy calculation, the transparent parameter must be set to 0.

---

Group Scheduling

When you are using the storeevents command for scheduling a group event, there are two parameters that are required:

Attendee Parameter
Method Parameter

Attendee Parameter

The two most important parameters for creating a group-scheduled event are attendee and method. The attendee parameter is a semicolon separated list of attendee entries. The attendee entry is explained in the section below.

Each attendee entry may contain several parameters, such as invitation participation status, whether attendance is required or not, etc. All such parameters are encapsulated in a syntax very similar to the ATTENDEE property defined in the iCalendar Specification (RFC 2445). Reading the entire document is recommended in order to have the necessary background information to understand the WCAP attendee syntax. There are some differences, such as, WCAP uses a different delimiter, “^”, to set apart these parameters. (However, WCAP uses the standard iCalendar semicolon delimiter for separating attendees.)

For example, where iCalendar would have the following:

PARSTAT=ACCEPTED;RSVP=TRUE:mailto:abc@xyz.com

WCAP would format it this way:

PARSTAT=ACCEPTED^RSVP=TRUE^mailto:abc@xyz.com

Examples of WCAP Attendee Entries

If attendee A (attA) accepts an invitation, the WCAP command would contain:

PARTSTAT=ACCEPTED^RSVP=TRUE^attA

If attendee B (attB) declines an invitation, the WCAP command would contain:

PARTSTAT=DECLINED^RSVP=TRUE^attB

If the email attendee jdoe@xyz.com has not yet decided to attend and is not required to respond, the WCAP command would contain:

PARTSTAT=NEEDS-ACTION^RSVP=FALSE^mailto:jdoe@xyz.com

An attendee in an existing meeting can be marked for deletion by assigning X-NSCP-WCAP-ATTENDEE-DELETE to PARTSTAT. For example, if you want to delete attendee jdoe, the attendee parameter of the storeevents command would contain the following:

PARTSTAT=X-NSCP-WCAP-ATTENDEE-DELETE^jdoe

Table 6-6 lists the parameters in the iCalendar ATTENDEE property understood by WCAP. Most of the parameters are optional. Not all are fully supported by Calendar Server, although the information will be stored. For group scheduling, only the PARTSTAT and RSVP parameters are relevant.

Table 6-6  iCalendar ATTENDEE parameters understood by WCAP

Parameters	Purpose
PARTSTAT	The only required parameter. This shows the attendees participation status.
CUTYPE	Calendar user type.
MEMBER	List of groups the attendee is part of. WCAP has no understanding of these groups.
ROLE	Role of the attendee in this meeting.
RSVP	Attendee response required or not.
DELEGATED-TO	To whom the attendee delegates attendance.
DELEGATED-FROM	Attendee is a delegate for this person.
SENT-BY	The calendar user acting on behalf of the specified user.
CN	Display name of attendee.
DIR	Directory entry reference.
LANG	Language of the entry.

In addition, WCAP allows the optional use of an additional parameter, SENT-STATUS, which is specific to Calendar Server and is not part of the iCalendar specification. Possible values for SENT-STATUS are: NOT-SENT, and SENT-SUCCEEDED. The default is NOT-SENT. The Group Scheduling Engine inside Calendar Server will not process an attendee with a SENT-STATUS value of SENT-SUCCEEDED.

Method Parameter

The method parameter describes the type of message used: invitation, response, cancellation.

For group scheduling, specify one of the following ITIP methods:

1	PUBLISH	Used only by the organizer.
2	REQUEST	Used only by the organizer.
4	REPLY	Used only by attendees.
8	CANCEL	Used only by the organizer.

Note	Even though the method parameter has a default value, it is a required parameter if you are trying to do anything other than PUBLISH. Leaving the parameter off the storeevents or storetodos commands will cause the default (PUBLISH) to be the presumed action.

In an invitation, three types of messages may occur:

An organizer invites attendees.

When an organizer creates a meeting, there are two ways to invite people:

Send a PUBLISH message, creating or modifying a meeting. The method parameter is set to “1”. Note that everthing except the attendee information is sent. (Attendees can see the event but not the other attendees.)
Send a REQUEST message, creating or modifying a meeting, and requesting a response to the invitation from attendees. The method parameter is set to “2”.

Only the organizer of the meeting can send a PUBLISH or REQUEST message.

Attendees respond to invitation.

An attendee sends a REPLY message, either accepting or declining the invitation. (The method parameter is set to “4”.)

Organizer cancels the meeting.

When an organizer cancels a meeting, attendees are notified by sending a CANCEL using one of the deleteevents commands. The method parameter is set to “8”.

Note	The preferred way to handle a cancellation is to use one of the deleteevents commands, rather than storeevents.

The following set of examples demonstrates the WCAP commands for an organizer “org” to invite attendees “attA” and “attB” to a meeting. Attendee “attA” accepts the invitation; attendee “attB” declines it. The uid for the meeting is “event_u1”. The event will be created on both attendees’ calendars. Each will respond to the event on their own calendar. The response will be sent back to the organizer’s calendar by the Calendar Server Group Scheduling Engine.

The following is an example of an invitation:

storeevents.wcap?id=${SESSIONID of org}&calid=org&dtstart=    20020201T200200Z&dtend=20020201T210000Z&summary=invite_attA_attB    &method=2&attendees=PARTSTAT=ACCEPTED^RSVP=TRUE^org;PARTSTAT=    NEEDS-ACTION^RSVP=TRUE^attA;PARTSTAT=NEEDS-ACTION^RSVP=    TRUE^attB&fmt-out=text/xml

The following is an example of the acceptance:

storeevents.wcap?id=${SESSIONID ofattA}&calid=attA&uid=event_u1    &method=4&attendees=PARTSTAT=ACCEPTED^RSVP=TRUE^attA    &fmt-out=text/xml

The following is an example of a declined meeting:

storeevents.wcap?id=${SESSIONID ofattB}&calid=attB&uid=event_u1    &method=4&attendees=PARTSTAT=DECLINED^RSVP=TRUE^attA    &comments=I_cannot_make_it_Sorry&fmt-out=text/xml

---

Output Format

WCAP commands can request the output format in two content types:

text/calendar - iCalendar
text/xml - iCalendar XML

To change the output format, set fmt-out to the target value. If fmt-out is not specified, the default format of text/calendar will be returned.

---

Recurring Components – Overview

Recurrence handling occurs as follows:

A recurring series of events or todos has a master entry plus entries for exceptions.
Changing the rrules of a single instance returns an error. When rrules are modified for a recurring series, the whole series is deleted and recreated.
Changing dtstart of a recurring series entry causes the whole series to be recreated with the new dtstart, thereby losing all exceptions.
Inserting a rid that was not part of the original rule is not supported.
Multiple rrules for any component are not supported.

---

Recurring Components – Creating, Modifying

The following parameters are used with the storeevents and storetodos commands to create and modify components:

rrules - Semicolon-separated list of quoted recurrence-rule strings for recurring events.
rdates – Semicolon-separated list of ISO 8601 date strings listing recurrence dates.
exrules – Semicolon-separated list of quoted recurrence-rule strings for dates to exclude.
exdates – Semicolon-separated list of ISO 8601 date strings listing dates to exclude.
rid – ISO 8601 DateTimeString giving the recurrence ID of an event.
mod – Modifier telling which instances of the event to store.
rchange – A boolean specifying whether or not to replace the rrules parameter. If rchange=1, the store commands map all mod settings (2-4) are mapped to 4. This means that you can not change an rrule for only some of the components in a recurring series. To change the rrules parameter, all components in the recurring series must be changed.

Note	The rrules, rdates, exrules, and exdates parameters always function in replace mode. That is, no matter what the replace parameter value is set to, the values passed in always replace the parameter value, rather being appended to it. This means you can not have multiple rrules for the same component. For more information on the replace parameter, see Updating Parameter Values.

rrules

The rrules parameter takes a semicolon-separated list of quoted recurrence rule strings. Each string represents a recurrence rule of the event. Each string must be enclosed in quotes. There are many parameters possible for recurrence rules. See RFC 2445 for a complete description of the syntax.

Three very useful parameters for specifying recurrence are freq, count and until:

The freq parameter in a rule defines the periodicity of the event, and has the following possible values:

DAILY	The event recurs daily.
WEEKLY	The event recurs weekly.
MONTHLY	The event recurs monthly.
YEARLY	The event recurs yearly.

The count parameter in a rule defines how many times the meeting will repeat. If you do not specify the count, the default is the maximum number of recurrences allowed.The default maximum is 60. To change the maximum number, set the server configuration preference calstore.recurrence.bound.
The until parameter in a rule specifies using an end date as opposed to using the count to limit the number of instances created. Instances will be created up to the end date or until 60 instances are created, whichever occurs first.

In the event that neither the count nor the until parameter are specified, the default is 60 instances.

Note	Using the storeevents.wcap command to create an event with only exdate or rdate values, without specifying a rrule results in no events being created. The same behavior can be observed with the storetodos.wcap command.

The following example shows an rrules parameter that specifies the event is to occur daily for 10 instances:

rrules="count%3D10%3Bfreq%3Ddaily" (COUNT=10;FREQ=DAILY)

The following example URL passes the example rrules parameter:

http://webcalendarserver/storecomponents.wcap?id=b5q2o8ve2rk02nv9t6 &calid=jdoe&uid=333&dtstart=20020301T112233Z &rrules="count%3D10%3Bfreq%3Ddaily"&dtend=20020301T112233&summary=uuuu

rdates

The rdates parameter takes a semicolon-separated list of date-time specifications where each date-time gives a recurrence date of the event.

For example, the following rdates parameter specifies a recurring event with two recurrence dates (3/31/02 11:22:33 and 5/31/02 11:22:33):

rdates=20020331T112233;20020531T112233

The following example URL passes the example rdates parameter:

http://webcalendarserver/storecomponents.wcap?id=b5q2o8ve2rk02nv9t6 &calid=jdoe&uid=333&dtstart=20020301T112233Z   &rdates=20020331T112233;20020531T112233 &dtend=20020301T112233&summary=uuuu

If you want to the change the recurrence rule after a certain date, you must set rchange to 1.

exrules

The exrules parameter takes a semicolon-separated list of quoted recurrence rule strings where each rule is an excluded recurrence of the event.

For example, the following exrules parameter specifies a recurring event that does not recur at the times specified by the two rules:

exrules="count%3D10%3Bfreq%3Ddaily";"freq%3Dweekly%3Bcount%3D4" (COUNT=10;FREQ=DAILY and FREQ=WEEEKLY;COUNT=4 encoded)

The first rule is for the event not to occur daily for 10 instances. The second rule is for the event not to occur weekly for 4 instances.

The following example URL passes the example exrules parameter:

http://webcalendarserver/storecomponents.wcap?id=b5q2o8ve2rk02nv9t6 &calid=jdoe&uid=333&dtstart=20020301T112233Z &exrules="count%3D10%3Bfreq%3Ddaily";"freq%3Dweekly%3Bcount%3D4" &rrules="count%3D100%3Bfreq%3Ddaily"&dtend=20020301T112233&summary=uuuu

exdates

The exdates parameter takes a semicolon-separated list of date-time specifications. Each date-time represents an excluded date of the event.

For example, the following exdates parameter specifies a recurring event that does not occur on the two specified dates (3/31/02 11:22:33 and 5/31/02 11:22:33):

exdates=20020331T112233;20020531T112233

The following example URL passes the example exdates parameter:

http://webcalendarserver/storecomponents.wcap?id=b5q2o8ve2rk02nv9t6 &calid=jdoe&uid=333&dtstart=20020301T112233Z &exdates=20020331T112233;20020531T112233 &rrules="COUNT%3D200%3BFREQ=DAILY";dtend=20020301T112233&summary=uuuu

rid

This parameter specifies a unique recurrence date of an event or todo. Use rid in conjunction with the mod parameter to specify a range of events and todos to be modified.

For example:

http://webcalendarserver/storecomponents.wcap?id=b5q2o8ve2rk02nv9t6 &calid=jdoe&uid=333&dtstart=20020301T112233Z &rid=20020331T112233;dtend=20020301T112233&summary=uuuu&mod=1

For a non-recurring event or todo, the rid is 0.

mod

When modifying recurring components, this parameter specifies whether to apply the changes to one or more instances of the event or todo. The following settings are mapped, but currently only the values 1 and 4 are honored. If 2 or 3 are specified, in certain cases they are mapped to 4.

Value	Option
1	This instance only.
2	This and all future instances.
3	This and all prior instances.
4	This and all instances.

When creating or modifying a recurring component, if changing rrules is allowed (rchange is set to 1), the system assumes a setting of 4, which causes the entire series of events or todos to be deleted and rewritten. If 2 or 3 are specified when trying to change rules or start times, it will be mapped to 4 anyway. If 2 0r 3 is specified for changing a summary or description, the setting will be honored, but no exceptions will be created for errors.

rchange

The rchange parameter specifies whether recurrences are expanded in storeevents, and storetodos. Normally, events and todos calendar components are not expanded, so the parameter defaults to 0, which implies the series is recreated.

However, you might not want to expand recurrences when you are modifying multiple events. For example, suppose a meeting recurs every Friday starting Jan. 1, 2002. Use the following URL to change the summary of each event after Feb. 1, 2002 to changed-event.

The following example sets the rchange parameter to 0, to make the modification without adding additional events:

http://webcalendarserver/storeevents.wcap?id=b5q2o8ve2rk02nv9t6 &calid=jdoe&uid=abcxyz&dtstart=20020201T112233Z &rrules="byday%3Dfr%3Bfreq%3Dweekly"&summary=changed-event &rid=20020201T112233Z&mod=2&rchange=0

Note that when you are modifying a recurrence series, do not pass in rrule unless you are trying to recreate the series with a new rule.

---

Recurring Components – Deleting

When you delete a recurring component, specify the recurrence ID and whether to delete the recurrences as well as the original event or todo.

Use the mod parameter to choose which option you want:

Value	Option
1	Delete/modify this instance only.
2	Delete/modify this and all future recurrences.
3	Delete/modify this and all prior recurrences.
4	Delete/modify all instances.

A setting of 2 will delete only as many instances as exist on the server.

Examples Using deleteevents_by_id

To delete just the single instance of the event, the mod parameter should be set to 1. For example, this URL would delete just the event that occurs on the date March 1, 2002 11:22:33 AM GMT.

http://webcalendarserver/deleteevents_by_id.wcap?id=23423423434abc&calid=j doe&uid=001&rid=20020301T112233Z&mod=1

To delete the event and all future instances of the event, the mod parameter should be set to 2. For example, this URL would delete the event that occurs on the date March 1, 2002 11:22:33 AM GMT and all future instances of this event (uid 001).

http://webcalendarserver/deleteevents_by_id.wcap?id=23423423434abc& calid=jdoe&uid=001&rid=20020301T112233Z&mod=2

To delete the event and all prior instances of the event, the mod parameter should be set to 3.

For example, this URL would delete the event that occurs on the date March 1, 200211:22:33 AM GMT and all prior instances of this event (uid 001).

http://webcalendarserver/deleteevents_by_id.wcap?id=23423423434abc& calid=jdoe&uid=001&rid=20020301T112233Z&mod=3

To delete all instances of the event, the mod parameter should be set to 4. For example, this URL would delete ALL instances of the event (uid 001).

http://webcalendarserver/deleteevents_by_id.wcap?id=23423423434abc& calid=jdoe&uid=001&rid=20020301T112233Z&mod=4

---

Recurring Components – Fetching

The following parameters are found in the fetchcomponents_by_* commands, and the fetchevents_by_id and fetchtodos_by_id commands:

compressed – A boolean specifying whether to return all of the recurring entry’s data, or to exclude the following parameters:rrules, rdate, exrule, exdate.

Note that this parameter is deprecated in the current release and may be removed from future releases.

recurring – A boolean parameter specifying whether or not to return all components in compressed form (master entry and exceptions). This parameter is also present in the fetch_deletedcomponents command.

---

Time Zones

To support a universal standard, Calendar Server uses the date and time strings in Greenwich Mean Time (GMT) or Coordinated Universal Time (UTC), called Zulu time. The server stores and returns all date and time strings from the database in Zulu time. WCAP converts the Zulu times to the appropriate time zone settings depending upon the value of the tzid and tzidout parameters.

The tzid parameter is used for date and time strings passed in with the dtstart, dtend, and rid parameters, which are not already in Zulu time. WCAP uses the value of the tzid parameter to calculate the Zulu time. If the tzid parameter is not passed in, the server’s default time zone is used to calculate Zulu time.

For commands that return events and todos, the data will be returned in Zulu time, unless the tzidout parameter is passed in. In this case the Zulu time is translated into the time zone specified in the tzidout parameter.

For example, if the fetch_components_by range command specifies a date range of 20020506T100000 to 20020507T100000, with a tzid=America/Los_Angeles, WCAP will translate that to Zulu time for database lookup. If the tzidout parameter was also passed in (for our example, tzidout=America/New_York), then the resulting output would be translated to that time zone and returned. If the tzidout parameter is missing, the component data is returned in Zulu time.

The tzidout parameter can be used with the storeevents and storetodos command when the fetch parameter is set to 1 (fetch=1).

The time zones information is kept in a plain text file (timezones.ics) in VTIMEZONE format.

The server never uses the system time zone information to calculate the current date and time. It uses the time elapsed in seconds since the Epoch (00:00:00 UTC, January 1, 1970) to calculate current date and time. Then depending on the user’s time zone settings, the date is displayed to reflect the correct time zone.

The following commands use both the tzid and tzidout parameters:

fetchcomponents_by_alarmrange
fetchcomponents_by_lastmod
fetchcomponents_by_range
fetchevents_by_id
fetchtodos_by_id
storeevents
storetodos

In addition, the following commands use the tzid parameter (but not the tzidout):

deleteevents_by_id
deletetodos_by_id
get_freebusy
set_calprops

---

Updating Parameter Values

Two commands, storeevents and storetodos, allow you to update (replace, append, or delete) parameter values. When updating current values for a component, you can either replace the current values with the new ones being passed in, append the new values to the current values, or pass in empty parameter values to delete the parameter.

The ability to append parameter values applies only to parameters that can accommodate multiple values (that is, parameters that use semicolon-separated values, such as the attendees parameter). The default is to append (replace=0) the new values to the current values. If you want to replace the current values with the new values being passed in, include the replace parameter in the command, with the value set to 1 (replace=1). If you do not include the replace parameter in the command, the system assumes the default setting (replace=0) and appends the new values to the old values.

With one exception, the recurrence and alarm parameters can only be replaced, not appended. Specifically, the parameters are: rrules, rdates, exrules, exdates, alarmAudio, alarmDescription,alarmFlashing, alarmPopup, and alarmStart. The alarmEmails parameter is the only one that allows multiple values, and thus is the only exception. Therefore you can append an alarm email recipient to the list by specifying replace=0.

In all cases, a parameter can be deleted by passing in an empty parameter and setting replace to 1. For example, to delete the alarmPopup parameter, pass in the following: alarmPopup=&replace=1. Using replace=1 can also be used to delete string fields. For example, to delete the description, you would use desc=&replace=1.

---

X-Tokens

Table 6-7 lists the X-tokens returned by WCAP commands.

Table 6-7  X-Tokens Returned by WCAP Commands 

Token Name	Type	WCAP Command	Description
X-NSCP-ATTENDEE-GSE-STATUS	integer	all fetch commands	Attendee status for group scheduled components.
X-NSCP-CALPROPS-ACCESS-CONTROL- ENTRY	string	all fetch commands	ACL for this calendar.
X-NSCP-CALPROPS-CALMASTER	string	all fetch commands	Calmaster
X-NSCP-CALPROPS-CATEGORIES	string	all fetch commands
X-NSCP-CALPROPS-CHARSET	string	all fetch commands	Character Set used by calendar.
X-NSCP-CALPROPS-CHILDREN	string	all fetch commands	Child calendars if present.
X-NSCP-CALPROPS-CREATED	string	all fetch commands	Date the component was created.
X-NSCP-CALPROPS-DESCRIPTION	string	all fetch commands	Calendar description.
X-NSCP-CALPROPS-LANGUAGE	string	all fetch commands	Language used by calendar.
X-NSCP_CALPROPS-LAST-MODIFIED	string	all fetch commands	Date string of last modification to properties.
X-NSCP-CALPROPS-NAME	string	all fetch commands	Name of calendar.
X-NSCP-CALPROPS-OWNERS	string	all fetch commands	Owners for this calendar.
X-NSCP-CALPROPS-PARENT-CALID	string	all fetch commands	Parent calid if present.
X-NSCP-CALPROPS-PRIMARY-OWNER	string	all fetch commands	Calendar’s primary owner.
X-NSCP-CALPROPS-READ	integer	all fetch commands	Permission to read properties.
X-NSCP-CALPROPS-RELATIVE-CALID	string	get_freebusy, all fetch commands	Calendar identifier of user.
X-NSCP-CALPROPS-RESOURCE	string	all fetch commands	Resource rather than a regular calendar.
X-NSCP-CALPROPS-TZID	string	all fetch commands	Time date string for calendar creation.
X-NSCP-CALPROPS-WRITE	integer	all fetch commands	Permission to write properties.
X-NSCP-CHARSET	string	all fetch commands	Character Set.
X-NSCP-DTEND-TZID	string	all fetch commands	End time string.
X-NSCP-DTSTART-TZID	string	all fetch commands	Start time string.
X-NSCP-DUE-TZID	string	all fetch commands	Due date time string.
X-NSCP-GSE-COMMENT	string	all fetch commands	Comment.
X-NSCP-GSE-COMPONENT-STATE	string	all fetch commands	Component state.
X-NSCP-GUID	GUID integer	get_guids	Globally unique identifier.
X-NSCP-LANGUAGE	string	all fetch commands	Returns the lang string (for example, en for English)
X-NSCP-LINK-CALID	string	all fetch commands	Calendar ID.
X-NSCP-ONGOING	integer	all fetch commands
X-NSCP-ORGANIZER-EMAIL	string	all fetch commands	Organizer’s email address.
X-NSCP-ORGANIZER-SENT-BY-UID	string	all fetch commands	uid for who created the component for the organizer.
X-NSCP-ORGANIZER-UID	string	all fetch commands	Organizer’s uid.
X-NSCP-ORIGINAL-DTSTART	Date Time Z string	fetch commands
X-NSCP-REQUEST-STATUS	string	deleteevents_by_ range, deletetodos_by_ range	Error message string returned from WCAP commands.
X-NSCP-TOMBSTONE	integer	all fetch commands	Dead events (those in the past).
X-NSCP-WCAP-CALENDAR-ID	string		calendar ID of logged-in user
X-NSCP-WCAP-ERRNO	integer	all	Error number generated from WCAP command
X-NSCP-WCAP-PREF-	varies by preference	get_userprefs	User preferences: cn, givenName, preferredLanguage, sn, nswcalCALID, cefontSizeDelta, ceTableSpacing, ceColorSet, ceBgcolor, ceCalList, ceAgendaList, ceAgendaTZMode_Personal, ceCursorColor
X-NSCP-WCAP-SERVER-PREF-	varies by preference	get_userprefs	Server preferences: allowchangepassword, allowcreatecalendars allowdeletecalendars
X-NSCP-WCAP-SESSION-ID	string	check_id	Session identifier of logged-in user
X-NSCP-WCAP-USER-ID	string		user ID of logged-in user
X-NSCP-WCAP-VERSION	string		WCAP version the server currently supports (current version is 3.0)
X-S1CS-ATTENDEE-EXDATELIST	string	all fetch commands	Attendee exceptions for each date.
X-S1CS-ATTENDEE-RDATELIST	string	all fetch commands	Attendees for each date.
X-S1CS-CALID	string	all fetch commands	Calendar ID.
X-S1CS-CALPROPS-ALLOW-DOUBLEBOOKING	string	get_calprops set_calprops	Doublebooking allowed.
X-S1CS-CALPROPS-COMMON-NAME	string	get_calprops	Common name. Set by querying LDAP cn attribute.
X-S1CS-CALPROPS-FB-INCLUDE	integer	get_calprops	0=not included in free/busy calculation. 1= included in free/busy calculation.
X-S1CS-CALPROPS-INVITATION-COUNT	string	get_calprops	Invoke command with invitecount=1 to return total number of open invitations.
X-S1CS-CALPROPS-OWNED-CALENDAR	string	list	Full calids of all calendars owned for this user.. For example: jdoe@example.com jdoe@example.com:Vacation
X-S1CS-CALPROPS-SUBSCRIBED-CALENDAR	string	list_subscribed	Full calids of all calendars this user subscribes to, including all owned by the user. For example: jdoe@example.com jdoe@example.com:Vacation fred@example.com jane@example.com:ProjectX
X-NSCP-COMPONENT-SOURCE	string	all fetch commands
X-S1CS-EMAIL	string	all fetch commands	Email address.
X-S1CS-EXPORTVERSION	string	all fetch commands	Export version.
X-S1CS-RECURRENCE-COUNT	integer	all fetch commands	Count of the number of components in the recurring series.
X-S1CS-RECURRENCE-EXDATELIST	string	all fetch commands	Exception list for recurring master.
X-S1CS-RECURRENCE-RDATELIST	string	all fetch commands	List of recurrence dates.
X-S1CS-RECURRENCE-UNTIL	string	all fetch commands	Date string for end date.
X-NSCP-TRIGGERED_BY	string	all fetch commands
X-S1CS-TZID-ALIAS	string	all fetch commands	Alias for time zone.

Previous      Contents      Index      Next

---

Copyright 2004 Sun Microsystems, Inc. All rights reserved.