Subject: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Oct 19 13:02:29 2006

Here's an omnibus proposal that addresses the following issues:

Issue 13: Is the first instance defined by DTSTART always
           considered as part of the COUNT of a recurrence
           rule?

Issue 24: Need to clarify number of recurrence instances
           generated when multiple recurrence rules are
           specified.

Issue 25: Is the first instance defined by DTSTART always
           excluded by EXRULE?

Based on the information I currently have, we only have
good interoperability when:

   - The value of the DTSTART property matches the pattern of
     the recurrence rule;

   - Only a single RRULE property is specified;

   - No EXRULE property is specified.

Given that most calendar client applications currently don't provide
a way to create a recurring component:

   - with a DTSTART property value that doesn't match the
     pattern of the recurrence rule;

   - with multiple recurrence rules;

   - with an exclusion recurrence rule.

I propose to modify the iCalendar specification to state the
following:

   - In a recurring component, the value of the DTSTART property
     SHOULD match the pattern of the recurrence rule. The recurrence
     set generated with a DTSTART property value that doesn't match
     the pattern of the rule is undefined.

   - The RRULE property SHOULD NOT occur more than once in a
     recurring component. The recurrence set generated with
     multiple RRULE properties is undefined.

   - The use of the EXRULE property is deprecated.

     Every reference to EXRULE would be removed from the draft.
     The EXRULE property would be documented as "Deprecated" in
     an Appendix of the draft and would refer readers to RFC 2445
     for more information on this property.

Cheers,
Bernard

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Thu Oct 19 14:43:13 2006

> Issue 25: Is the first instance defined by DTSTART always
SYMMETRICAL::  This issue should be slaved to the agreed resolution for
Issue 13.

That is to say, re-stating Issue 13:  If the first instance of DTSTART
is 'always' / 'NOT necessarily' included by RRULE(s) - then EXRULE
behaviour should match this.

-- 
_______________________________________________

  SoftDesign Group
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Thu Oct 19 14:43:25 2006

>           considered as part of the COUNT of a recurrence
I am in favour of a conditional inclusion (for COUNT), rather than a
blanket include/exclude principle.  While a blanket exclude (or include)
is simpler for coding, this still has to make sense to the vast hordes
of users (who tend to rely on common sense).
>   - The value of the DTSTART property matches the pattern of
This is a separate issue.  Some packages already impose this through
their GUI interface, but do not necessarily when importing, or even fail
when importing 'floating' DTSTART values outside the recurrence set. 
That is more symptomatic of lack of clarity, rather then deliberate intent.
>     the pattern of the rule is undefined. 
A simpler alternative would be exclude DTSTART (from the recurrence
set), when is does NOT match the pattern.

  - In a recurring component, the value of the DTSTART property
    SHOULD match the pattern of the recurrence rule. The recurrence
    set generated with a DTSTART property value that does not match
    the pattern of the rule will only use DTSTART to define duration.

  SoftDesign Group

---

From: andrew_dowden at softdesign.net.nz (Andrew N Dowden)
Date: Thu Oct 19 14:44:10 2006

>   - Only a single RRULE property is specified;
There needs to be an agreed minimum standard, or rating, for what
elements of rfc2445 are supported by which packages or platforms.  These
'guidelines' needs names, and industry pressure to target these levels.

Deleting (deprecating) elements that (although not yet widely supported)
would be of great value and functionality is NOT (in my humble opinion)
a function of an interface standards document.

If a single (open source) effort correctly implements these type of
features, and this functionality is included in the 'Level Green 0.2b'
(example only) interoperability guidelines - then 'barriers to entry' or
ability to achieve should be minimal.

The determining factor is going to be clarity, particularly in those
areas that (as previously noted by others) there is room for interpretation.

  SoftDesign Group

---

From: lear at cisco.com (Eliot Lear)
Date: Fri Oct 20 01:16:52 2006

We have a mechanism to add a label to "compliant" implementations (for 
some value): it's the version field, which can be specified as a range.  
IMHO that was a smart move by the original authors.  Anyone tested their 
implementations to know if they'd handle a range in that field correctly?

Eliot

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Oct 20 06:33:41 2006

Hi Bernard,

>      for more information on this property.

+1

I believe this is the right thing to do given the demonstrated lack of 
interoperability of this in current implementations. If we were to try and 
take 2445 to draft status we would likely have to do it anyway.

Apart from anything else it also simplifies recurrence rules to some degree 
(perhaps not as much as some would like) - but does get us moving in the 
right direction.

PS Please note that this also has an impact on iTIP - so I will need to 
make corresponding changes there once we have agreement on 2445bis.

-- 
Cyrus Daboo

---

From: lear at cisco.com (Eliot Lear)
Date: Fri Oct 20 06:38:48 2006

Bernard,

Thank you for this proposal.  I believe it addresses the desire of 
people to simplify recurrence rules, and at the same time deals with 
much of the ambiguities in the issues that we have been discussing.

I would ask that you please go ahead and make the changes to the draft 
accordingly in order for people to actually see what you have in mind.  
If you can have this in people's hands before the cutoff on Monday, 
that'd be utterly fantastic.

Thanks for your initiative,

Eliot

Bernard Desruisseaux wrote:
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Sun Oct 22 22:58:02 2006

Eliot,

I've just submitted draft -03 with the changes you've requested.

Those interested to review the draft before it is announced can
find it at the following locations:

http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-03.html

http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-03.txt

Cheers,
Bernard

---

From: mike at pscs.co.uk (Mike Higginbottom)
Date: Mon Oct 23 02:14:24 2006

>      for more information on this property.

Have we defined what actions are to be taken when implementations  
encounter undefined/deprecated content? I guess a blanket statement along  
the lines of 'ignore any undefined/illegal content' would be the best  
approach but some implementors might ignore only part of the data or make  
some kind of best guess. A defined, standard approach would be beneficial.  
I'm assuming this hasn't already been done somewhere of course...

-- 
Mike Higginbottom
Paul Smith Computer Services
Silk Mill House
196 Huddersfield Road
Meltham
Holmfirth
HD9 4AW
United Kingdom

http://www.pscs.co.uk
+44 (0)1484 855800

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Oct 23 04:37:39 2006

> the lines of 'ignore any undefined/illegal content' would be the best

This means we break backwards compatibility with RFC 2445, when multiple 
RRULEs or RRULEs that don't match the DTSTART are encountered. For RRULEs 
with an UNTIL or not limitation at all, the current RFC was quite 
uncontroversial, only the COUNT lead to problems.

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

---

From: lear at cisco.com (Eliot Lear)
Date: Mon Oct 23 06:05:01 2006

> uncontroversial, only the COUNT lead to problems.

Right.  The problem here is that we cannot dictate what the right answer 
is for code that is already written :-(  but we can say, "Look, don't 
generate rules that we know will be interpreted in different ways."

Eliot