[Kolab-devel] iTip Invitation Handling Notes

[Thomas Brüderli]

Jeroen van Meeuwen (Kolab Systems) wrote:
> On 2014-04-02 09:42, Thomas Brüderli wrote:
>> Jeroen van Meeuwen (Kolab Systems) wrote:
>>> An invitation that has been responded to does list the event's status in
>>> one's calendar should the message be opened for preview again, and as
>>> such the message no longer being marked as unread I don't see why the
>>> message would need to be removed.
>>
>> I think it's convenient to remove it after processing it. The iTip
>> message is just a transport container and after replying or updating my
>> calendar, it's not used anymore and I don't want it to clutter my inbox.
>> Maybe that could become a user preference whether to automatically move
>> iTip messages to Trash. Or even define a special-use folder to archive
>> all iTip messages?
> 
> My original line of thought did not consider so much whether the
> original message was preserved or not, but the sudden disappearance of
> the iTip message (Kontact current implementation), without the
> possibility to "Undo" a mis-click.

Agreed. I described this in an according paragraph on the wiki page:
https://wiki.kolab.org/User:Bruederli/Draft:iTip_Invitation_Handling_Notes#Automatic_Deletion_of_iTip_messages

>>> On the topic of "First invitation vs. update";
>>>
>>>   - Does the RFC actually allow the updated version of an event (with
>>> unchanged datetimes) to be sent out without bumping the sequence? I
>>> suppose valid scenarios for this type of update would be attendees
>>> getting added/removed, or other information getting updated? Either?
>>> Both?
>>
>> RFC 2445 4.8.7.4 states the following:
>>
>> """
>> (...)
>> """
>>
>> (...)
>>
>> Defining a sane set of properties that would increment the sequence if
>> changed is likely what we want to do here.
>>
>>>   Sort of impacts the "client should offer an option to update the
>>> user's local copy with the (...)", as well as whether or not an outdated
>>> version of the invitation should still allow the user to update the
>>> working copy of the event.
>>>
> 
> This deserves a little more attention - defining a rather static list of
> properties, that when updated, SHOULD bump the sequence number seems too
> arbitrary at first (who are we to decide what are significant changes),
> and simply including all properties in that list (i.e. always bump
> sequence) seems overkill.

That's basically what the RFC suggests. What are the options here? Ask
the user every time?

>>> In "Decline":
>>>
>>>   - A user SHOULD be asked whether the existing copy of an event should
>>> be deleted from his/her calendar:
>>>
>>>     This is too much confirmation -- either the default is to delete the
>>> event and "you can undo", or not to delete the event but update one's
>>> PARTSTAT.
>>
>> I disagree. I think this should be a concious decision whether I don't
>> want to be reminded of this event I'm not participating and thus have it
>> removed entirely.
> 
> Surely it is the VALARM separate from the PARTSTAT that triggers a
> reminder? Would a PARTSTAT=DECLINED "override" the existence of a VALARM
> (group of) setting(s)?

With "be reminded" I didn't specifically think of alarms but the simple
presence of an event in my calendar view.

The RFC doesn't describe a relation between PARTSTAT and VALARM. And I
would consider this a bit too magic.

> I recall a wish to be able to view declined events in one's calendar,
> which will either need to come from preserving the original iTip
> (+partstat tracking some place), or from an event in the calendar with
> PARTSTAT=DECLINED. The latter seems the more sensible approach.
> 
> That said, whether the event is deleted automatically or not, or updated
> automatically or not, separate confirmation is a (blocking)
> interruption, and should be avoided where possible.
> 
> Long story short, this probably deserves some additional deliberation as
> well.

I now chose a more open description:
https://wiki.kolab.org/User:Bruederli/Draft:iTip_Invitation_Handling_Notes#Decline


>>> In "Counter Proposal":
>>>
>>>   The new time slot proposal suggests the sender of the proposal
>>> implicitly accepts the event should the counter-proposal be accepted. If
>>> that holds true, the counter-proposal may need to be entered in to the
>>> calendar, perhaps with PARTSTAT=TENTATIVE (awaiting confirmation on the
>>> changed time slot).
>>
>> The RFC doesn't really specify the accept status in case of a counter
>> proposal. When an attendee sends a COUNTER message, the organizer either
>> has to accept or to decline it. In case of accepting, the organizer's
>> calendar agent sends a new REQUEST with the re-scheduled event to all
>> attendees, including the one who made the counter proposal.
>>
>> Although up until the re-schedule request is received, the event is not
>> scheduled at the proposed times, I agree that sending a counter proposal
>> equals an implicit acceptance. PARTSTAT=TENTATIVE is probably a good
>> solution. We just have to make sure that the tentative event is removed
>> (or cancelled) again once a DECLINECOUNTER message arrives.
>>
> 
> Or, perhaps we're doing more good than is good, doing that. After all,
> would this event with PARTSTAT=TENTATIVE not also deserve a comment or
> annotation that it is pending the acceptance of a counter proposal (by
> $x)? Slippery slope?
> 
> If the organizer is supposed to send out a new REQUEST, including to the
> attendee that made a counter proposal, I take it that attendee is also
> allowed to decline the event.

Yes. When the organizer accepts a counter proposal, that'll send update
REQUESTs to all attendees, including the one who made the counter
proposal. Each one then again has the option to accept, decline or
counter the invitation. And round we go...

I'd therefore just return the counter proposal but not take additional
steps by adding a copy into the attendee's calendar right now. That'll
finally happen when the organizer has accepted.

>>> This is all I have time for tonight, in terms of reading, but a more
>>> general question/remark pops up:
>>>
>>>   - If the iTip messages are not automatically deleted, does that impact
>>> the scheduling inbox for CalDAV clients somewhat, and/or is the \Seen
>>> status enough?
>>
>> We don't yet have a scheduling inbox for CalDAV, thus it's hard to
>> predict any implications. Under normal circumstances, a scheduling inbox
>> for CalDAV and the email inbox holding iTip messages are two distinct
>> systems. Only in Kolab they might be related.
>>
>> After first tests with Apple's Calendar app, it looks like items are
>> being removed from the scheduling inbox right after the client has read
>> them. That behavior suggests that removing iTip messages from the inbox
>> after processing them is what we should do in other clients, too.
>>
>>>   - Asking for confirmation is bad and allowing the user to undo is
>>> good. If the iTip messages are automatically deleted, before they are
>>> expunged from IMAP, a (brief) opportunity should exist to undo (noted
>>> that "nothing is ever actually lost" is quite a fair assumption).
>>
>> No objections. Unfortunately the web client doesn't yet have an undo
>> function for message deletion. Usually they are just moved to the trash
>> folder and not deleted directly and thus can be restored from there.
>>
> 
> In default Kolab groupware deployments, we specifically set "flag as
> deleted" and not move to trash.

I consider this a bug or at least a misconfiguration. What's the point
of automatically creating a Trash folder for every user account but then
not using it? Almost every mail client software out there by attempts to
move messages to the Trash folder when the user says "delete" (at least
in default configuration) and I suppose that's what most users also
expect to happen.

> I believe we have implemented this sort of "you can undo" for contacts
> (and events?) already, where (IIRC), an asynchronous delay is introduced
> (client-side) between the "flag as deleted" and "uid expunge" (??).

Yes we did. But that wasn't ported to the mail part. While it certainly
makes sense to have an "undo" option on email operations, that likely
should become a core feature of Roundcube.

~Thomas