Subject: RE: Recurrence ID changes?

From: [email-masked]
Date: Mon, 26 Jul 1999 23:06:25 GMT

Dan:
That is good! I forgot about this case. This is the case where you send 
out a REQUEST (SEQUENCE=0), then follow it up with a REQUEST (SEQUENCE=1, 
RECURRENCE-ID=19990726T133000Z) that changes the LOCATION (or some such 
peripheral property). Now you can't just send one REQUEST reply to the 
REFRESH. The RECURRENCE-ID values specifies one occurrence that will need 
a separate REQUEST to specify the different LOCATION property (or 
whatever).
Now, if this difference was expressable with a REQUEST, then Alex is 
correct, there are three ways to express this. It would be nice to agree 
on a common one to simplify interoperability. However, if this could only 
be expressed with a different method (i.e., ADD), then you can't express 
this as a single iCalendar object containing two VEVENT definitions. 
Rather, you need two iCalendar objects in a multipart/related or 
multipart/mixed container. Hence, if we agree that a common "packaging" is 
necessary, then it ought to be the multipart approach. Right?
-- Frank

---

From: Alexander Taler <[email-masked]>
Date: Mon, 26 Jul 1999 19:13:29 -0400

Can't this information always be expressed with a REQUEST?
At the very worst case I send a different VEVENT for each 
recurrence of the event:

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:bad string
VERSION:2.0

BEGIN:VEVENT
UID:foo
DTSTART:19990712T000000Z
SUMMARY:Bridge night
LOCATION:My place
END:VEVENT

BEGIN:VEVENT
UID:foo
DTSTART:19990719T000000Z
SUMMARY:Bridge night
LOCATION:Martha's place
END:VEVENT

BEGIN:VEVENT
UID:foo
DTSTART:19990726T000000Z
SUMMARY:Bridge night
LOCATION:Local pub
END:VEVENT

END:VCALENDAR

[email-masked] wrote:
> 
> Dan:
> 
> That is good! I forgot about this case. This is the case where you
> send out a REQUEST (SEQUENCE=0), then follow it up with a REQUEST
> (SEQUENCE=1, RECURRENCE-ID=19990726T133000Z) that changes the
> LOCATION (or some such peripheral property). Now you can't just send
> one REQUEST reply to the REFRESH. The RECURRENCE-ID values specifies
> one occurrence that will need a separate REQUEST to specify the
> different LOCATION property (or whatever).
> 
> correct, there are three ways to express this. It would be nice to
> agree on a common one to simplify interoperability. However, if this
> could only be expressed with a different method (i.e., ADD), then
> you can't express this as a single iCalendar object containing two
> VEVENT definitions. Rather, you need two iCalendar objects in a
> multipart/related or multipart/mixed container. Hence, if we agree
> that a common "packaging" is necessary, then it ought to be the
> multipart approach. Right?
> 
> -- Frank