Session Date/Time: 28 Sep 2022 04:00

CALEXT

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.