iCalendar Transport-Independent Interoperability Protocol (iTIP) deprecated
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. Furthermore, this article will describe internal handling
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.
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.
The iTIP protocol allows to synchronize following components
Currently the Open-Xchange Server will only handle the VEVENT component.
The iTIP protocol describes workflows for the calendar systems on how to handle calendar resources locally. Based on this workflow a calendar system might create, update or delete calendar resources and send scheduling messages to attendees or a organizer of a resources. Such messages are decorated with a designated method that indicates a certain workflow for the calendar system. The methods and their syntax are described below. The iTIP workflow on the Open-Xchange calendar system is fully controllable over the HTTP API. Incoming messages will be recognized and analyzed for the user, displaying human understandable descriptions about the messages content and indicating actions a user might want to perform in the calendar system base on the message.
Even though the protocol is designed for calendar systems to interoperate, situations will arise in which the user must finally decide what to do. Such situation can be triggered due technical problems, such as a concurrent modification of a calendar resource from third party calendar agents over CalDAV, or simply when the calendar system can't decide in the name of the user. Later situation might differ from the role of the user.
Whenever an attendee is invited to a new appointment the calendar system can't decide for the user if she wants to participate or not. Therefore the system will prompt to the user whether to accept, tentative accept or to decline the invitation. Another typical scenario for additional interaction from the attendee is when an already accepted appointment gets rescheduled. The attendee might have no other conflicting appointment in his calendar but the calendar system doesn't know about e.g. end of business times. So instead of auto-re-accepting the appointment the user has to decide about his participation.
Event though the organizer is the single point of change regarding the events properties like description or location, she may will get a response which needs attention from her. Such a case is for example when an uninvited attendee responses to a invitation. This might be a legal response in case of a delegation but can also happen when an scheduling message(iMIP) is forwarded to third party, that replies. The calendar system however can't decide if this is a legal response and the uninvited attendee shall be added to the event (triggering subsequent scheduling messages) or if this message shall be ignored.
Working on behalf of
Starting with v7.10.6 of the Open-Xchange server the working "on behalf" of another user scenario was extended. Whenever a user decides to share her calendar and her inbox to another internal user the later is allowed to handle the iTIP workflow on behalf of the first. This is frankly speaking the secretary function where a manager leaves the calendar management to her secretary. When the secretary is working on behalf of the manager, permissions to the underlying mail and the calendar folders will be checked and processing is only possible if enough permissions in both exist. Scheduling messages sent by the secretary will be announced as "on behalf". For example a invitation created by the secretary will generate a message to the organizer saying that he "sent an invitation on your behalf". Attendees for that invitation will receive a mail saying that the secretary "created an event on behalf" of the manager. Both mails will be sent using the managers mail account.
The PUBLISH method isn't treated in any special way. A VENENT posted over PUBLISH is handled the same way as a REQUEST.
With the REQUEST method initial invites, updates, rescheduling and more is realized. Many of the functionality mentioned in the RFC is build into the software. Not supported is delegating an event to another CU or forwarding to an uninvited CU.
Please note that when an request is processed it is possible that further mails will be generated by the server and send back to the organizer of the event. This will normally happen if an attendee updates her status on the incoming event by e.g. accepting an invitation. See also the REPLY method.
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 defined in the RFC2.
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.
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.
The ADD method is implemented as recommended by the RFC.
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
The REFRESH method is implemented as recommended by the RFC.
The COUNTER method is implemented as recommended by the RFC.
The DECLINECOUNTER method is implemented as recommended by the RFC.