**Session Date/Time:** 05 Nov 2024 16:30

# calext

## Summary

The Calext working group meeting at IETF 121 in Dublin covered several topics including the completion status of the Tasks and Subscription Upgrade drafts, a new draft on iTIP with Participants, and progress on the JS Calendar iCalendar mapping draft. The group discussed the approach for the JS Calendar iCalendar mapping draft, including whether to publish it as an experimental RFC or a long-lived draft. Milestones for existing documents were reviewed and updated.

## Key Discussion Points

*   **Tasks and Subscription Upgrade Drafts:** Both drafts are essentially complete, with minor changes to be resubmitted. A new working group last call will be issued for both.
*   **iTIP with Participants:**  This draft specifies how to do scheduling using participants instead of attendees and organizers in iCalendar. It leverages existing properties and defines new ones as needed. A call for adoption will be sent out. A key challenge discussed was keeping participant data synchronized with attendee parameters, and this synchronization needs to be addressed in the RFC.
*   **JS Calendar iCalendar Mapping Draft:**  The draft aims to define how to convert between JS Calendar and iCalendar formats while preserving information. The group discussed whether to publish as experimental RFC versus long-lived draft. The need to address the gap regarding organizer properties for scheduling in JS Calendar was highlighted. The meeting discussed how strict to be on 1 to 1 mapping between the data models. The group also had a discussion about how to handle rich text descriptions, specifically the interaction of the `DESCRIPTION` and `STYLE-DESCRIPTION` properties.
*   **Experimental RFC vs. Long-Lived Draft:**  A discussion ensued regarding the pros and cons of publishing the JS Calendar iCalendar mapping draft as an experimental RFC versus keeping it as a long-lived draft. Concerns were raised that the "experimental" status could deter implementation. It was agreed to gauge community interest on the mailing list. It will remain a draft, but there will be implementation milestones to encourage implementation and marking versions for that purpose.
*   **Charter:** The group discussed if charter revisions are needed for the group and if current drafts are meeting the group's charter commitments. Several in attendance felt that the group was meeting the charter goals well enough and that revisions were not needed.

## Decisions and Action Items

*   **Tasks and Subscription Upgrade Drafts:** Resubmit with minor changes and initiate a new working group last call.
*   **iTIP with Participants Draft:**  Send out a call for adoption. Address the issue of data synchronization between participants and attendees in the RFC.
*   **JS Calendar iCalendar Mapping Draft:** Start a discussion on the mailing list to gauge community interest in implementation and to determine if an RFC number is needed or just designated versions to implement against. Define and propose the criteria for a successful experiment on the mailing list.
*   **Milestones:** Updated milestones for various documents (see Next Steps).

## Next Steps

*   **Tasks Draft:** Submit to ASG by December.
*   **Subscription Upgrade Document:**  Submit to ASG by December.
*   **VPOL Document:** Update milestone to early June of next year.
*   **Calendar Series Document:** Leave as is, and revisit next year.
*   **JS Calendar iCalendar Mapping Document:** Review in March of next year. Start mailing list discussion immediately.
*   **Participant Mapping:** Goal to adopt the draft this month.