Application Level commands used for scheduling
To implement scheduling, a CAP server maintains an incoming schedule queue for each calendar in the system. Once a request in the queue has been handled by the server, it's either rejected or accepted into the calendar. The calendar server may possibly seek user input as to whether to accept the request. See section 2.2 of the CAP draft for more information.
Many of the scheduling commands are not fully elaborated in the current CAP draft as of early May, 2001. The draft says that the commands will behave essentially in the same ways as they do in iTIP (RFC2446).
The application-level scheduling commands are:
PUBLISH
REQUEST
REPLY
ADD
CANCEL
REFRESH
COUNTER
DECLINECOUNTER
Section 2.8 of the CAP draft says that iTIP is an indirect way to manipulate calendar components, while CAP is a direct way. If I understand this right, that means that the only difference is whether the messages are directly modifying data on a calendar server, or merely bouncing around among calendar clients. Section 7.2.3 of the CAP draft has some examples of how these methods work in the context of client-server communication.
 | I'd love it if someone could clarify some of this. Patches welcome. |
PUBLISH
The PUBLISH method is used to notify calendar users of an event that can be added to their schedule. When a CUA receives a PUBLISHed event, the user can choose to add this scheduled event to his/her list of booked events (the events in his/her own calendar). If the event isn't MODIFYed in the user's calendar to METHOD:CREATE, it should be METHOD:DELETEd. See CAP draft section 7.2.2.2 for more details.
REQUEST
The REQUEST method is used to notify calendar users of an event that can be added to their schedule. This should be handled like PUBLISH, except that it only goes to ATTENDEEs of the event. See CAP draft section 7.2.2.3 for more details.
REPLY
The REPLY method is used to reply to an event request. See CAP draft section 7.2.2.4 for more details.
ADD
The ADD method is used to add one or more instances to an existing event. See CAP draft section 7.2.2.5 for more details.
CANCEL
The CANCEL method is used to cancel an already-booked event. See CAP draft section 7.2.2.6 for more details.
REFRESH
The REFRESH method is used to request an updated copy of an event from a calendar server. See CAP draft section 7.2.2.7 for more details.
COUNTER
The COUNTER method is used to propose an alternate time, date, location, et cetera for a requested event. See CAP draft section 7.2.2.8 for more details.
DECLINECOUNTER
The DECLINECOUNTER method is used to refuse a counterproposal for an event. See CAP draft section 7.2.2.9 for more details.