Subject: Dealing with invites to individual instances

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 13:24:26 -0700

In the wake of Derik and Frank's generous post on
their understanding of how the iCal model works,
and at the risk of further disagreement, I have
a question about inviting CUs to individual
recurrences and not the entire series.

If I invite a CU using UID:1/RID:123/SEQ:0
and then reschedule UID:1 such that instance 123
is no longer a member of the recurrence set, how
do I communicate this change to the CU?

For arguments sake we'll say it got replaced
with RID:ABC.

As I understand it, the CU will never see UID:1
since they aren't invited to it and will only have
received messages about RID:123.

So when a message for RID:ABC shows up how will it
know that this object replaces RID:123 and is not
a new invite to RID:ABC in addition to RID:123?

Again this is strictly limited to when a CU is
not invited to the base recurring set.

Do you send them the base event anyway?
Do you have to cancel RID:123?
Is there something more that I'm missing?
Does something need to be added to iCal/iTIP to handle this case?

Thanks,
-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 15:20:33 -0700

> On August 20, 2003 4:24 pm, Michael Fair wrote:
>
> I'm not sure what you mean by 'relaced'. Do you mean cancel as in:
>
> 1. CANCEL RID:123
> 2. ADD RID:ABC

Yes, this is what we need the CUA to do, but I don't think we really want
to have to explicitly tell it to do so (However we wouldn't use "ADD"
we'd use "REQUEST").

I think we'd prefer to just be able to send the request for RID:ABC and
have the CUA figure out that it needs to cancel RID:123

The problem is I don't see what in the message for ABC tells it to remove
event 123.

> The CU _will_ see UID:1 as you said "If I invite a CU using UID:1"...
(typo?)
>
> Since the CU contains UID:1 the rest of your questions are answered,
right?

Well there are three events here:
UID:1/RID:NULL
UID:1/RID:123
UID:1/RID:ABC

The CU wasn't invited to the RID:NULL event (aka the entire series) so never
received a REQUEST for it.
And it's common practice not to include the recurrence set description in
messages
referring to just instances.

As a result of these two things, from what I can see, the CUA doesn't have a
way to
validate whether or not the RECURENCE-ID exists in the current set as
described
by the most recent RID:NULL (aka base description) event because it won't
have a
way to see what that set is.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 17:09:38 -0700

> On August 20, 2003 6:20 pm, Michael Fair wrote:
>
> Care to provide some enlightenment on why it would be important to have
the
> CANCEL performed automatically? Am I missing something obvious about the
> CANCEL/REQUEST (2 operations) vs performing it in one operation?

Because event RID:123 was implicitly canceled when it's RECURRENCE-ID
was removed from the set described by UID:1.  At no time was there an
explicit
cancel sent to anyone, further only people who are not invited to the base
event
need be explicitly made aware of such changes.

So here's the sequence of events in more context that might help.

You schedule UID:1 to be a recurring event, on of those instances is
identified by RID:123.  You then invite me to just instance RID:123.

You don't send me a REQUEST for the whole series (UID:1), you send me a
REQUEST for just the instance I'm invitied to (UID:1/RID:123).

You then reschedule the entire series and RID:123 is no longer in the
set and in its place you want RID:ABC.  This is no problem for anyone
who can see both recurrence set descriptions because they can see
that RID:123 is no longer in the set described by UID:1 and remove it
from their calendars.

But I have not seen the recurrence set desciption and still have RID:123 on
my
calendar.  Since I'm not an ATTENDEE of UID:1 proper I won't receive the
reschedule announcement for UID:1 and won't know to remove RID:123.

When a new event shows up referring to RID:ABC I won't know that it was
actually
as a result of a reschedule of UID:1 that resulted in RID:123 no longer
being a
valid event.  Assuming that remains true I'll just add RID:ABC as a second
instance
of UID:1 that I am invited to.

So what is just a single reschedule to everyone else, needs to be a
CANCEL and a REQUEST to me.  Or there needs to be some other
mechanism by which I can detect that RID:123 is no longer a member
of the recurrence set for UID:1.

-- Michael --

---

From: Mark Swanson <[email-masked]>
Date: Wed, 20 Aug 2003 21:01:15 -0400

> was removed from the set described by UID:1.  At no time was there an

Got it.

> need be explicitly made aware of such changes.

Agreed. I can't find anything in iTIP that notifies attendees of disappearing 
recurring instances. It would seem like the courtious thing to do would be to 
send a cancel/request to those attendees.

<snip>
> of the recurrence set for UID:1.

I think you've made a good point. Doing a cancel/request means the problem is 
solved within the iTIP spec - and I've noticed that under those circumstances 
a very hot place would have to freeze over before iTIP would be modified to 
handle it differently. :-)

