Re: RECURRENCE-ID discussion

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

For an analysis of why the fixed-id does not create an infinite
loop see the end of the post.

> However, at the very end, there is an unsupported statement:
>
> > Since the sender is an ATTENDEE of the instance component
> > only, it is only authorized to receive replies for that
> > singleton component.  As a consequence, the ORGANIZER's
> > CUA should not send the requested response.
>
> This is not supported by the RFC paragraph quoted.  6.1.7 talks about a
> REFRESH request from someone not an attendee to the event.
> If an event consists of multiple instances, the fact that an
> attendee is invited to only one of them does not exclude her
> from the set of attendees!  An Organizing CUA that is capable
> of sending a single instance of an event to an attendee
> without generating a new UID (which it could easily do), is
> surely capable of forming a response that only includes those
> instances to which that attendee is invited.

First, UID is one event, UID/RECURRENCE-ID is a different event.

In the UID only properties of the event the CU is not list as an
ATTENDEE and can never be listed as an ATTENDEE lest they be
invited to all instances of the recurring event.  So therefore
6.1.7 stands as used.  The ORGANIZER receives a REFRESH
request for UID only.  The CU isn't an ATTENDEE of that event.

The only way this might be possible if you fragment the event
to make two versions of the same UID, one for the ATTENDEE and
another for every one else.  Which leads me to second, this
violates the mandate that a UID be globally unique.  You now
have two objects of different forms with the same UID and no
other iTIP compliant disambiguating values.

As just an example of one case where this is a sever issue,
let's say that the ATTENDEE sent a COUNTER response.

In your model they will have received an object with a UID and
no RECURRENCE-ID.  At best it will be a recurring event with
only one RDATE, at worst it will just be a singleton.
Using the best case scenario the CUA might send a COUNTER
to just the individual instance in which case you lucked out.
Also using the best case scenario the CUA might detect that
the CU wants to reschedule every instance of the event (since
there is only one instance described in the event) and send
a COUNTER to the UID only component with a new RDATE.  Using
the worst case scenario, the CUA will send a COUNTER message
to the UID only event trying to turn it into a singleton at
a new time.

In anything but the best case scenario with some luck, they
will be sending a COUNTER message that attempts to redefine
the original recurring event.  No where in the RFCs does it
ever instruct an ORGANIZER's CUA to track independent versions
of the same event for different ATTENDEES.  And in fact it
actually says in both iCal and iTIP that you can't do that.
They say this both explicitly and implicitly every time they
talk about global uniqueness, updating a master copy (not
copies) over which only the ORGANIZER has rights to, and
that they expect CUs will pass these objects around to each
other for purposes of delegation and FYI (as indicated by
the reference to a "Party Crasher" which the ORGANIZER
never invited).


As two other examples of where your model breaks apart we
have 3.2.2.3 Delegating to another CU and 3.2.2.6 Forwarding
to an uninvited CU.  Let's use two different people, A and B,
who are invited to separate instances of a recurring event.
In your model, they each will have received an object with
no RECURRENCE-ID which describes a single different date
and time.  If B decides they can't make it, and wants to
delegate to A, or they decide they think A should be invited
as well, A's CUA will be totally confused about the message.
The message from B describes an event which it has on its
calendar, but has a different primary key.  It will have to
apply the message SEQUENCING rules and if the SEQUENCE number
doesn't catch the DTSTAMP value will certainly place the
incoming message as either an old message or one that looks
like an update that didn't come from the ORGANIZER.

Assuming that A's CUA was ultra brilliant and managed to
figure out what was going on it now has the responsibility
of sending a REPLY to the ORGANIZER.  How will the ORGANIZER
unambiguously know what's going on?

In the case of delegation, because B has to send a REPLY to
the organizer as well as A, it will be possible for the
ORGANIZER's CUA to figure out that it should be expecting
something from A that has an event which is actually B's
event merged with A's event (where in the RFC's does _ever_
talk about merging events), _if_ it magically on its own
accord receiving no instruction from the RFCs also treats
the ATTENDEE as part of the primary key for an event.


In the case of B just extending the invite to A, A's reply
when put through the message sequencing rules is just going
to look very strange.  First, just following the iTIP rules
there should only be one version of the same object at any
given time, your model extends the primary key to include
the ATTENDEE, but even then how is the ORGANIZER's CUA
supposed to figure out what just happened.  It's totally
ambiguous as to what the content of the REPLY is actually
going to be...  A had an original version of the UID object,
B invited A to a different version of the same object which
rather than throwing it out as a missequenced message or an
update from someone other than the organizer it decided to
treat as an invite to a separate instance of a recurring
event (why and how it did this I have no clue, I'm just
trying to make your model fit the reality of what needs
to happen here).
At this point A must formluate a reply to the ORGANIZER,
but I can't for the life of me figure out what it should be.

