Re: [Kolab-devel] iTip Invitation Handling Notes

On 2014-04-08 17:57, Thomas Brüderli wrote:
> Jeroen van Meeuwen (Kolab Systems) wrote:
>> 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
> 

Looking good.

>>>> On the topic of "First invitation vs. update";
>>>> 
>>>> (...)
>>> 
>>> (...)
>> 
>> 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?
> 

It seems RFC 5546 has a list (section 2.1.4 [1]) if properties, when 
changed, cause the SEQUENCE property to MUST be bumped -- it seems it 
leaves the rest to the discretion of the organizer, with a general 
guideline of "changes that could jeopardize the participation", for us 
most likely a human or manual assessment process.

Perhaps we know of a list of properties that do not put participation in 
jeopardy (summary, description, attachments, ...) and we could ask for 
the rest?

[1] http://tools.ietf.org/html/rfc5546#section-2.1.4

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

Could the inclusion of the events with a PARTSTAT=DECLINED be filtered 
within a certain view?

If it could, would this not get us to being able to display declined 
events without creating a separate container for it?

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

OK.

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

Whether or not the default configuration is to your liking -- it is the 
default configuration, and deletion (of iTip messages handled) should 
probably just match those settings (or the ones specified in the user 
profile to override the default settings).

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

That might benefit Roundcube as a whole, especially if also plugins and 
buttons such as "Mark as Junk" and "Archive" can be made to make use of 
it.

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