Subject: [Ietf-calsify] meeting agenda

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Nov 2007 13:06:38 +0100

Our agenda this time looks an awful lot like the agenda last time:

1.  Agenda Bashing (1 minute)
2.  Administrativia (Chairs - 3 minutes)
3.  RFC2445bis Status (Chairs - 5 minutes)
4.  RFC2446bis Discussion (Cyrus - the rest)

We plan on spending the vast bulk of the time on item 4, with the
expectation that we will close on changes sometime after the IETF
meeting.  Resolving RFC2446bis will also close ALL changes to
RFC2445bis, Issue 63 not withstanding.

Eliot
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Fri, 23 Nov 2007 13:06:38 +0100
From: Eliot Lear <[email-masked]>
To: CALSIFY Mailinglist <[email-masked]>
Subject: [Ietf-calsify] meeting agenda

Our agenda this time looks an awful lot like the agenda last time:

1.  Agenda Bashing (1 minute)
2.  Administrativia (Chairs - 3 minutes)
3.  RFC2445bis Status (Chairs - 5 minutes)
4.  RFC2446bis Discussion (Cyrus - the rest)

We plan on spending the vast bulk of the time on item 4, with the
expectation that we will close on changes sometime after the IETF
meeting.  Resolving RFC2446bis will also close ALL changes to
RFC2445bis, Issue 63 not withstanding.

Eliot

Date: Wed, 21 Nov 2007 13:48:19 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] iTip Cancel
Cc: [email-masked]

Hi Bernard,

--On Wednesday, November 21, 2007 10:23 -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

>> Hi,
>>   I am assuming support for RANGE in RECURRENCE-ID will be removed from
>> iTIP too. If so, how do I cancel all future instances of an existing
>> never ending series? Would it be a request to change the RRULEe to put
>> in an until, instead of a cancel?
>
> Yes.
>
> Another option would be to modify the master component with
> DTSTART set to the first instance to cancel and specify
> STATUS:CANCELLED, and specify RDATE and exception components
> for all previous recurrence instances.  Humm...

That would be extremely ugly!

> That being said, truncating the RRULE with COUNT or UNTIL
> looks much simpler to me.

Is that sufficient? Shouldn't CANCEL's be sent?

I still feel we are missing a lot by removing RANGE.

-- 
Cyrus Daboo

Date: Wed, 21 Nov 2007 10:23:44 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] iTip Cancel
Cc: [email-masked]

Ciny Joy wrote:
> Hi,
>   I am assuming support for RANGE in RECURRENCE-ID will be removed from 
> iTIP too. If so, how do I cancel all future instances of an existing 
> never ending series? Would it be a request to change the RRULEe to put 
> in an until, instead of a cancel?

Yes.

Another option would be to modify the master component with
DTSTART set to the first instance to cancel and specify
STATUS:CANCELLED, and specify RDATE and exception components
for all previous recurrence instances.  Humm...

That being said, truncating the RRULE with COUNT or UNTIL
looks much simpler to me.

Cheers,
Bernard

> 
> Thanks,
> Ciny
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 

Date: Tue, 20 Nov 2007 14:42:15 -0800
From: Ciny Joy <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-calsify] iTip Cancel

Hi,
   I am assuming support for RANGE in RECURRENCE-ID will be removed from 
iTIP too. If so, how do I cancel all future instances of an existing 
never ending series? Would it be a request to change the RRULEe to put 
in an until, instead of a cancel?

Thanks,
Ciny

To: [email-masked]
From: [email-masked]
Date: Mon, 19 Nov 2007 00:00:02 -0500
Cc: [email-masked]
Subject: [Ietf-calsify] I-D Action:draft-ietf-calsify-2446bis-04.txt 

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring and Scheduling Standards Simplification Working Group of the IETF.

	Title           : iCalendar Transport-Independent Interoperability Protocol (iTIP)
	Author(s)       : C. Daboo
	Filename        : draft-ietf-calsify-2446bis-04.txt
	Pages           : 122
	Date            : 2007-11-18

