Subject: [Ietf-calsify] Modifications to instances in a recurrence chain

From: br at osafoundation.org (Bobby Rullo)
Date: Thu Sep 28 17:24:05 2006

Hi all,

I am trying to property implement icalendar recurrence and there are  
some things that are not clear to me.

I was told by a colleague that the way to make changes to an  
individual instance in a chain of recurring events is to create  
within the same calendar an additional VEVENT with the same UID as  
the 'master' event and a RECURRENCE-ID whose value is the normal  
start date of that instance and then any properties that you would  
like to override for that particular instance.

So here are my questions:

	1) The above seems relatively clear to me, but I can't find it  
explicitly explained in rfc2445. Is there another spec which covers  
this?

	2) Is DTSTART a required property for recurrence instances? I would  
not think so, except that iCal automatically inserts a DTSTART into  
recurrence instances even when the only thing I changes was the  
SUMMARY. Just to see what would happen, I exported that calendar, got  
rid of the offending DTSTART and reimported. To my consternation, it  
reinserted the DTSTART with a seemingly random value - until I  
realized that it was the timestamp of when I imported the file.

	3) Is there any other required properties in an overriding VEVENT  
instance?

	4) Any (preferably Mac OS X and free/cheap) clients which handle  
this properly that I should be looking to as a reference  
implementation (at least for recurrence) ?

Thanks all,

bobby rullo

---

From: pregen at egenconsulting.com (Pat R Egen)
Date: Thu Sep 28 17:34:28 2006

RFC2446 covers the VEVENT stuff.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Bobby Rullo <[email-masked]> 
Sent by: [email-masked]
09/28/2006 08:28 PM

To
[email-masked]
cc

Subject
[Ietf-calsify] Modifications to instances in a recurrence chain

Hi all,

                 1) The above seems relatively clear to me, but I can't 
find it 
explicitly explained in rfc2445. Is there another spec which covers 
this?

                 2) Is DTSTART a required property for recurrence 
instances? I would 

                 3) Is there any other required properties in an 
overriding VEVENT 
instance?

                 4) Any (preferably Mac OS X and free/cheap) clients which 
handle 
this properly that I should be looking to as a reference 
implementation (at least for recurrence) ?

Thanks all,

bobby rullo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060928/448b9be3/attachment.htm

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Sep 28 17:35:18 2006

Hi Bobby,

--On September 28, 2006 5:28:04 PM -0700 Bobby Rullo <[email-masked]> 
wrote:

> I am trying to property implement icalendar recurrence and there are some
> things that are not clear to me.
>
> I was told by a colleague that the way to make changes to an individual
> instance in a chain of recurring events is to create within the same
> calendar an additional VEVENT with the same UID as the 'master' event and
> a RECURRENCE-ID whose value is the normal start date of that instance and
> then any properties that you would like to override for that particular
> instance.
>
> explicitly explained in rfc2445. Is there another spec which covers this?
>
> 	2) Is DTSTART a required property for recurrence instances? I would not
> think so, except that iCal automatically inserts a DTSTART into
> recurrence instances even when the only thing I changes was the SUMMARY.
> Just to see what would happen, I exported that calendar, got rid of the
> offending DTSTART and reimported. To my consternation, it reinserted the
> DTSTART with a seemingly random value - until I realized that it was the
> timestamp of when I imported the file.
>
> 	4) Any (preferably Mac OS X and free/cheap) clients which handle this
> properly that I should be looking to as a reference implementation (at
> least for recurrence) ?

The overridden component must be a full component in its own right - i.e. 
it must satisfy all the requirements of vevents - dtstart/dtend or duration 
etc.

At one point in time I also thought that overridden instances only needed 
to include those properties that were different from the original - but the 
problem with that is that you cannot tell if a property was removed. e.g. I 
have five attendees in the 'master' instance and I want to remove one from 
the overridden instance. In that case a 'diff' cannot work because you 
cannot indicate that one was removed. So the rule is the overridden 
component has to be complete - not a diff from the master.

