Re: RECURRENCE-ID discussion

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

"Doug Royer" <Doug@xxxxxxxxx> wrote in message
news:3F32CF99.9040901@xxxxxxxxxxxx
>
>
> Robert_Ransdell@xxxxxxxxxxxxxxxx wrote:
> >
> > Do you disagree that iTIP says that if it has a RECURRENCE-ID and
> > METHOD:REQUEST that it is a modify and not a new invitation?
> >
> > This blatantly FALSE.
> >
> > The request method makes no such distinction.
> > If you receive a request and it is not on your calendar, you must treat
> > it as an invitation.
>
> Nope - iTIP - Modify A Recurring Instance, look for:
>
> ...Note the use of "RECURRENCE-ID" property and "SEQUENCE"
> property in the second request.

What does this have to do with making a new REQUEST?

Of course this example uses a RECURRENCE-ID and it is
an update because the recipient already has their calendar.

A new REQUEST _by definition_ is one for which the CUA
has never seen the UID before.  This example is totally
out of a context.  A REQUEST is sent to do lots of things.

Some of which are to request a new VEVENT, update an existing
event, reconfirm an existing event, reschedule an existing
event, and as a response to a REFRESH.

How the local CUA treats the REQUEST is clearly laid out
in Section 3.2.2 of iTIP where it explicitly states that
if it has never seen the UID before it's a request for a
new VEVENT calendar component.

I can't find anything in the text that says:
If it has a RECURRENCE-ID and METHOD REQUEST then it is
an update, but in every single example case the recipient
CUA already has a copy of the UID.
It is not a new appearance.

Even the example that triggers the REFRESH request only
does so because it has received a message for which the
UID/SEQUENCE it already has versus the one in the message
is a 2+ difference so it figured it missed some updates
and wants the latest updated copy.

Again, not a new instance of a UID which it has never
seen before.

> And i iTIP - Working With Recurrence Instances, at and near:
>
>     ...If the "Organizer" wishes to
>     change the "DTSTART", the original "DTSTART" value is used for
>     "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
>     reflect the change.  Note that after the change has occurred, the
>     "RECURRENCE-ID" has changed to the new "DTSTART" value.
>
> If you add RECURRENCE-ID to a REQUEST VEVENT it is a modification.

This is simply saying that if you want to modify a VEVENT
you include the RECURRENCE-ID to identify it.  Your local
calendar has seen the UID before, and all preexisting ATTENDEES
have also seen the UID before so therefore it's a RESCHEDULE
because the UID already exists and the SEQUENCE is larger than
what all of them have seen.  This is clearly defined in
section 3.2.2.2.

If the recipient CUA has never seen the UID before it is treated
as a new request as defined in 3.2.2


-- Michael --