Subject: Recurrence ID changes?

From: "Dan Hickman" <[email-masked]>
Date: Wed, 21 Jul 1999 13:26:47 -0500

The paragraph below is shown at the very end of section 3.7.1 in the rfc2446
(iTIP).  The last two sentences seem to conflict in meaning.  The first says
that "the original DTSTART value is used for RECURRENCE-ID" but the second
says that "RECURRENCE-ID has changed to the new DTSTART".

I thought we decided to leave the RECURRENCE-ID the same.  If the last
sentence is true, then it seems we would have to exclude the original date
in an "EXDATE" property and then include the new date in an "RDATE"
property.  Is this right?

   An instance of a recurring event is assigned a unique identification,
   "RECURRENCE-ID" property, when that instance is renegotiated.
   Negotiation may be necessary when a substantive change to the event
   or to-do has be made (such as changing the start time, end time, due
   date or location). The "Organizer" can identify a specific recurrence
   instance using the "RECURRENCE-ID" property. The property value is
   equal to the date/time of the instance. If the "Organizer" wishes to
   change the "DTSTART", the original "DTSTART" value is used for
   "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
   reflect the change.  Note that after the change has occurred, the
   "RECURRENCE-ID" has changed to the new "DTSTART" value.

Thanks,
Dan Hickman

---

From: [email-masked]
Date: Thu, 22 Jul 1999 02:39:28 GMT

Dan:
If you issue a REFRESH, the RECURRENCE-ID property can only be specified 
if you want a refresh for a specific occurrence. Otherwise, you would be 
issueing a REFRESH with a UID, SEQUENCE two-tuple to identify the whole 
recurrence set. 
If you issue a REFRESH for a RECURRENCE-ID that doesn't exist anymore 
(i.e., SEQUENCE is "stale" and the RECURRENCE-ID doesn't correspond any 
longer to an occurrence), then you should get an error.
The response to the REFRESH for the whole recurrence set could be the 
initial REQUEST, followed by the reschedule REQUEST, in a 
multipart/related container. Right?
Another approach, that may be inline with your original thoughts, would be 
to send a single REQUEST with the RRULE for the original recurrence set, 
the EXDATE to negate the original occurrence that was rescheduled and a 
RDATE for the newly scheduled occurrence. Now I see what you were 
suggesting in your original note. However, as I pointed out, this form of 
the iCalendar object probably should not be used to reschedule an 
individual occurrence but might be a good approach for responding to the 
REFRESH.
Glad you are back involved in the mailing list.
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Mon, 26 Jul 1999 12:53:46 -0700 (PDT)

> From: "Dan Hickman" <[email-masked]>
> Date: Mon, 26 Jul 1999 14:34:21 -0500
>
> If all changes could be rolled into a single instance, then I agree.  For
> instance, if only the date-time changed then addition of an EXDATE and RDATE
> properties to the original component would suffice.
> 
> However, as soon as you change anything else about an individual occurrence
> (i.e. Subject, Attendees, Categories, etc) then this cannot be represented in
> a single component.  One component must be sent for the original event
> definition and another component would have to be sent with the individual
> RECURRENCE-ID changes.

True - And to create one you might need to use the METHOD:ADD in iTIP.

If the UID is the same - its part of the same recurrence even
if not in the same component (same organizer ...). 

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Mon, 26 Jul 1999 15:51:56 -0400

Dan replied:
>(i.e. Subject, Attendees, Categories,etc) then this cannot be represented 
in a
>single component.  One component must be sent for the original event 
definition
>and another component would have to be sent with the individual 
>RECURRENCE-ID changes.

I agree w/this but that is not how Frank described it in his response to 
you.  He wrote:

>The response to the REFRESH for the whole recurrence set 
>could be the initial REQUEST, followed by the reschedule 
>REQUEST, in a multipart/related container.

This is incorrect, no??  The actual format of the multipart/related would 
be the full snapshot of the current REQUEST (not the "initial" REQUEST) 
and then the exception modification in a separate body part.

I think we are all in agreement here; I just wanted to make sure there was 
no confusion about the contents of the multipart related (ie: the original 
REQUEST and then a delta or set of some deltas up to the current SEQUENCE, 
etc).

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Mon, 26 Jul 1999 22:16:30 GMT

Bruce is correct, I was wrong. Sorry. The response to the REFRESH would be 
a single REQUEST. Responses to a REFRESH are always a REQUEST reflecting 
the current state of the calendar component description.
However, all iTIP methods are not full snapshots. For example, the CANCEL 
and REPLY are are examples of shortened messages. The CANCEL need not have 
a copy of all of the properties of the calendar component that is being 
cancelled. Like wise with the REPLY. FYI.
Thanks, Bruce.

