Subject: RDATE question

From: Frank Spafford <[email-masked]>
Date: Wed, 13 Nov 2002 09:42:00 -0800 (PST)

I looked through the archives, but I can't find an answer to this question.

Suppose I have a repeating event, say a meeting, and the meeting has a LOCATION property of "Conference room 4".  For one meeting, however, the location is changed to "Conference room 2". 

How should I handle this situation?

Would this work:

RDATE;LOCATION=Conference room 2;TZID="Central Time (US & Canada)":20021107T100000,20021108T100000

---------------------------------
Do you Yahoo!?
U2 on LAUNCH - Exclusive medley & videos from Greatest Hits CD

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Nov 2002 12:34:09 -0700

That's one reason for the ADD method.

You can ADD a VEVENT to a repeating set of instances. It has the same
UID as the associated repeating events.

I recall it being added when we realized that if you meet once a month
at location X on Monday, then need to change one instance (or more) to
location Y on Tuesday (for example), then there was no way to keep it as part
of the same set. So we added the 'ADD' method.

Frank Spafford wrote:
> Suppose I have a repeating event, say a meeting, and the meeting has a 
> LOCATION property of "Conference room 4".  For one meeting, however, the 
> location is changed to "Conference room 2".
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> U2 on LAUNCH 
> <http://rd.yahoo.com/launch/mailsig/*http://launch.yahoo.com/u2> - 
> Exclusive medley & videos from Greatest Hits CD

-- 

  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: Mon, 18 Nov 2002 11:18:16 -0500

> UID as the associated repeating events.

ADDing is only the initial action to consider.  There is also how to send 
updates to a range of instances that can include the 'different place' 
entry.  Its now no longer possible to use the 
RECURRENCE-ID;RANGE=THISANDFUTURE w/o adversely affecting the LOCATION of 
the instance that is at a different place.

The problem gets much more complex/painful in this scenario since the 
recipient would treat the update/reschedule as a LOCATION change for the 
ADDed event too unless you take steps to prevent that.

Actually the ADD method is orthogonal to the need as I read it.  If I want 
to create the new event at the new LOCATION then ADD is the way to go.  If 
I want to create it differently from the start then ADD does not come into 
play.   Although the startup case and the range update case appear 
differently the solution to both is probably the same; crafting the right 
iCalendar stream at the Organizers end of things.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...