Doug wrote on 12/04/2003 04:10:11 PM:
> > Section 4.8.4.4 Recurrence ID
> > . . .
> > The date/time value (RECURRENCE-ID) is set to the time when the
> > original recurrence
> > instance would occur; meaning that if the intent is to change a
> > Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still
> > set to the
> > original Friday meeting.
>
> Meaning in the object being sent in the reschedule. In order to say X
> moves to Y,
> you need to properties to hold X and Y. So the above paragraph means
send a
> new object with the new Y in RECURRENCE-ID and the old X in DTSTART.
Lets not start this again shall we? The original authors have even
responded to this and they have clearly said that RECURRENCE-ID does not
change on an instance reschedule. The DTSTART for the instance can change
on each instance reschedule but the the RECURRENCE-ID does not.
I dont know what you mean by "hold X and Y". What you need is an
identifier to correctly identify the instance in question as its
properties change. Thats why was specified RECURRENCE-ID not to change on
reschedules but DTSTART can. The others have got it right from the bits
Ive read.
If the identifier changed each time, you'll have one heck of a time trying
to deal with missequenced or lost messages. Thats why RECURRENCE-ID does
not change on each instance reschedule; so you can safely detect missed
messages or missequenced ones and properly deal with them. Doug and
Franks response to this seemed to be pretty clear on this point.
And you seem to have it backwards in your last line there. The reschedule
would send the unchanged RECURRENCE-ID (the old X?) and the new DTSTART
(the new Y?) in a reschedule REQUEST (with 'newer' or 'higher' SEQUENCE,
DTSTAMP etc values). Thus a second reschedule would use the same
unchanged RECURRENCE-ID (the old X?) and another newer DTSTART (a new Z)
value with a still higher SEQUENCE and newer DTSTAMP.
If RECURRENCE-ID was supposed to be the previous incarnations DTSTART then
you have 3 problems to contend with: Cases where reschedules do NOT entail
changes to DTSTART (ie: a duration change only), how to deal with
resequencing of messages that can arrive in any order and how to deal with
missed messages. If you tried to build a 'chain' of RECURRENCE-ID(0) ->
DTSTART(1) / RECURRENCE-ID(1) -> DTSTART(2)... then you cannot recover
easily if a message is lost. It has been shown that in 5 simple steps you
can easily mangle the workflow process when missequencing occurs too.
Derik & Frank noted as much in their recent posting on this.
> > With RECURRENCE-ID consigned to the role of an identifier
> > it clearly falls to DTSTART to represent a recurrence instance's
> > effective start time.
>
> 2445 is talking about a reschedule object not what 2446 calls the master
> object.
2445 deals with the C&S properties and their meanings / behavoiur. 2446
deals with putting those properties into a coherent message for doing C&S
workflow.
The term "master" as first used in iTIP Section 2.1 Application Protocol
refers to the Organizers copy of the entry since that is the "definitive"
copy. All other copies are just that, copies that may or may not be in
sync w/the Organizers version. Much like there is only 1 'master' copy of
the U.S. Constitution or the Deed for your property. There can be copies
made all you like but there is only 'master' copy or version of it.
The line:
"Attendees" do not make
direct changes to the master calendar entry.
could be slightly wrong in the CAP context since it is possible that an
Invitee may have sufficient access rights to go and modify the Organizers
copy directly. However this was not how we originally modeled the
workflow process since that was not something anyone actually did in the
C&S systems. Invitees always sent some kind of response back and the
Organziers CUA (or perhaps server) would apply that change (or keep the
information separate from the actual entry itself). Whether or not its
good CAP design/practice to allow invitees to do this is something else
though...
> > This statement makes it clear that a recurrence instance has a
> > DTSTART property containing the "effective" value ... and this is
> > where RECURRENCE-ID gets its initial value. Initially, DTSTART
> > and RECURRENCE-ID have the same value. If the instance is
> > changed to a different time, DTSTART changes and
> > RECURRENCE-ID does not.
>
> Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the
> subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART.
>
> Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you
have 3
> daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC,
and
> the 3rd 6-DEC.
[Snip]
> Is does not say the "the value of DTSTART is", it says the value [of
> recurrence-id]
> is the effective value of DTSTART. Not the same meaning.
You are correct in that the text under 4.8.4.4 does NOT discuss the
DTSTART value for the instance. It is talking about how RECURRENCE-ID is
defined and dealt with. The text actually says:
The date/time value is set to the time when the original recurrence
instance would occur...
meaning that when the instance is created the DTSTART and RECURRENCE-ID
values are the same. As the instance gets rescheduled, the DTSTART
may/may not change but the RECURRENCE-ID defintely does not. It is kept
at the "original" value for the instance (which matched the original
DTSTART value the instance had).
The only reason the term "effective" is used is because not all recurrence
is sent using RDATEs where the values are just given. With RRULEs the
recipent must roll the rule out and calculate when the date/time of each
repeat instance is (factoring in TZ shifts, etc).
> It also does not say the value of DTSTART and RECURRENCE-ID are both
> set to the same value (as I understoon one person to have said).
I guess its all in how you read the cited line above then.
BTW: more than 1 person has said this. I said it when we had the entire
RECURRENCE-ID discussion during the summer and Frank and Derik (the
original authors of 2445) said this in their posting on 18-Aug-03
(http://www.imc.org/ietf-calendar/mail-archive/msg08662.html ):
a) the value for RECURRENCE-ID was agreed to be the date/time value of the
original recurrence instance. This value remains unchanged for as long as
the base recurrence set (or pattern) exists. A rescheduling of an
individual recurrence instance did not cause creation of new base
recurrence set, but only moved the start/end of the specified recurrence
instance.
and they even tried to explain why we did this:
This semantic and behavior was settled on because it is imperative in
order for an implementation to maintain order and sensibility between the
original definition for the recurrence set and exceptions created by
subsequent rescheduling actions on the recurrence set. To illustrate,
consider the consequences if RECURRENCE-ID changed on each reschedule of
an instance. Specifically, if the RECURRENCE-ID is changed on each
reschedule of an instance, the sender and the recipient have no way to
accurately know which instance is being referred to if just a single iTIP
message was lost or mis-sequenced, or if the message is an invitation to a
new instance entirely. This inability to distinguish invitation, from
reschedule, from update is not problematic with the fixed RECURRENCE-ID
because it is unambiguous which instance is being referred to.
Ok, I guess it depends on your understanding of the word "original" but
thats not something we need to codify in RFCs I hope. After all, you
should be assigning RECURRENCE-ID properties to each instance when you
first create them so you should see that the DTSTART and RECURRENCE-ID
values you start with are the same.
Bruce
===========================================================================
Bruce Kahn INet:
[email protected]
Messaging & Collaboration Phone: 978.399.6496
IBM Software Group FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.