CAP is a calendaring and scheduling protocol for operating on iCalendar (RFC2445) data. It's designed to allow calendar stores (CSs) and calendar clients (CUAs, Calendar User Agents) to interact with one another over an open connection. It's a client-server protocol not unlike the IMAP protocol for communicating with a mail storage server. CAP servers conventionally listen on port 5229.
In addition to enabling communication between a CS and a CUA, CAP also specifies that CSs should be able to speak CAP to one another. In such a case, one CS will act like a client to another CS so that they can share data.
From the CAP draft:
+-----+ +-----+
| | CAP | | CAP
CUA1------| CS1 |----------| CS2 |--------- CUA2
| | | | A
| | | | |
| | | | |
+-----+ +-----+ |
| IMIP |
+--------------------------------+ |
CAP's protocol model has three basic parts: CSTP (Calendar Server Transfer Protocol), which is a transport-level protocol; CAP calendaring commands; and CAP scheduling commands. These last two are application-level commands. CAP clients and servers embed iTIP and iCalendar objects within their application-level commands.
There's more detail later in this document about these commands, but for right now, all you need to know is that calendaring just covers keeping track of what a user's already committed to. Scheduling is the process of organizing events among users, and it's slightly more complicated.
Each calendar on a CAP server has a URL that looks like: cap://some.server.name/relcalid. The "relcalid" portion is referred to, unsurprisingly, as a relative calendar ID.
Calendar stores have a whole host of properties, which are detailed in the CAP draft section 11.1. These are, more or less, global values for the server. See page 42 of the CAP draft for an example of how they're used.
Calendars also have their own properties, which are extensions to iCalendar. They're listed in CAP draft section 11.2. These properties cover things like local language, character set, default access permissions, calendar name, etc. See the draft for a full list.
CAP assumes that each calendar user (CU) has a User Principal Name, or UPN; this is usually an RFC822-compliant email address. In some cases, it's not--- notably when a CUA or CS wants to do anonymous authentication.
CAP also supports the concept of user groups. User groups (UGs) also have UPNs, but calendar servers should be able to expand a UG to get a list of the CUs in it. UGs can be nested, and they can be static (set once by the calendar server) or dynamic (for example, a mailing list's members). See CAP draft 2.4.3 for more info.
CAP sets access rights on each element in a calendar; these are often referred to as calendar access rights (CAR), and they occur inside VCAR elements. VCAR is a new type of iCalendar component specified in CAP draft section 2.7.
VCAR elements grant certain privileges to particular users (most commonly the calendar owner), and they deny privileges to other users. Essentially, they're access control lists (ACLs). A VCAR element looks like this:
VCAL HERE 2.4.4.2 |
Actually figuring out who should have what rights to a calendar is not covered by CAP; that task is left up to the calendar server.
CAP assumes that in some cases, a calendar server will get its user information from a directory service such as LDAP or NIS. User authentication is a standard part of a CAP session (see below for more detail).
CAP supports SASL (RFC2222) negotiation of an encryption protocol for transport layer security (TLS). Servers don't have to support TLS, but those that do have to support at least TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. (If that doesn't make sense to you, just know this: CAP servers can encrypt their sessions using SSH-style encryption.)
For more information on users, authentication, and security, see section 2.4 of the CAP draft.
This is a state diagram of what happens in a typical CAP session from the CAP draft, section 3.
STARTTLS /
CAPABILITY
+-------+
| | +---------------+
| +-----------+ AUTHENTICATE | |
+-->| Connected |-------------->| Authenticated |
+-----------+ | |
| +---------------+
| |
| | +-----+
| V | |STARTTLS /
| +---------------+ |IDENTIFY
| | |<-+
| | Identified |<-----+
| +--------| | |
| | +---------------+ |
| | | command|
V |DISCONNECT | completes|
+--------------+ | | |
| Disconnected |<--+ | |
+--------------+ |SENDDATA | ABORT
A | |
| V |
| DISCONNECT +---------------+ |
+--------------------| Receive |------+
| |<--+
+---------------+ |
| |
+----+
CONTINUE
|
Each session that's established has a session id that's the same as the UPN of the currently connected user. For more detail on how this works, see CAP draft section 2.4.6.