This document specifies a protocol using the iCalendar object
specification to provide scheduling interoperability between
different calendar systems.  This is done without reference to a
specific transport protocol so as to allow multiple methods of
communication between systems.  Subsequent documents will define
profiles of this protocol using specific interoperable methods of
communications between systems.
iTIP complements the iCalendar object specification by adding
semantics for group scheduling methods commonly available in current
calendar systems.  These scheduling methods permit two or more
calendar systems to perform transactions such as publish, schedule,
reschedule, respond to scheduling requests, negotiation of changes or
cancel.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-calsify-2446bis-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-calsify-2446bis-04.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-calsify-2446bis-04.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-calsify-2446bis-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-11-18235549.I-D\@ietf.org>

--OtherAccess--

--NextPart--

Date: Thu, 15 Nov 2007 16:10:37 -0800
From: Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

Thanks again Bernard.
Sorry about not cc'ing the list earlier. It was an accidental omission.
I usually get the digest of the mailing list emails. So haven't seen 
Cyrus's reply yet. But glad to know I wasn't completely off track.
Looking forward to more discussions that might provide a solution to the 
preserving of future exceptions on a time change issue.

Thanks,
Ciny

Bernard Desruisseaux wrote:
> Hi Ciny,
>
> I'm only replying to you since you didn't CC the list on your message.
> Not sure why though!
>
> Ciny Joy wrote:
>> Bernard Desruisseaux wrote:
>>>
>>> Here you'll notice that the RDATE for the 2nd recurrence instance
>>> specifies the original scheduled time of this instance in order to
>>> preserve the original RECURRENCE-ID.
>> Thanks a lot for the detailed explanation. But if the "This & Future" 
>> change is for any field other than dtstart/dtend like description, 
>> attendee etc, we will need to create exceptions for all past instances?
>
> Yes.
>
>>> The real concern here is that starting from the 4th recurrence
>>> instance, we have lost the original RECURRENCE-IDs. 
>> We also remove any existing exception components in the future?
>
> You're right!  All the recurrence instance that were cancelled
> by mean of an EXDATE would also disappear.
>
>>> We need to
>>> think carefully about how bad that really is.  What are our
>>> options?
>>>
>>> 1- Keep the RANGE parameter and address its issues.  Hummm...
>>>
>>> 2- Remove the RANGE parameter, and recommend to move DTSTART
>>>    to the future instance that corresponds to the new recurrence
>>>    pattern for all future instances (current proposal) and
>>>    live with the fact that the RECURRENCE-ID of all those
>>>    instances will have changed.
>>>
>>> 3- Remove the RANGE parameter, and recommend to split the
>>>    calendar component in two. One calendar component with
>>>    the original RRULE modified to specify a COUNT or UNTIL
>>>    rule part, and a second calendar component that specify
>>>    a new RRULE with no COUNT or UNTIL rule part.
>>>
>>> 4- Something we haven't thought about yet...
>>>
>>> Not clear which is the best (or less worse) solution.
>>> Perhaps it depends on the situation.  When an Organizer
>>> decide to reschedule all future recurrence instances
>>> option (3) might be the way to go.  On the other hand,
>>> when an Attendee decide to decline all future recurrence
>>> instances, option (2) might be the only way to go.
>> The way I was thinking was, the difference is between a change that 
>> affects time and a change that doesn't. For the latter, wouldn't 
>> creating exceptions for the past events with the old data and 
>> updating master and existing future exceptions with the new be enough?
>
> Cyrus pointed this out on the mailing list and I agree.
>
> > For the
>> former, we were thinking of option 3 but some folks wanted to keep 
>> future exceptions. And that meant exception components with 
>> recurrence-ids that did not match the master. We got stuck there :-(
>
> I don't have much time to investigate right now, but it seems that
> Apple iCal is able to do that.  I'll get back to you when I'll have
> a chance to look at what they are actually sending to our server...
>
>>
>> Again, I might be way off track on this.
>
> No, you're not!
>
> Cheers,
> Bernard
>
>>
>> Thanks,
>> Ciny
>>> I'm wondering how many people bothered to read this email
>>> that far. Send me a private email if you did. Just curious.
>>> Sorry.
>>>
>>> Cheers,
>>> Bernard
>>>
>>>
>>>>
>>>> Thanks,
>>>> Ciny
>>>>>
>>>>>>
>>>>>>>> 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.
>>>>>>>>   
>>>>>> So is original DTSTART lost completely?
>>>>>
>>>>> The recurrence instance previously defined by DTSTART would become
>>>>> a simple recurrence instance defined by an RDATE property. You
>>>>> wouldn't be able to figure out what was the original DTSTART.
>>>>>
>>>>> > Doesn't this go against the
>>>>>> statement, "However, in such cases the original "DTSTART" date 
>>>>>> MUST still be maintained by the calendaring and scheduling system 
>>>>>> because the original "DTSTART" value has inherent usage 
>>>>>> dependencies by other properties such as the "RECURRENCE-ID"."
>>>>>
>>>>> I would think that what really matter is that the set of 
>>>>> RECURRENCE-ID
>>>>> is maintained.
>>>>>
>>>>>> If not, is there a standard way of maintaining it?
>>>>>> Also, in multiple places it is stated "The "DTSTART" property 
>>>>>> defines the first instance in the recurrence set". Will that be 
>>>>>> modified?
>>>>>
>>>>> That would clearly need to be modified.
>>>>>
>>>>> Cheers,
>>>>> Bernard
>>>>>>
>>>>>> Thanks,
>>>>>> Ciny
>>>>>>
>>>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Date: Thu, 15 Nov 2007 17:01:49 -0500
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Cc: [email-masked]

Hi Bernard,

--On November 15, 2007 3:03:59 PM -0500 Bernard Desruisseaux 
<[email-masked]> wrote:

> The real concern here is that starting from the 4th recurrence
> instance, we have lost the original RECURRENCE-IDs. We need to
> think carefully about how bad that really is.  What are our
> options?
>
> 1- Keep the RANGE parameter and address its issues.  Hummm...
>
> 2- Remove the RANGE parameter, and recommend to move DTSTART
>     to the future instance that corresponds to the new recurrence
>     pattern for all future instances (current proposal) and
>     live with the fact that the RECURRENCE-ID of all those
>     instances will have changed.
>
> 3- Remove the RANGE parameter, and recommend to split the
>     calendar component in two. One calendar component with
>     the original RRULE modified to specify a COUNT or UNTIL
>     rule part, and a second calendar component that specify
>     a new RRULE with no COUNT or UNTIL rule part.
>
> 4- Something we haven't thought about yet...

> On the other hand, when an Attendee decide to decline all future
> recurrence instances, option (2) might be the only way to go.

Actually I disagree. In that case there is a finite set of instances that 
the attendee has accepted and an infinite set that is declined. So the 
master component is marked as declined, and then overridden components for 
the finite set added with accepted status for that attendee. None of that 
involves either (1), (2) or (3).

I'm still not sure what the best overall solution for this is though. I am 
concerned about the loss of RECURRENCE-ID sync caused by (2). I think the 
rule should be if you have to do something that causes the recurrence-ids 
to change then you have to split the events. So that would cover the case 
of changing the time of all future instances, or changing the pattern of 
the rule, but not of changing the location of all future instances. For the 
later you would change the location of the master, then override all 
components upto the actual point of change and use the old location in 
those. Same would apply to attendee state etc. However, if we take that 
approach, it actually eliminates some of the problems with RANGE= and makes 
that more viable.

-- 
Cyrus Daboo

Date: Thu, 15 Nov 2007 15:03:59 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Cc: [email-masked]

Hi Ciny,

Ciny Joy wrote:
> Thanks Bernard. Just one question below...
> 
> Bernard Desruisseaux wrote:
>> Hi Ciny,
>>
>> Ciny Joy wrote:
>>>
>>>>
>>>>>
>>>>> 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.
>>> How do you define "if needed"?
>>
>> A past recurrence instance identical to the recurrence instance
>> defined by DTSTART, except for its scheduled time, would not need
>> a separate component.
> If we are making a "This & Future" change and changing dtstart to the 
> first instance of the newly created series, won't all past instances be 
> different from DTSTART? Or am I understanding this wrong?

Here's a simple example where separate components would not be
needed for past recurrence instances:

A.1 Schedule a daily event at 9:00 AM forever starting on Nov. 12.

     BEGIN:VEVENT
     DTSTART;TZID=America/Montreal:20071112T090000
     DTEND;TZID=America/Montreal:20071112T100000
     RRULE:FREQ=DAILY
     ...
     END:VEVENT

A.2 Reschedule 4th recurrence instance (Nov. 15) as well as
     all future recurrence instances at 10:00 AM

     BEGIN:VEVENT
     RDATE;TZID=America/Montreal:20071112T090000/20071112T100000
     RDATE;TZID=America/Montreal:20071113T090000/20071113T100000
     RDATE;TZID=America/Montreal:20071114T090000/20071114T100000
     DTSTART;TZID=America/Montreal:20071115T100000
     DTEND;TZID=America/Montreal:20071115T110000
     RRULE:FREQ=DAILY;COUNT=5
     ...
     END:VEVENT

Now let's look at a slightly more complex example:

B.1 Schedule a daily event at 9:00 AM forever starting on Nov. 12.

     BEGIN:VEVENT
     DTSTART;TZID=America/Montreal:20071112T090000
     DTEND;TZID=America/Montreal:20071112T100000
     RRULE:FREQ=DAILY
     ...
     END:VEVENT

B.2 Reschedule 2nd recurrence instance (Nov. 13) at 10:00 AM.

     BEGIN:VEVENT
     DTSTART;TZID=America/Montreal:20071112T090000
     DTEND;TZID=America/Montreal:20071112T100000
     RRULE:FREQ=DAILY;COUNT=5
     ...
     END:VEVENT
     BEGIN:VEVENT
     RECURRENCE-ID;TZID=America/Montreal:20071113T090000
     DTSTART;TZID=America/Montreal:20071113T100000
     DTEND;TZID=America/Montreal:20071113T110000
     ...
     END:VEVENT

B.3 Reschedule 4th recurrence instance (Nov. 15) as well as
     all future recurrence instances at 10:00 AM

     BEGIN:VEVENT
     RDATE;TZID=America/Montreal:20071112T090000/20071112T100000
     RDATE;TZID=America/Montreal:20071113T090000/20071113T100000
     RDATE;TZID=America/Montreal:20071114T090000/20071114T100000
     DTSTART;TZID=America/Montreal:20071115T100000
     DTEND;TZID=America/Montreal:20071115T110000
     RRULE:FREQ=DAILY;COUNT=5
     ...
     END:VEVENT
     BEGIN:VEVENT
     RECURRENCE-ID;TZID=America/Montreal:20071113T090000
     DTSTART;TZID=America/Montreal:20071113T100000
     DTEND;TZID=America/Montreal:20071113T110000
     ...
     END:VEVENT

Here you'll notice that the RDATE for the 2nd recurrence instance
specifies the original scheduled time of this instance in order to
preserve the original RECURRENCE-ID.

The real concern here is that starting from the 4th recurrence
instance, we have lost the original RECURRENCE-IDs. We need to
think carefully about how bad that really is.  What are our
options?

1- Keep the RANGE parameter and address its issues.  Hummm...

2- Remove the RANGE parameter, and recommend to move DTSTART
    to the future instance that corresponds to the new recurrence
    pattern for all future instances (current proposal) and
    live with the fact that the RECURRENCE-ID of all those
    instances will have changed.

3- Remove the RANGE parameter, and recommend to split the
    calendar component in two. One calendar component with
    the original RRULE modified to specify a COUNT or UNTIL
    rule part, and a second calendar component that specify
    a new RRULE with no COUNT or UNTIL rule part.

4- Something we haven't thought about yet...

Not clear which is the best (or less worse) solution.
Perhaps it depends on the situation.  When an Organizer
decide to reschedule all future recurrence instances
option (3) might be the way to go.  On the other hand,
when an Attendee decide to decline all future recurrence
instances, option (2) might be the only way to go.
I'm wondering how many people bothered to read this email
that far. Send me a private email if you did. Just curious.
Sorry.

Cheers,
Bernard

> 
> Thanks,
> Ciny
>>
>>>
>>>>> 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.
>>>>>   
>>> So is original DTSTART lost completely?
>>
>> The recurrence instance previously defined by DTSTART would become
>> a simple recurrence instance defined by an RDATE property. You
>> wouldn't be able to figure out what was the original DTSTART.
>>
>> > Doesn't this go against the
>>> statement, "However, in such cases the original "DTSTART" date MUST 
>>> still be maintained by the calendaring and scheduling system because 
>>> the original "DTSTART" value has inherent usage dependencies by other 
>>> properties such as the "RECURRENCE-ID"."
>>
>> I would think that what really matter is that the set of RECURRENCE-ID
>> is maintained.
>>
>>> If not, is there a standard way of maintaining it?
>>> Also, in multiple places it is stated "The "DTSTART" property defines 
>>> the first instance in the recurrence set". Will that be modified?
>>
>> That would clearly need to be modified.
>>
>> Cheers,
>> Bernard
>>>
>>> Thanks,
>>> Ciny
>>>
>>>>> 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
>>>
>>
> 
> 

Date: Wed, 14 Nov 2007 10:59:01 -0800
From: Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Sender: [email-masked]
To: Bernard Desruisseaux <[email-masked]>
Cc: [email-masked]

Thanks Bernard. Just one question below...

Bernard Desruisseaux wrote:
> Hi Ciny,
>
> Ciny Joy wrote:
>>
>>>
>>>>
>>>> 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.
>> How do you define "if needed"?
>
> A past recurrence instance identical to the recurrence instance
> defined by DTSTART, except for its scheduled time, would not need
> a separate component.
If we are making a "This & Future" change and changing dtstart to the 
first instance of the newly created series, won't all past instances be 
different from DTSTART? Or am I understanding this wrong?

Thanks,
Ciny
>
>>
>>>> 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.
>>>>   
>> So is original DTSTART lost completely?
>
> The recurrence instance previously defined by DTSTART would become
> a simple recurrence instance defined by an RDATE property. You
> wouldn't be able to figure out what was the original DTSTART.
>
> > Doesn't this go against the
>> statement, "However, in such cases the original "DTSTART" date MUST 
>> still be maintained by the calendaring and scheduling system because 
>> the original "DTSTART" value has inherent usage dependencies by other 
>> properties such as the "RECURRENCE-ID"."
>
> I would think that what really matter is that the set of RECURRENCE-ID
> is maintained.
>
>> If not, is there a standard way of maintaining it?
>> Also, in multiple places it is stated "The "DTSTART" property defines 
>> the first instance in the recurrence set". Will that be modified?
>
> That would clearly need to be modified.
>
> Cheers,
> Bernard
>>
>> Thanks,
>> Ciny
>>
>>>> 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
>>
>

Date: Wed, 14 Nov 2007 01:33:34 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Cc: ietf-calsify <[email-masked]>

Hi Andrew,

Andrew N Dowden wrote:
> Eliot Lear wrote:
>>> 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.
>>>     
> 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.

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

> 
> 3- Set DTSTART to match the first RDATE property.
> 

Date: Wed, 14 Nov 2007 01:20:06 -0500
From: Bernard Desruisseaux <[email-masked]>
To: Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Cc: [email-masked]

Hi Ciny,

Ciny Joy wrote:
> 
>>
>>>
>>> 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.
> How do you define "if needed"?

A past recurrence instance identical to the recurrence instance
defined by DTSTART, except for its scheduled time, would not need
a separate component.

> 
>>> 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.
>>>   
> So is original DTSTART lost completely?

The recurrence instance previously defined by DTSTART would become
a simple recurrence instance defined by an RDATE property. You
wouldn't be able to figure out what was the original DTSTART.

 > Doesn't this go against the
> statement, "However, in such cases the original "DTSTART" date MUST 
> still be maintained by the calendaring and scheduling system because the 
> original "DTSTART" value has inherent usage dependencies by other 
> properties such as the "RECURRENCE-ID"."

I would think that what really matter is that the set of RECURRENCE-ID
is maintained.

> If not, is there a standard way of maintaining it?
> Also, in multiple places it is stated "The "DTSTART" property defines 
> the first instance in the recurrence set". Will that be modified?

That would clearly need to be modified.

Cheers,
Bernard
> 
> Thanks,
> Ciny
> 
>>> 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
> 

Date: Wed, 14 Nov 2007 00:04:38 -0500
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Section 4.8.7.4 Sequence Number [Re: [Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10]

Do we want to remove the text in section 4.8.7.4 Sequence Number of
RFC 2445 that specifies when the sequence number MUST be incremented
as Cyrus was "tempted to suggest"?

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Ciny,
> 
> --On September 28, 2007 11:46:53 AM -0700 Ciny Joy <[email-masked]> 
> wrote:
> 
>>     So was their a conclusion on the SEQUENCE, DTSTAMP discussion? I am
>> especially interested in knowing which fields should be used to determine
>> the latest update received in iMIP. Also, is there a proposal to
>> standardize when these fields should be modified?
> 
> I am crafting a response to all the discussion that took place on this 
> recently.
> 
> My conclusions are the following:
> 
> 1) We do need SEQUENCE to properly allow an organizer to match up 
> responses from attendees with the latest revisions sent out by the 
> organizer.
> 
> 2) Clarify that SEQUENCE is not meant to be any kind of indicator to the 
> client that a response is needed. RSVP=TRUE must be used instead.
> 
> 3) Clarify that clients must determine for themselves what constitutes a 
> significant change to an event that would cause a new accept/decline 
> prompt to be presented to a user. Clients may treat a change in SEQUENCE 
> number as always causing a prompt, but should not rely solely on a 
> change of SEQUENCE number.
> 
> 4) Clarify under what circumstances SEQUENCE should change. There is 
> currently some text on that in 2445bis, but I am tempted to suggest that 
> really belongs in 2446bis in a single section dealing with SEQUENCE 
> issues. The text here would list some properties for which changes MUST 
> result in a sequence change, and others that MAY result in a change 
> depending on the exact nature of the property change. I don't think we 
> can go further than that.
> 
> I am working on putting together some text on this so that we can seek 
> consensus on these points.
> 

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request
Date: Sat, 10 Nov 2007 08:54:55 -0500

