Calendaring Support

imip-agent aims to provide broad support for the following standards:

The following sections indicate notable deviations or deficiencies in the support for these standards.


The general iCalendar format should be mostly supported, but the interpretation of calendar objects in imip-agent is currently limited to events and free/busy data, and the software does not seek to understand the other object types described in the specification.

The VTIMEZONE component is not interpreted. Instead, TZID properties are expected to provide tz database (tzinfo, zoneinfo, Olson database) identifiers that indicate the time zone or "regime" applying to the indicated datetimes.

The VALARM component is not interpreted since imip-agent does not seek to implement reminders or notifications, although it is conceivable that a mechanism could be implemented to achieve this over e-mail.

Week numbers (BYWEEKNO) are not yet supported in recurring datetimes.

Only the essential scheduling properties are interpreted by imip-agent. Thus, support for attachments, categories, and so on is not provided in the management interface. Such support may eventually be added, and existing calendar clients may, of course, use such features without any restrictions imposed by imip-agent.


Only event and free/busy object types are supported in scheduling.

VTIMEZONE and VALARM are not interpreted.

Delegation (RFC 5546 section 2.1.2) is not yet supported.

Multiple recurrence updates using the THISANDFUTURE attribute on the RECURRENCE-ID property (RFC 5546 section 4.4.5) is not yet supported.

The REQUEST-STATUS property is not yet supported. (See RFC 5546 section 7.3.)

Support is provided in the configuration of imip-agent for interpreting REQUEST messages that should really be COUNTER messages, generated by some mail programs. See the IMIP_COUNTER_AS_REQUEST setting in config.txt.


Since attachments are not supported by the management interface, imip-agent does not generate or interpret the various methods of referencing attachments in exchanged objects. (See RFC 6047 section 4.3.)