[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dealing with invites to individual instances

"Mark Swanson" <mark@xxxxxxxxxxxxxxxxx> wrote in message
> On August 21, 2003 12:41 pm, Doug Royer wrote:
> > Your making it way too complicated. iTIP is a protocol to transfer
> > information to ATTENDEEs, it is not an extension of the CUA
> > You only have to convey the needed information to the ATTENDEE. There
> > not need to be an all encompassing object that represents the state of
> > ATTENDEEs status on the wire. Just send the effected ATTENDEEs the
> > information they need.
> I was agreeing with Michael's description, which seems to be identical to
> yours. Just send the affected ATTENDEEs the info they need...

Doug is actually suggesting something different.

He is suggesting that instead of sending UID:1 with an RID,
don't send an RID at all.  Just send a UID 1 object with
the instance the ORGANIZER wants them to attend.

His reasoning is that the ORGANIZER is in control of the UID
and he can use the ATTENDEE field to figure out what instance
UID:1 means when user "W" sends back a REPLY.

The problem with this is when user "W" forwards or delegates
to user "Y" where "Y" has been invited to a different instance.

They both have the same UID on their calendar.
The UID's do not refer to the same event.
The CUAs must do the wrong thing no matter how they process it.

The case expands appropriately when they are invited to different
subsets of the recurring event described by UID:1.

Assuming for just a second that user "Y" could figure out what
was going on when "W" forwarded the event (not delegated, just
forwarded) when user "Y" sends a REPLY back to the ORGANIZER,
the ORGANIZER will looks in it's table and see the user "Y"/UID:1
is associated with instance "2" (for example).  But the REPLY
was actually for instance "3" which user "W" had forwarded to "Y".

The ORGANIZER has absolutely no way of reconciling this unless
he starts trying to match of DTSTART values.  But then this
gets into a whole messy situation when you start trying to track
different versions from different SEQUENCEs of these "unique"
events that really aren't all that unique.

Doug wants to overload the UID because he thinks he saves some
effort.  But in truth he breaks workflow.  The whole forwarding
and delgation thing aside for a moment, in his model, he can't
even tell if the CU ever received the latest update because in
his model the SEQUENCE number of the ATTENDEE doesn't need to
match the latest SEQUENCE actually sent.  So if an object
is at SEQUENCE:5 but the ATTENDEE response says SEQUENCE:3,
he can't tell if that's because the messages got lost in transit,
or if he never sent four and five because he didn't need to.

He'd have to keep track of SEQUENCE:3 and compare it to the current
version to find out if the changes between 3 and 5 affected this CU.

And the thing I love the most is even more simply than any of this,
if a user at SEQUENCE:3 tries to change their status and the
ORGANIZER has marched on to SEQUENCE:5 - a properly coded CUA should
ignore the SEQUENCE:3 reply and send them a SEQUENCE:5 update and
wait for their response.  This added trip could have been avoided
if he had just sent the SEQUENCE:5 update to begin with rather than
try and code in logic to detect whether or not a change affected
that CU or not.

These are just the low hanging fruits to pick on.
Things can get a lot uglier when you start dealing with out of
sequence responses to delegations, delegation and forwarding of
SEQUENCES between what the CU has and what the ORGANIZER has.

The main premise of Doug's model is that the CU never "spreads
the word" about the UID in question.  He assumes that all data
always gets back to the ORGANIZER before anyone else sees it.

The CUs can, will, and are allowed to delegate and forward to
their hearts content.  Spinning off per ATTENDEE UIDs with just
the info the CU needs introduces loads of confusion.
This approach is just plain stupid.

-- Michael --