[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