>Actually I dont think so.   Why would you send 2 entries, the "original" 
and the
>"update"??  Aren't all messages supposed to be 'full snapshots'?  If so, 
only the
>'current ' state needs to be sent.  Hence, if the SEQUENCE was 'stale' 
then the
>Organizer would send a new full snapshot in a single message; not a 
'base' and then the 
>most recent 'delta' (as that wont suffice at all).

---

From: [email-masked]
Date: Wed, 28 Jul 1999 14:37:11 GMT

Alex:
No, Your example is not valid iTIP for an VEVENT/REQUEST.
Syntax errors: 
You have multiple definitions of UID=foo without any RECURRENC-ID 
specified. This means that you have ambiguous definition of the VEVENT 
where UID=foo. If you specify the UID only, then this means that you are 
referring to the complete recurrence set.
You only specify an ATTENDEE that matches the ORGANIZER. If this is a 
group scheduled event, then by definition (when two or more of you get 
together...) you need attendees other than the ORGANIZER. iTIP restriction 
table for VEVENT/REQUEST specifies "1+" which means more than one.
Semantic errors:
Your VEVENT specifies a DTSTART with a date-time value type. This means 
you need a DTEND. If you mean all-day, then you MUST not specify a 
date-time value type, unless you specify a DTEND.
As mentioned above, your semantics for this iCalendar object are 
ambiguous, as you specify the same UID in all the VEVENTs, but no 
RECURRENCE-ID. This implies that the scope for each VEVENT definition is 
the complete recurrence set for UID=foo.
As mentioned above it is unclear who the participants are in the meeting, 
besides the ORGANIZER. You need to specify other participants or this is 
not a group scheduled meeting, but rather an appointment. Hence, no one 
would be issuing a REFRESH on the event. 
Which leads to another semantic error/issue. If you receive a REFRESH from 
a CUA that is not represented by an ATTENDEE value in the calendar 
component, then you MUST NOT respond to this REFRESH. This is a security 
threat by someone that is probing your calendar data base. See section 
3.2.6, 'The "REFRESH" method in a "VEVENT" calendar component is used by 
"Attendees" of an existing event to request an updated description...". 
This means that non-attendees are NOT supposed to be using this to get 
calendar info. These types of requests are security threats.
Hope this helps.
-- Frank

[email-masked] wrote:
> 
> This is improver iCalendar sytax. No "UID", no "SEQUENCE", etc.
> Maybe you weren't trying to be precise?
> 
> You can only add events to an existing request with an "ADD" method;
> not a "REQUEST".
> 
> Dan's point was not just the scenario for adding an occurrence, but
> changing some other details in an occurrence so that a single
> REQUEST would actually obliterate the differences. You are right,
> for this you might be able to use a second REQUEST with an
> incremented "SEQUENCE" value and a "RECURRENCE-ID" to show the
> different property values from the original occurrence set. That is,
> as long as the occurrence was defined in the occurrence set defined
> by the initial "REQUEST".
> 

Frank,

I was replying to what you said here 
(Message-ID: <[email-masked]>):

> 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). 

I don't think that you ever need separate REQUESTs to respond to 
a refresh.  The following is valid iTIP, and shows how a single
REQUEST can include instance specific information.  (Each recurrence
has a different location.)  This could be an initial REQUEST
(SEQUENCE:0) or a response to a REFRESH.

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

BEGIN:VEVENT
LOCATION:My place
UID:foo
ATTENDEE:mailto:[email-masked]
ORGANIZER:mailto:[email-masked]
DTSTART:19990712T000000Z
DTSTAMP:19990702T000000Z
SUMMARY:Bridge night
END:VEVENT

BEGIN:VEVENT
LOCATION:Martha's place
UID:foo
ATTENDEE:mailto:[email-masked]
ORGANIZER:mailto:[email-masked]
DTSTART:19990719T000000Z
DTSTAMP:19990702T000000Z
SUMMARY:Bridge night
END:VEVENT

BEGIN:VEVENT
LOCATION:Local pub
UID:foo
ATTENDEE:mailto:[email-masked]
ORGANIZER:mailto:[email-masked]
DTSTART:19990726T000000Z
DTSTAMP:19990702T000000Z
SUMMARY:Bridge night
END:VEVENT

END:VCALENDAR

Alex