Re: ADD does not INVALIDATE current PATTERN

As I suspected, you did not read the email. The subject
is 'ADD' not 'REQUEST'. Now read 'ADD':

	3.2.4 ADD

	...


   	  RECURRENCE-ID   0

[email protected] wrote:
> 
> Doug wrote:
>  > 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?
> 
> 
> 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 protected]>
> Sent by: [email protected]
> 
> 08/30/2003 01:43 PM
> Please respond to
> "[email protected]" <[email protected]>
> 
> 
> 	
> To
> 	"[email protected]" <[email protected]>
> cc
> 	
> Subject
> 	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
> 

-- 

  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