There's bound to be a number of little implementation details like this. It 
sure would be nice if they were captured in a common location.

</me hears nothing but the rustling of the wind in a far off Saskatchewan 
wheat field>

-- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web start (JNLP):
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp

---

From: Tim Hare <[email-masked]>
Date: Wed, 20 Aug 2003 21:37:01 -0400

It seems to me that the rescheduling process, either of one instance, or of 
a whole recurrence set, should require the ORGANIZER to notify all 
ATTENDEEs.  Because we allow ATTENDEEs to be added to individual instances, 
there must be at least a partial expansion of the recurrence set to allow 
that - which in essence makes copies of the list of ATTENDEEs (one copy per 
instance),  which can be updated individually. However this is implemented 
by a product, rescheduling should process the entire list of ATTENDEEs and 
notify them, but what I think we're seeing is a place where it sort of 
breaks down..

Therefore, the sequence of events should go something like this, right?

1. ORGANIZER schedules UID:1;RID:123;SEQUENCE:0 for users X,Y, and Z.   In 
essence we have 3 copies of the attendee list, one for each of RIDs 1-3, 
with content (X,Y,Z)
2. Someone, probably ORGANIZER, invites user W to RID:3.  Now we have 
(X,Y,Z);(X,Y,Z);(X,Y,Z,W)  for our lists of attendees.
3. ORGANIZER reschedules UID:1 with RID:ABC and SEQUENCE:1 - SEQUENCE must 
be updated to reschedule. This REQUEST should be sent to all participants 
(X,Y,Z,W)
4. The CUA sees a REQUEST for UID:1, which it has, with SEQUENCE:1 which 
tells it that there's an update involved. This REQUEST includes the new 
recurrence definitions, via RDATE/RRULE/EDATE/ERULE, but no RID according 
to the protocol. Everyone can update their calendar with this... BUT it is 
"wrong" for W to do so. W is not invited to all of the events in the 
recurrence set; and perhaps should not even consider him/herself to be 
invited to any of the new set.

Since W is not explicitly invited to RID:ABC,  we could just say "don't 
send the update to W (or any single-instance attendee)" but that breaks 
because then W has RID:3 still on her/his calendar  when they don't need to 
attend!

The "proper" thing as near as I can reason, is to send the update to 
everyone (X,Y,Z,W) and when W sees the UID:1 SEQUENCE:1 without RID:3, W 
removes UID:1 from the calendar. Barring that, an explicit CANCEL needs to 
be sent to only W.  IF the ORGANIZER desires W to attend RID A,B, or C they 
need to issue a new REQUEST.

This is the only way that I see within iTIP as written to handle this issue 
successfully. It does require separate actions for W, but this can be 
automated during implementation if so desired - when the CUA of the 
ORGANIZER finds single-instance ATTENDEEs, it can prompt the CU to 
determine if they want to invite those people again, and to what instance, 
and generate the required REQUESTs.

Do we need to add this explicitly to iTIP?

Tim Hare

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 20 Aug 2003 20:17:18 -0700

Originally I was just thinking about one instance "123" which
was transformed to a new instance "ABC" but I can work with
what has been posted which changes the heart of the example
to be instance "3" either no longer exists or has been replaced
with instance "C".

Either way user "W" now needs to be informed of the update,
but user "W" has not been invited to UID:1 only to instance "3".

<Description of creating three recurrences and
 then rescheduling them snipped>

> because then W has RID:3 still on her/his calendar  when they don't need
> to attend!

While I fully expect that if someone resequences a series, some
instance is going to replace whatever instance came prior, there
might be some merit in the logic.

If I change Mondays - Fridays there's still a 1-1 mapping for
the number of occurences, it was just easier to do that than
to reshcedule each instance.

