Every time you send a meeting invite, accept a calendar event, or subscribe to a public holiday feed, you're relying on RFC 5545. It defines the iCalendar data format — those .ics files that quietly serve as the universal lingua franca of scheduling. Despite being one of the most widely deployed data formats on the internet, most engineers have never read the spec that makes it all work.

RFC 5545 is actually the second generation of the iCalendar spec, obsoleting RFC 2445 (1998). The original emerged from the Calendaring and Scheduling (calsch) IETF working group, born out of a practical frustration: in the mid-1990s, every calendaring product spoke its own proprietary format. Lotus Notes couldn't talk to Microsoft Exchange, which couldn't talk to anything else. The vCalendar format from the IMC (Internet Mail Consortium) existed but was too limited for real interoperability.

The core design is deceptively simple. An iCalendar object is a plain-text stream of BEGIN:/END: blocks containing property-value pairs. A calendar is a VCALENDAR, events are VEVENT, to-dos are VTODO, and free/busy data is VFREEBUSY. Properties like DTSTART, DTEND, SUMMARY, and RRULE carry the actual data. The format inherits its line-folding conventions from vCard — lines longer than 75 octets get folded with a CRLF followed by a single whitespace character.

The most complex and arguably brilliant part of the spec is recurrence rules (RRULE). This single property can express patterns like "every second Tuesday of the month" or "yearly on the last weekday of March" using a compact grammar:

• FREQ=WEEKLY;BYDAY=MO,WE,FR — every Monday, Wednesday, Friday
• FREQ=MONTHLY;BYDAY=2TU — second Tuesday of each month
• FREQ=YEARLY;BYMONTH=3;BYDAY=-1FR — last Friday of March, yearly

Combined with EXDATE (exception dates) and RDATE (extra dates), this system can model nearly any human scheduling pattern. Getting the implementation right, however, is notoriously tricky — recurrence expansion across timezone transitions and daylight saving changes has been a source of bugs in every calendar application ever written.

Timezones are handled with embedded VTIMEZONE components rather than simple UTC offsets. Each VTIMEZONE contains STANDARD and DAYLIGHT sub-components with the actual transition rules. This was a deliberate choice: a meeting at "3 PM New York time" needs to survive future DST rule changes. The spec allows (and modern practice prefers) referencing the IANA timezone database via TZID, but the embedded rules provide a self-contained fallback.

One key design decision: iCalendar is a data format, not a protocol. The spec deliberately separates representation from transport. You can email an .ics file (RFC 6047), serve it over HTTP as a subscription feed, or use CalDAV (RFC 4791) for full read-write synchronization. This separation is why iCalendar survived the transition from email-centric scheduling to cloud calendaring — the transport changed, but the data format didn't.

A subtle but important property is UID — every event gets a globally unique identifier. When you update an event, the UID stays the same but the SEQUENCE number increments. This is how your calendar app knows that an updated invite replaces the original rather than creating a duplicate. Getting UID and SEQUENCE handling wrong is the source of the duplicate-event bugs that still plague calendar implementations today.

The spec also defines an ATTENDEE property with participation status (PARTSTAT) — accepted, declined, tentative, delegated. The entire RSVP workflow that feels native to Google Calendar or Outlook is modeled in this 2009 text document, transmitted as plain-text properties in a format that could be read with cat.