iCalendar Transport-Independent Interoperability Protocol (iTIP) deprecated
General
What's this about
This article will describe how the iTIP protocol was implemented, which parts of the protocol are missing and where the implementation differs from the standard.
iTIP
iTIP is a standard. It defines "how calendaring systems use iCalendar RFC5545 objects to interoperate with other calendaring systems"1. So basically it's about how to organize, maintain and update calendar events across multiple systems.
Transport
The RFC does explicit not mention a specific transport mechanism for iTIP. The provider implementing the RFC is free to choose. Open-Xchange uses mail to realize the iTIP protocol, efficiently implementing iMIP, too.
Handled components
The iTIP protocol allows to synchronize following components
- VEVENT
- VFREEBUSY
- VTODO
- VJOURNAL
Currently the Open-Xchange Server will only handle the VEVENT component.
Methods
PUBLISH
The PUBLISH method isn't treated in any special way. A VENENT posted over PUBLISH is handled the same way as a REQUEST.
REQUEST
With the REQUEST method initial invites, updates, rescheduling and more is realized. Many of the functionality mentioned in the RFC is build. Not supported is delegating an event to another CU or forwarding to an uninvited CU.
REPLY
A REPLY normally should only transmit the replying attendee status. Nevertheless some calendaring systems edit other properties on the event replying to, too. To avoid e.g. a changed event title, the server will silently drop all changed properties that are not allowed to be changed as defnied in the RFC3.
However changed parameters on the attendee object itself will be taken over. As long as the URI of the attendee doesn't change all other parameters can be edited.
Subsequent scheduling
Please note that when an reply is processed it is possible that further mails will be generated by the server. For example, let's assume an unknown calendar user answered to an event by accepting it and sending you, the organizer, a REPLY. This so called party crasher can be added to the event. Let's further assume you actually add the party crasher. Likewise a normal adding of an attendee, this action will generate a mail to (at least) external calendar users, informing them that a new participant is attending the event.
ADD
The ADD method is implemented as recommended by the RFC.
CANCEL
The CANCEL method is mostly implemented as recommended by the RFC.
Please note that following conditions slightly differs from the RFC and must also be met before a CANCEL is applied: * The sequence number of the transmitted event is equal or greater than the sequence number of the event known by the server * The sender of the mail is the organizer or someone acting on behalf of the organizer, announced by a set sent-by field in the corresponding organizer field
REFRESH
The REFRESH method is implemented as recommended by the RFC.
COUNTER
The COUNTER method is implemented as recommended by the RFC.
DECLINECOUNTER
The DECLINECOUNTER method is implemented as recommended by the RFC.