However, at the moment I change Mondays - Fridays all instances
need to be deleted and recreated anyway.  As the ORGANIZER's CUA
runs through sending messages to the existing ATTENDEE's I see
no reason it couldn't send a CANCEL to all ATTENDEE's of an
instance for which the RECURRENCE-ID is no longer valid and who
is not invited to the base set.

It can then send a new REQUEST either intuitively with some direction
from the ORGANIZER or at the exlpicit instruction of the ORGANIZER.
It would be the CUA's responsibility to inform the ORGANIZER when
a reschedule like this impacts users this way.

> be sent to only W.  IF the ORGANIZER desires W to attend RID A,B, or C
they > need to issue a new REQUEST.

I don't think user "W" should ever see a REQUEST for UID:1 without
a RECURRENCE-ID.  Even if not listed as an ATTENDEE the expected
behavior is that the CUA will think it's an invite to UID:1.

> Do we need to add this explicitly to iTIP?

I don't know.
If we do add new behavior to handle this case then I vote that
it just be made mandatory that the recurrence rules within which
the instance lives MUST be provided whenever the ATTENDEE is
not invited to the base set.  This would solve the problem neatly
because the new "C" REQUEST would describe a new set of dates
which did not include "3".  The CUA would then know that "3"
is no longer a valid RID and can remove it.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Aug 2003 10:41:19 -0600

> handle it differently. :-)

Your making it way too complicated. iTIP is a protocol to transfer information
to ATTENDEEs, it is not an extension of the CUA implementation. You
only have to convey the needed information to the ATTENDEE. There does
not need to be an all encompassing object that represents the state of
all ATTENDEEs status on the wire. Just send the effected ATTENDEEs
the information they need.

For:

   UID:U1
   SEQUENCE:S1
   with five instances (I1, I2, I3, I4, and I5).

If ATTENDEEs A1 and A2 are to have instance I1 removed from their
calendar and ATTENDEEs A3 and A4 are not, then bump the SEQUENCE number
in ORGANIZER cal store and send CANCEL:I1 to A1 and A2. You do not
need to send anything to A3 and A4. A1 and A2 reply:

    ORGANIZER now is at SEQUENCE:S1+1
    A1 last responded to SEQUENCE:S1+1
    A2 last responded to SEQUENCE:S1+1
    A3 last responded to SEQUENCE:S1
    A4 last responded to SEQUENCE:S1

    A3 and A4 last responded to SEQUENCE:S1 and it does not matter
    to A3 and A4 because nothing changed they need to care about.

    The ORGANIZER CUA only has to compare the current component
    (SEQUENCE:S1+1 in this example) to the change that the
    ORGANIZER-CU wishes. Simply compare the changes to the
    SEQUENCE:S1+1 object and see which ATTENDEEs it effects.

If later A3 is to be canceled from instance I2. The ORGANIZER-CUA looks
at the object and can tell that it only effects A3, so only
A3 is sent the CANCEL:I2 object. And A3 replies:

    ORGANIZER is now at SEQUENCE:S1+2.
    A1 last responded to SEQUENCE:S1+1
    A2 last responded to SEQUENCE:S1+1
    A3 last responded to SEQUENCE:S1+2
    A4 last responded to SEQUENCE:S1

Now for some reason A2 does a full or instance REFRESH,
so the ORGANIZER sends them an object (S1+2) as it effects A2.
There is no need or requirement that the S1+2 object sent to A3
above look exactly like the object now sent to A2 (for full
REFRESH the current object can use EXDATE, RDATE, RRULE, and
EXRULE to convey the current state of the object), and A2 replies:

    ORGANIZER is now at SEQUENCE:S1+2.
    A1 last responded to SEQUENCE:S1+1
    A2 last responded to SEQUENCE:S1+2
    A3 last responded to SEQUENCE:S1+2
    A4 last responded to SEQUENCE:S1

If later something changes that effects one or more ATTENDEEs.
Lets say all of them because the LOCATION changes. So the
ORGANIZER-CUA bumps the SEQUENCE number to S1+3. And
sends them to A1, A2, A3, and A4. And they reply.

    ORGANIZER is now at  SEQUENCE:S1+3
    A1 last responded to SEQUENCE:S1+3
    A2 last responded to SEQUENCE:S1+3
    A3 last responded to SEQUENCE:S1+3
    A4 last responded to SEQUENCE:S1+3

