Calendar Server Notifications

There are two parts to the format of an Calendar Server notification:

• The event reference– A URL identifying the event.

• The payload– The data describing the event. Three different payload formats are supported: binary, text/calendar, and text/XML.

There are two types of calendar notifications:

• Alarm Notifications– relay reminders

• Calendar Update Notifications– distribute changes to the calendar database

Alarm Notifications

Alarm notifications relay reminders. They are published by the csadmind daemon whenever it wants to send a reminder. The default subscriber for these alarms in Communications Services is the csnotifyd daemon. Notifications consumed by csnotifyd have a binary payload and are acknowledged (reliable).

Additionally, the server can be configured to generate one additional notification for each reminder, which can be consumed by a third party notification infrastructure.

Table 5–1 shows the configuration variables that enable these notifications.

caldb.serveralarams.
binary.url

enp:///ics/
alarm

caldb.serveralarms.
binary.enable

caldb.serveralarms.url

caldb.serveralarms.
contenttype

caldb.berkeleydb.
alarmretrytime

Event URL parameters are the same for either one:

• calid - Calendar ID

• uid - Component, either event or todo (task) ID

• rid - Recurrence ID

• aid - Alarm ID

• comptype - An event or a todo (task)

• URI

Calendar Update Notifications

Calendar update notifications distribute changes to the calendar database. They are published by the cshttpd or csdwpd daemons whenever a change is made to the database (if the notification is enabled for this type of change).

There are eleven types of notifications. Table 5–2 lists each type of calendar update notification, it’s ics.conf parameters, and their default values.

caldb.berkeleydb.ensmsg.refreshevent

caldb.berkeleydb.ensmsg.refreshevent.
url

caldb.berkeleydb.ensmsg.refreshevent.
contenttype

no

enp:///ics/caleventrefresh 

text/xml

caldb.berkeleydb.ensmsg.replyevent

caldb.berkeleydb.ensmsg.replyevent.
url

caldb.berkeleydb.ensmsg.replyevent.
contenttype

no

enp:///ics/caleventreply

text/xml

caldb.berkeleydb.ensmsg.createcal

caldb.berkeleydb.ensmsg.createcal.
url

yes

enp:///ics/calendarcreate

caldb.berkeleydb.ensmsg.deletecal

caldb.berkeleydb.ensmsg.deletecal.
url

yes

enp:///ics/calendardelete

caldb.berkeleydb.ensmsg.modifycal

caldb.berkeleydb.ensmsg.modifycal.
url

yes

enp:///ics/calendarmodify

caldb.berkeleydb.ensmsg.
createevent

caldb.berkeleydb.ensmsg.
createevent.url

yes 

enp:///ics/caleventcreate

caldb.berkeleydb.ensmsg.
modifyevent

caldb.berkeleydb.ensmsg.
modifyevent.url

yes 

enp:///ics/caleventmodify

caldb.berkeleydb.ensmsg.
deleteevent

caldb.berkeleydb.ensmsg.
deleteevent.url

yes 

enp:///ics/caleventdelete

caldb.berkeleydb.ensmsg.
createtodo

caldb.berkeleydb.ensmsg.
createtodo.url

yes 

enp:///ics/caltodocreate

caldb.berkeleydb.ensmsg.
modifytodo

caldb.berkeleydb.ensmsg.
modifytodo.url

yes 

enp:///ics/caltodomodify

caldb.berkeleydb.ensmsg.
deletetodo

caldb.berkeleydb.ensmsg.
deletetodo.url

yes 

enp:///ics/caltododelete

Event URL parameters include:

• calid - Calendar ID

• uid - Component, either event or todo (task) ID

• rid - Recurrence ID

Advanced Topics

Normally, ENS notifications for attendee replies and organizer refreshes are published to the caldb.berkeleydb.ensmsg.modifyevent topic along with other modifications. By setting the ics.conf parameter caldb.berkeleydb.ensmsg.advancedtopics to “yes” (the default is “no”), the ENS notifications can be published to separate modify, reply and refresh topics. This allows the consumer of the notification to understand more precisely what type of transaction triggered the notification.

Table 5–3 shows the topics ENS publishes notifications to depending on the setting of the ics.conf parmeter caldb.berkeleydb.ensmsg.advancedtopics.

caldb.berkeleydb.ensmsg.modifyevent
caldb.berkeleydb.ensmsg.refreshevent
caldb.berkeleydb.ensmsg.replyevent

caldb.berkeleydb.ensmsg.modifyevent

WCAP appid parameter and X-Tokens

When ENS sends out notifications of modifications made to existing events, it returns two X-Tokens with the notification, X-NSCP-COMPONENT-SOURCE and X-NSCP-TRIGGERED-BY.

The contents of the X-NSCP-COMPONENT-SOURCE X-Token varies depending on who originated the event and the absence or presence of the appid parameter in the original WCAP command that requested the event.

If the appid parameter is present in the original WCAP command, ENS returns its value in the X-NSCP-COMPONENT-SOURCE X-Token.(Only certain commands take the appid parameter. See the Calendar Server Programmer’s Manual for further information on the appid parameter.) Using this mechanism, applications can “tag” ENS notifications in order to detect which ones it originated. The value of the appid command is a character string of the application’s choosing. If the appid parameter is missing, standard values are assigned to the X-Token depending on the origin, see Table 5–4 that follows for the standard values).

The X-Token, X-NSCP-TRIGGERED-BY holds the name (uid) of the organizer or attendee that triggered the notification regardless of the absence or presence of the appid parameter.

Table 5–4 shows the effect of the presence of the appid parameter in WCAP commands on the value of the X-Token X-NSCP-COMPONENT-SOURCE.