[Kolab-devel] Tempting..., very tempting...

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Tue Jul 17 18:11:37 CEST 2012


Hi there,

I'm almost finished implementing the delegation part of Resource Management, 
which is when "any car, not a specific car" is being made a reservation for.

The RFC 5546 iTip specification states, for the process of delegation, that:

- the delegator is to send back to the organizer a notification that the 
invitation is being delegated (done),

- the delegator is supposed to send an iTip to the delegatee (not implemented, 
this is a derivation from the spec already, but useless for our 
implementation),

- the delegatee then needs to send back his/her response (done).

The result is, that anyone who attempts to make a reservation for any of the 
non-unique resources through the corresponding collection, will, if the 
reservation is accepted, receive a DELEGATED and an ACCEPTED response.

This seems completely useless and in fact could be annoying. But I really 
would like to derive from the RFC specification least as possible.

What are people's thoughts on defaulting to RFC specification, but adding a 
setting that says "ignore_rfc_suppress_delegated_itip_response = 0|1"?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120717/f53c19e9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120717/f53c19e9/attachment.sig>


More information about the devel mailing list