Re: RECURRENCE-ID discussion

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

> > 7) The REQUEST message the new invitee received, lists
> >    a VEVENT object with a UID that is not on its calendar
> >    since the CU has never been invited to this or any
> >    other version of this event before (regardless of whether
> >    or not SEQUENCE is 0 or there is a RECURRENCE-ID present).
> >    [As per the assumptions.]
> > Agree/Disagree?
>
> As long as you do not make it look like a modification
> to an existing VEVENT - agree.

Just because it might look like a modification to you doesn't
mean that it is one?  Sections 3.2.2.1 and 3.2.2.2 define the
only times a message can be a modification and the only times
a message can ever be a modification is when the CUA has the
existing UID on its calendar.

You are putting the cart before the horse.
i.e. You are putting the example before the definition.

Section 4.4.2 is an EXAMPLE of how to modify a recurring
instance.  It is not the definition of how to detect whether
or not a message is a modification of a recurring instance.

The definition of how to detect if a message is a modification
comes from section 3.2.2 we can't move on until we've resolved
this point as its critical to the proper interpretation of the
REQUEST message.

You assert that just because something looks like the
object in 4.4.2 it is a modification.  This is not true.

Anything that happens to actually be a modification will
look like 4.4.2.  But if it happens to be something else
it might look like 4.4.2 too.  A reconfirmation, a response
to a REFRESH, and a new invite will all look like 4.4.2.

Just because a message happens to look like it could be a
modification because it shares similar values to 4.4.2
doesn't mean that it is.  There are only two things that
can tell you if a request message is a modification of some
sort.  One is section 3.2.2.1 and the other is section 3.2.2.2
and neither of them are applicable if the CUA has does not
find the UID in question on its calendar.


Let me put this yet another way.  All of section 4 is examples.

As such they are theoretically not needed because the prose
above actually dictates what those examples will say. Right?

The examples are useful for creating some clarity around
what the text says sometimes, but it is not in any way shape
or form any kind of actual definition.  The examples are just
instances of the above sections.  In this case, example 4.4.2
happens to be an instance of section 3.2.2.1.

Section 3.2.2.1 is only valid "If the recipient CUA of a
"REQUEST" method finds that the "UID" property value already
 exists on the calendar".

If you send a REQUEST method to a CU and the CUA does
not have the corresponding UID on its calendar neither
section 3.2.2.1 nor 3.2.2.2 can be applied and therefore
the message cannot be a modification, reconfirmation, or
reschedule regardlesss of how much it looks like 4.4.2.

-- Michael --