Re: [Kolab-devel] iTip Invitation Handling Notes

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.

>> 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.

>> 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)?

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.

>>   - Here too I see no reason for the invitation message to need to be
>> removed automatically.
> 
> But what's the benefit of keeping all those invitations in your inbox?
> 

Well, I'm considering the effect of the iTip magically disappearing, 
which I've never liked in Kontact and disable wherever I can, and the 
added bonus of being able to correct a misfire.

>> 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.

>> 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 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" (??).

>>   - The shared folder concept is subject to the write access of the
>> individual as well - should an existing copy of the event be found in 
>> a
>> shared folder, the following options exist:
>> 
>>     - Add/update personal folder regardless, and send reply to 
>> organizer
>> who is then in charge of updating the participant's status in the "git
>> origin master HEAD" original copy of the event, which just so happens 
>> to
>> exist in a shared folder (where the organizer clearly has write 
>> access).
>> 
>>     - Cheating the process a little bit, have the attendee update the
>> participant status in the copy of the event in the shared folder, 
>> don't
>> save a copy of the event in the personal folder, and still send the
>> reply to the organizer -- note now the organizer has little to update. 
>> I
>> don't think this is the preferred way.
>> 
>>     - Display to the attendee to "Save the event in (...)" its list of
>> personal folders, but with an remark about the event already existing 
>> in
>> a shared folder, where it should/will be updated (by the organizer
>> receiving the REPLY), and add an option to NOT save (a copy of) the
>> event anywhere.
> 
> Sounds reasonable. I suggest to make a clear distinction of calendars 
> in
> "shared" namespace vs. "other users" namespace. The latter one IMO
> should be ignored throughout the entire iTip processing.
> 

Agreed.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel