imip-agent

Annotated docs/wiki/CounterProposals

1384:9baa0aae5b43
2017-10-31 Paul Boddie Provided a convenience function for instantiating handler objects. Added a mode that produces output instead of sending messages without also producing debugging information. client-editing-simplification
paul@933 1
= Counter-Proposals and Offers =
paul@933 2
paul@934 3
When attempting to schedule an event, an attendee may suggest an alternative
paul@934 4
time by issuing a counter-proposal in the form of a `COUNTER` message. Upon
paul@934 5
receiving a counter-proposal, an organiser may then issue an updated
paul@934 6
invitation with new details (potentially matching those suggested in the
paul@934 7
counter-proposal, but not necessarily) for attendees to accept or decline.
paul@934 8
Alternatively, an organiser may refuse to consider other times and send the
paul@934 9
attendee concerned a `DECLINECOUNTER` message.
paul@933 10
paul@933 11
== Offers to Schedule ==
paul@933 12
paul@934 13
It can be useful for an attendee issuing such a counter-proposal to mark the
paul@934 14
periods involved as tentatively occupied until they know that their proposal
paul@934 15
has been accepted or not; it is also useful for the organiser to be able to
paul@934 16
rely on such periods being temporarily reserved by attendees so that any
paul@934 17
acceptance of a counter-proposal will succeed instead of failing because an
paul@934 18
attendee has chosen to dedicate those periods to something else. Thus, an
paul@934 19
attendee will make a temporary offer of scheduling for periods of time
paul@934 20
associated with an event, expiring such an offer in case the organiser chooses
paul@934 21
not to respond in a timely fashion (or at all).
paul@933 22
paul@933 23
== Managing Counter-Proposals ==
paul@933 24
paul@934 25
Each attendee invited to an event may respond with a counter-proposal. Thus,
paul@934 26
an organiser needs to be able to collect multiple counter-proposals for each
paul@934 27
event and to choose one to accept, if any are to be accepted at all. In
paul@934 28
principle, an organiser could merge details of different proposals,
paul@934 29
particularly if multiple periods are involved (and also if different attendees
paul@934 30
are suggested in different proposals), with the resulting combination of
paul@934 31
details being issued as a new request to all attendees.