**Session Date/Time:** 28 Sep 2022 04:00

# [CALEXT](../wg/calext.html)

## Summary

The CALEXT working group held an interim meeting to address the long-standing issues surrounding scheduling model differences and mapping between JS Calendar and I-Calendar. The discussion centered on two approaches: "repair scheduling" (where JS Calendar extends I-Calendar's capabilities) and "reuse scheduling" (where JS Calendar strictly mirrors I-Calendar). A key point of contention was the interpretation of the working group's charter regarding backward compatibility and the extent to which JS Calendar should be a superset. Ultimately, the group decided to proceed with the "repair scheduling" model, requiring a robust mapping to I-Calendar through the definition of new I-Calendar properties and an updated iTIP interaction model. Additional decisions included deprecating the `SENT-BY` parameter from JS Calendar, guarding certain participant properties, and clarifying the use of the `other` scheduling method. Several expired drafts were also identified for immediate action.

## Key Discussion Points

*   **JS Calendar to I-Calendar Scheduling Mapping:** The core issue stems from the differing scheduling models between JS Calendar (which separates participant identity from scheduling methods) and I-Calendar (which uses a single calendar address for both). The existing RFC 8984 focused on I-Calendar to JS Calendar mapping, neglecting the reverse, leading to fragmentation concerns.
*   **Charter Interpretation and Scheduling Approaches:**
    *   **"Repair Scheduling" (JS Calendar as a Superset):** Allows JS Calendar to define new scheduling features not directly representable in I-Calendar, with the expectation that I-Calendar would be extended to map these concepts. This was seen as aligning with the initial vision for JS Calendar.
    *   **"Reuse Scheduling" (Same Data Model):** Implies that JS Calendar should not introduce scheduling concepts beyond what I-Calendar currently supports, ensuring direct interoperability without extensions. This was argued to align with a stricter interpretation of the current CALEXT charter.
    *   Neil argued strongly for "repair scheduling," citing benefits for JMAP clients in identifying participants and handling different internal/external URIs (e.g., for iTIP).
    *   Robert raised concerns about processing existing I-Calendar systems if new properties are not universally understood, risking fragmentation. However, Ken clarified that the charter requires mapping to the I-Calendar *format* (potentially with extensions), not necessarily to *existing implementations* that do not understand new properties.
*   **Participant Property Context:** Discussion on whether certain participant properties (`participationStatus`, `expectReply`, `scheduleStatus`) should be "guarded," meaning they only make sense and can be set when a participant has a `scheduleId` or `sendTo` property defined. Neil noted that `participationStatus` might still be relevant for an organizer's internal tracking without external scheduling.
*   **Deprecation of I-Calendar `SENT-BY`:** Mike proposed deprecating the `SENT-BY` parameter in I-Calendar, as it appears unused in implementations and adds unnecessary complexity. It was suggested that if deprecated in a revision to RFC 5545, JS Calendar should drop its explicit mapping.
*   **Clarifying `other` Scheduling Method:** The `other` scheduling method in JS Calendar should be used solely for mapping unknown or unclassified I-Calendar URIs. For new JS Calendar objects, specific vendor extensions should be preferred for non-standard internal URIs, rather than generic `other`.
*   **Expired Drafts:** Several working group drafts (`tasks`, `series`, `subscriptions`, `upgrade`, `vpoll`) were noted as expired on the data tracker. `scheduling-controls` will be allowed to expire.

## Decisions and Action Items

*   **Decision:** The working group will proceed with the "repair scheduling" model for JS Calendar. This means JS Calendar will define a richer scheduling model, and I-Calendar will be extended to provide robust mapping for these new concepts, including an updated iTIP interaction model.
    *   **Action Item (Neil):** Draft a proposal detailing the robust mapping of the "repair scheduling" model to I-Calendar (including any necessary extensions) and describing the iTIP interaction flow, including initial dual-format invitations and upgrade paths for direct communication. This should be a formal draft rather than an email.
*   **Decision:** The concept of the I-Calendar `SENT-BY` parameter will be dropped from JS Calendar. For mapping purposes, if encountered in an I-Calendar object, it will be treated as an unknown I-Calendar property (preserved but not actively utilized or explicitly mapped in JS Calendar).
    *   **Action Item (Robert):** Update the JS Calendar draft to reflect this decision.
*   **Action Item (Robert):** Revise the JS Calendar draft to:
    *   Add `scheduleAgent` and `scheduledFor` properties to `replyTo` and `sendTo`, mirroring their use with the `ORGANIZER` property in I-Calendar.
    *   Introduce "guarding" for scheduling-dependent participant properties (e.g., `expectReply`, `scheduleStatus`), requiring them to be set only if a `scheduleId` or `sendTo` is present, or clarify their independent mapping where appropriate (e.g., for `participationStatus`).
*   **Action Item (Robert):** Update the `jmap-calendars` specification to include references to the newly defined scheduling properties.
*   **Decision:** The `other` scheduling method in JS Calendar should be limited in use to mapping unknown I-Calendar URIs. For new JS Calendar objects, specific vendor extensions should be used for non-standard or internal URIs, rather than the generic `other` method.
*   **Action Item (Robert, Neil, Mike):** Update and unexpire the `tasks`, `vpoll`, and `subscription-upgrade` drafts, respectively, on the data tracker.
*   **Action Item (Ken):** Submit the `subscription-upgrade` draft for publication, after a final check of the working group last call comments and confirming no IPR.

## Next Steps

*   The working group aims to publish a new RFC draft for JS Calendar incorporating the scheduling decisions, targeting for the next IETF meeting.
*   Robert and Mario will continue working on the JS Contact and JS Contact Extensions RFCs, with the goal of reaching Working Group Last Call by the next IETF.