Re: [Kolab-devel] iTip Invitation Handling Notes

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.

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?

   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.

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.

   - Here too I see no reason for the invitation message to need to be 
removed automatically.

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

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

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?

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

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

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