Subject: ADD does not INVALIDATE current PATTERN

From: [email-masked]
Date: Fri, 29 Aug 2003 15:53:16 -0400

An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it does 
not change the pattern of existing set.
If an ADD INVALIDATED the existing set, than you would be forced to send a 
new RRULE/RDATES/EXRULE/EXDATES with ADD.
In that case the ADD would be pointless, just include the new DATE in the 
new rules.

An ADD is equivalent to sending the invitee an REQUEST with a 
RECURRENCE-ID that he does not currently have.
The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his 
calendar, storing off RECURRENCE-ID that CHAIR supplied.

The CHAIR does not really care either.  He is in control and just adds it 
to his set.

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 29 Aug 2003 14:11:02 -0700

I totally agree that an ADD does not invalidate any preexisting
RECCURENCE-ID.

I completely disagree that ADD does not change the current pattern.

ADD does change it only in a non-destructive manner though.

If I have an every Monday event and then ADD every Tuesday,
I have a new set.

This new set is every Monday and Tuesday.

I communicate this by telling existing ATTENDEEs to ADD every Tuesday.

If I invited a new CU post-ADD they would recveive a single UID
with recurrence rules describing every Monday and Tuesday.

The SEQUENCE value for the base event has increased.  The UID/SEQ
pair value has therefore changed and if ADD could ever be a
destructive change to the pattern then it could invalidate RIDs
according to the rules.

If we said that ADD did not change the recurrence pattern then it
would be impossible for ATTENDEEs to verify the set of possible
RECURRENCE-IDs through the response to a REFRESH.

If it didn't alter the recurrence rules, then the response object
would only contain the description of "every Monday". The "every
Tuesday" that had been added would be removed from the Calendar.

Since ADD can never be a destructive act it is only necessary to
send a description for the new set of instances.  The rules
described in the "ADD" message can be safely merged with the
existing rules of the base object while increasing the
SEQUENCE number.

This process is shown in example 4.4.7 of iTIP.
However where I expected the fourth "RDATE" to be in the REFRESH
response object was an "Error! Bookmark not defined" statement.
However looking closely, you can see that the "4th instance" is
indeed listed there.

Example 4.4.7 also covers "ADD".
This one however reveals a really strange case for preexisting
modifications to instances prior to the ADD.  In the example,
the new SEQUENCE update is going to be 7 and therefore by
design all the existing instance modifications will be <7.

The ADD is going to set the base object to be SEQ:7 which would
trump all instance specific data and force them to be removed
from the calendar.

However, from the text and examples, while it doesn't explicitly
address it, there is an implication that using an ADD will
preserve all existing instance specific modifications.

So is the right move to implicitly update all instances with
updates to 7+1 so that the instance data gets preserved?

The main problem I'm thinking of is CUs are going to want to
update their status info for those instances.  Their responses
should be at least SEQ:7, but preferably SEQ:>7.  Otherwise,
even though nothing about those instance has changed, the
ORGANIZER's CUA will think that it has not seen a response
for the latest version of those instances yet.

Or am I missing something simple?

-- Michael --

<[email-masked]> wrote in message
news:[email-masked]...

---

From: Doug Royer <[email-masked]>
Date: Sat, 30 Aug 2003 11:43:37 -0600

[email-masked] wrote:
> 
> An ADD does not INVALIDATE any RECURRENCE-ID in current set.  Thus it 
> does not change the pattern of existing set.
> If an ADD INVALIDATED the existing set, than you would be forced to send 
> a new RRULE/RDATES/EXRULE/EXDATES with ADD.
> In that case the ADD would be pointless, just include the new DATE in 
> the new rules.

The ADD method was added after a discussion on how to add instances
to an existing set that had something such as LOCATION different.

For example a series of meetings that take place around the world
(The IETF meetings for example). As each meeting may have a unique
LOCATION there is no way to describe the next few meetings in one
object. With the ADD method you can add to the instances of an
existing UID. So if the original object sent is a multipart/realted
MIME object. With one REQUEST and five ADD objects, then that is
describing the meeting set (pattern) for that UID. There are also
other valid reasons that a set of meetings could not be described
in on object.

So how could an iMIP CUA that can not do multipart differentiate
between the one multipart/related object that contained two MIME
objects (1 REQUEST + (5 ADD)) and a series of single MIME objects
(1 REQUEST + 1 ADD + 1 ADD + 1 ADD + 1 ADD + 1 ADD) if they are not
equivalent? It could not. So the net result has to be that the ADD
method also adds to the pattern exactly the same as if ADD was used
in the initial REQUEST multipart/mime object - it changes the pattern.

> RECURRENCE-ID that he does not currently have.

The ADD method is the only iTIP way described to add an instance
(RECURRENCE-ID) to an ATTENDEEs view that does not already exist in an
object known to the ATTENDEE. And RECURRENCE-ID is disallowed from
the ADD method in the iTIP restriction tables because it would limit
ADD to adding one instance at a time to the set.

I can not find any text or example that says you can invite someone
to a new instance by sending REQUEST and RECURRENCE-ID. I can find
text that says you can modify an existing instance with REQUEST
and RECURRENCE-ID. I can also find text that describes how to invite
an attendee. So equivalent to what?

> calendar, storing off RECURRENCE-ID that CHAIR supplied.

iTIP specifically disallows RECURRENCE-ID in ADD methods. Or do
you mean it would store the additional patterns described in the
DTSTART, RRULE, RDATE, EXRULE and EXDATE?

> The CHAIR does not really care either.  He is in control and just adds 
> it to his set.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Sun, 31 Aug 2003 12:00:10 -0400

> an attendee. So equivalent to what?

See ITIP REQUEST METHOD 3.2.2 REQUEST

    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.

The text does not say "This does not apply to new request" so it is valid 
for all METHOD REQUEST.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/30/2003 01:43 PM
Please respond to
"[email-masked]" <[email-masked]>

To
"[email-masked]" <[email-masked]>
cc

Subject
Re: ADD does not INVALIDATE current PATTERN

--