Re: ADD does not INVALIDATE current PATTERN

[email protected] 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.

> An ADD is equivalent to sending the invitee an REQUEST with a 
> 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?

> The invitee WOULD take CHAIRS word for RECURRENCE-ID and add it to his 
> 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 protected]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards