This chapter describes design changes in the Web Calendar Access Protocol (WCAP) between Oracle Communications Calendar Server and Sun Java System Calendar Server 6.
The major differences in WCAP design changes between Oracle Communications Calendar Server and Calendar Server 6 include the following:
Not all Calendar Server 6 WCAP commands are supported by Oracle Communications Calendar Server WCAPbis. Even for supported commands, not all parameters are supported.
The calid format, fetch_by_lastmod command, acl parameter, filter parameter, and alarms parameter have changed.
The XML tags used by Oracle Communications Calendar Server for XML output format are different from that of Calendar Server 6.
The text/json format was supported (and used by Convergence) in Calendar Server 6.3, with patch 121657-24, but was never documented. Beginning with Oracle Communications Calendar Server, it is officially supported and documented.
Calendar Server 6 WCAP had specific restrictions on calendarid. In Oracle Communications Calendar Server, calid is just part of the CalendarCollection URI. This is not constructed by WCAP clients. In createcalendar, the server constructs the calid for a given calendar name. As a result, createcalendar no longer accepts the calid parameter. Instead, it has the name parameter as a required parameter. The calid itself is returned in a create, login, or list commands' response, so clients can use it for commands like deletecalendar, get_calprops, set_calprops, and so on. A new X-prop X-S1CS-DEFAULTCALENDAR is returned on get_calprops of the default calendar.
The getting and setting of ACLs has been simplified in Oracle Communications Calendar Server. The scheduling and free/busy ACLs for a user and read/write ACLs for a calendar are completely separated. The acl parameter for set_calprops or create_calendar commands is still used to set read/write/manage acls of a particular calendar. An access control list still consists of a semicolon-separated list of ACEs. Each ACE consists of user/group-identifier:rights-token. The rights tokens can be one of the following:
n: none
r: read
w: read+write+delete
a: read+write+delete+manage
Two new commands, get_accountprops and set_accountprops, have been introduced to get and set account properties, including scheduling ACLs. Scheduling ACLs are also set as a semicolon-separated list of ACEs, where each ACE is a user/group-identifier:rights-token. The rights-token can be:
f: free/busy
s: free/busy and invite
m: all scheduling rights including manage
@ is a special user/group-identifier that can be used for all users. Whether all users includes anonymous users is determined by a server configuration option.
Rights not granted are denied by default. In an ACL string, more specific rights override other rights. That is, rights granted to a specific user are more specific than rights granted to a user as member of a group. Rights granted as part of "all" users setting are considered least specific. If a user is a member of multiple groups, the highest level of access granted individually by any one of the groups is the access level of the user. Levels of nesting within each group are not taken into consideration. A default ACL for all calendar collections is defined by the configuration option davcore.acl.defaultcalendaracl.
The access-control string is returned on a get request only if the user has manage access to the ACLs. If not, related information is returned in the X-PROP X-S1CS-MYRIGHTS. The value for this property is computed from the ACL string to return the access rights pertaining to the logged in user only. Value tokens are the same as those used in calendar and scheduling ACEs.
The get_all_timezones command still returns the same list of time zones returned by Calendar Server 6. But the VTIMEZONE values themselves are not an exact match with those in Calendar Server 6. The server maintains a list of time zone IDs and aliases to be used when generating this information in the timezoneids.txt file.
When events and tasks are stored, the datetime components are no longer converted to Zulu for storing. Instead the passed-in tzid value is tagged to the datetime, if not there already, and the corresponding VTIMEZONE is added to the resource, while storing. On retrieval, the time zone information stored with the resource is used to convert all datetime values to the time zone requested by tzidout parameter or Zulu time.
To support multiple alarms, all the Calendar Server 6 alarm parameters were replaced by a single alarms parameter that takes a compound value.
alarms=VALUE;VALUE
where VALUE has multiple properties separated by CRLF. For example: PROPERTY_NAME:PROPERTY_VALUE%0D%0APROPERTY_NAME:PROPERTY_VALUE and so on.
PROPERTY_NAME might contain PARAMETERS, which are separated by carat and represented by ^PARAM_NAME=PARAM_VALUE^PARAM_NAME=PARAM_VALUE.
New lines in value are represented by /n. Semicolons in value are escaped by using \; characters.
Example:
alarms=TRIGGER:-PT30M%0D%0AREPEAT:2%0D%0ADURATION:PT15M%0D%0AACTION:DISPLAY%0D%0ADESCRIPTION:Breakfast meeting with executive\nteam at 8:30 AM EST; TRIGGER^VALUE=DATE-TIME:19970317T133000Z%0D%0AREPEAT:4%0D%0ADURATION:PT15M%0D%0AATTACH^FMTTYPE=audio/basic:[ftp://example.com/pub/sounds/bell-01] .aud%0D%0AACTION:AUDIO;TRIGGER^RELATED=END:-P2D%0D%0AATTENDEE:[mailto:john_doe@example.com%0D%0ASUMMARY:REMINDER:] SEND AGENDA FOR WEEKLY STAFF MEETING%0D%0ADESCRIPTION:A draft agenda needs to be sent out to the attendees to the weekly managers meeting (MGR-LIST). \nAttached is a pointer to the document template for the agenda file%0D%0AACTION:EMAIL
Clients return all the alarms fetched plus the ones they want to add on in a Store command. To delete all alarms, the alarms parameter with empty value is used. To delete a particular alarm, just the remaining list of the alarms are stored.
Calendar Server 6 did not offer the complicated ANDed and ORed filters. To support these complicated filters, the filter parameter value in fetch was modified to use a XPATH-like syntax. List of attributes that can be searched on include ATTENDEE, ORGANIZER, SUMMARY, DESCRIPTION, LOCATION, CLASS, CATEGORIES just as in Calendar Server 6.
Searching in ALL means a search in the whole Resource CONTENT. No attachment searching is performed.
Organizer is ciny, and category is 1009 or 1000 - ((ORGANIZER='ciny') and ((CATEGORIES='1009') or (CATEGORIES='1000'))) Summary contains new - (contains(SUMMARY, 'new')) Organizer is ciny and location starts with Andro - ((ORGANIZER='ciny) and (starts-with(LOCATION, 'Andro')) Attendee is ciny and partstat needs-action - (ATTENDEE[@PARTSTAT='NEEDS-ACTION']='ciny') Attendee contains ciny and partstat is needs-action - (contains(ATTENDEE[@PARTSTAT='NEEDS-ACTION'], 'ciny'))
This command was used by Oracle Communications Connector for Microsoft Outlook with gettime and fetch_deleted. To do it more accurately and efficiently, fetchcomponents_by_lastmod in Oracle Communications Calendar Server provides the same information in one command. A sync token (X-S1CS-SYNCTOKEN) is also returned to be used for the next sync. The date parameters in fetchcomponents_by_lastmod have been removed in favor of the synctoken parameter. If synctoken is null, a full synchronization is done. Deleted resources are returned in restricted VEVENT or VTODO components with deleted status indicated in the X-S1CS-MODSTATUS property. (In this instance, the VEVENT component is modified to be just a container that returns status.)
This command no longer directly searches for calendars. It searches for users and groups in LDAP that match the search string and then returns the calendars of those entries. As a result, the calid, name, primaryOwner, and searchOpts parameters have been deprecated. The LDAP attributes filter used is configured server-wide. A new error code has been introduced to indicate invalid search string (88). A new X-PROP indicates partial results due to search limit exceeding: X-S1CS-PARTIAL-RESULT-COUNT
Calendar Server 6 WCAP supports the orgCalid, orgEmail, orgCN, and orgUID parameters. Connector for Microsoft Outlook mainly uses these parameters to set the organizer information when a delegatee creates events and tasks on behalf of someone else or to store an invitation from an external organizer. Calendar Server supports orgEmail and orgCN parameters, which are required to support storing of external invitations from Connector for Microsoft Outlook. Oracle Communications Calendar Server does not support orgCalid and orgUid parameters because they are redundant. Additionally, the server fills in the correct organizer information as long as the client sets the correct calendar information by using the calid parameter. That is, if a delegatee is creating on behalf of someone else, the client needs to set the calid value to that of the person on whose behalf the event or task is being created.
Calendar Server does not use all of the older WCAP error codes. See "Error Codes" for the new error codes introduced by Oracle Communications Calendar Server. Failed login and badly constructed commands return an HTTP error and not a WCAP error.
Oracle Communications Calendar Server works with the Calendar Server 6 LDAP schema with some exceptions. See the topic on LDAP schema changes for Calendar Server in Communications Suite Schema Reference.