Re: Recurrence ID changes?

[Alexander Taler <alext@xxxxxx>]

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


Frank_Dawson@lotus.com 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).
> 
> 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