Attendee Parameter

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

Examples of WCAP Attendee Entries

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.

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.

Method Parameter

The method parameter describes the type of message used: invitation, response, cancellation.

For group scheduling, specify one of the following ITIP methods:

In addition to these ITIP methods, there is another method used by Calendar Server internally (a non-ITIP method):

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