RFC: KEP3: Introduction of 'subevent' sub-tag for 'exclusion' from 'recurrence' (revision #10661 2 uses cases for <exception><subevent><deleted> and <exception><subevent><exceptionStartDate>

[Georg C. F. Greve]

Hi Alain,

Thanks for providing some more details! :)

On Sunday 12 December 2010 17.27:38 Alain Abbas wrote:
> step 2 :
> modify the subject one one of the occurence

This example seems to deviate from the current specification, no?

Right now an exception would be modeled as

<recurrence cycle="*daily*">
  <interval>1</interval>
  <range type="*number*">5</range>
  <exclusion>EXCEPTIONDATE</exclusion>
</recurrence>

which means that on EXCEPTIONDATE, the recurrence does not take place, the 
event has been deleted. Now if it has been modified, e.g. the summary as in 
your example, according to KEP 3 it would look like this:

<recurrence cycle="*daily*">
  <interval>1</interval>
  <range type="*number*">5</range>
  <exclusion>EXCEPTIONDATE
    <subevent>
       <summary>Changed summary </summary>
       <creation-date>DATE</creation-date>
       <last-modification-date>DATE</last-modification-date>
    </subevent>
  </exclusion>
</recurrence>

The change of the start date according to KEP 3 would look like this:

<recurrence cycle="*daily*">
  <interval>1</interval>
  <range type="*number*">5</range>
  <exclusion>EXCEPTIONDATE
    <subevent>
       <start-date>NEW DATE</start-date>
       <creation-date>DATE</creation-date>
       <last-modification-date>DATE</last-modification-date>
    </subevent>
  </exclusion>
</recurrence>

Both of these would give you the "root date" of the exception, which also MUST 
be used for Recurrence ID in iTIP handling. And it would maintain full 
backward compatibility, whereas  your suggestion seems to break it entirely. 
That may be justified if there is a major advantage to be gained - but what 
that might be escapes me right now.

So what is the major advantage of the different approach?

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/20101213/d995ebac/attachment.sig>