DURATION is used in VFREEBUSY requests in the sense of "search for a
half-hour block of free time", at least according to my interpretation of
this paragraph in 3.6.4 of draft-ietf-calsify-rfc2445bis-07.txt

"When present in a "VFREEBUSY" calendar component, the "DTSTART"
      and "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
      properties.  In a free time request, these properties can be used
      in combination with the "DURATION" property to represent a request
      for a duration of free time within a specified window of time." 

Since this is probably a fairly common use case when scheduling meetings,
the only choice that makes sense, in my opinion, is (b) .

To eliminate perceived vagueness, in the second sentence of the paragraph
from 3.6.4 we could change the wording to read:

"In a free tine request, the DTSTART, DTEND, and DURATION properties can be
used to represent a request to find a period of free time, of length
DURATION, within the period of time bounded inclusively by DTSTART and
DTEND."

It might also help to have one of the examples show that kind of request.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Aki Niemi
Sent: Thursday, November 08, 2007 6:25 AM
To: ext Cyrus Daboo
Cc: Calsify WG
Subject: Re: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request

[as chair]

Folks,

We need to resolve this issue, which to my knowledge is still pending.
Option a) below would require a change in rfc2445bis, which is almost done
now, so your input is needed *now*.

Cheers
Aki

ma, 2006-11-06 kello 07:25 -0800, ext Cyrus Daboo kirjoitti:
> Hi Bernard,
> 
> --On November 5, 2006 5:36:05 PM -0500 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
> >  > In a "VFREEBUSY" calendar component the property may be  > used 
> > to specify the interval of free time being requested.
> >
> > Yet, section 3.3.2 REQUEST of RFC 2446 (iTIP) specifies that the 
> > DURATION property is not allowed in a VFREEBUSY request.
> >
> > I see three options:
> >
> > a) Remove statement from iCalendar to be in sync with iTIP;
> >
> > b) Change iTIP to allow the DURATION property in a VFREEBUSY
> >     request and define the semantic as specified in iCalendar.
> >
> > c) Status quo.
> 
> We should rule out (c) as it represents an inconsistency between the 
> two specs. Note that 2445 does not clearly define what it means to 
> have DURATION present. e.g. is it allowed for the responder to only 
> return free times slots that are equal to or larger than the DURATION, 
> or should they still return the full list? If we can clearly specify 
> the behavior then I think (b) is reasonable, otherwise we have to do (a).
> 

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Subject: Next week's jabber chat. (was: Re: [Ietf-calsify] Calsify WG jabber chat)
From: Aki Niemi <[email-masked]>
To: [email-masked]
Organization: Nokia-TP-MSW/Helsinki
Date: Thu, 08 Nov 2007 14:12:44 +0200

