Thread 2: On recurrence exceptions

[Georg C. F. Greve]

Hi Bernhard,

On Wednesday 17 November 2010 18.40:20 Bernhard Reiter wrote:
> Rereading the email I believe Martin only wanted to introduce
> "<subevent>" which could be used once per exclusion to hold 
> the difference to the original event that is repeated.

Yes, that is correct. KEP 3 already incorporates that.


> In the emails referenced by Martin, Joon stated that preserving
> only tags below <event> was the idea of Joon and Bo when they worked out
> the  first format description. Their reasons where technical difficulties.
> Participants seems to have agreed that some technical difficulty is there
> to preserve tags everywhere.

I wonder what the difficulty was, but it seems to be an inconsistency then, as 
the format specification does not specify a "cut off recursion depth."

Do we know how many clients are out there that would lose that information?

And do we consider it a reasonable use case to have both old and new clients 
connected? The old clients would - for want of knowing the subevent tag - not 
be able to display changed recurrences anyhow.

So i think this is a strongly discouraged scenario.


> I am unsure how things will work with invitation handling. We also need to 
> check this with iTip and with the implementations.

As Sergio pointed out, the critical issue here appears to be the concept of 
the recurrence-id, which we can define to be the date of the exclusion from 
recurrence, similar to what iCalendar does, see 4.8.4.4 in
http://www.ietf.org/rfc/rfc2445.txt

So doing it this way will likely make us more compatible with iTip than 
attempting to circumvent the standards by allowing for fragmentation.

Provided that we do define the exclusion date as recurrence-id, we can then of 
course also remove one level from the XML nesting, by adding and requiring an 
explicit recurrence-id tag for subevents, which could then be directly under 
the event tag, even.

That's less elegant, because information is fragmented over the object, rather 
than bundled in its logical place, so I'd prefer the nested approach, which 
will also make handling of these events easier on clients in the future.

But in the end, both are at least possible.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101117/169bb621/attachment.sig>