Summary

  • Under RFC 2446, an attendee could send a complete alternate VEVENT in a COUNTER, but that object remained a proposal rather than an edit to the organizer-controlled master entry.
  • Organizer disposition, a revised REQUEST, attendee PARTSTAT, transport authentication, local calendar storage, reminders and actual participation were separate states and evidence layers.

Consider a hypothetical meeting scheduled for Monday. One attendee would prefer Tuesday and sends back a complete alternate VEVENT describing the Tuesday meeting. The object may be syntactically complete and operationally useful. It still does not make Tuesday the organizer’s master event.

That boundary follows from the division between the original iCalendar and iTIP specifications. RFC 2445 defined the iCalendar object model: components, properties and parameters used to represent calendar information. RFC 2446 defined the transport-independent scheduling transactions performed with those objects. A complete VEVENT therefore establishes that an alternative can be represented. It does not by itself establish authority to replace shared scheduling state.

The protocol roles are equally important. RFC 2446 distinguishes the Organizer, who initiates the scheduling exchange and controls the master entry, from invited Attendees who participate in it. Those iTIP roles are not the descriptive ROLE parameter on an ATTENDEE property. A value such as chair or required participant describes a participant’s function; it does not confer Organizer authority.

RFC 2446 also separates shared event state from individual participation state. The Organizer controls the master entry and its overall STATUS. An attendee’s PARTSTAT records that particular attendee’s participation status relative to the entry. An attendee can therefore report acceptance, rejection or another participation state without acquiring the right to rewrite the master event for everyone.

The iTIP methods make those boundaries concrete. PUBLISH distributes calendar information without an interactive response. REQUEST asks recipients to process a scheduling object and permits response. REPLY reports attendee status. COUNTER proposes a change. DECLINECOUNTER lets the Organizer reject that proposed change. Each method represents a different transaction rather than a different spelling of the same state transition.

In the hypothetical Monday-to-Tuesday case, the attendee’s COUNTER can contain the complete alternative VEVENT. Yet RFC 2446 still treats the COUNTER as a proposal to the Organizer, not as a direct edit of the Organizer’s calendar. Rejection is expressed through DECLINECOUNTER. Acceptance requires another transition: the Organizer reschedules the entry and sends a new REQUEST to affected attendees. The later RFC 5546, which obsoleted RFC 2446, preserves that division and says that after accepting a counterproposal the organizer’s calendar user agent should send a REQUEST to affected attendees.

SEQUENCE does not turn that negotiation into consent. RFC 2446 uses it to track Organizer revisions. REPLY, REFRESH, COUNTER, DECLINECOUNTER and a delegation REQUEST do not increment it, while ADD and CANCEL do. A reply can therefore legitimately refer to an older Organizer revision. A higher sequence number is evidence of revision history, not proof that every attendee agreed, received the revision or committed the same local state.

Forwarding demonstrates the same control principle. If an attendee forwards an invitation to a calendar user who was not invited, the forwarded message does not add that person to the Organizer’s master attendee list. RFC 2446 leaves that decision with the Organizer and says the forwarding attendee must not alter the event property set. Message reach can expand without transferring master-entry authority.

Store-and-forward delivery introduces another distinction. RFC 2446 anticipates that a CANCEL can arrive before its original REQUEST. It suggests retaining an uncorrelated cancellation with a nonzero sequence number while waiting for a lower-sequence message and permits aging it out if no corresponding message arrives. Transport arrival order therefore cannot automatically be treated as transaction order.

Authentication sits on yet another layer. iTIP is transport-independent. RFC 2447 supplied an email binding, and RFC 6047 later updated that iMIP binding. RFC 2446 identifies spoofing risks for both Organizer and Attendee messages and places authentication and encryption facilities with the transport binding. A parsed COUNTER can show what a message claims to be; it does not alone prove who actually sent it or whether that sender was authorized to act in the claimed role.

The resulting evidence model is deliberately layered. Source message bytes, authenticated sender, role authorization, method and UID, Organizer SEQUENCE, individual PARTSTAT, COUNTER contents, Organizer disposition, revised REQUEST, transport receipt, recipient-side commit, reminder execution and observed participation should not be collapsed into one fact. A visible calendar row or reminder may prove local software state while proving nothing about organizer authorization, global convergence or attendance.

Sources