Sun Java System Calendar Server 6 2005Q1 Developer's Guide |
Chapter 6
WCAP Common TopicsThis 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 EntriesAccess 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.
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:
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.
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:
- 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:
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 implementedyes
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 SetTo 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 CharactersIn the example, the encoded list of parameters for cal includes some encoded characters. Here are some examples of encoded characters:
The %XX is the hexadecimal ASCII value of the character. For example, the ’&’ character is 26 in hex (38 in ASCII).
Error HandlingEach 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 lists error codes returned by WCAP commands.
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 will fail with this error when attempting to store an event in a time slot that was already filled.
Double booking is not allowed under the following circumstances:
- If user.allow.doublebook=”yes” and the user’s calendar property doublebooking=0 (disallowed). When double booking is allowed by the administrator, the user’s calendar properties determine whether doublebooking is allowed in the calendar.
- If user.allow.doublebook=”no”. When double booking is not allowed by the administrator, the user’s calendar properties do not have any effect.
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.)
DWP_CONNECTION_FAILED
48
GSE scheduling events failed to make connection to DWP.
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.
DWP_CANNOT_RESOLVE_CALENDAR
50
Front end can’t resolve to a particular back end. Same as 11002.
DWP_BAD_DATA
51
Generic response. Check all DWP servers; one might be down. Same as 11003.
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.
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.
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.
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:
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
BAD_IMPORT_ARGUMENTS
77
Incorrect parameter received by import.wcap
READONLY_DATABASE
78
Database is in read-only mode. (returned for all attempts to write to the database)
ATTENDEE_NOT_ALLOWED_TO_REQUEST_ON_MODIFY
79
Attendee is not allowed to modify an event with method=request.
TRANSP_RESOURCE_NOT_ALLOWED
80
Resources do not permit the transparency flag.
RECURRING_COMPONENT_NOT_FOUND
81
Recurring component not found. Only happens when recurring=1 is passed in by fetch commands. This code is returned if part of the recurring series (either the master or an exception) is missing.
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 DataThe 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 DataAll 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 DataIf 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 DataThe 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 rrules, rdates, exrules, and exdates 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 StandardsFind 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:
For more information on time zones, see Time Zones,which follows later in this section.
Freebusy CalendarsCalendars 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:
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:
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:
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 EventsWhen 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 SchedulingWhen you are using the storeevents command for scheduling a group event, there are two parameters that are required:
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:
WCAP would format it this way:
Examples of WCAP Attendee Entries
If attendee A (attA) accepts an invitation, the WCAP command would contain:
If attendee B (attB) declines an invitation, the WCAP command would contain:
If the email attendee jdoe@xyz.com has not yet decided to attend and is not required to respond, the WCAP command would contain:
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:
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:
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 everything 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.
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 FormatWCAP commands can request the output format in two content types:
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 – OverviewRecurrence 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, ModifyingThe 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 rrules for only some of the components in a recurring series. To change the rrules parameter, all components in the recurring series must be changed.
- excludedtstart – An integer specifying whether or not to include the dtstart date in a recurring series if the date does not follow the rrule.
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:
- 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 exdates or rdates values, without specifying an rrules 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:
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):
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):
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 rrules unless you are trying to recreate the series with a new rule.
excludedtstart
When creating a recurring series according to the rrule, this integer specifies whether to include the dtstart date if the date does not follow the rrules. For example, if on a Monday, you were creating a recurring series of meetings that were to be held every Wednesday, the dtstart would be Monday, but that does not fit the set of dates (all Wednesdays) generated using the rrules. Therefore the server must decide whether to include the dtstart date or not based on the value of excludedtstart.
A value of 0 indicates the dtstart date is included in the recurring series and a value of 1 indicates the dtstart date is not included in the recurring series. The default is 0.
Recurring Components – DeletingWhen 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 – FetchingThe 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.
Sorting Order of Returned Events and TodosFetch commands that support the fetchorder parameter allow you to specify the order in which the events and todos are returned.
Three sorting choices can be specified:
The sorting logic is as follows:
- For events, put in order according to dtstart. If two events have the same dtstart date, then compare dtend for the two events. Return the one that fits the desired sort order. If they are the same, compare uid and return the components from the least value to the highest.
- For todos, all completed tasks are returned after all sorted not-due tasks. For two not-due tasks, compare dtdue. Return in the desired sort order. If they are the same, compare uid and return components from the least value to the highest. For descending sorts, some overdue tasks could be truncated because of the maxResults limit.
- For recurring components sorted in ascending order, the master record is returned first and then the exceptions. Depending on the maxResults limit, some exceptions could be truncated. In this case, error 81 will be given. (See Error Handling.)
- For recurring components sorted in descending order, exceptions are returned first and then the master record. Depending on the maxResults limit, it is possible for a master record to be truncated. In this case, error 81 will be given. (See Error Handling.)
Time ZonesTo 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:
In addition, the following commands use the tzid parameter (but not the tzidout):
Updating Parameter ValuesTwo 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-TokensTable 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-
ENTRYstring
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_
rangeError 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_calpropsDoublebooking allowed for this calendar if it is also allowed by the calendar administrator (user.allow.doublebook in the ics.conf).
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:VacationX-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:ProjectXX-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.