Thread 2: On recurrence exceptions
Georg C. F. Greve
greve at kolabsys.com
Wed Nov 17 19:16:42 CET 2010
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>
More information about the format
mailing list