The ORGANIZER CUA only has to remember the last SEQUENCE number that
an ATTENDEE replied to so that the ORGANIZER/CUA/CU can determine
*IF* the ATTENDEE replied at all. It is NOT used for history.

If the current change effects an ATTENDEE in the 'current' (pre changed) 
object. And if it does send them the update information.

When you reschedule, you bump the SEQUENCE number. It makes the old
instances disappear - that is what a reschedule is. The same is true
of the update shown in iTIP. When the new updated UID is sent with
the new SEQUENCE, the old instances go away.

It does not matter if the ATTENDEE was invited to one or more instances.
It does not matter if the ATTENDEE was invited to the initial instance.
When the ORGANIZER needs to send an ATTENDEE an object - send them
what they need so that the ATTENDEE-CU can decide if they will attend.
No history needed.

The same is true for CANCEL. Simply send the effected ATTENDEEs
a full or instance CANCEL. If it does not effect other ATTENDEEs
then do not send them anything. If anyone does a REFRESH, send
them an object that represents the current ORGANIZER view of the
object as it effects that ATTENDEE.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Thu, 21 Aug 2003 10:50:01 -0600

Tim Hare wrote:
> 
> It seems to me that the rescheduling process, either of one instance, or 
> of a whole recurrence set, should require the ORGANIZER to notify all 
> ATTENDEEs.  Because we allow ATTENDEEs to be added to individual 
> instances, there must be at least a partial expansion of the recurrence 
> set to allow that - which in essence makes copies of the list of 
> ATTENDEEs (one copy per instance),  which can be updated individually. 
> However this is implemented by a product, rescheduling should process 
> the entire list of ATTENDEEs and notify them, but what I think we're 
> seeing is a place where it sort of breaks down..

Why do you feel that unaffected ATTENDEEs need to see all changes?

In a worst case scenario no two ATTENDEEs would be attending the
same set of instances. Do you feel that is is a violation of iTIP
for the ORGANIZER to send each ATTENDEE (worst case) a unique
object tailored just for them?

--

---

From: Tim Hare <[email-masked]>
Date: Thu, 21 Aug 2003 22:58:39 -0400

Doug - that was a fairly clear explanation, to me. If I am understanding 
things correctly, changing RID:123 to RID:ABC involves  a CANCEL operation 
for the first 3 RIDs (1,2,3) and an ADD operation for the other RIDs 
(A,B,C)  correct? Of course you don't have to ADD as many as you CANCEL or 

>*IF* the ATTENDEE replied at all. It is NOT used for history.

I don't think the ORGANIZER CUA has to remember the sequence number per 
attendee if it doesn't want to.... The ORGANIZER "owns" the UID and 
SEQUENCE values,  in a sense.  Because the ORGANIZER controls changes to 
the event represented by UID, it always has the most up-to-date and 
therefore the highest SEQUENCE.

On other related topics,  once I re-read iTIP/iCAL and understood that the 
UID should be globally unique for the event being scheduled/changed, then 
forwarding and delegation no longer seems to me to be a problem either -an 
event can be forwarded or delegated to another CUA - when/if it issues a 
REPLY then it will use the same UID and the ORGANIZER CUA becomes aware of 
that CUA's participation. If the delegated CUA never issues a REPLY then 
under iTIP I see no requirement for the ORGANIZER to worry about that CUA , 
since it can not be aware of it - correct?

Tim Hare

---

From: Tim Hare <[email-masked]>
Date: Thu, 21 Aug 2003 23:11:42 -0400

I may have covered this in my other post, but I will cover it here just in 
case:

I do not think it is a violation of iTIP to send each ATTENDEE a unique 
object. As I have re-read the protocols, I don't think unaffected ATTENDEEs 
need to see all changes, unless the ATTENDEE is affected, then they MUST 
see the changes. Refering to my previous post, UID:1, RID:123 changed to 
UID:1, RID:ABC - since "W" is invited to instance 3,  W has to be notified 
when 3 disappears. Sending unique objects is, to me, a perfectly acceptable 
way to do it.

Tim Hare

At 10:50 AM 8/21/03 -0600, you wrote:

>>However this is implemented by a product, rescheduling should process the 
>>entire list of ATTENDEEs and notify them, but what I think we're seeing 
>>is a place where it sort of breaks down..
>

---

