[Ietf-calsify] The guts of recurrence rules as implemented

[Doug Royer]

(A) Looking at the data used by vendors, there seems to be 4 ways
     vendors deal with recurring rules:

(A.1) Only keep the original object and expand the instances
       dynamically.

(A.2) Only keep the expanded instances and toss the original.
       Makes infinitely expanding object break.

(A.3) Keep both the original and expanded instances. And they
       dynamically expand and cache the expanded instances as needed.

(A.4) Ignore any recurrence rules.
       Makes much break.


(B) And there are 2 ways vendors do DTSTART and RECURRENCE-ID on
     expanded instances.

  (B.1) In the expanded instance, they keep DTSTART
        the same as in the original object (iTIP 4.5.7.2 & 4.5.7.2).
        Set the RECURRENCE-ID value equal to the effective start
        time of the instance.


  (B.2) Set the DTSTART value and the RECURRENCE-ID value
        equal to each other all of the time. For those
        that do (A.2) they later notice they are unable
        to reschedule some types of requests under specific
        circumstances.

(C) A solution to (A.*) is to suggest that both the expanded and
     unexpended objects be sent by default. And we pick some limit
     for infinite or large expanding rules. (I had suggested
     a way to represent that on this list earlier - IS-SUB-SET
     parameter)

Now for what will be the debate. (B.*).

   (B.2) I see no advantage to always setting the DTSTART and
         RECURRENCE-ID value to be equal to the value of the other.
         The vendor data that I have seen that does this does not
         store the raw ICS files anyway (as their primary cal-store).
         So translating to/from the iTIP way does not seem like a burden.

         Doing the math to compute the start time is easy on any
         system including PDAs. That has been converted. If you
         do not remember, new to the list or can not find it, post
         a message for the details.

   (B.1) By doing (B.1) any single instance has all of the information
         needed to reschedule under any circumstances. Except: when
         the vendor stores in (A.2) format.

In the past there has been a large debate on this. I went back
and re-read the debate and in every case that I could find
(after looking to see how the vendor really did it) was a mixture
of (B.1) and (A.2) where things broke.

So, I think that (C) solves the problem. Everyone gets what
they want PLUS they have to do the simple math if they
store their data in (A.2) format.

If we do (C) and (B.2) then people that do not do (A.2) can
not correctly store their data and other specific combinations
of things break later in scheduling.

In a simple example. A 3 day recurring VEVENT would send a total
of 3 VEVENTs when exchanging calendar information (by default).
In all three objects the DTSTART value would be the DTSTART value
of the first instance (B.1 method). The RECURRENCE-ID value would
be the effective start date of the specific instance. And all
recurrence rules would be included in all objects. More
bandwidth - but as far as I can tell 100% interoperate with
anyone that even comes close to complying with 2445 and 2446.

Right now (B.2) implementations already have to do the math, they
just do it when sending objects. And (B.1) implementations already
do the math when getting objects.

By adding some unique property (Like the EXTENSIONS one I propose) then
everyone can tell that the sender is conforming to the 'new' standard.

The other solution is for the 3 day VEVENT to send 4 objects.
The original, then include 3 more VEVENTs in (B.2) format.


-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug at Royer.com                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20041230/48f9af0e/smime.bin