The iCalendar data format has a well defined data model. iCalendar "objects" encompass a set of iCalendar "components" each of which contains a set of iCalendar "properties" and possibly other sub-components. An iCalendar property consists of a name, a set of optional parameters (specified as "key=value" pairs) and a value.
iCalendar components include:
VCALENDARwhich encapsulates a set of other components to form a "calendar"VEVENTwhich represents an eventVTODOwhich represents a task or to-doVJOURNALwhich represents a journal entryVFREEBUSYwhich represents periods of free or busy time informationVTIMEZONEwhich represents a timezone definition (timezone offset and daylight saving rules)VALARMis a sub-component and is used to set alarms or reminders on events or tasks.STANDARDandDAYLIGHTare sub-components used inVTIMEZONEcomponents to represent standard and daylight time onsets and offsets.
Properties include:
DTSTARTwhich represents a start time for a componentDTENDwhich represents an end time for a componentSUMMARYwhich represents a title or summary for a componentRRULEwhich can specify rules for repeating events or tasks (for example, every day, every week on Tuesdays, etc)ORGANIZERwhich represents the calendar user who is organizing an event or assigning a taskATTENDEEwhich represents calendar users attending an event or assigned a task
In addition to this data model and the predefined properties, the specification defines how all those are used together to define the semantics of calendar objects and scheduling. The semantics are basically a set of rules stating how all the components and properties are used together to ensure that all iCalendar products can work together to achieve good interoperability. For example, a rule requires that all events must have one and only one DTSTART property. The most important part of the iCalendar specification is the semantics of the calendaring model that it represents. The use of text, XML or JSON to encode those is secondary.
iCalendar was designed to be extensible, allowing for new components, properties and parameters to be defined as needed. A registry exists to maintain the list of standard extensions with references to their definitions to ensure anyone can use them and work well with others.
New components being worked on include VAVAILABILITY and VPOLL.