[Jmap] Re: [calsify] CalDAV Scheduling design issues and a path forward with JMAP for Scheduling

[Mauro De Gennaro <[e-mail]>]

Hi Neil,

Thanks for your feedback!

> I agree that having to do canonicalisation and diffing sucks, but since this is basically also how iTIP works (you get a full event in every message and have to work out what's changed) you're probably going to need to implement all of this anyway to support iMIP, which sadly isn't going anywhere.

That’s correct,  iTIP itself works by sending full objects and doing diffs, but there's a key difference here. My complaint isn't about the implementation complexity (that is the fun part actually!). It's that in CalDAV Scheduling, the scheduling operations are completely implicit and inferred from object differences, which creates ambiguity about what the client actually intended to do.

In iTIP/iMIP, at least you have an explicit METHOD property that tells you "this is a REQUEST" or "this is a REPLY”, the semantic intent is clear. But in CalDAV Scheduling, the server has to guess whether you meant to send a REQUEST, CANCEL, or do nothing at all based on what changed in the object. And then having some scheduling parameters in the iCalendar object and others in HTTP headers just feels like a hack.


>> - Data loss risks: Clients making routine property changes (like adding alarms) can accidentally trigger CANCEL messages if they don't preserve all attendees correctly
> 
> I'm curious if you've seen a client do this (drop the attendees when making an unrelated change); I don't think I've ever heard of that happening with our user base.

You're right, I haven't actually seen a client drop attendees accidentally either, it's more of a theoretical risk from the "replace entire object" approach. But this is really a broader CalDAV problem that also affects scheduling.

With JMAP, we can do proper patch operations for just what needs changing, and the goal for JMAP Scheduling would be to have explicit scheduling APIs where the client says exactly which scheduling actions to perform, rather than making the server play detective with object diffs.


>> - Partial update complications: No way to make targeted changes (e.g., "just update the location") without risking unintended scheduling side effects
> 
> I don't know I follow that — updating the location should trigger a scheduling update to be sent to the attendees.

Yeah, bad example on my part! Location changes absolutely should trigger scheduling updates. What I meant was something like setting a local property (like TRANSP) that, due to a client or server bug, accidentally triggers unintended scheduling actions. 


>> - Client implementation burden: Every CalDAV client must understand complex scheduling semantics to safely modify calendar objects
> 
> Does it? I think a CalDAV client just needs to understand if it's the origin of the event. If so it can let the user edit anything, otherwise it should only let the user edit per-user properties. The rest is just distributing updates to the other participants, which the client doesn't have to worry about … although the server very much does.

This gets back to the same core issue about inferring scheduling actions from diffs. Basic scheduling isn't too bad, but things get hairy fast when you have complex recurrence scenarios where attendees participate in only some instances.

Here's a fun edge case I ran into: what if an attendee’s client adds an EXDATE (which should trigger a DECLINE message to the organizer) but also creates a RECURRENCE-ID override for that same date setting their PARTSTAT to DECLINED? Should the server skip generating an update for the EXDATE? Merge it with the one created by the user? Pick one? I found tons of ambiguity like this during implementation, you either have to accept all reasonable inputs and hope that's what the client wanted, or be super strict and force everyone to do things your way.

Also, since writing my original post, I found another RFC 6638 limitation: there's no way to tell the server that the guest list should be hidden in outgoing iTIP messages.


>> I plan to propose a JMAP Scheduling extension over the next few months that would provide explicit scheduling operations with clear semantics. This approach would also enable us to address the iTIP features that RFC 6638 explicitly doesn't cover, including publishing, countering, delegating, refreshing, and forwarding calendar components, as well as replacing the Organizer of a calendar component.
> 
> That sounds very interesting; I won't be at IETF123 in person, but would love to dial in to any such discussion if possible.

Absolutely! I'll do my best to have at least a draft of what the different scheduling actions could look like before IETF. Would love to get your input on the approach, even if it's remote participation.


Thanks,
Mauro