"A" might have two singleton events with differing versions
which it now merges  (despite all the confusion this causes),
to construct a single recurring event with two instances. I
guess it sets the SEQUENCE and DTSTAMP fields to the values
from the "most recent" singleton and just prays that's the
right answer....

"A" might have two recurring event descriptions which
each describe a different single instance which it again
must merge (despite all the glaring violations this causes
especially of 6.1.7).  Again, I guess the SEQUENCE and
DTSTAMP should just be set to the values of the
"most recent" object.


This model gets so convulated when the messages get passed
around because it is in total violation of the assumption
of the authors.  That there would be _one_, globally unique,
uniquely identifiable object that could be distributed
across the Internet without confusion.  The only thing
they then had to do was figure out how to version the
objects so that CUAs could figure out if what they were
looking at was an older or more recent version of the
event which brought about SEQUENCE and DTSTAMP.  They
then associated different semantics to each.

Updating SEQUENCE means something that would violate the
partstat field of the ATTENDEES and DTSTAMP was any for
any other non-triggering update.




So assuming you're still reading at this point, I'll go on.

> >  It should
> > go through the recurrence set and send a reply for all
> > instances that the ATTENDEE has been invited to, but
> > this will be one iTIP message with multiple VEVENT
> > components that each have a RECURRENCE-ID.  Not one
> > component with a UID that matches the original component
> > that the ATTENDEE was not invited to and no RECURRENCE-ID.
>
> Why not?

Because to do it any other way would either violate the global
uniqueness of the UID or imply the CU was invited to event
instances that it wasn't.


> Nothing
> in the RFCs I've read suggest that this is what MUST happen,
> nor even that it SHOULD.

You're right.  There is nothing in the RFCs that talks directly
about this.  There is no example of inviting an ATTENDEE to a
single instance.  There is only the document that should be
internally consistent enough to indicate how this should be
done.  Sadly, it unfortunately isn't, as we both have enough
evidence from the text to defend two very different standpoints.
We have to resort to figuring what the chain of messages in
each model will be to figure out which one holds more water
within the text as a whole.

I also never implied that it MUST do this.  In fact, I very
explicitly said that it had every right just to drop the
message on the floor.  The original recurring event is a
globally unique entity in its own right as must be each
instance of it.  Otherwise CUs passing around messages to
each other (which they are explicitly granted the right to
do) will confuse both each other's and the ORGANIZER's CUA.

I simply said that the most useful interpretation of that
REQUEST is to send a response that included all instances
of the event that the CU was invited to and therefore that's
what the ORGANIZER's CUA should do.


> This seems like a lot of trouble to go to, and while it may be
> necessary to send such a set of VEVENT objects if one subscribes
> to the 'RECURRENCE-ID fixed at SEQ:0' dogma, it is not necessary
> in the 'current-value' interpretation, and both would require
> that a VEVENT object be sent w/o a RECURRENCE-ID at some point,

This last part isn't actually true.  The fixed-id model never
requires a UID without a RECURRENCE-ID object to be consistent.

I will finish out what the CUA does with the response it gets
from the intelligent ORGANIZER which contained a copy of every
instance it was invited to with all objects containing a
RECURREINCE-ID and no object without one.

The recipient CUA would follow the rules as outlined in
2.1.5 Message Sequencing, and 3.2.2 REQUEST for each object.
As such it would go through each instance one by one, and
assuming that it had not missed any other messages it would
find that it found every object referenced and all the
SEQUENCE numbers for each object matched.

At this point it stops.

It processed the entire message and had no problems identifying
any of the objects being referenced.  If it had missed any
messages, then at least one of the SEQUENCE numbers would be
wrong, and section 4.7.2 Bad RECURRENCE-ID would apply which
for the dumb recurring event CUA would cause one last REFRESH
cycle (which I agree is wasteful).

For the smarter CUA it could use the fact that it has already
sent a REFRESH once, it has received a message that conatins
objects of which it found every one and would assume that it
was not invited to the base UID onnly event and not do the
REFRESH cycle again.

This creates the following semantics:

The CUA will send a REFRESH to the ORGANIZER only when it
receives a message for an object with a UID that it cannot
find or the SEQUENCE for any particular instance jumps more
than 1 point.  This means that it will only send a REFRESH
the first time it is invited to its first instance of that
recurring event, or when one of the instances jumps more
than one SEQUENCE number.