From: Mark Swanson <[email-masked]>
Date: Thu, 21 Aug 2003 23:20:34 -0400

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 implementation.
> You only have to convey the needed information to the ATTENDEE. There does
> not need to be an all encompassing object that represents the state of all
> 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...

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 22 Aug 2003 02:36:09 -0700

"Mark Swanson" <[email-masked]> wrote in message
news:[email-masked]...
> > not need to be an all encompassing object that represents the state of
all
> 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 --

---

From: "Chris Olds" <[email-masked]>
Date: Fri, 22 Aug 2003 03:57:33 -0700

Since I know Doug won't see this, I'm going to try again (I thought I had
already explained this in an understandable way, but that's clearly not the case).

On Fri, 22 Aug 2003 02:36:09 -0700, Michael Fair wrote
> > > You only have to convey the needed information to the ATTENDEE. There
> > > does not need to be an all encompassing object that represents the state
> > > of all ATTENDEEs status on the wire. Just send the effected ATTENDEEs

This is correct.  The Organizer knows the entire event, including who is
invited to what, and what replies have been recieved.

> to user "Y" where "Y" has been invited to a different instance.

First, delegation is indicated by a message from the delegator and the
delegatee to the Organizer, each clearly marked with information about the
delegation.  If *any* of these messages are seen by the organizer, there is no
problem.  If the organizer misses them all, there is no problem (except that
the Organizing CU won't know of the subtitution).  Either way, no problem.

> The CUAs must do the wrong thing no matter how they process it.

You keep saying this, but without any basis, as far as I can see.

> forwarded) when user "Y" sends a REPLY back to the ORGANIZER,

Why couldn't Y figure out what happened?  Is there no indication that the
REQUEST was forwarded from W rather than sent direct from O (the organizer)?
If not, why not?  If that's the case, then anyone can masquerade as O.

> was actually for instance "3" which user "W" had forwarded to "Y".

This is clearly defined as a "party crasher" scenario in iTIP.  

> events that really aren't all that unique.

Yes, those messy and hard to deal with DTSTART values.  Good thing we have
RIDs to handle this problem.... wait a sec!  RECURRENCE-IDs have the same type
as DTSTART values - how is this harder to deal with than getting a REPLY with
a RID?  It's *exactly* the same data, and just as easy to match & track.  I
would expect a CUA to track exactly what each participant has been invited to,
so this seems like basic functionality to me.

> or if he never sent four and five because he didn't need to.

So you're positing a CUA that can avoid sending unneeded messages to
attendees, but is not capable of retaining that fact?  Why?  If the CUA knows
that it sent a SEQ:3 REQUEST to a CU, then it expects a SEQ:3 response.  If
the current SEQ value of the object is at 5, but the last two changes didn't
affect a particular CU, then the SEQ:3 response is as good as a SEQ:5 response
from that CU.  How does the CUA know?  By not throwing away the information
that it avoided sending the extra messages.

> version to find out if the changes between 3 and 5 affected this CU.

No.  He'd have to see of the SEQ:3 RESPONSE covered all of the SEQ:5 instances
that the CU was invited to, and if they did, that's then end of it.  If the
orgainzer keeps track of the last SEQ value sent to a particular CU, then he
knows what SEQ he needs on a response for it to be valid & complete. Easy.

> wait for their response.  

Chapter and verse on this?  I know where it says stale REQUESTs should be
discarded; where is the similar language for REPLY objects?

> This added trip could have been avoided

This is not an added trip - it's the one you're saying is required, and Doug's
smart CUA was trying to avoid.  So, AT WORST, it's the same number of messages
as you would mandate every CUA send.  That's why it's an optimization; it
makes no difference to the protocol outcome.

> SEQUENCES between what the CU has and what the ORGANIZER has.

Delegated events are clearly marked, and mentioning them is a red herring.

> always gets back to the ORGANIZER before anyone else sees it.

This is not true, and has not been demonstrated.

> the info the CU needs introduces loads of confusion.

Not if the CUA is capable of retaining information about what iCal objects
have been sent, and to whom.  I wouldn't think this a terrible burden for a CUA.

> This approach is just plain stupid.

Yes, the approach you have postulated is stupid.  You say that a CUA is broken
unless it can match up messages with no recollection of what was sent (content
and SEQ), and can operate correctly when either a) no messages ever reach the
Attendee or b) no messages ever make it back to the Organizer.  Any CUA that
can always produce correct results under these conditions is magic, and should
sell well, once successfully demonstrated...