Note that next week's jabber chat has been canceled. We will chat again
on Nov 21st, focusing on preparations for IETF70.

Cheers,
Aki

to, 2007-11-08 kello 13:32 +0200, ext Aki Niemi kirjoitti:
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

From: Aki Niemi <[email-masked]>
To: [email-masked], Eliot Lear <[email-masked]>
Organization: Nokia-TP-MSW/Helsinki
Date: Thu, 08 Nov 2007 13:32:12 +0200
Subject: [Ietf-calsify] Calsify WG jabber chat

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Tzfile/Europe/Helsinki
X-LIC-LOCATION:Europe/Helsinki
BEGIN:STANDARD
TZNAME:EET
DTSTART:19701026T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-2SU;BYMONTH=10
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:EEST
DTSTART:19700330T040000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:20071023T072226Z-6691-1000-1-1@scotty
DTSTAMP:20071108T113212Z
DTSTART;TZID=/softwarestudio.org/Tzfile/Europe/Helsinki:20071024T163000
DTEND;TZID=/softwarestudio.org/Tzfile/Europe/Helsinki:20071024T173000
TRANSP:OPAQUE
SEQUENCE:3
SUMMARY:Calsify WG jabber chat
LOCATION:xmpp:[email-masked]
CLASS:PUBLIC
ORGANIZER;CN=Aki Niemi:MAILTO:[email-masked]
X-MICROSOFT-CDO-REPLYTIME:20071031T150125Z
CREATED:20071031T150125
LAST-MODIFIED:20071031T150125
RECURRENCE-ID;TZID=/softwarestudio.org/Tzfile/Europe/Helsinki:
 20071024T163000
