RFC 3283
Guide to Internet Calendaring
Guide to Internet Calendaring 📅✨
Okay bestie, here's the vibe check on RFC 3283: Guide to Internet Calendaring 🦋. It's an Informational RFC from June 2002, so it's a guide, not a rulebook. Its authors are B. Mahoney (MIT), G. Babics (Steltor), and A. Taler. It's part of the Network Working Group 🌸. The title block doesn't list any "obsoletes" or "updates" entries, so it doesn't replace or change any older RFC 🙌.
Status of This Memo 💌
Lowkey the most important bit up front: this memo is here to inform the Internet community 💜. It does not specify an Internet standard of any kind, and distribution is unlimited 🌈.
Copyright Notice ©️
The Internet Society owns the copyright here, from 2002, with all rights reserved 📜.
Abstract 🎀
So this doc maps out the Internet calendaring and scheduling landscape: the standards that already exist, the stuff that's still being worked on, and how they all connect 🔗. The goal is to give you context, make these docs easier to understand, and maybe help you build standards-based calendar and scheduling systems 💅. The standards covered are RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP) ✨. The work in progress is "Calendar Access Protocol" (CAP) 🧚. It also talks about the problems these protocols don't solve, which could be future projects 💀.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Concepts and Relationships . . . . . . . . . . . . . . . . . 4
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Fundamental Needs . . . . . . . . . . . . . . . . . . . . . 4
2.2 Protocol Requirements . . . . . . . . . . . . . . . . . . . 5
3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Standalone Single-user System . . . . . . . . . . . . . . . 8
3.2.2 Single-user Systems Communicating . . . . . . . . . . . . . 8
3.2.3 Single-user with Multiple CUAs . . . . . . . . . . . . . . . 9
3.2.4 Single-user with Multiple Calendars . . . . . . . . . . . . 9
3.2.5 Users Communicating on a Multi-user System . . . . . . . . . 10
3.2.6 Users Communicating through Different Multi-user Systems . . 10
4. Important Aspects . . . . . . . . . . . . . . . . . . . . . 10
4.1 Timezones . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Choice of Transport . . . . . . . . . . . . . . . . . . . . 11
4.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Amount of data . . . . . . . . . . . . . . . . . . . . . . . 11
4.5 Recurring Components . . . . . . . . . . . . . . . . . . . . 11
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Scheduling People, not Calendars . . . . . . . . . . . . . . 12
5.2 Administration . . . . . . . . . . . . . . . . . . . . . . . 12
5.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . 12
6.1 Access Control . . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . 12
6.3 Using E-mail . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . 161. Introduction 🌷
Calendaring and scheduling protocols exist to help people get calendar info and book meetings over the Internet 📆. They also help organizations share calendar info online, and give orgs looking for a solution a way to deploy one internally 🏢.
This doc is meant to give you context for those protocol docs, help you understand them, and maybe help you design standards-based calendaring systems 💖. Problems these protocols don't solve, plus security stuff to keep in mind, get covered at the end 🔚.
1.1 Terminology 🧠
This memo uses a lot of the same vocab as iCalendar [RFC-2445], iTIP [RFC-2446], iMIP [RFC-2447], and [CAP] 📖. Think of the definitions below as a warm intro 🫶. The definitions in the actual protocol specs are the official source of truth, so those win if there's ever a mismatch 👑.
Calendar
A collection of events, to-dos, journal entries, and so on 🗓️. A calendar can be a person's or a resource's agenda, or it can be a bundle of data for a more specialized purpose 🌈. Calendars are the basic storage containers for calendar info ✨.
Calendar Access Rights
The set of rules that say who can do what on a given calendar, like reading or writing info 🔐.
Calendar Service
A server app that's running and gives access to a bunch of calendar stores 🖥️.
Calendar Store (CS)
The data store inside a calendar service 🗄️. One service can have several calendar stores, and each store can hold several calendars, plus properties and components that live outside those calendars 📦.
Calendar User (CU)
An entity that accesses calendar info, usually a human 🙋♀️.
Calendar User Agent (CUA)
The software a calendar user talks to, either a calendar service or a local calendar store, in order to get calendar info 📱.
Component
A piece of calendar data, like an event, a to-do, or an alarm 🔔. Info about a component is stored as that component's properties 🧩.
Delegator
A calendar user who has handed off their part in a scheduled calendar component (for example, a VEVENT) to another calendar user, who's called the delegate or delegatee 🤝. Picture a super busy exec sending an employee to a meeting in their place 💼.
Delegate
A calendar user (also called the delegatee) who's been given a spot in a scheduled calendar component (like a VEVENT) instead of one of the attendees, who's called the delegator 🫡. Think of a team member sent to one specific meeting 🙌.
Designate
A calendar user who's allowed to act on behalf of another calendar user 🎀. An example is an assistant who books meetings for their boss 💅.
Local Store
A CS that lives on the same device as the CUA 💻.
Property
A description of one element of a component, such as its start time, title, or location 🏷️.
Remote Store
A CS that is not on the same device as the CUA ☁️.
1.2 Concepts and Relationships 🔗
iCalendar is the language used to describe calendar objects 🗂️. iTIP is a way to use iCalendar for scheduling 📅. iMIP shows how to do iTIP scheduling over e-mail 📧. CAP is a way to use iCalendar to access a calendar store in real time ⚡.
Here's the fun part: calendaring protocols are kinda like e-mail protocols 💌. iCalendar is the equivalent of RFC 2822 📝. iTIP and iMIP are like the Simple Mail Transfer Protocol (SMTP) 📮. CAP is like the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP) 📬. It's giving perfectly matched pairs 🥰.
2. Requirements 📋
2.1 Fundamental Needs 🎯
Here are some scenarios that show what people and organizations need from calendaring and scheduling, at the most basic level 💖.
a] A doctor wants to keep track of all her appointments 🩺.
Need: To read and manipulate one's own calendar with only one CUA 🙌.
b] A busy musician wants to keep her schedule across multiple devices, like an Internet-based agenda and a PDA 🎵.
Need: To read and manipulate one's own calendar, possibly using solutions from different vendors 🛍️.
c] A software dev team wants to schedule their time better by looking at each other's calendar info 👩💻.
Need: To share calendar info between users of the same calendar service 🤝.
d] A teacher wants his students to book appointments during his office hours 🍎.
Need: To schedule calendar events, to-dos, and journals with other users of the same calendar service 📚.
e] A movie theater wants to publish its showtimes for potential customers 🍿.
Need: To share calendar info with users of other calendar services, possibly from several different vendors 🎬.
f] A social club wants to schedule calendar entries effectively with its members 🎉.
Need: To schedule calendar events and to-dos with users of other calendar services, possibly from several different vendors 🦋.
2.2 Protocol Requirements ✨
okay so some of these needs can be handled by proprietary solutions (a, c, d) 💅, but others literally can't (b, e, f) 😭. those last ones show that standard protocols are required for getting at the info in a calendar store and for scheduling calendar entries. on top of that, these protocols need a shared data format for representing calendar info 🎀
these requirements are met by the following protocol specs 🦋
- Data format: iCalendar [RFC-2445]
iCalendar [RFC-2445] is the data format for representing calendar info, meant to be used and exchanged by other protocols 🌸 it can also show up in other places, like a drag-and-drop interface or an export/import feature. all the other calendaring protocols depend on iCalendar [RFC-2445], so every element of a standards-based calendaring and scheduling system will have to be able to interpret iCalendar [RFC-2445] 🔥
- Scheduling protocol: iTIP [RFC-2446]
iTIP [RFC-2446] describes the messages used to schedule calendar events 💜 inside iTIP messages, events are represented in iCalendar [RFC-2445] format, and they carry semantics that mark the message as an invitation to a meeting, an acceptance of an invitation, or the assignment of a task 🍓
iTIP [RFC-2446] messages live in the scheduling workflow, where users swap messages to organize things like events and to-dos ✨ CUAs generate and interpret iTIP [RFC-2446] messages at the direction of the calendar user 🫶 with iTIP [RFC-2446], users can create, modify, delete, reply to, counter, and decline counters to the various iCalendar [RFC-2445] components. users can also request the free/busy time of other people too 👑
iTIP [RFC-2446] is transport-independent, and it has one specified transport binding: iMIP [RFC-2447] binds iTIP to e-mail 📬 on top of that, [CAP] will provide a real-time binding of iTIP [RFC-2446], letting CUAs do calendar management and scheduling over a single connection ⭐
- Calendar management protocol: [CAP]
[CAP] describes the messages used to manage calendars on a calendar store 🌈 these messages use iCalendar [RFC-2445] to describe components like events and to-dos. they make it possible to perform iTIP [RFC-2446] operations, along with other calendar store operations like searching, creating calendars, specifying calendar properties, and specifying calendar access rights 💖
3. Solutions 🧚
3.1 Examples
okay now let's go back to the scenarios from section 2.1 and see how the calendaring protocols can be used 👀
a] the doctor can use a proprietary CUA with a local store, and maybe use iCalendar [RFC-2445] as a storage mechanism 🩺 that would let her easily import her data store into another application that supports iCalendar [RFC-2445] 🌷
b] the musician who wants her agenda from anywhere can use a [CAP]-enabled calendar service that's reachable over the Internet 🎶 she can then use any available [CAP] clients to get at her data 🦋
a proprietary system with a Web-based interface could also work here, but [CAP] would be superior because it lets third party applications in, like PDA synchronization tools 💅
c] the development team can use a calendar service that supports [CAP], and each member can use a [CAP]-enabled CUA of their choice 🧑💻
or, each member could use an iMIP [RFC-2447]-enabled CUA and book meetings over e-mail 📧 the drawback is that it's hard to examine other users' agendas, which makes organizing meetings harder 🙈
proprietary solutions exist too, but they make everyone use clients from the same vendor and block third party applications 🚫
d] the teacher can set up a calendar service and have students book time through any of the iTIP [RFC-2446] bindings 🍎 [CAP] gives real-time access but could need some extra configuration ⚙️ iMIP [RFC-2447] is the easiest to configure, but it may need more e-mail processing 📨
if [CAP] access is provided, figuring out the teacher's schedule is straightforward ✨ if not, it can be determined through iTIP [RFC-2446] free/busy requests 🔍 non-standard methods could also be used, like serving up iCalendar [RFC-2445], HTML, or XML over HTTP 🌐
a proprietary system could also be used, but then all students would need software from one specific vendor 😬
e] [CAP] would be the pick for publishing a movie theater's schedule, since it gives advanced access and search capabilities 🎬 it also makes integration with customers' calendar systems easy 💫
non-standard methods like serving data over HTTP could also work, but they'd be harder to integrate with customers' systems 🥲
a totally proprietary solution would be very difficult, if not impossible, since every user would have to install and use the proprietary software 💀
f] the social club could distribute meeting information as iTIP [RFC-2446] messages, sent via e-mail using iMIP [RFC-2447] 🥳 the club could send meeting invitations, plus a full published agenda 📅
or the club could provide access to a [CAP]-enabled calendar service 🖥️ however, that's more expensive, since it requires maintaining a server 💸
3.2 Systems
the following diagrams show possible systems and how they use the various protocols 🗺️
3.2.1 Standalone Single-user System
a single user system that doesn't talk to other systems doesn't need any of the protocols 🧘♀️ however, it may use iCalendar [RFC-2445] as a data format in some places.
----------- O
| CUA w/ | -+- user
|local store| A
----------- / \3.2.2 Single-user Systems Communicating
users with single-user systems can schedule meetings with each other using iTIP [RFC-2446] 🤝 the easiest binding of iTIP [RFC-2446] to use would be iMIP [RFC-2447], since messages can sit in the users' mail queues, which we assume already exist 📬 [CAP] could also be used.
O ----------- ----------- O
-+- | CUA w/ | -----[iMIP]----- | CUA w/ | -+- user
A |local store| Internet |local store| A
/ \ ----------- ----------- / \3.2.3 Single-user with Multiple CUAs
one user can use more than one CUA to access their calendar 📱 they might use a PDA, a Web client, a PC, or some other device, depending on accessibility 💻 some of these clients may have local stores and others may not. the ones with local stores need to synchronize the data on the CUA with the data on the CS 🔄
-----------
| CUA w | -----[CAP]----------+
|local store| |
O ----------- ----------
-+- | CS |
A | |
/ \ ----------
----------- |
| CUA w/o | -----[CAP]----------+
|local store|
-----------3.2.4 Single-user with Multiple Calendars
one user can have lots of independent calendars 🗂️ for example, one might hold work stuff and another personal stuff 💼🌙 the CUA may or may not have a local store. if it does, it needs to synchronize the CUA's data with the data on both of the CS 🔁
----------
+------------[CAP]------ | CS |
| | |
O ----------- ----------
-+- | CUA |
A | |
/ \ -----------
| ----------
+------------[CAP]------ | CS |
| |
----------3.2.5 Users Communicating on a Multi-user System
users on a multi-user system can schedule meetings with each other using [CAP]-enabled CUAs and services 🏢 the CUAs may or may not have local stores. the ones with local stores need to synchronize the data on the CUAs with the data on the CS 🔄
O -----------
-+- | CUA w | -----[CAP]----------+
A |local store| |
/ \ ----------- ----------
| CS |
| |
----------
O ----------- |
-+- | CUA w/o | -----[CAP]----------+
A |local store|
/ \ -----------3.2.6 Users Communicating through Different Multi-user Systems
users on a multi-user system may need to schedule meetings with users on a different multi-user system 🌍 the services can talk to each other using [CAP] or iMIP [RFC-2447] 🤙
O ----------- ----------
-+- | CUA w | -----[CAP]-------| CS |
A |local store| | |
/ \ ----------- ----------
|
[CAP] or [iMIP]
|
O ----------- ----------
-+- | CUA w/o | -----[CAP]-------| CS |
A |local store| | |
/ \ ----------- ----------4. Important Aspects 🔍
there are a bunch of important aspects of these calendaring standards that people, especially implementers, should be aware of 🧠✨
4.1 Timezones
the dates and times in components can refer to a specific time zone 🌏 time zones can be defined in a central store, or a user can define them to fit their own needs. all users and applications should be aware of time zones and time zone differences ⏰ new time zones may need to be added, and others removed. two different vendors might describe the same time zone differently, like by using a different name 🌀
4.2 Choice of Transport
there are issues to watch for when choosing between a network protocol like [CAP] and a store and forward protocol like iMIP [RFC-2447] 🚚
using a network ("on-the-wire") mechanism may require some organizations to make provisions so calendaring traffic can traverse a corporate firewall on the required ports 🧱 depending on the organizational culture, that can be a seriously challenging social exercise 😅
using an email-based mechanism exposes time-sensitive data to unbounded latency ⏳ large or heavily used mail systems may experience an unacceptable delay in message receipt 📭
4.3 Security
see the "Security Considerations" (Section 6) section below 🔐
4.4 Amount of data 📦✨
okay so, some components can be HUGE 😭 like a component with a massively large attachment. Some apps are low-bandwidth or can only store so much data, so size matters. The maximum component size can be set in [CAP] 🎀. In iMIP [RFC-2447], you can also control it by restricting the maximum size of the e-mail the application is allowed to download 💌.
4.5 Recurring Components 🔁
bestie, in iCAL [RFC-2445] you can write super complex recurrence rules for VEVENTs, VTODOs, and VJOURNALs 🗓️. You have to be careful about interpreting these rules correctly, and you need to pay extra attention so everyone can interoperate using them 🫶. This is a "triple-check your work" situation 💅.
5. Open Issues 🚧
ngl, these protocols don't solve everything yet, and there are a bunch of cute features that just aren't here yet 🥺. Here are some of the biggest ones 👇.
5.1 Scheduling People, not Calendars 🧑🤝🧑
Meetings are scheduled with people, but people can have a bunch of calendars stored in a bunch of different places, and there can be lots of ways to reach them 📱. The calendaring protocols don't try to give you one special way to contact a given person 🙅♀️. Instead, you book 'calendar addresses', which can be e-mail addresses or individual calendars 📧. It's up to the users themselves to make sure the bookings end up in the right place 🎯.
5.2 Administration 🛠️
The calendaring protocols don't cover how to manage users and calendars on a calendar service 😬. Each implementation has to handle that with its own proprietary mechanisms 🔒.
5.3 Notification 🔔
People love being notified about upcoming events, new events, or changes to existing ones 💅. The calendaring protocols don't try to handle this in a real-time system 🙈. What they do give you is the ability to store alarm information on events, which clients can use to show local notifications for upcoming stuff ⏰. To find out about new or changed events, though, clients have to keep poll the data store, which is very much a "check, check, check again" vibe 🔄.
6. Security Considerations 🔐💀
Okay bestie, this part is SERIOUS 😤 so please read it carefully. Dramatic is fine here 🎭.
6.1 Access Control 🗝️
There has to be reasonable granularity in the configuration options for accessing data through [CAP] 🎚️. That way, what should be released to requesters gets released, and what shouldn't be released doesn't 🙅♀️. The details of how to handle this are in [CAP] 📖.
6.2 Authentication 🪪
Access control has to come with a good authentication system, so the right people get the right information 👑. For [CAP], that means authentication is required before any database access happens, and access rights and authentication credentials have to be checked before any information is released 🛡️. [CAP] uses the Simple Authentication Security Layer (SASL) for this 🔑. With iMIP [RFC-2447], this might be a bit of a challenge, because authentication often isn't something store-and-forward protocols think about 📮😅.
Authentication also matters for scheduling 📆, since receivers of scheduling messages should be able to validate who the apparent sender is 🕵️♀️. Scheduling messages are wrapped in MIME [RFC-2045], so signing and encryption are freely available 🎁. For messages sent over mail, that's the only option available 📬. Developers should take extra care implementing the security features in iMIP [RFC-2447], because the whole concept (and the need for it) might feel foreign or not obvious to users 🤷♀️, even though it's essential for the system to work the way people expect 💖.
The real-time protocols do provide for authenticating users, and for keeping that authentication information around so the receiving end-user or server can validate it 🌟.
6.3 Using E-mail 📧💌
Scheduling information can travel over mail without any authentication information attached 😱. That makes e-mail spoofing extremely easy if the receiver isn't checking for authentication 🎭. So it's suggested that implementers think about requiring authentication by default, using mechanisms like the ones described in Section 3 of iMIP [RFC-2447] 🔐. The use of e-mail, plus the potential for anonymous connections, means 'calendar spam' is possible 🗑️. Developers should keep this threat in mind when designing systems, especially ones that allow automated request processing 🤖.
6.4 Other Issues 🚩
The current security context should be obvious to users ✨. The underlying mechanisms might not be clear to them, so efforts should be made to show the current state clearly in the UI 🖥️. A classic example is the 'lock' icon some Web browsers show during secure connections 🔒💜.
With both iMIP [RFC-2447] and [CAP], Denial of Service attacks have to be considered 🚨. Being able to flood a calendar system with bogus requests is very likely to get exploited once these systems are widely deployed 😭. Detection and recovery methods will need to be thought through 🛠️.
Acknowledgments 🫶
Thanks to the following folks, who took part in developing this document 💕:
Eric Busboom, Pat Egen, David Madeo, Shawn Packwood, Bruce Kahn,
Alan Davies, Robb Surridge.References 📚
[RFC-2445] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification - iCalendar", RFC
2445, November 1998.
[RFC-2446] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
"iCalendar Transport-Independent Interoperability Protocol
(iTIP): Scheduling Events, Busy Time, To-dos and Journal
Entries", RFC 2446, November 1998.
[RFC-2447] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol - iMIP", RFC 2447,
November 1998.
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[CAP] Mansour, S., Royer, D., Babics, G., and Hill, P.,
"Calendar Access Protocol (CAP)", Work in Progress.Authors' Addresses 🖋️
Bob Mahoney
MIT
E40-327
77 Massachusetts Avenue
Cambridge, MA 02139
US
Phone: (617) 253-0774
EMail: bobmah@mit.edu
George Babics
Steltor
2000 Peel Street
Montreal, Quebec H3A 2W5
CA
Phone: (514) 733-8500 x4201
EMail: georgeb@steltor.com
Alexander Taler
EMail: alex@0--0.orgFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and handed out to others 📄. Derivative works that comment on or explain it, or help with implementing it, may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind 🎉. The one condition is that the above copyright notice and this paragraph are included on all such copies and derivative works 📌. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations 🚫. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's needed to translate it into languages other than English 🌍.
The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns ♾️.
This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED 🙃. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 🧾.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society 💖.
📦 where this page comes from
- ietf: rfc3283 2002-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms