CounterOffer issue

[fortin@xxxxxxxxxxxx (Gilles Fortin)]

The usual case meeting has been addressed by the current proposal: one
person (OWNER) calls a meeting and the other attendees can only(?) accept
or decline.

However very often you want all participants to attend a meeting (usually
only a few people are involved). The challenge is to find a common slot for
all. Asking for a busy search for all attendees will help aiming for an
empty slot, but giving the attendees the ability to do a counteroffer is
essential.

Here is a scenario of a meeting between three people from three different
organizations A,B and C which looks highly probable:

A: does a busy search for B,C.
A: sends a meeting event to B and C.
B: cannot accept A's proposed time; does a busy search for A,C to get the
most up to date availability.
B: proposes another meeting date/time to A and C.
C: cannot accept B's proposed time; does a busy search for A,B to get the
most up to date availability.
C: proposes another meeting date/time to A and B.
... this can go on until...
A: accepts C'proposed time.
B: accepts C'proposed time.

With the actual draft, this does not look possible??  It seems an attendee
would need to decline the event, and issue a new one where he would take
ownership with a new UID. He would probably keep the same event title to
indicate it is a counteroffer. All the attendees would need to delete the
old one. Referencing the original UID could help? Where?  Should the
propose standard allow for this?  The draft should be more specific on who
(only the OWNER or any participant) can modify what (time, agenda, adding
participants) in a meeting.

One solution could be to have some kind of meeting type (LOCKED) that would
indicate if a meeting is open to counteroffers or not, which should not be
allowed in cases like the December IETF meeting that involves many people.

If the aim is real-time scheduling, it seems to me that ALL attendees (not
just the owner) should be notified of the other attendee's acceptation or
rejection. From the examples ?, it seems that the RSVP command returns the
participant's status (declined, confirmed) from the owner's server. Is this
the only way to get each participant's status.

Real-time notification does however involve some tricky issues:

A: sends a meeting event to B and C.
C's server is down: he does not receive it. (A's server will probably try
to send it at some interval according to the spec?)
B: proposes another meeting date/time to A and C.
C's server receives B's counteroffer before A's original proposal.
What happens then?? B's counteroffer will probably be rejected as referring
to an unknown event.

Gilles Fortin
__________________________________
Teamsoft Inc.
5633 Monkland, #200
Montreal, Canada H4A 1E2
+514-481-3141    fax:+514-481-2495
Internet: fortin@teamsoft.com    Web: http://teamsoft.com