When you are using the storeevents command for scheduling a group event, there are two parameters that are required:
Each attendee entry can contain several parameters, such as invitation participation status, whether attendance is required 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 |
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 |
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 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 does not process an attendee with a SENT-STATUS value of SENT-SUCCEEDED.
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. |
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 |