Real CUAs can look up dates.  Real CUAs can remember what SEQ value was last
sent to (and is therefore expected from) and Attendee.  Real CUAs that can
send invite an Attendee to a subset of an event can build custom REQUEST
objects should be able to match up the REPLY correctly without needing a
different UID (and if they can't, they could just internally generate a UID
per custom invite without the Organizing CU knowing or caring).

I hope you read the whole message this time.  Last time, I used a surprise
party to show why a CU might want his CUA to generate custom objects, all with
the same UID, and you ignored it.  You should take a deep breath, read the
whole thing again, and only then should you respond.

   /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Aug 2003 09:19:34 -0600

Tim Hare wrote:
> things correctly, changing RID:123 to RID:ABC involves  a CANCEL 
> operation for the first 3 RIDs (1,2,3) and an ADD operation for the 
> other RIDs (A,B,C)  correct? Of course you don't have to ADD as many as 
> you CANCEL or vice-versa. The only thing I have a quibble with here is 
> the statement:

It does not need to involve a cancel explicitly.

A CANCEL does not *need* to be sent.

So the ORGANIZER could:

   (a) SEND 3 single instance CANCELs
       SEND 3 ADDs

       GET 6 REPLYs

       (2) round trips (you can not mix METHOD values
           in one iMIP packet or one CAP MIME object.

.OR.

   (b) SEND 3 instance modifications.

       GET 3 REPLYs

       (1) round trip

.OR.

   (c) SEND an entire new object to the effected ATTENDEEs.

       GET 1 REPLY

       (1) round trip

The risk of (a) is that they could be rescheduled between the
CANCEL and the ADD. If the ATTENDEEs are resources and not people, that
might be a critical issue.

If done via iMIP the round trips account for more time.

> therefore the highest SEQUENCE.

That is all true. What if the ORGANIZER *never* gets a METHOD:REPLY
from one or more ATTENDEEs?

Without remembering which ATTENDEE replied, the ORGANIZER could not
have the information in order to decide who to re-send a REQUEST.
In some situations the ORGANIZER will need to resend, in others
it could be considered an implicit "no thanks".

> On other related topics,  once I re-read iTIP/iCAL and understood that 
> the UID should be globally unique for the event being scheduled/changed, 
> then forwarding and delegation no longer seems to me to be a problem 
> either -an event can be forwarded or delegated to another CUA - when/if 
> it issues a REPLY then it will use the same UID and the ORGANIZER CUA 
> becomes aware of that CUA's participation. If the delegated CUA never 
> issues a REPLY then under iTIP I see no requirement for the ORGANIZER to 
> worry about that CUA , since it can not be aware of it - correct?

True, the ORGANIZER never *has* to worry. It is an application specific
requirement and not an iTIP requirement.

--

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 22 Aug 2003 12:15:07 -0700

I have read your entire post.
I'll try and keep it to just the simplest and most demonstrable points.
For simplicity sake, we'll call the instances or instance subset,
users "Y" and "W" were invited to instances "Y" and "W" respectively.
For purposes of calculating DTSTART we'll say that "Y" was invited
first, and thus "W" has the more recent DTSTART.

> delegatee to the Organizer, each clearly marked with information about
> the delegation.  If *any* of these messages are seen by the organizer,
> there is no problem.  If the organizer misses them all, there is no
> problem (except that the Organizing CU won't know of the subtitution).
> Either way, no problem.

And if the delegation announcemnt got lost or ORGANIZER simply
received the messages out of order?
Delagatee response, then Delagation announcement.

This also assumes the ORGANIZER was event sent a reply by the
delegatee to begin with which I'll address below.

> You keep saying this, but without any basis, as far as I can see.

I proved it in the post you didn't comprehend before responding
with an off-topic suprise party.  I'll do it again.
(The problem is that your suprise party left all workflow properties
 the same and just changed non-workflow properties.  I have no
 problem with that.)

Recurring event UID:1 has instances "Y" and "W" to which it separately
invites CUs "Y" and "W" respectively.

So "Y" puts on its calendar:
UID:1
SEQUENCE:0
DTSTART:timeOfY

And "W" puts on its calendar:
UID:1
SEQUENCE:0
DTSTART:timeOfW

To keep it really simple I'll just discuss the "forwarding" part
since that's the least confusing.

User "W" sends "Y" a forwarded REQUEST containing:
UID:1
SEQUENCE:0
DTSTART:timeOfW

"Y" receives the message and on its calendar it finds UID:1.
It says "Oh cool, an update or a reschedule."

"Y" looks at both SEQUENCE values and sees SEQUENCE:0.
"Y" compares the the DTSTAMP values and sees the the UID:1
    it just received is more recent than the one it has.
It says "Great an update I can handle this."

However, it might notice that this didn't come from the
ORGANIZER.  Since there can only be one unique UID:1 and
the ORGANIZER is the master of all updates it will probably
just throw this message out and not process the invite.
**** It just did the wrong thing ****

But let's follow another chain:
Assuming there is no signature or other source authentication
means to verify the message it will update its calendar and it
now no longer has instance "Y" but instead has instance "W".
**** It just did the wrong thing ****

It might not send the ORGANIZER a REPLY because it doesn't
think it needs to as the SEQUENCE didn't change at all.
**** It just did the wrong thing ****

However, It might notice that something is fishy because the
DTSTART changed but SEQUENCE wasn't updated (however I can
easily present a scenario where the SEQUENCE was increased
and it wouldn't notice a thing).  Given that the DTSTART
changed, it might figure out that it should ask the CU and
they then say they can't attend.

So the dutiful CUA sends a REPLY to the ORGANIZER with UID:1
SEQUENCE:0 and a negative attendence.

The ORGANIZER receives this message, it looks in its lookup
table of instance-attendee match ups and finds that UID:1
was attached to instance "Y".  So given the SEQUENCE is the
same but the DTSTAMP is more recent than the one it has it
goes ahead and says that "Y" is no longer coming to instance "Y".
**** It just did the wrong thing ****

No matter how many different variations I tried because UID:1
has been overloaded to mean two different instances the CUAs
can never figure out what the right thing to do is.

> > So if an object

> I would expect a CUA to track exactly what each participant has been
> invited to, so this seems like basic functionality to me.

iTIP certainly never recommends you do this.

However, you are totally right that if a CUA tracked what they
sent in addition to what they received they could figure out
whether or not a CU had responded to the right SEQUENCE yet.
I was incorrectly basing my conclusion from iTIP where such
tracking of what was sent is totally unnecessary.

I will totally grant you that a CUA "could" do this and there
is no reason to stop it from doing so.  But it's not in iTIP
and therefore is not "basic functionality".

I withdraw my argument that the CUA using this model would not
be be able track what SEQUENCE a CUs response should be at if
trying to use this optimization.  Any CUA trying to use the
"splinter the UID" model of inviting CUs to will have to do
this to keep track of expected responses.  It solves that
particular problem quite neatly.

To prevent any confusion however, there are still other problems
you have yet to demonstrate competency in.  Most particularly
having CUs with different versions of the same UID trying to
forward and delegate to each other.

> discarded; where is the similar language for REPLY objects?

I am totally wrong about this one too.
Again I was concluding something based on the iTIP model where
splintering UIDs with separate versions is a violation of the
uniqueness property and that increasing a SEQUENCE value meant
that something significant about the event changed.

I had also misapplied a recommendation out of context.

In section "5.2.2 Unexpected Reply from an Unknown Delegate" we have:
   ... If the version of the
   "REPLY" method is out of date the "Organizer" SHOULD treat the
   message as a "REFRESH" message and update the delegate with the
   correct version.

I had not remembered the context of being from an unkown delegate
and had inaccurately recalled that this was a normal part of the
REPLY prose.

Further, given the iTIP model where a SEQUNCE jump always means
an attendence invlidation, treating a REPLY to an old SEQUENCE
makes sense, but is not actually proposed in iTIP.

iTIP in section 3.2.2 simply says that later SEQUENCE versions
(or DTSTAMP as the case might be) obsolete all earlier replies.

I stand corrected.  Thank you.

> Real CUAs that can

I've already posed the forwarding dilemma for custom REQUEST objects
above I have demonstrated it for at least the fifth time now and so
far there has been no response.

Generating a new internal UID would almost work, except now when the
CUs who are invited to the same instances (not instance set, just
same instances) forward messages to each other they won't be able
to figure out they are talkig about something they already know about.

> I hope you read the whole message this time.  Last time, I used a
> surprise party to show why a CU might want his CUA to generate
> custom objects, all with the same UID, and you ignored it.  You
> should take a deep breath, read the whole thing again, and only
> then should you respond.

It would have been nice if you had actually read and understood the
problem before replying with your unrelated suprise party.  It would
have been even better if you had just understood my response to your
suprise party before trying to say that I have neither read nor
understood your response to a problem that was no where near the
situation I described.  (I even told you why it wasn't relevant.)

Not that it matters since I've again duplicated the scenario above,
but in my reposense, just after the part where you say the ORGANIZER
is free to reject party crashers I requested you look at the actual
messages being passed around.  Just above that I put a snip comment
saying why the example was irrelevant.

Here's the post from me that you didn't read/understand/respond to.
It's really long - don't bother replying as the salient parts have
been copied above.

    Subject: Re: New question in regards to the fixed-id model
    Sent: Thursday, August 14, 2003 4:08 PM

-- Michael --

---

From: Tim Hare <[email-masked]>
Date: Fri, 22 Aug 2003 20:05:09 -0400

First - I think we need to come up with ONE use case of the Recurrence-ID 
problems, or one set, anyway. We need to place it as a document where 
everyone can get it, and base our discussions around that. We keep 
introducing new scenarios, and changing terms (I used X,Y,Z, and W as 
ATTENDEEs in one case, and Michael Fair used Y and W as instances in 
another) - I think this is adding to the confusion. Has anyone got good 
ideas or pointers to somewhere with good examples of notation?

Second - does iTIP explicitly describe protocols for changing single 
instances of a recurrence set and if so, what sections?

Third - in the following quote:

>The CUAs must do the wrong thing no matter how they process it.

I need some clarification of the term "event" here. I don't see how the 
first two statements can be true under iCal/iTIP UNLESS you say that an 
updated UID  with a recurrence rule that has had changes to the instances 
is a new event - in that case, the version (SEQUENCE) of the UID would be 
different - so the two CUAs have representation of the same event at 
different version levels in my opinion. This is something which is going to 
happen all the time give time delays in the various mappings of iTIP to 
communication protocols.

Fourth - non-delegated forwarding of events:  While I see that this can 
happen,  I don't see how or why the iTIP protocol should worry about 
breaking a CUA's representation of an event when that CUA was never invited 
to the event. In my opinion it can also be a security/privacy concern to 
keep that CUA updated:  say for example that I want to keep track of the 
executives in some organization. I co-opt an employee to forward executive 
meeting REQUESTs to me, and I send REPLY methods for all of those VEVENTS. 
 From that point on, under some of the scenarios discussed, I would 
constantly be updated about what's going on.  Of course, the access 
controls might prevent that, if there are any - but wouldn't they, 
shouldn't they, also prevent the event from being replied to by 
non-authorized CUAs?  My bottom line here is that I think unless the event 
is delegated via an iTIP process and not merely forwarded.

Tim Hare

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Aug 2003 19:51:44 -0600

> instances of a recurrence set and if so, what sections?

iTIP - 4.4.2 Modify A Recurring Instance

The example changes a single instance.

> updated UID  with a recurrence rule that has had changes to the 
> instances is a new event - in that case, the version (SEQUENCE) of the 
> UID would be different - so the two CUAs have representation of the same 
> event at different version levels in my opinion. This is something which 
> is going to happen all the time give time delays in the various mappings 
> of iTIP to communication protocols.

Agreed - if it is the same UID, then it is the same iCAL object
and then the SEQUENCE and DTSTAMP must be used to compare the objects.

Conclusions reached based on the false assumption that they are
different iCAL objects and not just versions of the same object
are going to lead to all sorts of ghost chasing debates.

> breaking a CUA's representation of an event when that CUA was never 
> invited to the event.

In fact iTIP says "3.2.2.6 Forwarding to An Uninvited CU"

    ...   An "Attendee" invited to an event may invite another uninvited CU to
    the event. The invited "Attendee" accomplishes this by forwarding the
    original "REQUEST" method to the uninvited CU. The "Organizer"
    decides whether or not the uninvited CU is added to the attendee
    list. ...

So it is covered. The organizer may toss the object.

--