Re: [Kolab-devel] iTip Invitation Handling Notes

Jeroen van Meeuwen (Kolab Systems) wrote:
> On 2014-03-24 12:56, Thomas Brüderli wrote:
>> Those who are interested are kindly invited to read the suggestions and
>> to enter the discussion. The page still contains some questions that
>> seek for answers.
>>
> 
> In the routine for event invitation acceptance, you list that the
> original invitation message should be removed. I don't think that it
> needs to.
> 
> 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?

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

"""
It is monotonically incremented by the "Organizer's" CUA each time the
"Organizer" makes a significant revision to the calendar component. When
the "Organizer" makes changes to one of the following properties, the
sequence number MUST be incremented: DTSTART, DTEND, RDATE, RRULE,
EXDATE, EXRULE, STATUS
"""

and

"""
The "Organizer" CUA MUST increment the sequence number when ever it
makes changes to properties in the calendar component that the
"Organizer" deems will jeopardize the validity of the participation
status of the "Attendees". For example, changing the location of a
meeting from one locale to another distant locale could effectively
impact the participation status of the "Attendees".
"""

The latter one is a rather subjective decision which may even require a
human confirmation. But I fear that users would not understand this if
asked whether to increase the sequence number.

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.
> 
> Use "distribution group" and "mailing list" rather than "distribution
> list", please.

Done.
> 
> 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.
> 
>   - 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?
> 
> In "Delegate":
> 
>   The DELEGATED-FROM property parameter SHOULD be attached to the
> delegatee's ATTENDEE property (3.2.3, "REPLY", 4.2.5, "Delegating an
> Event").
> 
>   Both also apply to the forwarded REQUEST (4.2.5, "Delegating an Event").

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


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

Thanks for your reply!

Cheers,
Thomas
_______________________________________________
devel mailing list
[email protected]
https://lists.kolab.org/mailman/listinfo/devel