-- 
Cyrus Daboo

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Fri Sep 29 12:17:34 2006

Hi Folks,

Thanks, Bobby, for leaping in with your questions.  You've reminded me 
that I've been delinquent in discussing confusion I've experience (or 
seen other people experience) about recurrence in iCalendar.

For all of these issues I've experienced ambiguity, so I think we should 
really try to clarify them:

A) I'd like to see a clearer link in rfc2445 (or 2445bis) to rfc2446, 
explaining that there's more complexity to serializing recurring events 
with modifications, would be helpful.  I've noticed that a variety of 
smart people have missed that they need to read 2446 to understand 
modifications to recurring events.

B) In both rfc2445 and rfc2445bis-01, the VEVENT component's definition 
says that all properties are optional, but both UID and DTSTART's 
explanations say they are in fact required in VEVENTs.

C) What is the RECURRENCE-ID for an occurrence if an earlier 
modification that applies to THISANDFUTURE has changed the start time? 
My memory is that Cyrus and I had different ideas of how this should 
work.  In practice, both Apple iCal and Chandler create an entirely new 
event (with a new UID) if the user makes a THISANDFUTURE change to 
anything but the first occurrence, so I haven't experienced issues with 
this, but that's only because we don't do iTIP. :)

D) Similarly to C), if there is one or more THIS modifications to a 
particular RECURRENCE-ID, one of which changes the DTSTART, is the 
RECURRENCE-ID changed?  For this I'd say no, the DTSTART and 
RECURRENCE-ID don't match, but the RECURRENCE-ID stays the same.

E) Finally, the more meaty topic, do modification VEVENTs (a VEVENT with 
a particular UID/RECURRENCE-ID pair) represent diffs to the pre-existing 
rule, or an entire self-contained description of the most up-to-date 
information about that particular occurrence?

In past discussions with Cyrus about this, I was swayed by his argument 
that we need a way to delete ATTENDEEs.  But every time I discuss this 
with people it's unsatisfying.

Quick background, I think there are three main ways applications might 
model THISANDFUTURE changes that effect events that are already modified:

1) Don't detach individually modified occurrences, later THISANDFUTURE 
changes effect all occurrences, even if the property being changed was 
already changed
2) Completely detach changes to individual occurrences (THISANDFUTURE 
changes never again effect them)
3) Detach specific properties, so a change to one occurrence's SUMMARY 
won't prevent a change to all DTSTARTs from effecting that occurrence, 
but changes to all SUMMARYs *won't* effect that detached occurrence.

When I've surveyed users, 1) is considered really bad almost universally 
(it's seems too easy to erase important information), 2) is acceptable 
but annoying, and 3) is ideal.  Currently, Chandler and Apple iCal do 
2), I'd be curious to hear about other clients.  In the near future 
Chandler will move to doing 3).

If, when serialized as iCalendar, modifications are required to express 
the full and complete state of the modification (not just diffs to the 
master), then it's impossible to semantically express the concept of a 
particular detached property, it's all or nothing.

In practice, I think that many clients (at least iCal and Chandler) 
*when parsing an icalendar stream* already interpret the absence of many 
properties as implying that the property is inherited from it's parent.

So, back to the ATTENDEE case.  It seems to me that clients could 
interpret the absence of a property as implying that it's inherited, but 
if even one instance of that property is present in the modification, 
it's a change.  I think this would solve the ATTENDEE case.  The main 
thing I can think of that wouldn't work would be deleting a VALARM, 
which I would find preferable to not being able to express

If we interpreted modifications as working this way, I think we'd want 
to allow VEVENTs to not have a DTSTART if they had a RECURRENCE-ID, and 
of course, either way, we should specify the behavior clearly in the 
relevant specs.

Sincerely,
Jeffrey