Strict vs “usefully strict” ICS validation
Why this note exists
Calendar interoperability has always lived in the uncomfortable space between what the specification says and what real calendar clients actually accept. The latter is often a moving target. Recently, reports surfaced that Microsoft’s New Outlook began enforcing RFC 5545 far more strictly than previous versions. A concrete example — involving the ordering of VALARM components inside a VEVENT — can be read in a detailed write up from (Sanford Whiteman). When calendar generators put VALARM before properites like LOCATION, New Outlook may ignore the out-of-order properties.
This note explains how we think about that boundary at CorrectICS: when to be strict, when to be permissive, and why usefully strict validation matters more than ever.
The problem with binary “valid / invalid” thinking
On paper, iCalendar validation is simple: RFC 5545 defines what is valid, and anything else is not.
In practice, the ecosystem evolved very differently.
For over two decades:
- Major calendar clients tolerated malformed or out-of-order properties
- Popular libraries and validators followed client behavior, not the spec
- “Invalid but works everywhere” became an accepted category
This wasn’t negligence — it was survival. Strict validators that rejected files users could successfully import felt wrong, even if they were technically correct.
As a result, most tooling converged on a permissive baseline.
Why permissive parsing became the norm
Three incentives pushed the ecosystem in this direction:
-
Client behavior defined reality If Outlook, Google Calendar, and Apple Calendar all accepted a file, rejecting it felt pedantic.
-
Interoperability mattered more than purity ICS files are often generated automatically (emails, links, CRM systems). Breaking imports created immediate user pain.
-
RFC enforcement lagged implementation Many parts of RFC 5545 are precise, but historically unenforced. Validators mirrored that enforcement gap.
The New Outlook inflection point
New Outlook’s rewritten ICS parser enforces RFC 5545’s requirement that all VEVENT properties appear before any VALARM components.
Files that previously worked everywhere now silently lose data (for example, missing LOCATION fields).
From a standards perspective, Outlook is correct.
From an ecosystem perspective, this is disruptive.
The key lesson is not “Outlook is strict.” It’s that assumptions about permissive behavior are no longer safe.
Why many validators missed this
Most validators — including early versions of CorrectICS — did not flag this ordering issue.
That wasn’t an oversight in parsing logic. It was a design decision shaped by history:
- No major client enforced this rule
- Reference libraries ignored ordering
- Invalid ordering had no observable impact
In other words, there was no signal that this violation mattered.
New Outlook changed that.
What “usefully strict” means to us
At CorrectICS, we distinguish between three categories:
1. Hard violations
These are issues that cause imports to fail or data to be dropped in at least one major client.
- Always flagged as errors.
2. Latent violations
These violate the RFC and are likely to break as clients tighten enforcement.
- Flagged with elevated warnings and clear explanation.
3. Benign deviations
Technically invalid, but consistently tolerated across clients with no data loss.
- Flagged informationally, not as blocking errors.
The VALARM ordering issue moved from category (3) to category (1) overnight.
Our job is to track — and communicate — those shifts.
What changed in CorrectICS
Following the New Outlook behavior change:
- We updated validation to detect invalid
VEVENT/VALARMordering - We escalated the severity to reflect real-world breakage
- We added targeted messaging explaining why this now matters
This isn’t about being more pedantic. It’s about being more accurate.
Why this distinction matters going forward
- “Works today” is no longer a guarantee
- Validators need to reflect client reality, not just historical behavior
- Binary valid/invalid signals are insufficient
Usefully strict validation is about giving developers advance warning, not surprise failures.
That’s the line we aim to walk.
Closing thought
RFCs don’t change often. Implementations do.
As clients get stricter or more flexible, the cost of hidden invalidity rises. Validators that understand why files worked in the past — and why they may stop working — become more valuable than those that simply quote the spec.
That’s the perspective CorrectICS is built around.