RFC 5546: iCalendar Transport-Independent Interoperability Protocol (iTIP)
In plain English — editorial summary, not part of the RFC
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems. The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK]
Document record
- Document ID
- RFC5546
- Published
- December 2009
- Authors
- C. Daboo
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- app
- Pages
- 133
- Also known as
- —
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4791Calendaring Extensions to WebDAV (CalDAV)Updated
March 2007
- RFC 2739Calendar Attributes for vCard and LDAPUpdated
January 2000
- RFC 6868Parameter Value Encoding in iCalendar and vCardCurrent
February 2013
- RFC 7808Time Zone Data Distribution ServiceCurrent
March 2016
- RFC 8984JSCalendar: A JSON Representation of Calendar DataCurrent
July 2021
- RFC 9922A Common YANG Data Model for SchedulingCurrent
March 2026
- RFC 5550The Internet Email to Support Diverse Service Environments (Lemonade) ProfileCurrent
August 2009
- RFC 5551Lemonade Notifications ArchitectureCurrent
August 2009
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?