Summary

  • PARTSTAT=ACCEPTED records an attendee's participation status in a scheduling object; it does not observe what happened when the event began.
  • Reliable attendance analysis must keep response, representation, revision, delivery and event-observation evidence in separate fields.

At 09:00, the meeting room has an empty chair. The organizer's calendar still shows the missing invitee as accepted. Nothing is broken. The calendar is answering the question it was designed to answer: what participation status is attached to this attendee in this version of the scheduling object? The room is asking a later and different question.

That distinction is easy to lose because “accepted” sounds like an outcome rather than a reply. In RFC 5545, PARTSTAT is defined as a calendar user's participation status. For an event, its ordinary vocabulary includes NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE, and DELEGATED. These values let calendar systems coordinate intentions. They do not instrument a doorway, a conference client, or a person's attention.

Daboo's useful separation of roles

Cyrus Daboo matters to this boundary because his standards record crosses the layers that calendar products often flatten. He was one of the authors of CalDAV, RFC 4791, authored iTIP, RFC 5546, and co-authored CalDAV Scheduling, RFC 6638. His IETF profile lists a wider body of calendaring, contacts, WebDAV, and mail work. CalConnect's 2013 service-award account describes his role in CalDAV and interoperable calendaring as a dated institutional record, not as a claim that any one person invented the system.

The protocol model is more careful than the everyday label. Under RFC 5546, the organizer controls the master scheduling object. The organizer normally starts an attendee at NEEDS-ACTION. The attendee changes the PARTSTAT on their own ATTENDEE property and sends a REPLY; the organizer then incorporates the response. The event's overall STATUS and an attendee's PARTSTAT are different state variables with different authorities.

So an organizer-side ACCEPTED record supports a bounded statement: the current organizer copy carries an accepted response for this attendee address. It does not by itself say who operated the responding client, whether the reply remained current after a change, or what occurred at the event.

One address can hide several actors

iTIP explicitly accommodates representation. An attendee can delegate attendance to another calendar user. A SENT-BY parameter can show that the responding calendar user acted for the named attendee or organizer. An assistant, shared mailbox, automated agent, or delegated participant can therefore be part of a legitimate exchange.

This is not an edge case to erase. It is a warning against treating a calendar address as a biometric identity. Three facts may be different: whose address is on the invitation, who caused the reply to be sent, and who eventually attended. A reporting system that stores only “Alice — accepted” has thrown away the very fields needed to interpret the record.

Acceptance also has a time boundary

Calendar objects change. RFC 5546 uses SEQUENCE for organizer revisions and says a REPLY does not increment it. The sequence carried in a reply identifies the revision to which the attendee responded. Move a meeting from Tuesday to Friday, replace the venue, or alter a recurrence instance and an old acceptance may no longer answer the operational question.

Recurring events make the scope problem visible. A series can have a general response while one occurrence, identified by RECURRENCE-ID, is declined or changed. Counting the series-level ACCEPTED once for every occurrence silently manufactures attendance records that the calendar never asserted.

Servers move scheduling state, not people

RFC 6638 adds another separation. With implicit scheduling, storing, modifying, or removing a scheduling object can cause a CalDAV server to send the required scheduling messages. Incoming messages may be processed automatically. When an attendee reply reaches the organizer, the server can update PARTSTAT; SCHEDULE-STATUS can describe delivery or processing results.

Those are valuable operational receipts. They help explain whether scheduling machinery attempted or completed its part. But server processing is not human action, and message delivery is not event presence. The schedule agent may be SERVER, CLIENT, or NONE. A system that converts successful delivery into “the user confirmed” crosses an authority boundary before the meeting has even started.

The missing column should remain missing

After the event, an organization may need to know who attended—for room safety, professional certification, a recorded vote, paid training, or resource allocation. That question can be legitimate, but its evidence must be commissioned separately. A badge scan has tailgating and lending risks. A conference-client join record measures a session, not attention. A facilitator's roll call can contain mistakes. A signed completion record answers yet another question.

The defensible design is a small evidence ledger: invitation address; response value; responder or representative; organizer revision; recurrence scope; scheduling delivery state; observed event signal; observation method; time window; exception or appeal. ACCEPTED belongs in the response column. If no attendance observation was collected, the event-observation column stays blank.

That blank is not a database defect. It is an honest statement about the limit of the evidence.