This will at worst cause one and only one REFRESH/REQUEST
cycle, lest more missed messages are introduced into
the queue.

> 'current-value' semantics for RECURRENCE-ID are simple, consistent,
> error-reistant, and require less bookkeeping and fewer messages.
> The fact that reading the RFCs and using common definitions for
> 'original' and 'change' supports this view is just gravy, IMHO.

Ok, let's try and follow that "error resistant" train.
First, from above I've shown you why it is a total violation
of the intent of global uniqueness, and the real world problems
with versioning a UID per ATTENDEE.

Now let's talk about the presence of missed messages.

First, let's just say we're talking about very normal
activity where we invite everyone to every meeting.

Let's call SEQ:0 "every Monday for this year".

Every responds in the affirmative that they will attend.
The ORGANIZER, just being nice, sends an update to inform
everyone of the new ATTENDEE status changes.

Now let's say we add a comment to the first instance.
For arguments sake we'll say it says '1st instance'.
This forces the CUA to track some per instance info
for this event which it must persist.
This sends an update to the attendees with RID:1st Monday
and SEQUENCE:0 that sets the comment.  No big deal.



So now we move the 1st instance to Tuesday due to some
major failure the message gets delayed and no one receives
it and the ORGANIZER isn't aware so doesn't resend it.

In the 'current-value' model the official SEQUENCE on
the ORGANIZER's calendar is now 1 and the official RID
is now "1st Tuesday".  There is an inconsistency on
the CUs calendar as they have SEQUENCE:0 and RID:1st Monday.


So now we move the same instance again to Wednesday.
This RID:1st Tuesday and SEQUENCE:2

There is no failure and everybody gets this message.

Everybody now receives a message for RID:1st Tuesday which
none of them have, to now be 1st Wednesday.  Given sections
2.1.5 and 3.2.2 the CUA must put this on the calendar
as a new invitation.
This means they now have two meetings scheduled.
The original Monday version at SEQUENCE:0 and
the new Wednesday version at SEQUENCE:2.
There is nothing in the RFC that says they have to do
anything further at this point.

Dumb CUAs will just let it sit there.  Smarter CUAs
will notice the inconsistency and ask for a REFRESH.
This is what the CUA should do, but it doesn't have to.

Let's say that before the REFRESH answer arrives, the
delayed message shows up.

Since in this model there is only one SEQUENCE  value
that all instances share, and it's lower than the most
recent value we've seen for that UID.  We throw the
update out.  It's old and no longer valid.

If however the 'current-value' model concedes that
each instance tracks its own SEQUENCE as section 3.7.1
dictates, then it process the message as an update
to the 1st Monday instance.

This still creates the wrong situation where there are
two events in the first week, one now on either Monday
or Tuesday depending on whether or not you processed the
message and one on Wednesday.

So now the response to the REFRESH shows up.  The only
valid response it could be in this model is one where
it has rescheduled the set to be every Monday this year,
except the 1st Monday, and an RDATE of 1st Wednesday
with the SEQUENCE set to "2".

This makes the CUA touch every instance of the recurring
event for which it has per instance data and update the
persisted SEQUENCE value to 2.

Finally it has this now bogus event on its calendar at
Monday or Tuesday depending on how you processed it and
so it must delete it since it's not listed in the master
UID object.

In the presence of missed or delayed messages the
'current-value' model must live with invalid calendars
until a full copy of the most recent information arrives.

In the fixed-id model missed messages only result in
dealing with older, but at one time valid data.

Redoing this same example with the fixed-id model
we get the following:
1) Schedule every Monday, accept it, add the comment.
   (no big deal)
2) Miss the Tuesday move
   Again CUs end up with same calendar as above.

3) Receive the Wednesday move.
   Since the fixed RID is still set to '1st Monday'
   The CUA correctly moves the Monday instance to
   Wednesday and updates its SEQUENCE to 2.

At this point dumb CUAs who don't do anything have
and keep a consistent calendar with all info they
have seen to date and nothing is inconsistent with
the actual view the ORGANIZER has.
Smart CUAs will detect the 0 to 2 jump and ask for
a REFRESH.

The old "move to Tuesday" message will show up and
the CUA will accurately identify it as a reference
to the fixed-id '1st Monday' but with SEQUENCE:1
which is less than the 2 it currently has for that
component and discard it.

The response to the refresh will show up and the
data it has on its calendar will exactly match
what's in the message, it will do nothing and
stop there.


This is only a mild example of what can get screwed
up using a 'current-value' model.

-- Michael --