CALEXT at IETF118

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

Agenda

Intro and Notewell: 5 min

• Agenda bash - HTML descriptions

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

• 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

• 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

• 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

• 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

• 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

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

• updated