Tempting..., very tempting...

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

_______________________________________________
Kolab-devel mailing list
[email protected]
https://www.intevation.de/mailman/listinfo/kolab-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEABECAAYFAlAFjrkACgkQKN6f2pNCvwgUkwCgtffO7H2dVjggV6hsin6Et1tO
JHQAn3OSZAmuNPB55+W802CCzZoc6apg
=Pgu4
-----END PGP SIGNATURE-----