DESCRIPTION:Weekly jabber chat for the Calsify WG. Template agenda: going 
 through and closing issues on the WG issue tracker:\n\nhttp:
 //www.ofcourseimright.com/cgi-bin/roundup/calsify\n
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=ACCEPTED;RSVP=TRUE;CN=Aki 
 Niemi;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;
 RSVP=TRUE;LANGUAGE=en:MAILTO:[email-masked]
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=CHAIR;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;
 CN=Eliot Lear;LANGUAGE=en:MAILTO:[email-masked]
EXDATE;VALUE=DATE:20071205
EXDATE;VALUE=DATE:20071114
RRULE:FREQ=WEEKLY;UNTIL=20071231T143000Z;INTERVAL=1;BYDAY=WE
END:VEVENT
END:VCALENDAR

Subject: Re: [Ietf-calsify] Section 4.8.2.5 Duration: VFREEBUSY request
From: Aki Niemi <[email-masked]>
To: ext Cyrus Daboo <[email-masked]>
Organization: Nokia-TP-MSW/Helsinki
Date: Thu, 08 Nov 2007 13:25:21 +0200
Cc: Calsify WG <[email-masked]>

[as chair]

Folks,

We need to resolve this issue, which to my knowledge is still pending.
Option a) below would require a change in rfc2445bis, which is almost
done now, so your input is needed *now*.

