Summary

  • Revision 08 of the iCalendar extensions draft introduces OWNER as a participant role, but says the role is indicative only and must not by itself grant authority to change a calendar object.
  • JMAP Calendars shows the missing control surface: an owner-role participant must match one of the user's account identities, and a write still depends on current calendar rights and event constraints.
  • Parsing the label, accepting the mutation, sending scheduling messages, remote processing, and a participant seeing the change are separate receipts.

The dangerous calendar entry is not necessarily malformed. It may be perfectly valid, pass every parser, and display an authoritative-looking owner badge. The failure begins when software promotes that descriptive field into a permission.

Revision 08 of the iCalendar extensions draft adds an OWNER participation role. Its stated purpose is meaningful: an owner can make changes affecting all participants, such as rescheduling an event or adding and removing attendees and roles. Then the draft draws the line that matters. The role is only indicative, its semantics depend on the calendaring exchange protocol, and an implementation must not grant change authority solely because the role appears in the object.

That sentence separates a claim carried by data from power exercised by a system. The distinction is familiar in access control, but calendar software makes it easy to miss. A role arrives beside dates, participants, recurrence rules and locations. Because the rest of the record is actionable, the role can look actionable too.

A portable claim crosses boundaries that authority does not

RFC 5545 gives iCalendar a portable representation for calendaring and scheduling information. Portability is precisely why the role cannot carry universal permission. The same record may pass through files, mail, synchronization services, calendar stores and exchange protocols whose identity and rights models differ.

The extension draft does not define what OWNER means for CalDAV. It says so explicitly. Recognition of the token therefore cannot safely become a guessed write rule. A receiver can preserve and display the role while declining to infer an authority model that the surrounding protocol never established.

Nor would eventual IANA registration change that. The iCalendar registries coordinate names, references and status. A registry entry would tell implementations which specification defines OWNER; it would not authenticate the participant, bind the participant to an account, or authorize a mutation.

This is the same boundary that Minimum Initial Specification protects. A common format should establish the minimum interoperable meaning without absorbing every future policy decision. OWNER can be common vocabulary. The grant remains local to the protocol and the authority that operates it.

JMAP makes the missing steps visible

The active JMAP Calendars draft supplies a concrete example. A user counts as an event owner only when two conditions meet: a Participant has the owner role, and that Participant corresponds to one of the user's ParticipantIdentity records in the account.

Even that conjunction is not a universal capability. Calendar rights still constrain the operation. mayWriteOwn permits a user to create, modify or destroy an event only in the calendars where that right applies and only when the user owns the event or the event has no owner. mayWriteAll, mayRSVP, mayShare and mayDelete describe different powers. They should not be collapsed into one “owner” switch.

The distinction becomes operational in CalendarEvent/set. The server must enforce the rights returned in each calendar's myRights and reject a disallowed change with a forbidden error. That result is the authority receipt. The role is one input to the decision, not the decision itself.

Other constraints can narrow the result again. If an event copy is not the scheduling origin, clients must restrict edits to per-user properties even if the surrounding calendar rights appear broader, because a later authoritative scheduling update may overwrite the copy. Privacy, recurrence, calendar membership and origin state can all change what a particular write is allowed to mean.

The resulting evidence chain is deliberately longer than a badge:

Stage What it establishes What remains open
Parse OWNER is present in valid calendar syntax Who asserted it and whether it is current
Identity match The participant maps to an account identity Rights over this calendar and event
Rights evaluation A current rule permits a defined operation Whether the mutation succeeded
Mutation receipt The server accepted a state change Whether scheduling was dispatched
Delivery receipt A message reached another system Whether it was applied or shown
Participant readback A participant can observe the update Durable convergence across every copy

A successful save is not a successful meeting change

JMAP Calendars lets a client request scheduling messages when changing a scheduled event. That request sits beside the mutation; it is not proof that every participant received the result. A server can accept a local update, choose recipients, queue messages, encounter transport failure, face rejection at a remote service, or deliver to a copy that a user never reads.

RFC 6638 and RFC 4791 show why storage and scheduling need separate treatment. A calendar collection, a user's scheduling authority, an inbox or outbox, and the eventual attendee copy are related surfaces, not one atomic fact. Leadership reporting should therefore resist phrases such as “the owner changed the meeting” unless the evidence identifies which layer changed.

The strongest compact record is a linked set of receipts: source object hash; participant and role location; account-identity match; rights version; origin and privacy state; policy decision; mutation identifier and before/after hashes; scheduling decision; recipient set; transport outcome; and participant-visible readback. None needs to expose event content. Digests, stable identifiers and scoped results can preserve accountability without turning calendars into surveillance logs.

Standards progress is not operating proof

The Datatracker record shows revision 08 as a CALENDAR EXTENSIONS Working Group Internet-Draft intended for Proposed Standard, with publication requested. The history and shepherd write-up document its process. It still has no RFC number. The requested IANA changes and the behavior of deployed products must not be reported as complete facts.

The draft also updates GEO, COLOR and VLOCATION, and adds COORDINATES and SHOW-WITHOUT-TIME. Those changes illustrate a useful discipline. SHOW-WITHOUT-TIME affects presentation, not the temporal span used for scheduling and conflict checks. The document repeatedly refuses to let a display cue rewrite a deeper state. OWNER follows the same logic: presentation and declared role cannot silently rewrite authorization.

Running-Code Primacy directs attention to the actual decision path: which identity resolved, which rights were loaded, which rule ran, and which write was accepted. The Policy Mirror reveals where discretion hides—in role rendering, identity lookup, rights caching, origin classification and delivery defaults. Reality Layers supplies the final test: syntax, status, authority and outcome must remain separate even when one interface paints them all green.

The leadership question is therefore not “does the calendar say owner?” It is “which system granted which operation, against which current state, and what later evidence shows the change reached the people who depended on it?”

Sources