CAP is a calendaring and scheduling protocol for operating on iCalendar (RFC 2445) data. It is designed to allow calendar stores (CSs) and calendar clients (CUAs, Calendar User Agents) to interact with one another over an open connection. It is a client-server protocol not unlike the IMAP protocol for communicating with a mail storage server.
There are three parts to CAP:
This is the part your client uses to read and write to the calendar(s) you have access to. It allows you to do things like put a meeting invitation on your calendar, find out when all the members of your group have free time at the same time, so you can schedule a meeting, etc.
The scheduling part of CAP enables you to do things like send meeting requests to other people, and respond to requests and published events you received from other people. This part leans very heavily on the iTIP specification.
CSTP stands for Calendar Server Transfer Protocol. This part specifies things like how to connect to a server, how to tell it who you are and convince it you aren't lying. This is the equivalent to iMIP.
CAP is currently only a draft, not a full RFC.
CAP needs a number of extra iCalendar components (which will be specified in the next version of the iCalendar RFC):
The component that specifies access rights. CAP has a concept of multiple, hierarchical calendars. This component specifies the rights for a calendar.They get treated hierarchically; subcalendars inherit the VCAR components of their parent calendars, which is the only reason there is a hierarchy. subcalendars don't inherit any other components, like VEVENTs, VTODOs or JOURNALs
For example, you might have a calendar for your whole college that only administrators can schedule events in, but everyone can look at it. The Mathematics department might have a sub-calendar that only math professors can write to, but everyone can read it. A person can have multiple calendars.
The wrapper around all CAP commands. It specifies which kind of command this is and what the target calendar(s) are.
This is used to select which components in a calendar are being affected by a command. So you can say ‘Get me all my meetings from calendar X, but only those for today and tomorrow’.
As of August 2001, all we've done is start working on the part of CAP that supports querying a calendar server. That's Net::CAP::SQLmin. We need help implementing the other components that are part of CAP.