Cheers
Aki

ma, 2006-11-06 kello 07:25 -0800, ext Cyrus Daboo kirjoitti:
> Hi Bernard,
> 
> --On November 5, 2006 5:36:05 PM -0500 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
> >  > In a "VFREEBUSY" calendar component the property may be
> >  > used to specify the interval of free time being requested.
> >
> > Yet, section 3.3.2 REQUEST of RFC 2446 (iTIP) specifies that
> > the DURATION property is not allowed in a VFREEBUSY request.
> >
> > I see three options:
> >
> > a) Remove statement from iCalendar to be in sync with iTIP;
> >
> > b) Change iTIP to allow the DURATION property in a VFREEBUSY
> >     request and define the semantic as specified in iCalendar.
> >
> > c) Status quo.
> 
> We should rule out (c) as it represents an inconsistency between the two 
> specs. Note that 2445 does not clearly define what it means to have 
> DURATION present. e.g. is it allowed for the responder to only return free 
> times slots that are equal to or larger than the DURATION, or should they 
> still return the full list? If we can clearly specify the behavior then I 
> think (b) is reasonable, otherwise we have to do (a).
> 

From: Aki Niemi <[email-masked]>
To: ietf-calsify <[email-masked]>
Organization: Nokia-TP-MSW/Helsinki
Date: Wed, 07 Nov 2007 15:20:07 +0200
Subject: [Ietf-calsify] Reminder: scheduled weekly jabber chat starting in 10 minutes

