Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed

From: Eliot Lear <[email-masked]>
Date: Tue, 06 Nov 2007 10:02:40 +0100

Bernard,

We have heard no discussion on your proposal.  Fair warning to all:
silence shall equal consent to the request below.

Eliot

Eliot Lear wrote:
> Dear all,
>
> On August 3rd, Bernard tried for the third time to gain consensus on
> this topic.  Please comment now.  We would like to close RFC2445bis and
> this is one of several niggling points remaining.
>
> Please state your preference as to which solution below you prefer.
>
> Thank you,
>
> Eliot
>   
>
> ------------------------------------------------------------------------
>
> Subject:
> [Ietf-calsify] Issue 63: Section 4.8.5.3 Recurrence Date/Times: RDATE
> < DTSTART
> From:
> Bernard Desruisseaux <[email-masked]>
> Date:
> Fri, 03 Aug 2007 17:22:51 -0400
> To:
> Calsify WG <[email-masked]>
>
> To:
> Calsify WG <[email-masked]>
>
>
> Disclaimer: This is the third time I bring up this issue. See:
>
> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-November/001349.html
>
> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-February/001522.html
>
>
> Cyrus recently brought up the fact that the deprecation of
> RANGE=THISANDFUTURE (Issue 48) might be an issue with unbounded
> recurring calendar components in the context of iTIP.
>
> I have already suggested a solution for the case where an
> organizer cancels all future recurrence instances of a
> recurring calendar component.  See:
>
> http://lists.osafoundation.org/pipermail/ietf-calsify/2007-July/001746.html
>
>
> This time I would like to suggest a solution for the case where
> an organizer changes all future recurrence instances of a recurring
> calendar component:
>
> 1- Specify RDATE properties for all past recurrence instances
>    and define exception components for them if needed. The
>    number of past recurrence instances is always finite...
>
> 2- Remove EXDATE properties for any past recurrence instances.
>
> 3- Set DTSTART to the first recurrence instance to which you
>    want the change to apply.
>
> The only issue here is that we need to clarify that RDATE can
> specify a value less than the value specified by DTSTART.
>
> Cheers,
> Bernard
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>   
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Andrew N Dowden <[email-masked]>
Date: Wed, 07 Nov 2007 18:00:08 +1300

>> specify a value less than the value specified by DTSTART.
Is there anything wrong with? :

1- Specify RDATE properties for all past recurrence instances,
    while excluding those removed by EXDATE properties..
   ( The number of past recurrence instances is always finite. )

2- Remove any RRULE and EXDATE properties.

3- Set DTSTART to match the first RDATE property.

-- 

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 14 Nov 2007 01:33:34 -0500

Hi Andrew,

> 2- Remove any RRULE and EXDATE properties.

We're trying to address an issue with *unbounded* recurring
calendar components here (i.e., RRULE doesn't specify the
COUNT nor the UNTIL rule parts).

Removing the RRULE property would clearly make the recurring
calendar component bounded which is not want we want.

Cheers,
Bernard