# CALEXT at IETF118   {#calext-at-ietf118}

Tuesday 2023-11-07 14:00 CET (13:00 UTC)

## Agenda   {#agenda}

Intro and Notewell: 5 min

*   Agenda bash - HTML descriptions

## Errata: 5 min   {#errata-5-min}

*   Ken looking at ERRATA to check - Mike not online.
*   Robert will be a bit late in meeting
*   Francesca: ERRATA come to WG mailing list, and also to AD. Just
    checking status.
    *   Also fine to not discuss now and take to mailing list.

*   ical tasks and subscription upgrade are expired and in WGLC. Need to
    talk to Mike.

## ical tasks and subscription upgrade: 10 min   {#ical-tasks-and-subscription-upgrade-10-min}

*   Mike is presenting
*   Will resubmit
*   In WG last call
*   There is likely few open issues to be addressed
*   Joris: I found some things. Nothing big.

ACTION: Mike to update and resubmit ical tasks and subscription update
in the next two weeks

## vpoll: 5 min   {#vpoll-5-min}

*   Make is presenting
*   Changing iTIP to be simpler
*   Have had working interoperable version many years ago, but it's had
    changes since. If we can get a couple of people testing, then it's
    pretty much done.

ACTION: All to review vpoll document.

## jscontact and friends: 5 min   {#jscontact-and-friends-5-min}

*   Robert presenting
*   Nearly done!
*   There are interop tests published

ACTION: Robert to upload new I-D for jscontact with revised IANA items.

## jscalendar and friends: 10 min   {#jscalendar-and-friends-10-min}

*   Robert presenting
*   Goal today: find out next steps
*   There are additions that might not need a new -bis version
*   There are clarifications and fixes that also might not warrant a new
    -bis version
*   There are renames that might be a bad idea anyway
*   There are incompatible changes that warrant a new -bis version
*   Proposal: add what we need to IANA registry for JMAP Calendars - go
    ahead with backwards compatible scheduling for JMAP Calendars.
*   Should come up with a jscalendar bis, but won't stop JMAP for Tasks
    and JMAP for Calendars RFCs.
*   If we bring in versioning from JSContact, then we can use that

*   Joris:
    *   Very valuable to keep JSCalendar in sync with JSContact, they
        are both underlying formats. Doesn't make sense to have
        different sturcture between those.
    *   Not fully understanding the next steps. Want to NOT include
        scheduleId in 1.0?
    *   Robert: no, other way around - suggest that all the things in
        non-published JSCalendar-bis draft (just additions) we should
        add, and add scheduleId.
    *   Right now: defined to point to participantId. Doesn't help with
        calAddress in the icalendar data (in the compatible to
        JSCalendar version) - might end up that one participant
        delegates to another participant in the same event - but if the
        delegate doesn't have a scheduleId, we can't convert to
        ICALENDAR.
    *   Joris: is anything blocking you from continuing work? Additional
        interop testing?
    *   Robert: for updating jscalendar-bis, or for jmap calendars.
    *   Blocking is just time - both for having jscalendar useful, and
        for jmap.
    *   Do the EASY changes when not under pressure to do jscalendar
        bis.

*   Neil:
    *   I think scheduleId is all that is missing.
    *   Maybe a document that defines the new properties.
    *   Leave non-breaking changes for later.
    *   Robert: yes, that's right.
    *   When we add scheduleId to existing, say "this points to
        participant ID"
    *   makes things a bit more complicated - would make delegatedTo
        point - not important enough for breaking change.

*   Neil:
    *   do we want to add scheduleId in the JMAP Calendars document, or
        as expert review we could just ask IANA to register.

*   Ken:
    *   If we're registering with "usage: Common" - ask Francesca if
        "webpage with documentation" is enough pending RFC?
    *   Francesca: would have to see how the sufficient documentation
        text is phrased, or if experts are the ones to decide. Does not
        have to be a spec, maybe a draft would be enough. Can only give
        my personal opinion, it's the experts' opinion. Problem with web
        page is "who maintains it"
    *   Robert: Also currently defined in JMAP Calendars RFC, section
        for experts "an RFC or a public webpage like a wiki, or
        documented in the description column of the IANA registry" - up
        to experts to decide what's required. Agree public webpage is
        least valuable.

Daniel:

*   How close is existing jscalendar-bis ready to be shipped?
*   Robert: haven't had much discussion on it, would prefer to only
    publish jscalendar-bis in tandem with jscalendar-icalendar; then we
    have full interoperability

Robert:

*   For each item will define what kind of documentation is required.
    Check that using it will not be an issue with icalendar. Want to
    revisit because it's been a while.

Joris:

*   Don't really like - we have published JMAP Calendars and JMAP Tasks
    - but developers will implement JMAP Tasks / JMAP Calendars - then
    new version coming? Why implement now.
*   Maybe drop the BIS and say we don't have a perfect conversion and
    that's OK.

Robert:

*   If BIS or not, doesn't matter. Developers should expert this to
    evolve, exactly why JSContact has versioning. Same thing for
    jscalendar, it's basically 1.0 now, shouldn't expect that it
    obsoletes existing, just adding new stuff.

ACTION: Robert to ask on mailing list regarding next steps.

## serverside subscriptions and series: 10 min   {#serverside-subscriptions-and-series-10-min}

*   Mike presenting
*   serverside subscriptions: No big interest right now
*   Ken:
    *   "Put it on the backburner"
    *   Francesca: can mark it as dead so it's clear we're not working
        on it.

*   Series:
    *   Would like to try to do something over next few months.
    *   But working on vpoll first

ACTION: serverside subscription - leave expired

ACTION: series - set milestone out to future

## AOB: 5 min   {#aob-5-min}

### HTML descriptions in Calendar   {#html-descriptions-in-calendar}

*   Ben Buksch presenting
*   Frequently requested feature in Thunderbird
*   Ran into multiple problems - no clear specification on how to do
    that
*   iCalendar description is explicitly plain text
*   There are proposals X-ALT-DESC property (nobody using except
    Microsoft)
*   Most just dump HTML into plain text description - no clear way to
    distinguish from plain text (Google does that)
*   Mike: Eventpub spec has styled descriptions specifically for this
    purpose - was driven by google (RFC 9073)
*   ALTREP as well
*   Found X-ALT-DESC property - now used by thunderbird
*   Mike:

*   Bron:
    *   So we have an evangalism problem!
    *   Ben: yep looked really hard and didn't find it.
    *   Ben: so STYLED-DESCRIPITON is a parallel propery, so it has the
        same update problem.

Ken:  
 \* Style description can have a parameter on it  
 \* if one of them is derived it can be flagged as "derived"

Ben:

*   Problem is clients that don't know, so they modify the description
    and don't know. So you end up with a description which says B,
    styled-description says A.
*   Edit in two clients, one knows, one doesn't - synchronise the
    calendar back, it's broken.
*   Mike: I know this can happen, it's the same user with two clients
*   Ben: it's the same
*   Ben: client that edits the data should know to remove the parameter.
*   ...
*   Ken: We need something new. Either a property or a parameter.
*   Neil: If a client updates only styled description and not the other
    it needs to be detectible

ACTION: Ben to write description of the problem to the list

## Milestones: 5 min   {#milestones-5-min}

*   updated