Summary

  • Revision 21 of the JSCalendar 2.0 draft adds a small but consequential condition: if a Task has no explicit overall progress, at least one participant must have reported progress before the default can be completed.
  • Silence is not failure or work in process, but it is also not completion evidence. Systems should retain the reporting denominator, the values received, the rule version and whether the aggregate was explicit or derived.

Imagine the last column of a project dashboard is empty. No participant has said “completed.” No one has said “failed” or “in process” either. The row nevertheless turns green because every progress value in the empty set satisfies the completion test.

That is the kind of boundary hidden inside a seemingly modest edit to JSCalendar 2.0: A JSON Representation of Calendar Data. Revision 21 arrived on the IETF Datatracker on 2 October 2026. It changes the rule for deriving a Task's default progress when the Task does not carry an explicit overall progress value.

Revision 20, following the wording already published in RFC 8984, said the default was completed if the progress value of all participants was completed. Revision 21 adds an existence test. At least one participant must have a progress property, and every participant with such a property must report completed.

The new words matter because a universal statement over an empty set can be true in formal logic. A programmer, query engine or policy author can therefore read “all progress values are completed” as satisfied when there are no progress values to contradict it. The captured sources do not show that any deployed calendar product made that choice. The revision nevertheless removes the ambiguity at the specification boundary, before an implementation can turn missing evidence into a positive state.

The rule is more precise than “every participant must report.” Participant-level progress is optional. A task can list ten participants, receive progress from two, and derive completed if both reporting participants say completed and the Task itself omits overall progress. The eight silent participants do not automatically block the result. What revision 21 forbids is a completed aggregate with zero qualifying reports.

That denominator belongs in the decision record. “Two of two reporting participants completed” and “two of ten listed participants completed” may produce the same JSCalendar default, but they are not the same management fact. The first number describes the predicate. The second describes observation coverage. A leadership dashboard that presents only the aggregate discards the distinction its operators need most.

The remaining precedence is explicit. First, completion is derived when at least one progress value exists and all supplied participant progress values are completed. If that test fails, any failed participant report makes the default failed. If none failed but at least one is in-process, the default is in-process. If no criterion matches—including the case where no participant reported progress—the fallback is needs-action.

This ordering answers mixed cases. Completed plus failed does not become a majority vote; it becomes failed. Completed plus in-process becomes in-process. Missing values are not invented as failures, in-process reports or completions. They remain missing while the rule operates only on the participant progress values actually present.

The aggregation also applies only when overall Task progress is omitted. If an authorised producer writes an explicit task-level value, the participant-derived default does not overwrite it. That creates a second control question: was the displayed state asserted at task level or computed from participant reports? Two identical words—completed—can have different provenance.

Participant reports have their own preconditions. In revision 21, participant progress is defined only inside a Task. Setting it requires a calendarAddress, and the participant's participationStatus must be accepted. Its base values are in-process, completed and failed, with registered or vendor-specific extensions possible under the draft's rules. Participant cancelled is not one of those base values, even though the Task-level progress vocabulary includes cancelled.

Nor is percentComplete a substitute. The draft treats it as a separate optional integer from zero through 100, available at Task or participant level under their respective definitions. A percentage can support a richer view, but the categorical default is not specified as a numerical average. Systems should not silently turn 100 into completed, or missing percentages into zero, unless a separate local policy says so and records that transformation.

The older standards explain why these distinctions are durable. RFC 5545 separates a VTODO's STATUS and completion timestamp from attendee participation state. RFC 5546 likewise distinguishes the organiser's object state from an attendee's PARTSTAT in scheduling exchanges. JSCalendar's convenient JSON model does not erase the difference between an individual's contribution and the status of the task as a whole.

Transport adds another layer. JMAP Calendars may carry and synchronize calendar data, and CalDAV scheduling has its own authority and delivery rules. A successful API write, accepted scheduling message or current IANA registry entry does not prove that revision 21's aggregation ran in a particular product. The active draft is a CALENDAR EXTENSIONS Working Group document in the IETF stream, intended for Proposed Standard and under AD Evaluation; it is not yet an RFC.

Most importantly, a calendar status is not an outcome receipt. A person can mark a contribution complete without the promised file arriving, a machine can synchronize a Task whose external job failed, and an explicit overall state can be wrong. Revision 21 improves the shared representation by refusing to manufacture completion from no reports. It does not make every supplied report true or prove the work in the world.

Lu Heng's Minimum Initial Specification gives the right architectural scale: the common layer needs only enough deterministic structure to stop absence becoming completion. Running-Code Primacy then asks which draft revision, query, default rule and override path actually ran. Reality Layers prevents a valid scheduling state from acquiring symbolic authority over performance it never observed.

The practical control is an aggregate receipt. Preserve the Task UID and version, explicit overall progress if present, participant count, reporting-participant count, accepted progress values, extension values, predicate order, derived result, software rule version and downstream action. The receipt should say “derived” or “asserted,” not merely repeat the final status.

A tiny existence clause is doing serious institutional work. It says that unanimous evidence requires at least one piece of evidence. Silence may still require follow-up, but it cannot be promoted into success by a convenient default.

Sources