>And what about the example I sent to this list
that shows how
>your model broken in that area? You know the one that showed
>that new attendess in your model can not process instance
>changes unless they just happen to be the same as the SEQUENCE:0 instances?
Of course nothing works if you send your changing recurrence
ids. This is not the iCalendar RFC 2445
model.
recurrence set is referenced by referring to just the "UID"
property
value corresponding to the calendar component. The "RECURRENCE-ID"
property allows the reference to an individual instance within
the
recurrence set.
If the value of the "DTSTART" property is a DATE type
value, then the
value MUST be the calendar date for the recurrence instance.
The date/time value 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 is still set to the original Friday meeting.
RECURRENCE-ID
ARE SUPPOSE TO BE THE "ORIGINAL" dates
of the "ORIGINAL" repeat set.
If you send your changing values
as recurrence ids to a properly coded iCalendar, of course you will not
work correctly.
_____________________
Note: new email address
tom_ransdell@xxxxxxxxxxxxxxxx
Doug Royer <Doug@xxxxxxxxx> Sent by: owner-ietf-calendar@xxxxxxxxxxxx
08/07/2003 06:05 PM
Please respond to
ietf-calendar@xxxxxxx
To
ietf-calendar@xxxxxxx
cc
Subject
Re: RECURRENCE-ID discussion
Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
> The point I was making is that its 100% easy and straight forward
adding
> ANY ATTENDEE at ANY time after SEQUENCE:0 in "my" (aka iCalendars)
> model. I just moved SEQUENCE ahead to 10 to reuse the fragments
already
> in play but I see that easily confused some folks. Sorry about
that.
>
> Lets see if I can rephrase the point for you: Adding new ATTENDEEs
at
> ANY TIME is no problem with a fixed RECURRENCE-ID model; your claim
of
> "you can NEVER add someone to the series...after any change"
is just
> flat out wrong. Yep, that about rephrases it just right.
And what about the example I sent to this list that shows how
your model broken in that area? You know the one that showed
that new attendess in your model can not process instance
changes unless they just happen to be the same as the SEQUENCE:0 instances?
> Above was an example of how easy it is to add someone to a single
> instance, I simply send them a REQUEST using the current definition
and
> thats it. Adding them to the set is just as easy. I showed
how easy it
> was last month when Arnaud asked for examples. To save time
and effort
> Ill let you go check the archives for 'em if you are still unsure
how it
> can be done.
Except all of your examples were how to modify an existing VEVENT
and you called it inviting a new attendee. There is no problem
to solve, just send them a VEVENT with NO RECURRENCE-ID as all
of the examples in iCAL and iTIP show and every thing works.
There is no need to invent a new way to invite an ATTENDEE.