From: Aki Niemi <[email-masked]>
To: ietf-calsify <[email-masked]>
Organization: Nokia-TP-MSW/Helsinki
Date: Wed, 07 Nov 2007 15:26:05 +0200
Subject: [Ietf-calsify] Correction: in *1 hour* and 5 minutes. (was: Re: Reminder: scheduled weekly jabber chat starting in 10 minutes)

(Sigh) :)

Ironport-Content-Filter: send-to-smtp
Date: Wed, 07 Nov 2007 18:00:08 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: ietf-calsify <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed

Eliot Lear wrote:
>> 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.
>>     
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

Date: Tue, 06 Nov 2007 14:14:56 -0800
From: Ciny Joy <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Sender: [email-masked]
To: [email-masked]

>
>>
>>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. 
>>
How do you define "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.
>>    
>>
So is original DTSTART lost completely? Doesn't this go against the 
statement, "However, in such cases the original "DTSTART" date MUST 
still be maintained by the calendaring and scheduling system because the 
original "DTSTART" value has inherent usage dependencies by other 
properties such as the "RECURRENCE-ID"."
If not, is there a standard way of maintaining it?
Also, in multiple places it is stated "The "DTSTART" property defines 
the first instance in the recurrence set". Will that be modified?

Thanks,
Ciny

>>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
>>    
>>

Date: Tue, 06 Nov 2007 10:02:40 +0100
From: Eliot Lear <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed
Cc: "[email-masked]" <[email-masked]>

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
>