Each attendee entry can contain several sub-parameters, such as invitation participation status, whether attendance is required or not, whether the attendee is a group or not, and so forth. 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. Some differences exist, 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 |
The following table 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 is stored. For group scheduling, only the PARTSTAT and RSVP parameters are relevant.
Parameters |
Purpose |
---|---|
PARTSTAT |
The only required parameter. This shows the attendee's participation status. |
CUTYPE |
Calendar user type. Values are INDIVIDUAL, GROUP |
MEMBER |
List of groups the attendee is part of. |
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 does not process an attendee with a SENT-STATUS value of SENT-SUCCEEDED.
If the attendee is an individual, set CUTYPE=INDIVIDUALin WCAP commands. If one of the attendees is a group, set CUTYPE=GROUP. An additional X-Token, X-S1CS-EXPAND, can be given to specify whether the group is to be expanded or not (TRUE, FALSE).
For example, for a storeevents command:
storeevents.wcap?id-$SEESSIONID&calid=testuser&dtstart=20060402T090000Z& dtend=20060402T100000Z&method=2&attendee=PARSTAT=NEEDS_ACTION^RSVP=TRUE^ CUTYPE=GROUP^X-S1CS-EXPAND=TRUE^testgroup |
When fetched, an expanded group invitation would return and individual record for each group member as well as a record for the group. For example:
ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL ;PARTSTAT=NEEDS-ACTION;CN="Test User1" ;RSVP=TRUE ;X-NSCP-ATTENDEE-GSE-STATUS=2 ;X-S1CS-EMAIL=testuser1@test.com ;MEMBER=testgroup :testuser1 ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL ;PARTSTAT=NEEDS-ACTION;CN="Test User2" ;RSVP=TRUE ;X-NSCP-ATTENDEE-GSE-STATUS=2 ;X-S1CS-EMAIL=testuser2@test.com ;MEMBER=testgroup :testuser2 X-S1CS-GROUP-ATTENDEE;CUTYPE=GROUP ;X-S1CS-EMAIL=testgroup@test.com ;X-S1CS-EXPAND=TRUE :testgroup
If the same group was invited in non-expanded mode, a fetch would result in only the group record being returned, as shown in the following example:
storeevents.wcap?id-$SEESSIONID&calid=testuser&dtstart=20060402T090000Z& dtend=20060402T100000Z&method=2&attendee=PARSTAT= NEEDS_ACTION^RSVP=TRUE^CUTYPE=GROUP^X-S1CS-EXPAND=False^testgroup |
ATTENDEE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP ;PARTSTAT=ACCEPTED;CN="Test Group" ;RSVP=FALSE ;X-NSCP-ATTENDEE-GSE-STATUS=2 ;X-S1CS-EMAIL=testgroup@test.com ;X-S1CS-EXPAND=FALSE :testgroup
If the EXPAND X-Token is not given in the WCAP command, the system will use the internal default, which is specified in the ics.conf parameter group.invite.expand. The request to expand might be overridden if the member size becomes greater than the value specified in the ics.conf parameter calstore.group.attendee.maxsize.
If the CUTYPE is not set in the command, the system will set CUTYPE internally when it discovers the whether the attendee is an individual or a group.
The method parameter describes the type of message used: invitation, response, cancellation.
When there are multiple attendee, 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. |
In addition to these ITIP methods, there is another method used by Calendar Server internally (a non-ITIP method):
256 |
UPDATE |
Used by attendee to update only the attendee’s copy of a group scheduled event. Does not affect anyone else’s calendar data. |
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 causes the default (PUBLISH) to be the presumed action.
In an invitation, three types of messages can 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 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.
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”.
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 the invitation. The uid for the meeting is “event_u1”. The event is created on both attendees’ calendars. Each responds to the event on their own calendar. The response is 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 |