Re: [Fwd: I-D ACTION:draft-royer-rid-ical-00.txt]

> > Doug, from what I read on Frank and Derik's replies and on other peoples
> > comments on the list, I see a pattern evolving.  People are coding their
> > applications using more of a fixed model.  Why do we have to have a
> > complicated draft when all we need to do is remove the one sentence in
> > 3.7.1, change examples to reflect that change and resubmit the draft.
>  >
> > So, my question to everyone on the list that has been active on the
> > Recurrence-ID issue - does this sound like too simplistic an approach?
> > Am I missing something.  The arguments seem to lean towards Bruce's
> > comments and attempt at a model.

That is certainly a step in the right direction and would clear
up the blatant conflicts.

However there are other areas too.
Off the top of my head:

"Bad Recurrence-ID" needs to be expanded to include a fourth
possibility; that it has never seen neither the base UID nor
the RECURRENCE-ID before.

The "may be" in "so that each instance may be both sequence
and versioned" needs to be changed to "is" I don't recall the
section offhand.  This needs to make it explcit that the
SEQUENCE value for each instance is tracked independently
and that they do not share a common SEQUENCE counter.


Somehow it needs to be made clear that every relevant reference
to "UID" throughout the document really means something more
along the lines of "primary key" which could include UID,
RECURRENCE-ID, and RANGE to accurately identify which events
are being referred to.  Much of the confusion here has been
as a result of interpretting "UID" to not mean all of those.

Any place where dealing with recurring instances (or sets of
them via RANGE) is not appropriate should be explicitly
mentioned that such use is inappropriate.  I cannot think
of any such cases at the moment.


Making it clear that when canceling an event for a particular
user the SEQUENCE value should not be incremented (or at least
more discussion on what it should do).


I'm sure there are others.  If there is a new list thread started
after some definite declaration that the changing recurrence-id
model is dead and should be eliminated from iTIP and perhaps we
should look at making iCal even more clear I'll be happy to provide
more direct textual recommendations with section numbers.


Of course these are just my initial thoughts and I'd be happy to
hear others either confirm, disagree, or add to these.


> I have a list that I am not confident to send out yet as I re-read
> the examples sent. It looks as if there are 4 distinct models and
> not 2. This list will be included in the next rev of that draft.
>
> Its not as simple as 'fixed' vs. 'non-fixed' which is one of the
> points of the draft.

At one point in time it appeared as if there was more than
1 fixed-id model.

But I think that the split perceived was actaully a consequence
of limiting the scope of the conversation in attempt to create
clarity since it was getting harder and harder to put together
sentences that Doug would understand.

Doug's two fixed-id models as hes explained so far are thus:
1) A recurrence-id is created at the time the instance is
   first born into existence and is fixed from then on
   forever regardless of any other changes to the event.

2) A recurrence-id is fixed from the last "rescheduling"
   of the base event.

Rescheduling means a SEQUENCE bump with the UID and no
RECURRENCE-ID (in many cases the recurrence-ids actually
stay the same, but not all).

"Add" is officially a rescheduling, but it has no destructive
powers over any existing RECURRENCE-ID.

It's not entirely clear to me at this time if canceling an
instance (and I mean truly canceling it) is a rescheduling
of the base event or an update to just the instances involved.
I leave this to someone else with more clarity on this issue
to clarify for us.


Model (1) has been obsolete since Derik and Frank's post and
I'm not event clear that it was ever believed that model (1)
was ever the totality of how to deal with recurring events.

I'm fairly confident that regardless of what might have been
flying around at the beginning of the conversations, the
fixed-id camp has all come to using model (2).

There was a time in the conversation when the discussion
was explicitly trying to exclude reschedules of the base
event from the conversation.  When such an exclusion is made,
recurrence-ids are indeed permanently fixed from SEQUENCE:0
and model (1) is actually the truth in that context.

Doug never seemed to grasp this part of the conversation.

Doug also hasn't understood per instance sequence numbers,
or at least has never been able to represent the model
accurately to demonsrate any sort of competence in using it,
and as a result he may be seeing more models than we've
actually been talking about.

I can absolutely gaurantee that Doug's list is obsolete
regardless of what's on it.  There are not 4 models
flying around.  He's just seeing 4 models.


What Doug also might have on his list came from differences in
opinion about how rescheduling all instances would have occured.

After hashing it out, we discovered that there are two ways
to reschedule every instance in a series, and we initially were
talking about our respective methods which caused confusion.

One way is to reschedule the entire series, the other is to
provide the first RECURRENCE-ID in the series and use the
RANGE:THISANDFUTURE.  These two methods result in slightly
different objects on the calendar though the displayed results
to the CU are the same.

That has since been resolved and we are in agreement that
each of us was always saying the right thing given their view.

-- Michael --