Subject: [Ietf-calsify] rfc2445bis: minor issue in section 3.2.3

From: alexey.melnikov at isode.com (Alexey Melnikov)
Date: Mon Oct 30 12:18:32 2006

>3.2.3.  Calendar User Type
 [...]
 >   Example:
 >
 >        ATTENDEE;CUTYPE=GROUP:MAILTO:[email-masked]

Should imc.org be replaced with example.org here?

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Tue Oct 31 12:35:25 2006

I already fixed this one as well as "timezones.r.us.net"
in my upcoming draft -04 version.

Thanks,
Bernard

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

Date: Tue, 31 Oct 2006 12:34:47 -0800
From: Bernard Desruisseaux <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] rfc2445bis: minor issue in section 3.2.3
Cc: "[email-masked]" <[email-masked]>

I already fixed this one as well as "timezones.r.us.net"
in my upcoming draft -04 version.

Thanks,
Bernard

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

Date: Mon, 30 Oct 2006 22:35:17 +0100
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] no jabber or author meetings tomorrow - see you all monday

... and safe travels to those who are going to San Diego...

Eliot

Date: Mon, 30 Oct 2006 20:18:14 +0000
From: Alexey Melnikov <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] rfc2445bis: minor issue in section 3.2.3

 [...]

Date: Mon, 30 Oct 2006 20:16:25 +0000
From: Alexey Melnikov <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] rfc2445bis: ABNF in section 3.1

 >3.1.  Content Lines
 [...]

 >      CR = %x0D
 >      ; carriage return
 >
 >      LF = %x0A
 >      ; line feed
 >
 >      CRLF       = CR LF
 >      ; Internet standard newline

These 3 rules are already defined in RFC 4234, no need to repeat them in 
this document.

 >      CTL        = %x00-08 / %x0A-1F / %x7F
 >        ; Controls

Oops, RFC 4234 defines this rule as:

      CTL        =  %x00-1F / %x7F
        ; controls

i.e. it includes HTAB!

I suggest that iCalendar renamed CTL to ICAL-CTL, or similar.

 >      ALPHA      = %x41-5A / %x61-7A   ; A-Z / a-z
 >
 >      DIGIT      = %x30-39
 >        ; 0-9
 >
 >      DQUOTE     = %x22
 >        ; Quotation Mark
 >
 >      WSP        = SPACE / HTAB
 >
 >      SPACE      = %x20
 >
 >      HTAB       = %x09

These rules are already defined in RFC 4234, no need to repeat them.
But note that the "SPACE" rule was renamed to "SP" in RFC 4234. The 
SPACE is only used in section 3.1 as far as I can see.

Date: Mon, 30 Oct 2006 20:13:38 +0000
From: Alexey Melnikov <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] rfc2445bis: section 2.3. International Considerations

 >2.3.  International Considerations
 >
 >   In the rest of this document, descriptions of characters are of the
 >   form "character name (codepoint)", where "codepoint" is from the US-
 >   ASCII character set.  The "character name" is the authoritative
 >   description; (codepoint) is a reference to that character in US-ASCII
 >   or US-ASCII compatible sets (for example the ISO-8859-x family,
 >   UTF-8, ISO-2022-xx, KOI8-R).  If a non-US-ASCII compatible character
 >   set is used, appropriate code-point from that character set MUST be
 >   chosen instead.  Use of non-US-ASCII-compatible character sets is NOT
 >   recommended.

My suggestion is to drop discussion of US-ASCII compatible sets, 
considering that the updated specification would only allow for US-ASCII 
& UTF-8. The rest of the text should be moved to the section 2.

Suggested replacement text (to be moved to section 2):

 >   In the rest of this document, descriptions of characters are of the
 >   form "character name (codepoint)", where "codepoint" is from the US-
 >   ASCII character set.  The "character name" is the authoritative
 >   description; (codepoint) is a reference to that character in US-ASCII
 >   character set.

I also think that US-ASCII above can be replaced with "Unicode" here, 
but this is probably not needed.

Date: Thu, 26 Oct 2006 08:29:10 -0700
From: Sam Roberts <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule:	Duration of members of the, generated recurrence set

On Thu, Oct 26, 2006 at 02:02:33AM +0300, Aki Niemi wrote:
> Not sure if that's an appropriate place.
> 
> However, in other working groups similar types of test cases have been
> published as an informational RFC. See for example RFC 4475. I know it
> has been very useful as a primer to people attending the interop events.

The S/MIME group publishes a growing set of test-data. Its incredibly
useful. It also contains some nice perl code to rip it apart into the
test suite.

I don't think recurrence rules would have been implementable by many
without the examples.

More examples that demonstrate corner cases and illustrate the answers
to the questions raised on this group would be particularly useful.

Its a lot of work but it sure would be nice...

Sam

Date: Wed, 25 Oct 2006 17:53:42 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: Aki Niemi <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule:	Duration of members of the, generated recurrence set
Cc: [email-masked]
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------030900080700090007050102
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

As it happens, CalConnect has also published a number of test cases and 
test streams on its website and would be delighted to host a FAQ and/or 
test cases.  The more the better.

Cheers,

Dave Thewlis
-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) � +1 707 498 2238 (mobile)
http://www.calconnect.org � [email-masked] 
<mailto:[email-masked]>

Aki Niemi wrote:
> ext Oliver Block kirjoitti:
>   
>> Am Donnerstag, 19. Oktober 2006 22:11 schrieb Reinhold Kainhofer:
>>     
>>> PS: This would also be a nice example in a iCalendar test suite... 
>>>       
>> I agree.
>>
>>     
>>> Is there 
>>> any "official" place where we can install an FAQ (as suggested in my
>>> previous mails) or such a test cases repository?
>>>       
>> How about 
>>
>> http://tools.ietf.org/wg/calsify/
>>     
>
> Not sure if that's an appropriate place.
>
> However, in other working groups similar types of test cases have been
> published as an informational RFC. See for example RFC 4475. I know it
> has been very useful as a primer to people attending the interop events.
>
> If the working group thinks something like this would be useful and
> someone is willing to write the I-D, I think we could consider it.
>
> Cheers,
> Aki
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
>   

<mailto:[email-masked]>

--------------030900080700090007050102
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
As it happens, CalConnect has also published a number of test cases and
test streams on its website and would be delighted to host a FAQ and/or
test cases.&nbsp; The more the better.<br>
<br>
Cheers,<br>
<br>
Dave Thewlis<br>
-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font><br>
<br>
<br>
<br>
Aki Niemi wrote:
<blockquote cite="[email-masked]" type="cite">
  <pre wrap="">ext Oliver Block kirjoitti:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Am Donnerstag, 19. Oktober 2006 22:11 schrieb Reinhold Kainhofer:
    </pre>
    <blockquote type="cite">
      <pre wrap="">PS: This would also be a nice example in a iCalendar test suite... 
      </pre>
    </blockquote>
    <pre wrap="">I agree.

    </pre>
    <blockquote type="cite">
      <pre wrap="">Is there 
any "official" place where we can install an FAQ (as suggested in my
previous mails) or such a test cases repository?
      </pre>
    </blockquote>
    <pre wrap="">How about 

<a class="moz-txt-link-freetext" href="http://tools.ietf.org/wg/calsify/">http://tools.ietf.org/wg/calsify/</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Not sure if that's an appropriate place.

However, in other working groups similar types of test cases have been
published as an informational RFC. See for example RFC 4475. I know it
has been very useful as a primer to people attending the interop events.

If the working group thinks something like this would be useful and
someone is willing to write the I-D, I think we could consider it.

Cheers,
Aki
_______________________________________________
Ietf-calsify mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://lists.osafoundation.org/mailman/listinfo/ietf-calsify">http://lists.osafoundation.org/mailman/listinfo/ietf-calsify</a>

  </pre>
</blockquote>
<br>
<div class="moz-signature"><br>
<font size="-1"><a href="mailto:[email-masked]"></a></font></div>
</body>
</html>

--------------030900080700090007050102--

Date: Thu, 26 Oct 2006 02:02:33 +0300
From: Aki Niemi <[email-masked]>
Organization: Nokia-NRC/Helsinki
To: ext Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule:	Duration of members of the, generated recurrence set
Cc: [email-masked]

ext Oliver Block kirjoitti:
> Am Donnerstag, 19. Oktober 2006 22:11 schrieb Reinhold Kainhofer:
>> PS: This would also be a nice example in a iCalendar test suite... 
> 
> I agree.
> 
>> Is there 
>> any "official" place where we can install an FAQ (as suggested in my
>> previous mails) or such a test cases repository?
> 
> How about 
> 
> http://tools.ietf.org/wg/calsify/

Not sure if that's an appropriate place.

However, in other working groups similar types of test cases have been
published as an informational RFC. See for example RFC 4475. I know it
has been very useful as a primer to people attending the interop events.

If the working group thinks something like this would be useful and
someone is willing to write the I-D, I think we could consider it.

Cheers,
Aki

Date: Wed, 25 Oct 2006 22:32:07 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-03.txt
Cc: [email-masked]

Bernard,

On behalf of the working group I would like to thank you on your fast 
turnaround of two versions and your commitment to getting through the 
update.

Dear all,

The chairs believe that the open issues to rfc2445bis will be the 
PRIMARY topic of discussion.  I ask that you please be prepared by 
having read the draft below and having reviewed the issues list.  I will 
send an update of that list in the coming days.

Thanks for your participation.  With luck we will close this document in 
the coming weeks.

Eliot

[email-masked] wrote:
> 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		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
> 	Author(s)	: B. Desruisseaux
> 	Filename	: draft-ietf-calsify-rfc2445bis-03.txt
> 	Pages		: 159
> 	Date		: 2006-10-25
> 	
> There is a clear need to provide and deploy interoperable calendaring
>    and scheduling services for the Internet.  Current group scheduling
>    and Personal Information Management (PIM) products are being extended
>    for use across the Internet, today, in proprietary ways.  This memo
>    has been defined to provide the definition of a common format for
>    openly exchanging calendaring and scheduling information across the
>    Internet.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-03.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-rfc2445bis-03.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-rfc2445bis-03.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.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>   

To: [email-masked]
From: [email-masked]
Date: Wed, 25 Oct 2006 15:50:02 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-03.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		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-03.txt
	Pages		: 159
	Date		: 2006-10-25
	
There is a clear need to provide and deploy interoperable calendaring
   and scheduling services for the Internet.  Current group scheduling
   and Personal Information Management (PIM) products are being extended
   for use across the Internet, today, in proprietary ways.  This memo
   has been defined to provide the definition of a common format for
   openly exchanging calendaring and scheduling information across the
   Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-03.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-rfc2445bis-03.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-rfc2445bis-03.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-rfc2445bis-03.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 25 Oct 2006 10:08:16 -0700
From: "Mike Samuel" <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] Java implementation of RFC 2445 Recurrences
Reply-To: [email-masked]

http://code.google.com/p/google-rfc-2445/

This is Google Calendar's implementation of RFC 2445 repeating events,
so if anyone has any grievances about how we implement the spec,
please let me know.

cheers,
mike

Date: Tue, 24 Oct 2006 21:25:03 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] final call for issues to be fixed in rfc2445bis

<CHAIR HAT ON>

Dear All,

The chairs would like to draw your attention to the milestones, in which 
we are now overdue to make a working group last call for rfc2445bis.  
The good news is that we are making good progress on open issues.  The 
bad news is that we are not yet done.  On balance, this is acceptable 
for a time, but we now would like to bound that time.  We ask that if 
you have any open issues that you send them to the list by no later than 
the 7th of November.  After that point, we will exclusively focus on 
closing the existing set of issues, and addressing only those news 
issues that were brought about by changes to the draft that have not 
been previously considered.

Thanks for your participation,

Eliot

Date: Tue, 24 Oct 2006 16:25:04 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] no jabber today

The authors are requested to join in an author's call at 7:00pm CEDT / 
10:00am PST.

Thanks,

Eliot

Date: Tue, 24 Oct 2006 09:31:15 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] Issue 54: version number bump?

Dear all,

Should the specification version be bumped to, say, 2.1?  If we do this, it
allows us to make stronger assertions about implementations that would conform
to the new version.  So, for instance, in the case of the omnibus simplification
for RRULE and EXRULE, we could say that versions conforming to 2.1 of the
specification MUST NOT generate EXRULE or RRULEs where DTSTART is not part of
the set.

Eliot

Date: Mon, 23 Oct 2006 13:13:21 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Issue 32: Re: [Ietf-calsify] Section 4.4: "Single iCalendar object" versus         "Sequence of iCalendar objects"

Are there any objections to this change?

Without this change, statements such as the following in
section 4.2.19 "Time Zone Identifier" would remain
ambiguous:

 > An individual "VTIMEZONE" calendar component MUST be
 > specified for each unique "TZID" parameter value
 > specified in the iCalendar object.

Based on the current definition of "iCalendar object" it
would be valid to specify an iCalendar object that makes
reference to a VTIMEZONE in another iCalendar object.

Cheers,
Bernard

Alexey Melnikov wrote:
> Bernard Desruisseaux wrote:
> 
>> Section 4.4 iCalendar Object of RFC 2445 says:
>>
>> > The Calendaring and Scheduling Core Object is a collection of
>> > calendaring and scheduling information. Typically, this information
>> > will consist of a single iCalendar object. However, multiple
>> > iCalendar objects can be sequentially grouped together. The first
>> > line and last line of the iCalendar object MUST contain a pair of
>> > iCalendar object delimiter strings. The syntax for an iCalendar
>> > object is as follows:
>> >
>> >   icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
>> >                icalbody
>> >                "END" ":" "VCALENDAR" CRLF)
>>
>> I would like to modify this section to introduce the notion of an
>> "iCalendar stream" to make it explicit when we are refering to a
>> "single iCalendar object" or a "sequence of iCalendar objects".
>>
>> Proposed new text:
>>
>> > The Calendaring and Scheduling Core Object is a collection of
>> > calendaring and scheduling information. Typically, this information
>> > will consist of an iCalendar stream with a single iCalendar object.
>> > However, multiple iCalendar objects can be sequentially grouped
>> > together in an iCalendar stream. The first line and last line of
>> > the iCalendar object MUST contain a pair of iCalendar object
>> > delimiter strings. The syntax for an iCalendar stream is as follows:
>> >
>> >   icalstream = 1*icalobject
>> >
>> >   icalobject = "BEGIN" ":" "VCALENDAR" CRLF
>> >                icalbody
>> >                "END" ":" "VCALENDAR" CRLF
> 
> I like that.
> 

Date: Mon, 23 Oct 2006 10:39:12 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.1 Content Lines: NON-US-ASCII

Are there any objections to change the definition of
NON-US-ASCII as follows:

   NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
   ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC 3629].

Cheers,
Bernard

Bernard Desruisseaux wrote:
> Bernard Desruisseaux wrote:
>> In section 4.1 Content Lines of RFC 2445 it says:
>>
>>  >     NON-US-ASCII       = %x80-F8
>>  >     ; Use restricted by charset parameter
>>  >     ; on outer MIME object (UTF-8 preferred)
>>
>> Unless I'm mistaken, the characters %xF9 to %xFD are allowed in UTF-8.
> 
> It seems I was mistaken.
> 
> I had come to this quick conclusion by reading the following
> statement in RFC 2279:
> 
> - The octet values FE and FF never appear.
> 
> But RFC 3629 which obsoletes RFC 2279 specify has the following
> statement instead:
> 
> - The octet values C0, C1, F5 to FF never appear.
> 
> As such, the NON-US-ASCII rule should be:
> 
>   NON-US-ASCII       = %x80-BF / %xC2-F4
> 
> Cheers,
> Bernard
> 
>>
>> At a minimum this should be:
>>
>>  >     NON-US-ASCII       = %x80-FD
>> or
>>  >     NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
>>  >     ; UTF8-2, UTF8-3, and UTF8-4 are defined in RFC 3629.
>>
>> and if we agree to support ISO-8859-1, then it should be:
>>
>>  >     NON-US-ASCII       = %x80-FF
>>
>> 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

Date: Mon, 23 Oct 2006 15:04:54 +0200
From: Eliot Lear <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
Cc: [email-masked]

Reinhold Kainhofer wrote:
> Am Montag, 23. Oktober 2006 11:14 schrieb Mike Higginbottom:
>   
>> 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
>>     
>
> 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.
>   

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

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
Date: Mon, 23 Oct 2006 13:37:29 +0200

Am Montag, 23. Oktober 2006 11:14 schrieb Mike Higginbottom:
> 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

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/

Date: Mon, 23 Oct 2006 10:14:16 +0100
To: "Bernard Desruisseaux" <[email-masked]>, "Calsify WG" <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
From: "Mike Higginbottom" <[email-masked]>
Organization: PSCS

On Thu, 19 Oct 2006 21:00:45 +0100, Bernard Desruisseaux  
<[email-masked]> wrote:

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

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

Date: Mon, 23 Oct 2006 01:56:35 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
Cc: Calsify WG <[email-masked]>

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

Eliot Lear wrote:
> 
> 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:
>> 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
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>

Date: Fri, 20 Oct 2006 16:06:20 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] current issue list with status

This is a multi-part message in MIME format.
--------------040702060509010206070508
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Please find attached the current issue list.  Issues that are either 
resolved or have consensus have been omitted.  Enjoy those gaps.  This 
list was gotten from 
http://www.ofcourseimright.com/cgi-bin/roundup/calsify using the search 
function, and is best viewed as HTML.

Eliot

D 	Activity 	Title 	Status

22 	3 months ago 	how does someone discover the appropriate caldav 
server? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue22> 	unread
rfc2445bis
5 	2 weeks ago 	proposed changes to RRULE / EXDATE 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue5> 	chatting
8 	2 weeks ago 	Reinhold Kainhofer: Deprecate P1D or P24H? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8> 	notext
10 	2 weeks ago 	Reinhold Kainhofer: end date not inclusive 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10> 	notext
11 	1 week ago 	Reinhold Kainhofer: additional examples, VTIMEZONEs, 
RRULEs 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11> 	notext
13 	2 days ago 	Reinhold Kainhofer: confusion in DTSTART text about "if 
specified" and BY rules 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue13> 	Discuss
14 	1 week ago 	Reinhold Kainhofer: meaning of DTSTART/DTEND with 
recurrence rules 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue14> 	notext
16 	1 week ago 	when BY extends past last occurrence 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue16> 	notext
19 	3 months ago 	IANA considerations for registration of new properties 
a/o attributes 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue19> 	unread
23 	2 days ago 	Contradiction between UNTIL BNF rule and text 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23> 	Discuss
24 	2 days ago 	need to clarify number of recurrence instances generated 
by multiple RRULEs 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue24> 
in-progress
25 	2 days ago 	Is the first recurrence instance, defined by DTSTART, 
always excluded by EXRULE? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue25> 
in-progress
27 	2 days ago 	DTEND/DURATION ? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue27> 	Discuss
30 	2 weeks ago 	] Section 3.2: "charset" parameter 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue30> 	Discuss
32 	1 month ago 	Section 4.4: Single iCalendar Object versus sequence of 
iCalendar Objects 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue32> 	unread
34 	1 month ago 	3.2: method parameter and sequence of iCalendar Objects 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue34> 	unread
35 	3 weeks ago 	Section 4.2.10 language 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue35> 	chatting
42 	3 weeks ago 	Section 4.6.6 Alarm Component: Restriction over the 
value of the ACTION property 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue42> 	unread
43 	3 weeks ago 	Section 4.8.5.4 Recurrence Rule: Allowed value type of 
DTSTART and DTEND 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue43> 	unread
44 	3 weeks ago 	Section 4.8.8.1 Non-standard Properties: Parameters 
allowed on x-prop 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue44> 	unread
45 	3 weeks ago 	Sections 4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3: Bad LDAP 
URL in examples 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue45> 	unread
46 	3 weeks ago 	ABNF simplification? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue46> 	chatting
47 	3 weeks ago 	Section 4.8.6.3 Trigger: Trigger relative to DATE value 
type <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue47> 
Discuss
48 	1 week ago 	Section 4.2.13 Recurrence Identifier Range: Should we 
deprecate the RANGE parameter? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue48> 	Discuss
rfc2446bis
20 	3 months ago 	IANA considerations for registration of new properties 
a/o attributes 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue20> 	unread
rfc2447bis
17 	just now 	iMIP: authorization to work on behalf of another calendar 
user <http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue17> 
unread
18 	1 month ago 	iMIP: suggestion to use language to select an iCalendar 
from "multipart/alternative" 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue18> 	chatting
21 	3 months ago 	do we need a new mime type for this update, in order 
for backward compat? 
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue21> 	unread

--------------040702060509010206070508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear all,<br>
<br>
Please find attached the current issue list.  Issues that are either
resolved or have consensus have been omitted.  Enjoy those gaps.  This
list was gotten from
<a class="moz-txt-link-freetext" href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify">http://www.ofcourseimright.com/cgi-bin/roundup/calsify</a> using the search
function, and is best viewed as HTML.<br>
<br>
Eliot<br>
<br>
<br>
<table class="list">
  <tbody>
    <tr>
      <th>D</th>
      <th>Activity</th>
      <th>Title</th>
      <th>Status</th>
    </tr>
    <tr>
      <th class="group" colspan="4"><br>
      </th>
    </tr>
    <tr>
      <td>22</td>
      <td class="date">3 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue22">how
does someone discover the appropriate caldav server?</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <th class="group" colspan="4">rfc2445bis</th>
    </tr>
    <tr>
      <td>5</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue5">proposed
changes to RRULE / EXDATE</a> </td>
      <td>chatting</td>
    </tr>
    <tr>
      <td>8</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue8">Reinhold
Kainhofer: Deprecate P1D or P24H?</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>10</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue10">Reinhold
Kainhofer: end date not inclusive</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>11</td>
      <td class="date">1 week ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue11">Reinhold
Kainhofer: additional examples, VTIMEZONEs, RRULEs</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>13</td>
      <td class="date">2 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue13">Reinhold
Kainhofer: confusion in DTSTART text about "if specified" and BY rules</a>
      </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>14</td>
      <td class="date">1 week ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue14">Reinhold
Kainhofer: meaning of DTSTART/DTEND with recurrence rules</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>16</td>
      <td class="date">1 week ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue16">when
BY extends past last occurrence</a> </td>
      <td>notext</td>
    </tr>
    <tr>
      <td>19</td>
      <td class="date">3 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue19">IANA
considerations for registration of new properties a/o attributes</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>23</td>
      <td class="date">2 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue23">Contradiction
between UNTIL BNF rule and text</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>24</td>
      <td class="date">2 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue24">need
to clarify number of recurrence instances generated by multiple RRULEs</a>
      </td>
      <td>in-progress</td>
    </tr>
    <tr>
      <td>25</td>
      <td class="date">2 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue25">Is
the first recurrence instance, defined by DTSTART, always excluded by
EXRULE?</a> </td>
      <td>in-progress</td>
    </tr>
    <tr>
      <td>27</td>
      <td class="date">2 days ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue27">DTEND/DURATION
?</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>30</td>
      <td class="date">2 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue30">]
Section 3.2: "charset" parameter</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>32</td>
      <td class="date">1 month ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue32">Section
4.4: Single iCalendar Object versus sequence of iCalendar Objects</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>34</td>
      <td class="date">1 month ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue34">3.2:
method parameter and sequence of iCalendar Objects</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>35</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue35">Section
4.2.10 language</a> </td>
      <td>chatting</td>
    </tr>
    <tr>
      <td>42</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue42">Section
4.6.6 Alarm Component: Restriction over the value of the ACTION property</a>
      </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>43</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue43">Section
4.8.5.4 Recurrence Rule: Allowed value type of DTSTART and DTEND</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>44</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue44">Section
4.8.8.1 Non-standard Properties: Parameters allowed on x-prop</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>45</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue45">Sections
4.2.6, 4.8.4.1, 4.8.4.2, and 4.8.4.3: Bad LDAP URL in examples</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>46</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue46">ABNF
simplification?</a> </td>
      <td>chatting</td>
    </tr>
    <tr>
      <td>47</td>
      <td class="date">3 weeks ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue47">Section
4.8.6.3 Trigger: Trigger relative to DATE value type</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <td>48</td>
      <td class="date">1 week ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue48">Section
4.2.13 Recurrence Identifier Range: Should we deprecate the RANGE
parameter?</a> </td>
      <td>Discuss</td>
    </tr>
    <tr>
      <th class="group" colspan="4">rfc2446bis</th>
    </tr>
    <tr>
      <td>20</td>
      <td class="date">3 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue20">IANA
considerations for registration of new properties a/o attributes</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <th class="group" colspan="4">rfc2447bis</th>
    </tr>
    <tr>
      <td>17</td>
      <td class="date">just now</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue17">iMIP:
authorization to work on behalf of another calendar user</a> </td>
      <td>unread</td>
    </tr>
    <tr>
      <td>18</td>
      <td class="date">1 month ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue18">iMIP:
suggestion to use language to select an iCalendar from
"multipart/alternative"</a> </td>
      <td>chatting</td>
    </tr>
    <tr>
      <td>21</td>
      <td class="date">3 months ago</td>
      <td> <a
 href="http://www.ofcourseimright.com/cgi-bin/roundup/calsify/issue21">do
we need a new mime type for this update, in order for backward compat?</a>
      </td>
      <td>unread</td>
    </tr>
  </tbody>
</table>
</body>
</html>

--------------040702060509010206070508--

Date: Fri, 20 Oct 2006 15:38:41 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
Cc: Calsify WG <[email-masked]>

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:
> 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
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

Date: Fri, 20 Oct 2006 09:34:02 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

Hi Bernard,

--On October 19, 2006 4:00:45 PM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

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

+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

Date: Fri, 20 Oct 2006 10:16:45 +0200
From: Eliot Lear <[email-masked]>
To: Andrew N Dowden <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
Cc: [email-masked]

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

Date: Fri, 20 Oct 2006 10:44:06 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

Bernard Desruisseaux wrote:
> Issue 24: Need to clarify number of recurrence instances
>           generated when multiple recurrence rules are
>           specified.
>   - 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
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

Date: Fri, 20 Oct 2006 10:43:21 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

Bernard Desruisseaux wrote:
> Issue 13: Is the first instance defined by DTSTART always
>           considered as part of the COUNT of a recurrence
>           rule?
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
>     the recurrence rule;
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.
>   - 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. 
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
  Dowden Software Associates
  P O Box 31 132, Lower Hutt 5040, NEW ZEALAND

Date: Fri, 20 Oct 2006 10:43:05 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

Bernard Desruisseaux wrote:
> Issue 25: Is the first instance defined by DTSTART always
>           excluded by EXRULE? 
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: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the, generated recurrence set
Date: Thu, 19 Oct 2006 23:01:48 +0200

Am Donnerstag, 19. Oktober 2006 19:51 schrieb Bernard Desruisseaux:
> I believe we need to clarify what is meant by "duration" here.
>
> Example 1:
>
>    In my opinion, the duration of the recurrence instance on March 12th,
>    2006 should be 1 day (24 hours).

I agree.

> Example 2:
>
>    I believe the duration of the recurrence instance on March 12th,
>    2006 should be the "computed duration of the first instance",
>    that is, 23 hours.

hm...

Ragards,

Oliver

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the, generated recurrence set
Date: Thu, 19 Oct 2006 22:59:23 +0200

Am Donnerstag, 19. Oktober 2006 22:11 schrieb Reinhold Kainhofer:
> PS: This would also be a nice example in a iCalendar test suite... 

I agree.

> Is there 
> any "official" place where we can install an FAQ (as suggested in my
> previous mails) or such a test cases repository?

How about 

http://tools.ietf.org/wg/calsify/

Regards,

Oliver

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the, generated recurrence set
Date: Thu, 19 Oct 2006 22:11:23 +0200

Am Donnerstag, 19. Oktober 2006 19:51 schrieb Bernard Desruisseaux:
> In section 4.8.5.4 Recurrence Rule it says:
>  > Any duration associated with the iCalendar object applies to all
>  > members of the generated recurrence set.
>
> I believe we need to clarify what is meant by "duration" here.
>
> Example 1:
>
>    DTSTART;TZID=America/Montreal:20070311T000000
>    DURATION:P1D
>    RRULE:FREQ=DAILY;COUNT=2
[...]
>    In my opinion, the duration of the recurrence instance on March 12th,
>    2006 should be 1 day (24 hours).

I would also tend to say that if a duration is explicitly given, this duration 
applies to all recurrences. I would also tend to agree with you on your 
second example, where the duration is implicitly given as the difference 
between DTSTART and DTEND.

> All that being said:
>
>    - I doubt that all (most?) iCalendar application will interpret
>      P1D as 23 hours or 25 hours when a time zone shift occurs.

How many applications really take into account that extra or missing hour in 
the GUI?

Cheers,
Reinhold

PS: This would also be a nice example in a iCalendar test suite... Is there 
any "official" place where we can install an FAQ (as suggested in my previous 
mails) or such a test cases repository?
- -- 
- ------------------------------------------------------------------
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/

Date: Thu, 19 Oct 2006 16:00:45 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

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

Date: Thu, 19 Oct 2006 13:51:12 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Issue 27: Section 4.8.5.4 Recurrence Rule: Duration of members of the,generated recurrence set

In section 4.8.5.4 Recurrence Rule it says:

 > Any duration associated with the iCalendar object applies to all
 > members of the generated recurrence set.

I believe we need to clarify what is meant by "duration" here.

Example 1:

   DTSTART;TZID=America/Montreal:20070311T000000
   DURATION:P1D
   RRULE:FREQ=DAILY;COUNT=2

   The first instance start at midnight on March 11th, 2007 and has
   a duration of 1 day. Given that on that day there is a shift from
   standard time to daylight saving time, this instance will actually
   last 23 hours.

   Should the duration of the recurrence instance that will occur on
   March 12th, 2007 be the "computed duration of the first instance",
   that is, 23 hours, or the "specified duration of the first instance",
   that is, 1 day?

   In my opinion, the duration of the recurrence instance on March 12th,
   2006 should be 1 day (24 hours).

Example 2:

   DTSTART;TZID=America/Montreal:20070311T000000
   DTEND;TZID=America/Montreal:20070312T000000
   RRULE:FREQ=DAILY;COUNT=2

   The first instance start at midnight on March 11th, 2007 and is
   specified to end at midnight on March 12th, 2007. Given that on
   that day there is shift from standard time to daylight saving time,
   this instance will actually last 23 hours.

   I believe the duration of the recurrence instance on March 12th,
   2006 should be the "computed duration of the first instance",
   that is, 23 hours.

All that being said:

   - I doubt that all (most?) iCalendar application will interpret
     P1D as 23 hours or 25 hours when a time zone shift occurs.

   - There are known iCalendar applications that don't even support
     the DURATION property today!

Cheers,
Bernard

Date: Tue, 17 Oct 2006 16:58:26 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder, calsify jabber starts at 17:00 CEST / 8:00 PDT

see you there!

Date: Mon, 16 Oct 2006 11:11:06 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] draft agenda for our meeting

FYI, the final IETF agenda is out.  Our slot is Monday afternoon:

1300-1500 Afternoon Session I
APP   calsify   Calendaring and Scheduling Standards Simplification WG
GEN   edu       Education
INT   l2vpn     Layer 2 Virtual Private Networks WG
INT   mip6      Mobility for IPv6 WG
RAI   enum      Telephone Number Mapping WG
SEC   emu       EAP Method Update WG
TSV   dccp      Datagram Congestion Control Protocol WG

Seems like we have the following:

 - Agenda Bash (chairs)
 - 2445bis address any remaining issues (chairs, Bernard)
    - simplification of RRULEs
 - 2446bis open issues (Cyrus)
 - 2447bis open issues (Alexey)

Comments / requests?

Eliot

Date: Fri, 13 Oct 2006 20:41:02 -0400
From: Cyrus Daboo <[email-masked]>
To: Jeffrey Harris <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] RRULE's and COUNT

Hi Jeffrey,

--On October 13, 2006 1:12:37 PM -0700 Jeffrey Harris 
<[email-masked]> wrote:

> Ouch!  Teach me to make statements about my own code without testing a
> recent build.  There was a point in time when it did (what I considered
> to be) the right thing, but I apparently neglected to write a unit test.
>  I wonder what all that count massaging code is doing right now...  Time
> to go write a few more unit tests.
>
> Still, modulo regressions, Chandler *ought* to do a) from Bernard's list.

The Apple Calendar server which uses vobject does (a), so since Chandler 
also uses that (last I heard) I would expect the same too.

> I think rfc2445 contains a variety of confusing and conflicting
> statements.  I interpreted the "if specified" to be a matching statement
> with the VEVENT ABNF's implication that DTSTART isn't required, but I
> can certainly see why others might interpret it differently.

Well as we know the ABNF is wrong as the description for DTSTART says it is 
required! Or perhaps the description is wrong and the ABNF is right.

-- 
Cyrus Daboo

Date: Fri, 13 Oct 2006 13:12:37 -0700
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULE's and COUNT

Hi Reinhold,

> Well, I tried it out, and it seems that Chandler 0.6 does NOT include DTSTART 
> in its COUNT if DTSTART does not match the rule: Importing an event with
>   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
>   DTSTART:20061009T070000Z
> (where the DTSTART is a monday and thus does not match the rule) results in 
> the event appearing on Oct 9, Oct 10, Oct 12 and Oct 17.
> 
> Chandler 0.7.1 simply ignores the DTSTART if it doesn't match the rule:
>   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
>   DTSTART:20061009T070000Z
> appears only on Tue Oct 10, Thu Oct 12 and Tue Oct 17 (but not on Oct 9).

Ouch!  Teach me to make statements about my own code without testing a
recent build.  There was a point in time when it did (what I considered
to be) the right thing, but I apparently neglected to write a unit test.
 I wonder what all that count massaging code is doing right now...  Time
to go write a few more unit tests.

Still, modulo regressions, Chandler *ought* to do a) from Bernard's list.

I think rfc2445 contains a variety of confusing and conflicting
statements.  I interpreted the "if specified" to be a matching statement
with the VEVENT ABNF's implication that DTSTART isn't required, but I
can certainly see why others might interpret it differently.

Sincerely,
Jeffrey

Date: Fri, 13 Oct 2006 11:12:35 -0700
From: Ciny Joy <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [Ietf-calsify] Re: Survey of RRULE/COUNT behavior

Hi,
    The Sun calendar server gives the result as specified in option "a" 
by default. That is

a)     Monday,  October 16, 2006
       Tuesday, October 17, 2006
       Tuesday, October 24, 2006

But we also support a special flag that clients can use to exclude dtstart if it does not comply with the rrule. Then the result is as in "c".
    c) Tuesday, October 17, 2006
       Tuesday, October 24, 2006
       Tuesday, October 31, 2006

Ciny

[email-masked] wrote:

>
>------------------------------
>
>Message: 2
>Date: Fri, 13 Oct 2006 11:01:49 -0400
>From: Bernard Desruisseaux <[email-masked]>
>Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify]
>	RRULE's	and	COUNT
>To: [email-masked]
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>I propose a different survey.
>
>1- Import the attached iCalendar object.
>
>2- Report the dates of the recurrence instances generated by
>    your calendar application:
>
>    a) Monday,  October 16, 2006
>       Tuesday, October 17, 2006
>       Tuesday, October 24, 2006
>
>    b) Monday,  October 16, 2006
>       Tuesday, October 17, 2006
>       Tuesday, October 24, 2006
>       Tuesday, October 31, 2006
>
>    c) Tuesday, October 17, 2006
>       Tuesday, October 24, 2006
>       Tuesday, October 31, 2006
>
>Thanks,
>Bernard
>
>  
>

Date: Fri, 13 Oct 2006 12:54:53 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's and COUNT
Cc: [email-masked]

You need to add "METHOD:PUBLISH" in the iCalendar object to
import it with Outlook.

You are correct that Outlook generates option C.

Cheers,
Bernard

Reinhold Kainhofer wrote:
> Am Freitag, 13. Oktober 2006 17:01 schrieb Bernard Desruisseaux:
>> 1- Import the attached iCalendar object.
> 
> Outlook gives an error message... 
> If anything, I think Outlook generates option C (if you try to create this 
> object in the GUI, the DTSTART will not be used and the dialog shows that the 
> recurrence is effectie Oct 17-Oct 31).
> 
> Cheers,
> Reinhold

Date: Fri, 13 Oct 2006 11:39:21 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, [email-masked]
Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's	and	COUNT

Hi Bernard,

--On October 13, 2006 11:01:49 AM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> I propose a different survey.
>
> 1- Import the attached iCalendar object.
>
> 2- Report the dates of the recurrence instances generated by
>     your calendar application:
>
>     a) Monday,  October 16, 2006
>        Tuesday, October 17, 2006
>        Tuesday, October 24, 2006
>
>     b) Monday,  October 16, 2006
>        Tuesday, October 17, 2006
>        Tuesday, October 24, 2006
>        Tuesday, October 31, 2006
>
>     c) Tuesday, October 17, 2006
>        Tuesday, October 24, 2006
>        Tuesday, October 31, 2006

Apple iCal: a

Mulberry:   a

Apple Calendar Server (internal recurrence indexer) : a
(uses vobject python library)

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's =?utf-8?q?and=09COUNT?=
Date: Fri, 13 Oct 2006 17:29:38 +0200

Am Freitag, 13. Oktober 2006 17:01 schrieb Bernard Desruisseaux:
> 1- Import the attached iCalendar object.

Outlook gives an error message... 
If anything, I think Outlook generates option C (if you try to create this 
object in the GUI, the DTSTART will not be used and the dialog shows that the 
recurrence is effectie Oct 17-Oct 31).

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/

Date: Fri, 13 Oct 2006 11:22:37 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about	"if	specified" and BY rules

Hi Reinhold,

--On October 13, 2006 5:04:42 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

>> I believe this change would 'break' many existing implementations.
>> Certainly it seems the majority of currently implementations always
>> consider DTSTART as the first instance in COUNT, and I think the spec
>> should be clarified to 'bless' that view.
>
> Really? What do you understand as the majority?

We'll find out from the survey...

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's =?utf-8?q?and=09COUNT?=
Date: Fri, 13 Oct 2006 17:17:48 +0200

Am Freitag, 13. Oktober 2006 17:01 schrieb Bernard Desruisseaux:
> 2- Report the dates of the recurrence instances generated by
> =C2=A0 =C2=A0 your calendar application:
>     a) Monday,  October 16, 2006
>        Tuesday, October 17, 2006
>        Tuesday, October 24, 2006
>
>     b) Monday,  October 16, 2006
>        Tuesday, October 17, 2006
>        Tuesday, October 24, 2006
>        Tuesday, October 31, 2006
>
>     c) Tuesday, October 17, 2006
>        Tuesday, October 24, 2006
>        Tuesday, October 31, 2006

=2D) KOrganizer 3.5.5 (all versions behave the same): B
=2D) Evolution 2.6.3: B
=2D) Mozilla Sunbird 0.3: C
=2D) Google Calendar: B
=2D) Chandler 0.6.1: B
=2D) Chandler 0.7.1 (pre-release alpha): C
=2D) (php|e)Groupware: Don't support these events

Cheers,
Reinhold
=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

Date: Fri, 13 Oct 2006 11:19:09 -0400
From: Mike Douglass <[email-masked]>
Cc: [email-masked]
Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's and	COUNT

For bedework I get option c

Bernard Desruisseaux wrote:
> I propose a different survey.
>
> 1- Import the attached iCalendar object.
>
> 2- Report the dates of the recurrence instances generated by
>    your calendar application:
>
>    a) Monday,  October 16, 2006
>       Tuesday, October 17, 2006
>       Tuesday, October 24, 2006
>
>    b) Monday,  October 16, 2006
>       Tuesday, October 17, 2006
>       Tuesday, October 24, 2006
>       Tuesday, October 31, 2006
>
>    c) Tuesday, October 17, 2006
>       Tuesday, October 24, 2006
>       Tuesday, October 31, 2006
>
> Thanks,
> Bernard
>
> Cyrus Daboo wrote:
>> Hi Reinhold,
>>
>> --On October 13, 2006 10:12:13 AM +0200 Reinhold Kainhofer 
>> <[email-masked]> wrote:
>>
>>>> We certainly have variation in implementations of this, I'd lean 
>>>> towards
>>>> following what 2445 said originally, rather than changing the 
>>>> meaning of
>>>> COUNT.
>>>
>>> Hehe, that's the problem: We have an argument about what 2445 
>>> originally
>>> said!  Apparently, I have a different opinion about that than you.
>>
>> At this point maybe we need to get a count of which way 
>> implementations have gone in dealing with this before making a final 
>> decision. However, I do believe we must pick one way of doing it and 
>> make the new spec clear on that.
>>
>> So I propose a survey:
>>
>> 1. Does your implementation treat the DTSTART instance as the first 
>> instance in a RRULE set, even if it does not match the RRULE itself?
>>
>> yes/no
>>
>> 2. What is the name/version of that implementation?
>>
>> ------
>>
>> Assuming the above questions will solicit the right information we 
>> need, perhaps the chairs could formally ask this and tabulate the 
>> result?
>>
> ------------------------------------------------------------------------
>
> BEGIN:VCALENDAR
> PRODID:-//Bernard//vi//EN
> VERSION:2.0
> BEGIN:VTIMEZONE
> TZID:Eastern Time (US & Canada)
> BEGIN:STANDARD
> DTSTART:20051030T020000
> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
> TZOFFSETFROM:-0400
> TZOFFSETTO:-0500
> TZNAME:Standard Time
> END:STANDARD
> BEGIN:DAYLIGHT
> DTSTART:20060402T020000
> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
> TZOFFSETFROM:-0500
> TZOFFSETTO:-0400
> TZNAME:Daylight Savings Time
> END:DAYLIGHT
> END:VTIMEZONE
> BEGIN:VEVENT
> ORGANIZER:MAILTO:[email-masked]
> DTSTART;TZID="Eastern Time (US & Canada)":20061016T173000
> DTEND;TZID="Eastern Time (US & Canada)":20061016T180000
> RRULE:FREQ=WEEKLY;COUNT=3;INTERVAL=1;BYDAY=TU;WKST=SU
> TRANSP:OPAQUE
> SEQUENCE:0
> UID:[email-masked]
> DTSTAMP:20061013T142548Z
> SUMMARY:Test
> PRIORITY:5
> CLASS:PUBLIC
> END:VEVENT
> END:VCALENDAR
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>   

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "=?iso-8859-1?q?if=09specified?=" and BY rules
Date: Fri, 13 Oct 2006 17:04:42 +0200

Am Freitag, 13. Oktober 2006 15:40 schrieb Cyrus Daboo:
> I believe this change would 'break' many existing implementations.
> Certainly it seems the majority of currently implementations always
> consider DTSTART as the first instance in COUNT, and I think the spec
> should be clarified to 'bless' that view.

Really? What do you understand as the majority?

So far I have:

DTSTART always first instance in COUNT, even if it does not match the rule:
  -) Apple iCal (at least according to Jeffrey)

DTSTART only first instance in COUNT if it matches the rule:
  -) Google Calendar (Online version as of Oct 12, 2006; checked by RK)
  -) KOrganizer and KAlarm, (all versions; implemented by RK)
  -) Evolution (version 2.6.3; checked by RK)
  -) Mozilla Calendar/Sunbird (version 0.3; checked by RK)
  -) Chandler (version 0.6; checked by RK)

Other behavior (e.g. don't allow such rules at all, give an error, etc.):
  -) Outlook
  -) (e|php)Groupware
  -) Chandler 0.7alpha3 (Ignores the DTSTART altogether if DTSTART does not
      match RRULE!!! DTSTART also not included in COUNT; checked by RK)

I put my results on a wiki page:
http://wiki.kde.org/?page=RFC2445+RRULEs

A sample .ics file to test various implementations is also there.

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/

Date: Fri, 13 Oct 2006 11:01:49 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's and	COUNT

This is a multi-part message in MIME format.
--------------020307000406010005080205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I propose a different survey.

1- Import the attached iCalendar object.

2- Report the dates of the recurrence instances generated by
    your calendar application:

    a) Monday,  October 16, 2006
       Tuesday, October 17, 2006
       Tuesday, October 24, 2006

    b) Monday,  October 16, 2006
       Tuesday, October 17, 2006
       Tuesday, October 24, 2006
       Tuesday, October 31, 2006

    c) Tuesday, October 17, 2006
       Tuesday, October 24, 2006
       Tuesday, October 31, 2006

Thanks,
Bernard

Cyrus Daboo wrote:
> Hi Reinhold,
> 
> --On October 13, 2006 10:12:13 AM +0200 Reinhold Kainhofer 
> <[email-masked]> wrote:
> 
>>> We certainly have variation in implementations of this, I'd lean towards
>>> following what 2445 said originally, rather than changing the meaning of
>>> COUNT.
>>
>> Hehe, that's the problem: We have an argument about what 2445 originally
>> said!  Apparently, I have a different opinion about that than you.
> 
> At this point maybe we need to get a count of which way implementations 
> have gone in dealing with this before making a final decision. However, 
> I do believe we must pick one way of doing it and make the new spec 
> clear on that.
> 
> So I propose a survey:
> 
> 1. Does your implementation treat the DTSTART instance as the first 
> instance in a RRULE set, even if it does not match the RRULE itself?
> 
> yes/no
> 
> 2. What is the name/version of that implementation?
> 
> ------
> 
> Assuming the above questions will solicit the right information we need, 
> perhaps the chairs could formally ask this and tabulate the result?
> 

--------------020307000406010005080205
Content-Type: text/plain;
 name="test.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="test.ics"

BEGIN:VCALENDAR
PRODID:-//Bernard//vi//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Time (US & Canada)
BEGIN:STANDARD
DTSTART:20051030T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:Standard Time
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20060402T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:Daylight Savings Time
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER:MAILTO:[email-masked]
DTSTART;TZID="Eastern Time (US & Canada)":20061016T173000
DTEND;TZID="Eastern Time (US & Canada)":20061016T180000
RRULE:FREQ=WEEKLY;COUNT=3;INTERVAL=1;BYDAY=TU;WKST=SU
TRANSP:OPAQUE
SEQUENCE:0
UID:[email-masked]
DTSTAMP:20061013T142548Z
SUMMARY:Test
PRIORITY:5
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

--------------020307000406010005080205--

Date: Fri, 13 Oct 2006 16:19:47 +0200
From: Eliot Lear <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] RRULE's and COUNT
Cc: [email-masked]

Is this one of those cases where we should get prescriptive about what
to output so that we avoid this circumstance?  So for instance, say that
when applying DTSTART with an RRULE, the value should be that of the
first occurrence?

Eliot

Reinhold Kainhofer wrote:
> Am Freitag, 13. Oktober 2006 03:16 schrieb Jeffrey Harris:
>   
>>> I wonder how other proprietary applications interpret it (in
>>> particular Outlook and Apple iCal)....
>>>       
>> One other in the open source camp, Chandler includes DTSTART in its
>> count.
>>     
>
> Well, I tried it out, and it seems that Chandler 0.6 does NOT include DTSTART 
> in its COUNT if DTSTART does not match the rule: Importing an event with
>   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
>   DTSTART:20061009T070000Z
> (where the DTSTART is a monday and thus does not match the rule) results in 
> the event appearing on Oct 9, Oct 10, Oct 12 and Oct 17.
>
> Chandler 0.7.1 simply ignores the DTSTART if it doesn't match the rule:
>   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
>   DTSTART:20061009T070000Z
> appears only on Tue Oct 10, Thu Oct 12 and Tue Oct 17 (but not on Oct 9).
>
> Cheers,
> Reinhold
>
>   

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULE's and COUNT
Date: Fri, 13 Oct 2006 16:12:49 +0200

Am Freitag, 13. Oktober 2006 03:16 schrieb Jeffrey Harris:
> > I wonder how other proprietary applications interpret it (in
> > particular Outlook and Apple iCal)....
>
> One other in the open source camp, Chandler includes DTSTART in its
> count.

Well, I tried it out, and it seems that Chandler 0.6 does NOT include DTSTART 
in its COUNT if DTSTART does not match the rule: Importing an event with
  RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
  DTSTART:20061009T070000Z
(where the DTSTART is a monday and thus does not match the rule) results in 
the event appearing on Oct 9, Oct 10, Oct 12 and Oct 17.

Chandler 0.7.1 simply ignores the DTSTART if it doesn't match the rule:
  RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
  DTSTART:20061009T070000Z
appears only on Tue Oct 10, Thu Oct 12 and Tue Oct 17 (but not on Oct 9).

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/

Date: Fri, 13 Oct 2006 09:46:53 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Survey of RRULE/COUNT behavior, was Re: [Ietf-calsify] RRULE's and COUNT

Hi Reinhold,

--On October 13, 2006 10:12:13 AM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

>> We certainly have variation in implementations of this, I'd lean towards
>> following what 2445 said originally, rather than changing the meaning of
>> COUNT.
>
> Hehe, that's the problem: We have an argument about what 2445 originally
> said!  Apparently, I have a different opinion about that than you.

At this point maybe we need to get a count of which way implementations 
have gone in dealing with this before making a final decision. However, I 
do believe we must pick one way of doing it and make the new spec clear on 
that.

So I propose a survey:

1. Does your implementation treat the DTSTART instance as the first 
instance in a RRULE set, even if it does not match the RRULE itself?

 yes/no

2. What is the name/version of that implementation?

 ------

Assuming the above questions will solicit the right information we need, 
perhaps the chairs could formally ask this and tabulate the result?

-- 
Cyrus Daboo

Date: Fri, 13 Oct 2006 09:40:10 -0400
From: Cyrus Daboo <[email-masked]>
To: Andrew N Dowden <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if	specified" and BY rules

Hi Andrew,

--On October 13, 2006 12:31:23 PM +1300 Andrew N Dowden 
<[email-masked]> wrote:

> suggestion:
>   change "if specified," to "if within the recurrence set, then"
>
> new text:
>       The COUNT rule part defines the number of occurrences at which to
>       range-bound the recurrence.  The "DTSTART" property value, if
>       within the recurrence set, then counts as the first occurrence.
>
> Summary:
> The means DTSTART is not automatically taken as the first occurrence
> (and does
> not always count towards COUNT).  This wont immediately effect those
> applications that try to avoid DTSTART varying from RRULE, and better
> supports COUNT as relates to BYxxx (eg. BYDAY) elements.
>

I believe this change would 'break' many existing implementations. 
Certainly it seems the majority of currently implementations always 
consider DTSTART as the first instance in COUNT, and I think the spec 
should be clarified to 'bless' that view.

-- 
Cyrus Daboo

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Re: Issues with Andrews proposal [Was: Issue 13: confusion in DTSTART text about "if specified" and BY rules]
Date: Fri, 13 Oct 2006 15:09:29 +0200

Am Freitag, 13. Oktober 2006 13:50 schrieb Reinhold Kainhofer:
> Am Freitag, 13. Oktober 2006 13:24 schrieb Oliver Block:
> > Interpretation 1 (DTSTART is 1st occurance):
> > ------------------------------------------------------
> >
> > > > � DTSTART;VALUE=DATE:20061013
> > > > � RRULE:FREQ=WEEKLY;COUNT=3
> > > > This would last until Oct 27.
> >
> > A = {20061013, 20061020, 20061027}
> > B = {}
> > R = A \ B means in this case R = A
> >
> > > > Now add one simple EXDATE to exclude DTSTART:
> > > > � DTSTART;VALUE=DATE:20061013
> > > > � RRULE:FREQ=WEEKLY;COUNT=3
> > > > � EXDATE;VALUE=DATE:20061013
> >
> > A = {20061013, 20061020, 20061027}
> > B = {20061013}
> > R = A \ B = {20061020, 20061027}
>
> That's not what Andrews suggested:
>       "The COUNT rule part defines the number of occurrences at which to
>       range-bound the recurrence.  The "DTSTART" property value, if
>       within the recurrence set, then counts as the first occurrence."
>
> Andrew suggested that the date/time of DTSTART only counts towards the
> COUNT if it is in R. As it is not in R, the set A will be {20061013,
> 20061020, 20061027, 20061103}, and R={20061020, 20061027, 20061103}. And we
> have the problem that the calculation of A depends on R, which in turn
> depends on A.
>
> Or is it just a misunderstanding and Andrew didn't want to use "recurrence
> set", which means R in our case, but was rather talking about the set A?

I think so.

> Notice that in this case the DTSTART matches the RRULE anyway, so we are
> not talking about Issue 13 here! Issue 13 only appears when the DTSTART
> does not fulfil the restrictions of the RRULE, i.e. if DTSTART is a Monday
> and the RRULE has BYDAY=TU,TH.

ack

Regards,

Oliver

-- 
Leben ist mehr als ... 
http://www.nak-nrw.de/p_6_4.html

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Date: Fri, 13 Oct 2006 13:50:15 +0200
Subject: [Ietf-calsify] Re: Issues with Andrews proposal [Was: Issue 13: confusion in DTSTART text about "if specified" and BY rules]

Am Freitag, 13. Oktober 2006 13:24 schrieb Oliver Block:
> Interpretation 1 (DTSTART is 1st occurance):
> ------------------------------------------------------
>
> > > =A0 DTSTART;VALUE=3DDATE:20061013
> > > =A0 RRULE:FREQ=3DWEEKLY;COUNT=3D3
> > > This would last until Oct 27.
>
> A =3D {20061013, 20061020, 20061027}
> B =3D {}
> R =3D A \ B means in this case R =3D A
>
> > > Now add one simple EXDATE to exclude DTSTART:
> > > =A0 DTSTART;VALUE=3DDATE:20061013
> > > =A0 RRULE:FREQ=3DWEEKLY;COUNT=3D3
> > > =A0 EXDATE;VALUE=3DDATE:20061013
>
> A =3D {20061013, 20061020, 20061027}
> B =3D {20061013}
> R =3D A \ B =3D {20061020, 20061027}

That's not what Andrews suggested:
      "The COUNT rule part defines the number of occurrences at which to
      range-bound the recurrence.  The "DTSTART" property value, if
      within the recurrence set, then counts as the first occurrence."

Andrew suggested that the date/time of DTSTART only counts towards the COUN=
T=20
if it is in R. As it is not in R, the set A will be {20061013, 20061020,=20
20061027, 20061103}, and R=3D{20061020, 20061027, 20061103}. And we have th=
e=20
problem that the calculation of A depends on R, which in turn depends on A.

Or is it just a misunderstanding and Andrew didn't want to use "recurrence=
=20
set", which means R in our case, but was rather talking about the set A?

> Interpretation 2 (1st occurance is first date generated by RRULE):
> -------------------------------------------------------------------------=
=2D-
>-----
>
> > >   DTSTART;VALUE=3DDATE:20061013
> > >   RRULE:FREQ=3DWEEKLY;COUNT=3D3
> > > This would last until Oct 27.
>
> A =3D {20061020, 20061027, 20061103}

Okay, now it's getting interesting! Why is 20061013 not part of A? The=20
examples in section "4.8.5.4 Recurrence Rule" clearly show that it should b=
e.
Similarly, 20061103 should not be part of A.

Notice that in this case the DTSTART matches the RRULE anyway, so we are no=
t=20
talking about Issue 13 here! Issue 13 only appears when the DTSTART does no=
t=20
fulfil the restrictions of the RRULE, i.e. if DTSTART is a Monday and the=20
RRULE has BYDAY=3DTU,TH.

Cheers,
Reinhold

=2D-=20
=2D-----------------------------------------------------------------
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.a=
t/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules
Date: Fri, 13 Oct 2006 13:24:48 +0200

Am Freitag, 13. Oktober 2006 12:29 schrieb Reinhold Kainhofer:

> Exactly. But the Andrew's proposal would add a cross dependency of set A on
> set B (as the COUNT of RRULE would depend on whether the DTSTART is in the
> final set R, which means that it is not in B).

Let's take your example from above:

Interpretation 1 (DTSTART is 1st occurance):
------------------------------------------------------
> > � DTSTART;VALUE=DATE:20061013
> > � RRULE:FREQ=WEEKLY;COUNT=3
> > This would last until Oct 27.

A = {20061013, 20061020, 20061027}
B = {}
R = A \ B means in this case R = A

> > Now add one simple EXDATE to exclude DTSTART:
> > � DTSTART;VALUE=DATE:20061013
> > � RRULE:FREQ=WEEKLY;COUNT=3
> > � EXDATE;VALUE=DATE:20061013

A = {20061013, 20061020, 20061027}
B = {20061013}
R = A \ B = {20061020, 20061027}

Interpretation 2 (1st occurance is first date generated by RRULE):
--------------------------------------------------------------------------------
> > � DTSTART;VALUE=DATE:20061013
> > � RRULE:FREQ=WEEKLY;COUNT=3
> > This would last until Oct 27.

A = {20061020, 20061027, 20061103}
B = {}
R = A \ B means in this case R = A

> > Now add one simple EXDATE to exclude DTSTART:
> > � DTSTART;VALUE=DATE:20061013
> > � RRULE:FREQ=WEEKLY;COUNT=3
> > � EXDATE;VALUE=DATE:20061013

A = {20061020, 20061027, 20061103}
B = {20061013}
R = A \ B = {20061020, 20061027, 20061103}

That's how I understand either of the interpretations.

Regards,

Oliver

-- 
Leben ist mehr als ... 
http://www.nak-nrw.de/p_6_4.html

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules
Date: Fri, 13 Oct 2006 12:29:37 +0200

Am Freitag, 13. Oktober 2006 12:21 schrieb Oliver Block:
> Am Freitag, 13. Oktober 2006 10:12 schrieb Reinhold Kainhofer:
> > Actually, this introduces a cross-dependency between EXDATE/EXRULE and
> > RRULE! E.g. Take a rule
> >   DTSTART;VALUE=DATE:20061013
> >   RRULE:FREQ=WEEKLY;COUNT=3
> > This would last until Oct 27.
> > Now add one simple EXDATE to exclude DTSTART:
> >   DTSTART;VALUE=DATE:20061013
> >   RRULE:FREQ=WEEKLY;COUNT=3
> >   EXDATE;VALUE=DATE:20061013
> > With your suggestion the RRULE would now last until Nov 3.
>
> Aren't you supposed to create the set of dates, before you exclude a date?
>
> 1 Create a set A from RRULE
> 2 Add RDATE to the set A (without duplicates)
> 3 create a set B from EXRULE
> 4 Add EXDATE to the set B (without duplicates)
> 5 Add all dates to R (recurrence set) that are in A and not in B (R = A \ B
> )

Exactly. But the Andrew's proposal would add a cross dependency of set A on 
set B (as the COUNT of RRULE would depend on whether the DTSTART is in the 
final set R, which means that it is not in B).

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: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules
Date: Fri, 13 Oct 2006 12:21:04 +0200

Am Freitag, 13. Oktober 2006 10:12 schrieb Reinhold Kainhofer:
> Actually, this introduces a cross-dependency between EXDATE/EXRULE and
> RRULE! E.g. Take a rule
>   DTSTART;VALUE=DATE:20061013
>   RRULE:FREQ=WEEKLY;COUNT=3
> This would last until Oct 27.
> Now add one simple EXDATE to exclude DTSTART:
>   DTSTART;VALUE=DATE:20061013
>   RRULE:FREQ=WEEKLY;COUNT=3
>   EXDATE;VALUE=DATE:20061013
> With your suggestion the RRULE would now last until Nov 3.

Aren't you supposed to create the set of dates, before you exclude a date?

1 Create a set A from RRULE
2 Add RDATE to the set A (without duplicates)
3 create a set B from EXRULE
4 Add EXDATE to the set B (without duplicates)
5 Add all dates to R (recurrence set) that are in A and not in B (R = A \ B )

Regards,

Oliver

-- 
Leben ist mehr als ... 
http://www.nak-nrw.de/p_6_4.html

From: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules
Date: Fri, 13 Oct 2006 10:12:56 +0200

Am Freitag, 13. Oktober 2006 01:31 schrieb Andrew N Dowden:
> Reinhold Kainhofer wrote:
> > This will result in the event occuring on Oct 10 and 17. The "if
> > specified"
> > (in the sense "if it matches the RRULE") in the rfc is meant to
> > clarify that
> > the RRULE does not add Oct 17 and 24, but rather Oct 10 and 17.
>
> I strongly agree with your "if it matches the RRULE", but extended to
> the recurrence set derived from all RDATE, RRULE, EXDATE, and EXRULE
> properties.
>
> suggestion:
>   change "if specified," to "if within the recurrence set, then"
>
> new text:
>       The COUNT rule part defines the number of occurrences at which to
>       range-bound the recurrence.  The "DTSTART" property value, if
>       within the recurrence set, then counts as the first occurrence.

Actually, this introduces a cross-dependency between EXDATE/EXRULE and RRULE! 
E.g. Take a rule
  DTSTART;VALUE=DATE:20061013
  RRULE:FREQ=WEEKLY;COUNT=3
This would last until Oct 27.
Now add one simple EXDATE to exclude DTSTART:
  DTSTART;VALUE=DATE:20061013
  RRULE:FREQ=WEEKLY;COUNT=3
  EXDATE;VALUE=DATE:20061013
With your suggestion the RRULE would now last until Nov 3. 
Compare this with an EXDATE for the next friday:
  DTSTART;VALUE=DATE:20061013
  RRULE:FREQ=WEEKLY;COUNT=3
  EXDATE;VALUE=20061020
This event lasts only until Oct 27. Quite inconsistent, don't you think?

As the recurrence set is evaluated in the order 
1) DTSTART
2) Add all date/times from RDATE and RRULE
3) Exclude all date/times from EXDATE and EXRULE
the evaluation of 2) now depends on 3) !

>
> Summary:
> The means DTSTART is not automatically taken as the first occurrence

It would be, unless DTSTART is EXCLUDED by EXDATE or EXRULE.

> (3.) Cyrus Daboo - 'next Monday + next Friday, on/after 20061011'
>
>   DTSTART;VALUE=DATE:20061011
>   RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
>   RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR
>
>   [RESULT: Oct13 Fri, Oct16 Mon]

You forgot to include DTSTART in the recurrence set! 

> (4.) Reinhold Kainhofer - 'next 3, Tuesday OR Thursday, on/after 20061009'
>
>   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
>   DTSTART;VALUE=DATE:20061009
>
>   [RESULT: Oct10 Tue, Oct12 Thu, Oct17 Tue]

Here you are missing Oct 9 Mon (DTSTART)! As you count the DTSTART in this 
case towards the COUNT, Oct17 won't be in the recurrence set.

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: Reinhold Kainhofer <[email-masked]>
Organization: Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] RRULE's and COUNT
Date: Fri, 13 Oct 2006 10:12:13 +0200

Am Freitag, 13. Oktober 2006 03:16 schrieb Jeffrey Harris:
> Hi Reinhold,
>
> > I wonder how other proprietary applications interpret it (in
> > particular Outlook and Apple iCal)....
>
> One other in the open source camp, Chandler includes DTSTART in its
> count. iCal also counts the DTSTART as the first occurrence, regardless
> of the rule.  iCal lets you construct such an event in the UI, Chandler
> doesn't.
>
> Section 4.3.10 says:
>
> The COUNT rule part defines the number of occurrences at which to
> range-bound the recurrence. The "DTSTART" property value, if specified,
> counts as the first occurrence.
>
> That seems pretty clear, so while I found it annoying when implementing
> recurrence, I'm used to it now.

At first glance, I agree it seems pretty clear. But notice the ", if 
specified" in there. These things are not inserted just for the fun of it. 
What I learnt in my part-time law studies is that particularly such easily 
overlooked insertions can change the whole meaning and can't simply be 
ignored. As I said in my previous mails, the only meaning of "if specified" 
that makes any sense to me is "if specified [by the RRULE]". 
This needed to be clarified, as the DTSTART is already in the recurrence set 
and duplicate dates are ignored, so there would be the question whether to 
count such ignored date/times towards the COUNT.

In particular, (a) "if specified" indicates a condition, so it is not always 
the case that DTSTART is counted towards COUNT and (b) as the spec says that 
DTSTART MUST be present it cannot mean "if DTSTART is given at all". 

Also, if DTSTART is automatically included in the dates generated by rules, 
EXRULE does not really make that much sense any more. 
If the "if specified" is meant as "if generated by the rule", then suddenly 
everything falls nicely in place and several problems are no issues any more.

> We certainly have variation in implementations of this, I'd lean towards
> following what 2445 said originally, rather than changing the meaning of
> COUNT.  

Hehe, that's the problem: We have an argument about what 2445 originally said! 
Apparently, I have a different opinion about that than you.

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/

Date: Thu, 12 Oct 2006 18:16:12 -0700
From: Jeffrey Harris <[email-masked]>
To: [email-masked]
Subject: [Ietf-calsify] RRULE's and COUNT

Hi Reinhold,

> I wonder how other proprietary applications interpret it (in 
> particular Outlook and Apple iCal)....

One other in the open source camp, Chandler includes DTSTART in its
count. iCal also counts the DTSTART as the first occurrence, regardless
of the rule.  iCal lets you construct such an event in the UI, Chandler
doesn't.

Section 4.3.10 says:

The COUNT rule part defines the number of occurrences at which to
range-bound the recurrence. The "DTSTART" property value, if specified,
counts as the first occurrence.

That seems pretty clear, so while I found it annoying when implementing
recurrence, I'm used to it now.

We certainly have variation in implementations of this, I'd lean towards
following what 2445 said originally, rather than changing the meaning of
COUNT.  But I'm not deeply attached, we already have incompatibility,
it'd be nice to agree on the same interpretation, whatever it is.

Sincerely,
Jeffrey

From: "Tim Hare" <[email-masked]>
To: "'Calsify WG'" <[email-masked]>
Subject: RE: [Ietf-calsify] Section 4.3.10 Recurrence Rule: x-name rule part?
Date: Thu, 12 Oct 2006 20:28:16 -0400

Again, I am not a calendar software implementer (any more) but I think
recurrence rules are one place where X-anything can be a big problem. I do
understand that some implementer somewhere may have already coded
X-BYPRIMENUMBERINTERVALS or something, so that may be an argument for
maintaining the rule part, but if we do retain it, I propose language be
added similar to the following:

"x-name" rule parts are allowed to provide for experimentation and
implementation-specific uses, however because of interoperability concerns
"x-name" rule parts MUST NOT change the interpretation of recurrence rules
in any way and MUST NOT contribute to creating the set of instances when the
recurrence rule is expanded.

All of that said, I agree with removing the rule-part entirely.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard
Desruisseaux
Sent: Thursday, October 12, 2006 3:23 PM
To: Calsify WG
Subject: [Ietf-calsify] Section 4.3.10 Recurrence Rule: x-name rule part?

In section 4.3.10 Recurrence Rule of RFC 2445 it says:

 > Formal Definition: The value type is defined by the following  >
notation:
 >   recur      = "FREQ"=freq *(
 >              ( ";" x-name "=" text )
 >              )

which implies that a RECUR value (e.g., the value of a RRULE or an
EXRULE) can specify a "x-name" rule part with a "text" value.

For some reason I would have expected "x-name" rule part to have a
"paramtext" value and not "text" value.

But more importantly, I don't understand why we should allow "x-name"
rule parts. IMHO, it should be sufficient to have the ability to specify an
"xparam" on properties of RECUR value type (e.g., RRULE and EXRULE).

Instead of:
   RRULE:RRULE:FREQ=DAILY;COUNT=10;X-FOO-BAR=42
one could do:
   RRULE;X-FOO-BAR=42:RRULE:FREQ=DAILY;COUNT=10

I hereby propose to remove "x-name" from the "recur" rule part definition.

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

Date: Fri, 13 Oct 2006 12:31:23 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules

Reinhold Kainhofer wrote:
> Am Dienstag, 10. Oktober 2006 17:35 schrieb Bernard Desruisseaux:
> > In section 4.3.10 Recurrence Rule of RFC 2445 it says:
> >  > The COUNT rule part defines the number of occurrences at which to
> >  > range-bound the recurrence. The "DTSTART" property value, if
> >  > specified, counts as the first occurrence.
>
> > I would like to remove "if specified" given that DTSTART should be
> > REQUIRED when either RRULE or EXRULE are present.
>
> > NEW TEXT:
> >  > The COUNT rule part defines the number of occurrences at which to
> >  > range-bound the recurrence. The "DTSTART" property value counts as
> >  > the first occurrence.
>
> I don't think that this is what was intended.
> E.g. imagine an event with
>
> DTSTART;VALUE=DATE:20061010
> RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=MO
>
> This event will recur on October 10 and on the next two mondays (Oct
> 16 and
> 23). With your proposed change, it will only occur on October 10 and
> on the
> next monday (Oct 16), which I would find quite counter-intuitive.
>
> If the DTSTART mathes the RRULE, there is no difference (as the
> DTSTART in
> that case also counts towards the COUNT):
>
> DTSTART;VALUE=DATE:20061010
> RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=TU
>
> This will result in the event occuring on Oct 10 and 17. The "if
> specified"
> (in the sense "if it matches the RRULE") in the rfc is meant to
> clarify that
> the RRULE does not add Oct 17 and 24, but rather Oct 10 and 17.
I strongly agree with your "if it matches the RRULE", but extended to
the recurrence set derived from all RDATE, RRULE, EXDATE, and EXRULE
properties.

suggestion:
  change "if specified," to "if within the recurrence set, then"

new text:
      The COUNT rule part defines the number of occurrences at which to
      range-bound the recurrence.  The "DTSTART" property value, if
      within the recurrence set, then counts as the first occurrence.

Summary:
The means DTSTART is not automatically taken as the first occurrence
(and does
not always count towards COUNT).  This wont immediately effect those
applications that try to avoid DTSTART varying from RRULE, and better
supports COUNT as relates to BYxxx (eg. BYDAY) elements.

Simply including or excluding DTSTART from COUNT does not provide any
certainty of results against an unskilled users expectations.  This is
also an area where the apparent ambiguity of  rfc2445  has resulted in
partial and varied implementations to date.

further background arguments, see my previous posting 12-Oct-2006
04:12pm (+1300)

examples: (from other postings)

(1.) Reinhold Kainhofer - 'next 2 Mondays, on/after 20061010'

  DTSTART;VALUE=DATE:20061010
  RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=MO

  [RESULT: Oct16 Mon, Oct23 Mon]

(2.) Reinhold Kainhofer - 'next 2 Tuesdays, on/after 20061010'

  DTSTART;VALUE=DATE:20061010
   RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=TU

  [RESULT: Oct10 Tue, Oct17 Tue]

(3.) Cyrus Daboo - 'next Monday + next Friday, on/after 20061011'

  DTSTART;VALUE=DATE:20061011
  RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
  RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR

  [RESULT: Oct13 Fri, Oct16 Mon]

(4.) Reinhold Kainhofer - 'next 3, Tuesday OR Thursday, on/after 20061009'

  RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
  DTSTART;VALUE=DATE:20061009

  [RESULT: Oct10 Tue, Oct12 Thu, Oct17 Tue]

-- 
_______________________________________________

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

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation =?iso-8859-1?q?of=09issues?=
Date: Thu, 12 Oct 2006 21:56:42 +0200

Am Mittwoch, 11. Oktober 2006 17:37 schrieben Sie:
> Hi Reinhold,
>
> --On October 11, 2006 5:16:28 PM +0200 Reinhold Kainhofer
>
> <[email-masked]> wrote:
> > DTSTART;VALUE=DATE:20061011
> > RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
> > RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR
> >
> > will result in the event only happening on Oct 11, but not on any monday
> > or  any friday, which is not what I would expect. I wonder how different
> > implementations interpret this snipplet...
> > Intuitively, I would expect the event to happen on Oct 11, plus on the
> > next  one monday and on the next one friday.
>
> An instance representing the supplied DTSTART value is always present as
> per 4.8.5.4 (which says in the Description paragraph: 'The "DTSTART"
> property defines the first instance in the recurrence set.'). So a COUNT=1 
> will only ever generate the DTSTART instance. 

The DTSTART is the first instance in the *recurrence set*, which is defined of 
the union of DTSTART plus all date/times generated by RRULEs and RDATEs, 
exclding all date/times generated by EXRULEs and EXDATEs. 
This sentence does not say that the RRULE generates the DTSTART as its first 
date/time.

I looked at how different calendaring applications currently handle the COUNT 
property at the example of
   RRULE:FREQ=WEEKLY;COUNT=3;BYDAY=TU,TH
   DTSTART;VALUE=DATE:20061009
If the DTSTART is taken as the first occurrence generated by the RRULE 
(although it does not match the BY* rule parts), this event would recur on
   Oct 9
   Oct 10
   Oct 12
If the DTSTART is not automatically taken as the first occurrence (and does 
not count towards COUNT), the event would happen on
   Oct 9
   Oct 10
   Oct 12
   Oct 17

I looked at KOrganizer, Evolution, Mozilla Calendar and Google Calendar (which 
are the only calendaring applications that I currently have access to). 
eGroupware and phpGroupware don't support the COUNT at all.

 Here are my findings:

-) KOrganizer: We understand the 'if specified' as 'if specified by the rule' 
in the sense "if generated by the rule", so the event hapens on Oct 9,10,12 
and 17. DTSTART is not automatically the first event in the list of 
occurences generated by RRULE

-) Evolution: Same result: Oct 9, 10, 12 and 17.

-) Mozilla Calendar: The UI does not allow you to set an RRULE that does not 
match the DTSTART, so this issue does not appear easily. However, you can 
later move the first occurrence to a different day, so that it no longer 
matches the RRULE. In that case, the same result as in KOrganizer and 
Evolution happens: Oct 9, 10, 12 and 17.
Importing such an event leads to non-sensical results (i.e. occurrence on Oct 
9, 12 and 17)

-) Google Calendar: Does not allow you to create recurrences with COUNT. But 
it is able to import such ics files. In that case, the event also occurs on 
Oct 9,10,12 and 17.

So, basically all big open source implementations, plus Google calendar do not 
automatically take DTSTART as the first date generated by the RRULE and do 
not count it towards the COUNT. 

I wonder how other proprietary applications interpret it (in particular 
Outlook and Apple iCal)....

As the consensus amongst implementations seems to be not to automatically take 
DTSTART as the first occurrence, we should clarify the RFC in that direction. 
(It also makes more sense in connection with the EXRULE issue, which would 
then be solved). 

The only problem that is still there are the two contradicting sentences about 
DTSTART always being the first instance in the recurrence set vs. 
EXRULE/EXDATE being used to exclude DTSTART from the recurrence set...
But that issue needs to be solved separately anyway and is not connected to 
our current issue.

Cheers,
Reinhold

PS: I quickly asked our secretary to check Outlook (with no exchange server). 
It doesn't even use the start date as an instance of the event. I.e. I 
created an event on monday Oct 9 and set it to recur weekly on tue and thu 
for 3 times. The event only showed up on Oct 10, 12 and 17!!!
Importing the .ics with the above DTSTART and RRULE failed (with no helpful 
error description whatsoever).

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

Date: Thu, 12 Oct 2006 15:23:24 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.3.10 Recurrence Rule: x-name rule part?

In section 4.3.10 Recurrence Rule of RFC 2445 it says:

 > Formal Definition: The value type is defined by the following
 > notation:
 >
 >   recur      = "FREQ"=freq *(
 >
 >              [...]
 >
 >              ( ";" x-name "=" text )
 >              )

which implies that a RECUR value (e.g., the value of a RRULE or an
EXRULE) can specify a "x-name" rule part with a "text" value.

For some reason I would have expected "x-name" rule part to have a
"paramtext" value and not "text" value.

But more importantly, I don't understand why we should allow "x-name"
rule parts. IMHO, it should be sufficient to have the ability to specify
an "xparam" on properties of RECUR value type (e.g., RRULE and EXRULE).

Instead of:
   RRULE:RRULE:FREQ=DAILY;COUNT=10;X-FOO-BAR=42
one could do:
   RRULE;X-FOO-BAR=42:RRULE:FREQ=DAILY;COUNT=10

I hereby propose to remove "x-name" from the "recur" rule part definition.

Cheers,
Bernard

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of issues
Date: Thu, 12 Oct 2006 15:56:31 +0200

Am Donnerstag, 12. Oktober 2006 15:32 schrieb Bernard Desruisseaux:
> I would like the jabber sessions to remain scheduled on
> Tuesday.  I'm flexible for the time of the day.

Okay. I don't have any time next tuesday, either (only maybe from 10:00 to 
11:15 CEST, but that's right in the middle of the night in the US). So again 
I won't be able to attend.

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/

Date: Thu, 12 Oct 2006 09:32:24 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Eliot Lear <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of issues
Cc: [email-masked]

Eliot,

I would like the jabber sessions to remain scheduled on
Tuesday.  I'm flexible for the time of the day.

Thanks,
Bernard

Eliot Lear wrote:
> Cyrus Daboo wrote:
>> Hi Eliot,
>>
>> --On October 11, 2006 5:39:37 PM +0200 Eliot Lear <[email-masked]> wrote:
>>
>>> Thank you, Reinhold.  Let me simply ask the group whether the same time
>>> or 9:00am on Wednesdays would be possible?
>> Timezone?
>>
> 
> Heh.  So to restate the proposal would be for next Wednesday 8:00 or
> 9:00 PDT or 17:00 or 18:00 CEST.
> 
> Eliot
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Thu, 12 Oct 2006 09:00:53 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-02.txt

Folks,

I uploaded an HTML version that tracks all the changes
I did to the draft on the IETF Tools web site:

http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-02.html

Cheers,
Bernard

[email-masked] wrote:
> 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		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
> 	Author(s)	: B. Desruisseaux
> 	Filename	: draft-ietf-calsify-rfc2445bis-02.txt
> 	Pages		: 158
> 	Date		: 2006-10-11
> 	
> There is a clear need to provide and deploy interoperable calendaring
>    and scheduling services for the Internet.  Current group scheduling
>    and Personal Information Management (PIM) products are being extended
>    for use across the Internet, today, in proprietary ways.  This memo
>    has been defined to provide the definition of a common format for
>    openly exchanging calendaring and scheduling information across the
>    Internet.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-02.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-rfc2445bis-02.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-rfc2445bis-02.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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Thu, 12 Oct 2006 16:12:25 +1300
From: Andrew N Dowden <[email-masked]>
Organization: Dowden Software Associates
To: [email-masked]
Subject: Re: Lets deprecate EXRULE, Re: [Ietf-calsify] summary of jabber	sessions and confirmation of	issues

Cyrus Daboo wrote:
>> If we remove that confusing sentence from issue 14 and properly re-word
>> the  issue in 13, it's clear that the DTSTART is not automatically
>> generated by  the EXRULE, thus the DTSTART is not always excluded and
>> the
>> issue is solved.
>>
>> I'm fine with deprecating exrule (although I worked hard to implement
>> multiple  exrules support it in libkcal...).
> We can't do that because issue 13 cannot be resolved in the way you
> propose as per my pervious email.
>
> The problem we have is this:
>
> 1) If we take the 2445 statement that DTSTART is always the first
> instance in a rule set, and say that applies to EXRULE, then the
> presence of ANY EXRULE will always exclude the DTSTART - so there is
> no way to define an EXRULE that does not exclude the DTSTART. This
> would force clients to use a 'fake' DTSTART value that they know would
> be excluded, so that the actual first instance occurs when it should.
> Ugly!
>
> 2) If we say that DTSTART is not the first instance for the EXRULE
> set, then we have an inconsistency in the way COUNT & INTERVAL work in
> RRULE and EXRULE.
>
> Because of this, and the fact that EXRULE is rarely used, I think we
> should deprecate its use in 2445bis. That means implementations MUST
> NOT generate EXRULE, but may choose to continue accepting EXRULE in
> whatever fashion they currently do.
>
I have previously argued that DTSTART needs to be better defined, and
that this would then solve the problems identified with RRULE, EXRULE,
and COUNT or BYSETPOS

    previous post, to Bugzilla (as regards rfc2445, recurrence and DTSTART)
    https://bugzilla.mozilla.org/show_bug.cgi?id=266298#c10

In summary: (yet to be worded in rfc-speak)

(a.) The recurrence set is generated from DTSTART property, along with
RRULE, RDATE, EXDATE and EXRULE properties.
     [RESULT: as set of date/times]

(b.) DTSTART property defines first instance in the recurrence set.
    [RESULT: excludes from recurrence set (if any) all date/times prior
to DTSTART]

(c.) DTSTART property, if specified, counts as the first occurrence.
    [EXCEPTION: each time/date instance within recurrence set is
counted; if DTSTART is NOT within recurrence set, it is NOT counted.]

If this needs to be restated, reposted, or clarified (in context of more
recent discussions) then please advise.

PS. Sorry I forgot to post this discussion into  calsify  (where it
belongs).

-- 
_______________________________________________

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

To: [email-masked]
From: [email-masked]
Date: Wed, 11 Oct 2006 18:50:02 -0400
Cc: [email-masked]
Subject: [Ietf-calsify] I-D ACTION:draft-ietf-calsify-rfc2445bis-02.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		: Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Author(s)	: B. Desruisseaux
	Filename	: draft-ietf-calsify-rfc2445bis-02.txt
	Pages		: 158
	Date		: 2006-10-11
	
There is a clear need to provide and deploy interoperable calendaring
   and scheduling services for the Internet.  Current group scheduling
   and Personal Information Management (PIM) products are being extended
   for use across the Internet, today, in proprietary ways.  This memo
   has been defined to provide the definition of a common format for
   openly exchanging calendaring and scheduling information across the
   Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-calsify-rfc2445bis-02.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-rfc2445bis-02.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-rfc2445bis-02.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-rfc2445bis-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 11 Oct 2006 18:18:48 +0200
From: Eliot Lear <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of issues
Cc: [email-masked]

Cyrus Daboo wrote:
> Hi Eliot,
>
> --On October 11, 2006 5:39:37 PM +0200 Eliot Lear <[email-masked]> wrote:
>
>> Thank you, Reinhold.  Let me simply ask the group whether the same time
>> or 9:00am on Wednesdays would be possible?
>
> Timezone?
>

Heh.  So to restate the proposal would be for next Wednesday 8:00 or
9:00 PDT or 17:00 or 18:00 CEST.

Eliot

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and =?iso-8859-1?q?confirmation=09of=09issues?=
Date: Wed, 11 Oct 2006 18:16:24 +0200

Am Mittwoch, 11. Oktober 2006 18:03 schrieben Sie:
> Hi Reinhold,
>
> --On October 11, 2006 5:50:22 PM +0200 Reinhold Kainhofer
>
> <[email-masked]> wrote:
> >> An instance representing the supplied DTSTART value is always present as
> >> per 4.8.5.4 (which says in the Description paragraph: 'The "DTSTART"
> >> property defines the first instance in the recurrence set.'). So a
> >> COUNT=1 will only ever generate the DTSTART instance. So your
> >> 'intuitive' expectation is wrong.
> >
> > On the other hand, section 4.8.5.2 about EXRULE (and section 4.8.5.1
> > about  EXDATE) says that the EXRULE/EXDATE properties can be used to
> > exlude the  DTSTART. Notice the word *can* and "in such cases", which
> > indicate that the  DTSTART is not always automatically generated by an
> > EXRULE.
> >
> > So, the DTSTART is not always the first instance in the recurrence set,
> > and an  EXRULE does not necessarily exclude the DTSTART. Consequently, a
> > recurrence  rule does not necessarily generate the DTSTART as its first
> > date/time.
>
> But again, 4.8.5.2 states: 'The "DTSTART" defines the first instance in the
> recurrence set.'. I consider that a stronger statement than 'can be used to
> exlcude...'. As defined it 'always excludes the DTSTART'. 

Well, first, there is that "if specified", which I understand as "if generated 
by the rule". And second, if DTSTART is excluded by EXRULE or EXDATE it is 
not the first instance in the recurrence set, so we have a contradiction in 
any case. 

> The bottom line is this just re-emphasizes why EXRULE is a real problem and
> should be deprecated.

The same problem goes with RRULE and the COUNT.

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/

Date: Wed, 11 Oct 2006 12:03:39 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation	of	issues

Hi Reinhold,

--On October 11, 2006 5:50:22 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

>> An instance representing the supplied DTSTART value is always present as
>> per 4.8.5.4 (which says in the Description paragraph: 'The "DTSTART"
>> property defines the first instance in the recurrence set.'). So a
>> COUNT=1 will only ever generate the DTSTART instance. So your 'intuitive'
>> expectation is wrong.
>
> On the other hand, section 4.8.5.2 about EXRULE (and section 4.8.5.1
> about  EXDATE) says that the EXRULE/EXDATE properties can be used to
> exlude the  DTSTART. Notice the word *can* and "in such cases", which
> indicate that the  DTSTART is not always automatically generated by an
> EXRULE.
>
> So, the DTSTART is not always the first instance in the recurrence set,
> and an  EXRULE does not necessarily exclude the DTSTART. Consequently, a
> recurrence  rule does not necessarily generate the DTSTART as its first
> date/time.

But again, 4.8.5.2 states: 'The "DTSTART" defines the first instance in the 
recurrence set.'. I consider that a stronger statement than 'can be used to 
exlcude...'. As defined it 'always excludes the DTSTART'. There is nothing 
in the spec explaining how it would not do that, or how COUNT etc should be 
interpreted in that case.

The bottom line is this just re-emphasizes why EXRULE is a real problem and 
should be deprecated.

-- 
Cyrus Daboo

Date: Wed, 11 Oct 2006 11:59:32 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Lets deprecate EXRULE, Re: [Ietf-calsify] summary of jabber sessions and confirmation of	issues

Hi Reinhold,

--On October 11, 2006 5:16:28 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

>> Issue 25: The proposal now is to deprecate EXRULE.  Cyrus to kick off
>> discussion.  OPEN
>
> If we remove that confusing sentence from issue 14 and properly re-word
> the  issue in 13, it's clear that the DTSTART is not automatically
> generated by  the EXRULE, thus the DTSTART is not always excluded and the
> issue is solved.
>
> I'm fine with deprecating exrule (although I worked hard to implement
> multiple  exrules support it in libkcal...).

We can't do that because issue 13 cannot be resolved in the way you propose 
as per my pervious email.

The problem we have is this:

1) If we take the 2445 statement that DTSTART is always the first instance 
in a rule set, and say that applies to EXRULE, then the presence of ANY 
EXRULE will always exclude the DTSTART - so there is no way to define an 
EXRULE that does not exclude the DTSTART. This would force clients to use a 
'fake' DTSTART value that they know would be excluded, so that the actual 
first instance occurs when it should. Ugly!

2) If we say that DTSTART is not the first instance for the EXRULE set, 
then we have an inconsistency in the way COUNT & INTERVAL work in RRULE and 
EXRULE.

Because of this, and the fact that EXRULE is rarely used, I think we should 
deprecate its use in 2445bis. That means implementations MUST NOT generate 
EXRULE, but may choose to continue accepting EXRULE in whatever fashion 
they currently do.

-- 
Cyrus Daboo

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: CALSIFY Mailinglist <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation =?iso-8859-1?q?of=09issues?=
Date: Wed, 11 Oct 2006 17:50:22 +0200

Am Mittwoch, 11. Oktober 2006 17:37 schrieben Sie:
> Hi Reinhold,
>
> --On October 11, 2006 5:16:28 PM +0200 Reinhold Kainhofer
>
> <[email-masked]> wrote:
> > DTSTART;VALUE=DATE:20061011
> > RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
> > RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR
> >
> > will result in the event only happening on Oct 11, but not on any monday
> > or  any friday, which is not what I would expect. I wonder how different
> > implementations interpret this snipplet...
> > Intuitively, I would expect the event to happen on Oct 11, plus on the
> > next  one monday and on the next one friday.
>
> An instance representing the supplied DTSTART value is always present as
> per 4.8.5.4 (which says in the Description paragraph: 'The "DTSTART"
> property defines the first instance in the recurrence set.'). So a COUNT=1
> will only ever generate the DTSTART instance. So your 'intuitive'
> expectation is wrong.

On the other hand, section 4.8.5.2 about EXRULE (and section 4.8.5.1 about 
EXDATE) says that the EXRULE/EXDATE properties can be used to exlude the 
DTSTART. Notice the word *can* and "in such cases", which indicate that the 
DTSTART is not always automatically generated by an EXRULE.

So, the DTSTART is not always the first instance in the recurrence set, and an 
EXRULE does not necessarily exclude the DTSTART. Consequently, a recurrence 
rule does not necessarily generate the DTSTART as its first date/time.

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/

Date: Wed, 11 Oct 2006 11:48:33 -0400
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of	issues
Cc: [email-masked]

Hi Eliot,

--On October 11, 2006 5:39:37 PM +0200 Eliot Lear <[email-masked]> wrote:

> Thank you, Reinhold.  Let me simply ask the group whether the same time
> or 9:00am on Wednesdays would be possible?

Timezone?

-- 
Cyrus Daboo

Date: Wed, 11 Oct 2006 17:39:37 +0200
From: Eliot Lear <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of issues
Cc: [email-masked]

Thank you, Reinhold.  Let me simply ask the group whether the same time
or 9:00am on Wednesdays would be possible?

Eliot

Date: Wed, 11 Oct 2006 11:37:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>, [email-masked]
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of	issues

Hi Reinhold,

--On October 11, 2006 5:16:28 PM +0200 Reinhold Kainhofer 
<[email-masked]> wrote:

> DTSTART;VALUE=DATE:20061011
> RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
> RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR
>
> will result in the event only happening on Oct 11, but not on any monday
> or  any friday, which is not what I would expect. I wonder how different
> implementations interpret this snipplet...
> Intuitively, I would expect the event to happen on Oct 11, plus on the
> next  one monday and on the next one friday.

An instance representing the supplied DTSTART value is always present as 
per 4.8.5.4 (which says in the Description paragraph: 'The "DTSTART" 
property defines the first instance in the recurrence set.'). So a COUNT=1 
will only ever generate the DTSTART instance. So your 'intuitive' 
expectation is wrong.

-- 
Cyrus Daboo

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of issues
Date: Wed, 11 Oct 2006 17:24:53 +0200

Am Mittwoch, 11. Oktober 2006 17:16 schrieb Reinhold Kainhofer:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm really sorry that I'm not able to participate in the (apparently very
> productive) Tuesday jabber sessions, as we have a scientific presentation
> at our department every tuesday from 16:30 until 18:00...

The session log can still be read if you enter the chat room. 

Regards,

Oliver

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] summary of jabber sessions and confirmation of issues
Date: Wed, 11 Oct 2006 17:16:28 +0200

I'm really sorry that I'm not able to participate in the (apparently very 
productive) Tuesday jabber sessions, as we have a scientific presentation at 
our department every tuesday from 16:30 until 18:00...

Am Mittwoch, 11. Oktober 2006 09:20 schrieb Eliot Lear:
> Issue 5:  wording agreed.  CONSENSUS.

Fine with me.

> Issue 8:  no support for change.  CLOSE.

I'm also opposed to deprecating either P1D or PT24H. However, I propose to 
create an official FAQ that deals with lots of clarifications that come up on 
the mailing list and elsewhere.

E.g.
Q: What is the difference between DURATION:P1D and DURATION:PT24H?
A: In most cases there will not be a difference. The only difference happens 
when a daylight savings time switch occurs in that duration. In particular, 
the following snipplet will generate an event from Oct 28, 12:00 until Oct 
29, 12:00 (same time the next day, even though an additional hour is inserted 
at 03:00 for the switch to winter time):
  DTSTART;TZID=Europe/Vienna:20061028T120000
  DURATION:P1D
while the following snipplet generates an event from Oct 28, 12:00 until Oct 
29, 11:00 (since there is an additional hour at 03:00 on Oct 29)
  DTSTART;TZID=Europe/Vienna:20061028T120000
  DURATION:PT24H

- ----

A different issue is what should happen to the following event, where the end 
time does not exist. When does it end?
  DTSTART;TZID=Europe/Vienna:20060325T023000
  DURATION:P1D
As there is no 02:30 on March 26, 2006, in Europe, what is the end time of 
that event? Similarly for
  DTSTART;TZID=Europe/Vienna:20060325T023000
  DTEND;TZID=Europe/Vienna:20060326T023000
As the DTEND is a non-existing date/time, what should happen to the event?

> Issue 9:  dup of Issue 27 (which we are already working on) CLOSE.

Actually, Issue 9 contains two issues. The first one is a dupe of 27. The 
second is a little wording issue, but that's nitpicking and does not really 
need to be changed. 

- - -) Section 4.3.10 says:
   "If BYxxx rule part values are found which are beyond the available
   scope (ie, BYMONTHDAY=30 in February), they are simply ignored."

The "they" seems to refer to rule part values, which is not true.

E.g. take 
  DTSTART;VALUE=DATE:20060101
  RRULE:FREQ=MONTHLY;MYMONTHDAY=31

In February, the rule part value 31 for BYMONTHDAY is beyond the scope, but 
that value is not ignored (which would result in taking the day from DTSTART, 
thus there would be an occurence on Feb 1), but rather the resulting invalid 
date is ignored.

As I said, that's nitpicking, and I'm fine with closing the issue without any 
changes.

> Issue 10: Bernard will provide text - OPEN.

Currently RFC 2445 says:
> For cases where a "VEVENT" calendar component specifies a "DTSTART"
> property with a DATE data type but no "DTEND" property, the events
> non-inclusive end is the end of the calendar date specified by the
> "DTSTART" property.

I propose to change "end of the calendar date" to "begin of the day following 
the calendar date" in the text:

> For cases where a "VEVENT" calendar component specifies a "DTSTART"
> property with a DATE data type but no "DTEND" property, the events
> non-inclusive end is the begin of the day following the calendar date
> specified by the "DTSTART" property. 

The advantage is that we still have every end non-inclusive, and that the 
second from 23:59:59 to 00:00:00 is also still part of that event.

> Issue 11: Lots of chat.  Normative text is accurate, but some clarifying
> example is required.  Bernard will propose.  OPEN

Yes, the normative text is accurate, it's just not very clear how to apply the 
rules. In particular, the example given in the RFC does not depend on the 
correct order of the BY* evaluations.

> Issue 12: Duplicate of issue 11 CLOSE

Okay, just to clarify how to evaluate the RRULE for the timezones:
     DTSTART:19671029T020000
     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10

Each date/time is specified by 
     (year,month,day,hour,minute, second). 
In the beginning we start off with 
     (*,*,*,*,*,*). 
As FREQ is YEARLY, we loop through all years. For 2006, we have the 
restriction
     (2006,*,*,*,*,*). 
Now we evaluate BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,   
BYMINUTE, BYSECOND and BYSETPOS in that order. The BYMONTH adds the 
additional restriction
     (2006,10,*,*,*,*).
We don't have BYWEEKNO, BYYEARDAY or BYMONTHDAY, but BYDAY now says to take 
the last sunday that matches the restrictions above (i.e. the last sunday in 
october 2006, which is the 29th):
     (2006,10,29,*,*,*)
As we don't have any other BY* rules, we're finished. All missing pieces of 
the date/time are now taken from DTSTART:
    (2006,10,29,02,00,00)

So we end up with the correct date.

Similarly, for 
     DTSTART:19671029T020000
     RRULE:FREQ=MONTHLY;BYDAY=-1SU;BYMONTH=10
we loop through all months. Let's start in August 2006:
     (2006,08,*,*,*,*)
The BYMONTH=10 tells us to set the month to 10, but this conflicts with 
August, so no occurence is generated. Next in the loop is September 2006:
    (2006,09,*,*,*,*)
Again, the BYMONTH=10 conflicts with the already-existing restrictions. Next 
in the loop is October 2006:
     (2006,10,*,*,*,*)
The BYMONTH=10 can be set and does not conflict with the already existing 
restrictions. Next is BYDAY, which tells us to take the last sunday of all 
days that match the above restrictions (i.e. the last sunday in October 2006, 
which is the 29th):
    (2006,10,29,*,*,*)
Again, the times are taken from the DTSTART:
    (2006,10,29,02,00,00)
Next in our monthly loop is November, which again does not generate an 
occurence. Only the next october generates the next occurrence.

Thus, both rules produce exactly the same recurrence set. I propose to add 
several such clarifications to an official FAQ as proposed above. I'm willing 
to write them.

> Issue 13: Related to Issue 25.  Remove "if specified" (however there is
> discussion on the list about this) CONSENSUS

As I said on the list, simply removing the "if specified" changes the 
interpretation of RRULEs to results that one would not expect. E.g. an event 
with two rrules:

DTSTART;VALUE=DATE:20061011
RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=MO
RRULE:FREQ=WEEKLY;COUNT=1;BYDAY=FR

will result in the event only happening on Oct 11, but not on any monday or 
any friday, which is not what I would expect. I wonder how different 
implementations interpret this snipplet...
Intuitively, I would expect the event to happen on Oct 11, plus on the next 
one monday and on the next one friday.

I propose the following text:
  The value of the "DTSTART" property, if generated by the rule, counts as the
  first occurrence.

As the RFC says that duplicate date/time instances in the recurrence set are 
ignored (and thus particularly the value generated by the rrule), that text 
makes it clear, that they still count towards the COUNT.

> Issue 14: Related to Issue 25.  The text is not easily inserted into the
> doc, so more text is needed.  OPEN

I don't understand why the discussed sentence is in the RFC anyway.

Section "4.8.5.4 Recurrence Rule" says:

" The recurrence set is
   generated by considering the initial "DTSTART" property along with
   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
   within the iCalendar object. The "DTSTART" property defines the first
   instance in the recurrence set. ..." 

And later on we have:

"   The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
   property pair, specified within the iCalendar object defines the
   first instance of the recurrence. "

Isn't the same thing already said in the previous cited paragraph? If so, I 
propose to simply delete the sentence "The "DTSTART" and "DTEND" property 
pair ... instance in the recurrence set."

> Issue 16: Example needed.  Cyrus provided a cleaned up version of the
> example, but Bernard would like to see more text.  This issue remains open. 
> OPEN 

Sorry, I don't have any idea for a better formulation. 

> Issue 25: The proposal now is to deprecate EXRULE.  Cyrus to kick off
> discussion.  OPEN

If we remove that confusing sentence from issue 14 and properly re-word the 
issue in 13, it's clear that the DTSTART is not automatically generated by 
the EXRULE, thus the DTSTART is not always excluded and the issue is solved.

I'm fine with deprecating exrule (although I worked hard to implement multiple 
exrules support it in libkcal...).

Actually, while reading the recurrence description in RFC 2445, section 
4.8.5.4, I propose another clarification:

Current text:
   "The final recurrence set is generated
   by gathering all of the start date/times generated by any of the
   specified "RRULE" and "RDATE" properties, and excluding any start
   date/times which fall within the union of start date/times generated
   by any specified "EXRULE" and "EXDATE" properties."

Proposed text:
   "The final recurrence set is generated
   by gathering all of the date/times generated by any of the
   specified "DTSTART", "RRULE" and "RDATE" properties, and excluding any 
   date/times which fall within the union of date/times generated
   by any specified "EXRULE" and "EXDATE" properties."

Rationale: The current text sounds as if the only dates generated by RRULE or 
RDATE can be excluded by EXRULE or EXDATE. However, section 4.8.5.2 
explicitly says "The "EXRULE" property can be used to exclude the value 
specified in "DTSTART".".

And one more issue:
In section 4.3.10, RFC 2445 says:
"For example, within  a MONTHLY rule, +1MO (or simply 1MO) represents the 
first Monday within the month, whereas -1MO represents the last Monday of the
month." 

This is not true in general, only if no other BY* rule parts are given. E.g. 
in the RRULE
  RRULE:FREQ=MONTHLY;BYDAY=1MO;BYMONTHDAY=15,16,17,18,19,20,21
the BYDAY=1MO specifies the first monday in a month within the days numbered 
15, 16, 17, 18, 19, 20 or 21.

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/

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Wed, 11 Oct 2006 09:38:37 +0200
Subject: [Ietf-calsify] iCal event invitation: IETF-Calsify Jabber Session

--Apple-Mail-2--290992579
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has invited you to the iCal event: IETF-Calsify Jabber  
Session, scheduled for October 17, 2006 at 5:00 PM (Europe/Zurich).  
To accept or decline this invitation, click the link below.

--Apple-Mail-2--290992579
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20061011-093837.ics
Content-Disposition: attachment;
	filename=iCal-20061011-093837.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Zurich=0D=0A=
LAST-MODIFIED:20061011T073836Z=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20060326T010000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20061029T030000=0D=0ATZOFFSETTO:+0100=0D=0ATZOFFSETFROM:+0200=0D=0A=
TZNAME:CET=0D=0AEND:STANDARD=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070325T030000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0100=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
DURATION:PT1H=0D=0AATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";RSVP=3DTRUE:mailto:Ietf-calsify@osafound=0D=0A=20ation.org=0D=
=0ALOCATION:[email-masked]=0D=0ADTSTAMP:20061011T073831Z=0D=0A=
UID:E68B43F6-4A63-4462-A35D-83180D378825=0D=0ASEQUENCE:5=0D=0A=
DTSTART;TZID=3DEurope/Zurich:20061017T170000=0D=0ASUMMARY:IETF-Calsify=20=
Jabber=20Session=0D=0ADESCRIPTION:Agenda:\n\nDiscuss=20remaining=20open=20=
items.=20=20We'll=20continue=20fro=0D=0A=20m=20our=20session=20from=20=
last=20week.\n\nFor=20those=20looking=20for=20jabber=20software\,=0D=0A=20=
=20check=20http://www.jabber.org=20for=20locations.=20=20On=20the=20Mac=20=
both=20Adium=20and=20i=0D=0A=20Chat=20will=20do=20the=20job.=20=20I=20=
believe=20trillian=20will=20do=20it=20on=20the=20PC=20as=20will=20t=0D=0A=
=20he=20Google=20talk=20client\,=20but=20I=20don't=20have=20one\,=20so=20=
check=20the=20web=20site.\n\=0D=0A=20nTo=20use=20jabber=20you=20must=20=
have=20an=20account.=20=20These=20are=20available=20on=20talk.go=0D=0A=20=
ogle.com=20or=20you=20can=20use=20jabber.psg.com=20IF=20you=20upload=20a=20=
vCard=20during=20regi=0D=0A=20stration.=20=20This=20is=20all=20that=20=
Randy=20Bush=20asks\,=20as=20it=20is=20his=20generosity=20th=0D=0A=20at=20=
has=20made=20this=20service=20avaialble.=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A=

--Apple-Mail-2--290992579--

Date: Wed, 11 Oct 2006 09:20:25 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] summary of jabber sessions and confirmation of issues

Dear all,

We are generally enjoying jabber and getting a fair amount of work
done.  This means there will be another jabber session next Tuesday at
5:00pm CEST or 8:00am PDT.

Here is a summary of the past two jabber sessions, relating to open issues:

Issue 3:  clarification requested from Oliver.  OPEN.
Issue 5:  wording agreed.  CONSENSUS.
Issue 8:  no support for change.  CLOSE.
Issue 9:  dup of Issue 27 (which we are already working on) CLOSE.
Issue 10: Bernard will provide text - OPEN.
Issue 11: Lots of chat.  Normative text is accurate, but some clarifying
example is required.  Bernard will propose.  OPEN
Issue 12: Duplicate of issue 11 CLOSE
Issue 13: Related to Issue 25.  Remove "if specified" (however there is
discussion on the list about this) CONSENSUS
Issue 14: Related to Issue 25.  The text is not easily inserted into the
doc, so more text is needed.  OPEN
Issue 16: Example needed.  Cyrus provided a cleaned up version of the
example, but Bernard would like to see more
               text.  This issue remains open.  OPEN
Issue 25: The proposal now is to deprecate EXRULE.  Cyrus to kick off
discussion.  OPEN

Where you see "OPEN|CONSENSUS|CLOSE" these are subject to validation on
this list.

For further clarification as to the discussion, please see the log at
http://www3.ietf.org/meetings/ietf-logs/calsify.  Also, please feel free
to review the issue tracker, which can be found at
http://www.ofcourseimright.com/cgi-bin/roundup/calsify.

Thanks for your support.

Eliot

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Tue, 10 Oct 2006 18:41:41 +0200
Subject: [Ietf-calsify] iCal event invitation: Calendaring Lunch

--Apple-Mail-1--344808419
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has invited you to the iCal event: Calendaring Lunch,  
scheduled for November 6, 2006 at 11:30 AM (America/Los_Angeles). To  
accept or decline this invitation, click the link below.

--Apple-Mail-1--344808419
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20061010-184136.ics
Content-Disposition: attachment;
	filename=iCal-20061010-184136.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:America/Los_Angeles=0D=0A=
LAST-MODIFIED:20061010T164135Z=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20061029T090000=0D=0ATZOFFSETTO:-0800=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:PST=0D=0AEND:STANDARD=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070311T020000=0D=0ATZOFFSETTO:-0700=0D=0ATZOFFSETFROM:-0800=0D=0A=
TZNAME:PDT=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";RSVP=3DTRUE:mailto:Ietf-calsify@osafound=0D=0A=20ation.org=0D=
=0ALOCATION:TBD=0D=0ADTSTAMP:20061010T164126Z=0D=0A=
UID:6DD35238-5A4C-4CA1-AE64-6E553AD5F0AD=0D=0ASEQUENCE:7=0D=0A=
DTSTART;TZID=3DAmerica/Los_Angeles:20061106T113000=0D=0A=
SUMMARY:Calendaring=20Lunch=0D=0A=
DTEND;TZID=3DAmerica/Los_Angeles:20061106T124500=0D=0ADESCRIPTION:This=20=
is=20an=20informal=20event=20just=20prior=20to=20the=20working=20group=20=
me=0D=0A=20eting.=20=20Please=20RSVP=20to=20me=20if=20you=20are=20=
interested.=20=20I=20will=20post=20the=20locati=0D=0A=20on=20to=20those=20=
who=20are=20interested=20once=20I=20can=20figure=20it=20out.=0D=0A=
ORGANIZER;CN=3D"Eliot=20Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0A=
END:VCALENDAR=0D=0A=

--Apple-Mail-1--344808419--

From: Reinhold Kainhofer <[email-masked]>
Organization: FAM, Vienna University of Technology
To: [email-masked]
Subject: Re: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules
Date: Tue, 10 Oct 2006 17:49:56 +0200

Am Dienstag, 10. Oktober 2006 17:35 schrieb Bernard Desruisseaux:
> [ This issue was brought up by Reinhold on the ietf-calendar mailing list.
> ]
>
> In section 4.3.10 Recurrence Rule of RFC 2445 it says:
>  > The COUNT rule part defines the number of occurrences at which to
>  > range-bound the recurrence. The "DTSTART" property value, if
>  > specified, counts as the first occurrence.
>
> I would like to remove "if specified" given that DTSTART should be
> REQUIRED when either RRULE or EXRULE are present.
>
> NEW TEXT:
>  > The COUNT rule part defines the number of occurrences at which to
>  > range-bound the recurrence. The "DTSTART" property value counts as
>  > the first occurrence.

I don't think that this is what was intended. 
E.g. imagine an event with 

DTSTART;VALUE=DATE:20061010
RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=MO

This event will recur on October 10 and on the next two mondays (Oct 16 and 
23). With your proposed change, it will only occur on October 10 and on the 
next monday (Oct 16), which I would find quite counter-intuitive.

If the DTSTART mathes the RRULE, there is no difference (as the DTSTART in 
that case also counts towards the COUNT):

DTSTART;VALUE=DATE:20061010
RRULE:FREQ=WEEKLY;COUNT=2;BYDAY=TU

This will result in the event occuring on Oct 10 and 17. The "if specified" 
(in the sense "if it matches the RRULE") in the rfc is meant to clarify that 
the RRULE does not add Oct 17 and 24, but rather Oct 10 and 17.

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/

Date: Tue, 10 Oct 2006 11:35:35 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Issue 13: confusion in DTSTART text about "if specified" and BY rules

[ This issue was brought up by Reinhold on the ietf-calendar mailing list. ]

In section 4.3.10 Recurrence Rule of RFC 2445 it says:

 > The COUNT rule part defines the number of occurrences at which to
 > range-bound the recurrence. The "DTSTART" property value, if
 > specified, counts as the first occurrence.

I would like to remove "if specified" given that DTSTART should be
REQUIRED when either RRULE or EXRULE are present.

NEW TEXT:

 > The COUNT rule part defines the number of occurrences at which to
 > range-bound the recurrence. The "DTSTART" property value counts as
 > the first occurrence.

Cheers,
Bernard

Date: Tue, 10 Oct 2006 16:59:56 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] reminder... jabber starting on the hour (5:00pm CEST / 8:00am PDT)

[email-masked]

Eliot

Date: Mon, 09 Oct 2006 12:58:30 +0100
From: Alexey Melnikov <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
Cc: Calsify WG <[email-masked]>

Bernard Desruisseaux wrote:

> Alexey,
>
> I understand you "don't feel good about disallowing "method"
> with iCalendar stream containing multiple objects."

If the "method" is not present, this means that the message is not an 
iMIP message.
So for an iMIP message the "method" must be present.

The use case I am thinking about is batch replay of transactions. You 
can say that transactions might have different "method" values. But I 
would rather not prohibit something that might be useful in the future, 
if this doesn't cost anything (or almost nothing) for implementors.

> What should be done with the "method" parameter when the iCalendar
> stream is a sequence of iCalendar objects with the same or different
> METHOD values?

If a stream is a sequence of iCalendar objects with the same METHOD 
value, it is Ok to allow for "method" parameter.
If a stream is a sequence of iCalendar objects with different METHOD 
values, then this should be considered an error.

> While I don't understand your concern here, I'm open to other
> alternatives to close this (minor) issue. :-)

How about the following:

Old text:

 > The "method" parameter MUST be the same value as that
 > specified in the "METHOD" component property in the iCalendar object.
 > If one is present, the other MUST also be present.

Bernard's new text:

 > The "method" parameter MUST be specified only for iCalendar
 > stream that contains a single iCalendar object. The "method"
 > parameter MUST be the same value as that specified in the "METHOD"
 > component property in the iCalendar object. If one is present,
 > the other MUST also be present.
_
_My proposal:

 > The "method" parameter can be specified only for an iCalendar
 > stream that contains one or more iCalendar objects, all having
 > the same value of the "METHOD" component property. The "method"
 > parameter MUST be the same value as that specified in the "METHOD"
 > component property in the iCalendar object. For such iCalendar
 > streams, if one is present, the other MUST also be present.

 > It is an error if the "method" parameter is specified for an iCalendar
 > stream that contains multiple iCalendar objects with different
 > values of the "METHOD" component property.

Does this work?

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Sun, 8 Oct 2006 16:37:07 +0200
Subject: [Ietf-calsify] iCal event update: IETF-Calsify Jabber Session

--Apple-Mail-1--525081861
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has updated to the iCal event: IETF-Calsify Jabber  
Session, scheduled for October 10, 2006 at 5:00 PM (Europe/Zurich).  
To acknowledge this invitation, click the link below.

--Apple-Mail-1--525081861
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20061008-163700.ics
Content-Disposition: attachment;
	filename=iCal-20061008-163700.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Zurich=0D=0A=
LAST-MODIFIED:20061008T143659Z=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20060326T010000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20061029T030000=0D=0ATZOFFSETTO:+0100=0D=0ATZOFFSETFROM:+0200=0D=0A=
TZNAME:CET=0D=0AEND:STANDARD=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070325T030000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0100=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist";PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto=0D=0A=20=
:[email-masked]=0D=0ALOCATION:[email-masked]=0D=0A=
DTSTAMP:20061008T143644Z=0D=0AUID:F951B64A-448B-40D8-A9B4-B4BD3F09A612=0D=
=0ASEQUENCE:9=0D=0ADTSTART;TZID=3DEurope/Zurich:20061010T170000=0D=0A=
SUMMARY:IETF-Calsify=20Jabber=20Session=0D=0A=
DTEND;TZID=3DEurope/Zurich:20061010T180000=0D=0A=
DESCRIPTION:Agenda:\n\nDiscuss=20remaining=20open=20items.=20=20We'll=20=
continue=20fro=0D=0A=20m=20our=20session=20from=20last=20week.\n\nFor=20=
those=20looking=20for=20jabber=20software\,=0D=0A=20=20check=20=
http://www.jabber.org=20for=20locations.=20=20On=20the=20Mac=20both=20=
Adium=20and=20i=0D=0A=20Chat=20will=20do=20the=20job.=20=20I=20believe=20=
trillian=20will=20do=20it=20on=20the=20PC=20as=20will=20t=0D=0A=20he=20=
Google=20talk=20client\,=20but=20I=20don't=20have=20one\,=20so=20check=20=
the=20web=20site.\n\=0D=0A=20nTo=20use=20jabber=20you=20must=20have=20an=20=
account.=20=20These=20are=20available=20on=20talk.go=0D=0A=20ogle.com=20=
or=20you=20can=20use=20jabber.psg.com=20IF=20you=20upload=20a=20vCard=20=
during=20regi=0D=0A=20stration.=20=20This=20is=20all=20that=20Randy=20=
Bush=20asks\,=20as=20it=20is=20his=20generosity=20th=0D=0A=20at=20has=20=
made=20this=20service=20avaialble.=0D=0AORGANIZER;CN=3D"Eliot=20=
Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0AEND:VCALENDAR=0D=0A=

--Apple-Mail-1--525081861--

Date: Fri, 06 Oct 2006 16:09:17 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] we'll try jabber again next week

Tuesday 5:00pm CEST / 8:00am PDT, just like last week.  We closed a
bunch of issues.  Remember, we will use the calsify room on
jabber.ietf.org ([email-masked] for those using iChat, for
instance).  You can find a list of software on http://www.jabber.org,
and you can get an account via either Google or jabber.psg.com.  If you
use psg.com, be sure to upload your vCard (that's all Randy asks for
this free service).

Regards,

Eliot

Date: Wed, 04 Oct 2006 15:37:12 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Reinhold Kainhofer <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Value of missing DTEND when DTSTART; VALUE=DATE
Cc: [email-masked]

Reinhold,

Are you okay with the text proposed by Cyrus?

Thanks,
Bernard

Reinhold Kainhofer wrote:
> Am Dienstag, 3. Oktober 2006 20:54 schrieb Bernard Desruisseaux:
>> In section 4.6.1 Event Component of RFC 2445 it says:
>>> For cases where a "VEVENT" calendar component specifies a "DTSTART"
>>> property with a DATE data type but no "DTEND" property, the events
>>> non-inclusive end is the end of the calendar date specified by the
>>> "DTSTART" property.
>> The events "non-inclusive end" should be the start of the day following
>> the calendar date specified by the "DTSTART" property. Otherwise,
>> 23:59:59 would not be part of the event...
> 
> Mathematically speaking, 23:59:59 is NOT the end of the day (there's still one 
> whole second left!). 
> 23:59:59.99999999999999999999999999999999...=0:00:00.0 
> is the end of the day. That's the non-inclusive end, just as the RFC says.
> 
> 
> Cheers,
> Reinhold
> 

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.8.6.3 Trigger: Trigger relative to DATE value type
Date: Wed, 4 Oct 2006 13:05:01 +0200

Hi,

I don't know if there was further discussion on this.

Am Montag, 25. September 2006 20:16 schrieb Bernard Desruisseaux:
> In section 4.8.6.3 Trigger of RFC 2445 it says:
>  > Alarms specified in an event or to-do which is defined in terms of a
>  > DATE value type will be triggered relative to 00:00:00 UTC on the
>  > specified date. For example, if "DTSTART:19980205, then the duration
>  > trigger will be relative to19980205T000000Z.

Some paragraphs before it says:

>   Value Type: The default value type is DURATION. The value type can be
 >  set to a DATE-TIME value type, in which case the value MUST specify a
 >  UTC formatted DATE-TIME value.

Regards,

Oliver

-- 
Leben ist mehr als ... 
http://www.nak-nrw.de/p_6_4.html

From: Reinhold Kainhofer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Value of missing DTEND when DTSTART; VALUE=DATE
Date: Tue, 3 Oct 2006 22:35:29 +0200

Am Dienstag, 3. Oktober 2006 20:54 schrieb Bernard Desruisseaux:
> In section 4.6.1 Event Component of RFC 2445 it says:
> > For cases where a "VEVENT" calendar component specifies a "DTSTART"
> > property with a DATE data type but no "DTEND" property, the events
> > non-inclusive end is the end of the calendar date specified by the
> > "DTSTART" property.
>
> The events "non-inclusive end" should be the start of the day following
> the calendar date specified by the "DTSTART" property. Otherwise,
> 23:59:59 would not be part of the event...

Mathematically speaking, 23:59:59 is NOT the end of the day (there's still one 
whole second left!). 
23:59:59.99999999999999999999999999999999...=0:00:00.0 
is the end of the day. That's the non-inclusive end, just as the RFC says.

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/

Date: Tue, 03 Oct 2006 16:29:26 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Value of missing DTEND when DTSTART; VALUE=DATE
Cc: Calsify WG <[email-masked]>

Cyrus,

I like your text.

In addition to this change I will change the text before the last
example:

OLD TEXT:

 > The following is an example of the "VEVENT" calendar component
 > used to represent an anniversary that will occur annually. Since
 > it takes up no time, it will not appear as opaque in a search
 > for busy time; no matter what the value of the "TRANSP"
 > property indicates:

NEW TEXT:

 > The following is an example of the "VEVENT" calendar component
 > used to represent an anniversary that will occur annually:

I guess the assumption was that the event would last 0 second since
neither DTEND nor DURATION are specified, but that's not the case
when DTSTART is a DATE value.

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Bernard,
> 
> --On October 3, 2006 2:54:12 PM -0400 Bernard Desruisseaux 
> <[email-masked]> wrote:
> 
>> In section 4.6.1 Event Component of RFC 2445 it says:
>>
>>> For cases where a "VEVENT" calendar component specifies a "DTSTART"
>>> property with a DATE data type but no "DTEND" property, the events
>>> non-inclusive end is the end of the calendar date specified by the
>>> "DTSTART" property.
>>
>> The events "non-inclusive end" should be the start of the day following
>> the calendar date specified by the "DTSTART" property. Otherwise,
>> 23:59:59 would not be part of the event...
>>
>> I propose to simply change "non-inclusive" to "inclusive" in the text:
>>
>>> For cases where a "VEVENT" calendar component specifies a "DTSTART"
>>> property with a DATE data type but no "DTEND" property, the events
>>> inclusive end is the end of the calendar date specified by the
>>> "DTSTART" property.
> 
> Actually that whole section needs more revision because it does not say 
> anything about DURATION. At the very least, I think the updated text 
> should say:
> 
>    For cases where a "VEVENT" calendar component specifies a "DTSTART"
>    property with a DATE data type but no "DTEND" or "DURATION" property,
>    the event's duration is taken to be one day.
> 
> By specifying the behavior using duration instead of end, you get around 
> the whole inclusive/exclusive mess.
> 

Date: Tue, 03 Oct 2006 16:04:49 -0400
From: Cyrus Daboo <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>, Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.6.1 Event Component: Value of missing	DTEND when DTSTART; VALUE=DATE

Hi Bernard,

--On October 3, 2006 2:54:12 PM -0400 Bernard Desruisseaux 
<[email-masked]> wrote:

> In section 4.6.1 Event Component of RFC 2445 it says:
>
>> For cases where a "VEVENT" calendar component specifies a "DTSTART"
>> property with a DATE data type but no "DTEND" property, the events
>> non-inclusive end is the end of the calendar date specified by the
>> "DTSTART" property.
>
> The events "non-inclusive end" should be the start of the day following
> the calendar date specified by the "DTSTART" property. Otherwise,
> 23:59:59 would not be part of the event...
>
> I propose to simply change "non-inclusive" to "inclusive" in the text:
>
>> For cases where a "VEVENT" calendar component specifies a "DTSTART"
>> property with a DATE data type but no "DTEND" property, the events
>> inclusive end is the end of the calendar date specified by the
>> "DTSTART" property.

Actually that whole section needs more revision because it does not say 
anything about DURATION. At the very least, I think the updated text should 
say:

    For cases where a "VEVENT" calendar component specifies a "DTSTART"
    property with a DATE data type but no "DTEND" or "DURATION" property,
    the event's duration is taken to be one day.

By specifying the behavior using duration instead of end, you get around 
the whole inclusive/exclusive mess.

-- 
Cyrus Daboo

Date: Tue, 03 Oct 2006 14:54:12 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.6.1 Event Component: Value of missing DTEND when DTSTART; VALUE=DATE

In section 4.6.1 Event Component of RFC 2445 it says:

> For cases where a "VEVENT" calendar component specifies a "DTSTART"
> property with a DATE data type but no "DTEND" property, the events
> non-inclusive end is the end of the calendar date specified by the
> "DTSTART" property.

The events "non-inclusive end" should be the start of the day following
the calendar date specified by the "DTSTART" property. Otherwise,
23:59:59 would not be part of the event...

I propose to simply change "non-inclusive" to "inclusive" in the text:

> For cases where a "VEVENT" calendar component specifies a "DTSTART"
> property with a DATE data type but no "DTEND" property, the events
> inclusive end is the end of the calendar date specified by the
> "DTSTART" property.

Cheers,
Bernard

Date: Tue, 03 Oct 2006 13:09:53 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: [Ietf-calsify] Section 3.2: "method" parameter and sequence of iCalendar objects
Cc: Calsify WG <[email-masked]>

Alexey,

I understand you � don't feel good about disallowing "method"
with iCalendar stream containing multiple objects. �

What should be done with the "method" parameter when the iCalendar
stream is a sequence of iCalendar objects with the same or different
METHOD values?

While I don't understand your concern here, I'm open to other
alternatives to close this (minor) issue. :-)

Thanks,
Bernard

Alexey Melnikov wrote:
> Bernard Desruisseaux wrote:
> 
>> Alexey Melnikov wrote:
>>
>>> Bernard Desruisseaux wrote:
>>>
>>>> New text:
>>>>
>>>> > The "method" parameter MUST be specified only for iCalendar
>>>> > stream that contains a single iCalendar object.
>>>
>>> No, I think this is not correct. It is Ok to have multiple iCalendar 
>>> objects in an iCalendar stream, as long as they all have the same 
>>> METHOD property.
>>
>> Where is that defined?
> 
> It is nowhere prohibited :-).
> 
>> My reasoning is that if the iCalendar stream contains more than one
>> iCalendar object then it most likely doesn't describe a scheduling
>> transaction, and thus you probably shouldn't specify a "method"
>> parameter in the Content-Type header field.
> 
> I don't feel good about disallowing "method" with iCalendar stream 
> containing multiple objects.
> An implementation already has to check if the "method" parameter matches 
> what is specified in the calendar stream with a single object. It is not 
> difficult to check all objects.
> 
> Does anybody have some statistics on how frequently a calendar stream 
> can contain multiple calendar objects?
> 

Date: Tue, 03 Oct 2006 16:52:07 +0200
From: Eliot Lear <[email-masked]>
To: Oliver Block <[email-masked]>
Subject: Re: [Ietf-calsify] iCal event invitation: IETF-Calsify Jabber Session
Cc: [email-masked]

Oliver, on the Mac you can use Adium or iChat.  On the PC, I think both
Nitro and Trillian can be used, and perhaps others.  Check out
http://www.jabber.org/software/clients.shtml.

You'll need an account.  If you have a GMAIL account you can use
talk.google.com or you can create one on (I think) users.jabber.org.

Eliot

Oliver Block wrote:
> Hello Eliat,
>
> thanks for your invitation. Which client would I need? I never used Jabber.
>   
> Regards,
>
> Oliver
>
>
> Am Montag, 2. Oktober 2006 21:48 schrieb Eliot Lear:
>   
>> Eliot Lear has invited you to the iCal event: IETF-Calsify Jabber
>> Session, scheduled for October 3, 2006 at 5:00 PM (Europe/Zurich). To
>> accept or decline this invitation, click the link below.
>>     
>
>   

From: Oliver Block <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] iCal event invitation: IETF-Calsify Jabber Session
Date: Tue, 3 Oct 2006 16:42:43 +0200

Hello Eliat,

thanks for your invitation. Which client would I need? I never used Jabber.

Regards,

Oliver

Am Montag, 2. Oktober 2006 21:48 schrieb Eliot Lear:
> Eliot Lear has invited you to the iCal event: IETF-Calsify Jabber
> Session, scheduled for October 3, 2006 at 5:00 PM (Europe/Zurich). To
> accept or decline this invitation, click the link below.

-- 
Leben ist mehr als ...
http://www.nak-nrw.de/p_6_4.html

Date: Tue, 03 Oct 2006 09:26:34 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Tim Hare <[email-masked]>
Subject: Re: [Ietf-calsify] Issue 33: characters v. octets
Cc: [email-masked]

Tim,

I will go with "UTF-8 multi-octet sequence" instead of "character"
as was suggested by Mark for the line folding issue (i.e., Issue 1).

Thanks,
Bernard

Tim Hare wrote:
>  
> Section 6 should also say 'MUST not truncate', it needs to be the same in
> both places,  other than that I agree with the proposed change.
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Eliot Lear
> Sent: Monday, September 25, 2006 6:28 AM
> To: [email-masked]
> Subject: [Ietf-calsify] Issue 33: characters v. octets
> 
> <CHAIR HAT OFF>
> 
> After a long drawn out discussion on Issue 1 regarding breaking of lines, I
> would also like to close on Issue 33, which reads:
> 
> 
>> http://lists.osafoundation.org/pipermail/ietf-calsify/2006-August/0010
>> 78.html
>>
>> In section 4.8.4.7 Unique Identifier of RFC 2445 it says:
>>
>>  > Implementations MUST be able to receive and persist values of at  > 
>> least 255 characters for this property.
>>
>> And, in Section 6 Recommended Practices it also says:
>>
>>  > 6. An implementation can truncate a "SUMMARY" property value to 255
>>  >    characters.
>>
>> In both sections I propose to change "255 characters" to "255 octets".
> 
> 
> I propose the following alternative wording:
> 
> In section 4.8.4.7:
> 
>  > Implementations MUST be able to receive and persist values of at  > least
> 255 octets for this property, but MUST not truncate values  > in the middle
> of a character.
> 
> 
> In section 6:
> 
>  > 6. An implementation can truncate a "SUMMARY" property value to 255
>  >    octets, but should not truncate the property value in the middle
>  >    of a character.
> 
> 
> 
> If someone has appropriate wording to perhaps replace the word
> "character" with code point, that would be fine too.
> 
> _______________________________________________
> 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: Reinhold Kainhofer <[email-masked]>
To: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.2.13 Recurrence Identifier Range: Should we deprecate the RANGE parameter?
Date: Tue, 3 Oct 2006 09:46:44 +0200

Am Dienstag, 3. Oktober 2006 00:41 schrieb Caleb Richardson:
> Given an event with a daily recurrence at 1400 UTC and a newly created
> component with the following properties:
>
> RECURRENCE-ID;RANGE=THISANDFUTURE:20070401T140000Z
> DTSTART:20070401T133000Z
>
> Clearly this indicates that all occurrences of this event on and after
> April 1st 2007 should occur at 1330 UTC instead of 1400 UTC.
>
> Common sense dictates that future occurrences should NOT have their date
> set to April 1st 2007, but nowhere is this explicitly mentioned in RFC
> 2445.
[...]
> There seems to be a correlation between the recurrence FREQUENCY and
> what date-time fields should be applied to the master component, I think
> it would be beneficial to have these rules enumerated in RFC 2445 (if
> this is in fact the desired behavior).

Even worse: If you have a recurrence on every first monday of the month, and 
you shift it with RANGE=THISANDFUTURE to a different date (e.g. to a sunday), 
what is the recurrence for the future events? First monday? (Probably not, 
because that's the thing you changed). First sunday? (would make sense, but 
what about a recurrence every first monday and tuesday? Shall the days be 
shifted here, too? Both days or just the one from RECURRENCE-ID?) Day before 
the first monday? (can't be expressed in RRULE).
So, basically, the recurrence rule needs to be updated, too, which is 
practically impossible due to the huge complexity that is possible with 
rrules.

I'm all for removing the RANGE parameter. In KOrganizer and libkcal I also 
simply generate a new event with RELATED-TO set to the original event as a 
sibling. This makes life much easier, as you now have a completely separate 
event where the RRULE can be edited separately and the UIDs don't conflict.

Cheers,
Reinhold

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/

Date: Mon, 02 Oct 2006 16:18:04 -0700
From: Jeffrey Harris <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: Re: [Ietf-calsify] Section 4.2.13 Recurrence Identifier Range: Should we deprecate the RANGE parameter?

Hi Bernard,

+1 to deprecating RANGE.  While we lose some semantic power, it
simplifies life, and I think the major use cases for RANGE can be
handled by just re-issuing a truncated version of the old event plus a
new event.  This is what several clients already do.

Sincerely,
Jeffrey

Date: Mon, 02 Oct 2006 15:41:43 -0700
From: Caleb Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ietf-calsify] Section 4.2.13 Recurrence Identifier Range: Should we deprecate the RANGE parameter?
To: undisclosed-recipients: ;

A third issue:

Which portions of the DTSTART and DTEND properties specified as part of 
a component containing a RECURRENCE-ID should be applied to the "master 
component".

For example:

Given an event with a daily recurrence at 1400 UTC and a newly created 
component with the following properties:

RECURRENCE-ID;RANGE=THISANDFUTURE:20070401T140000Z
DTSTART:20070401T133000Z

Clearly this indicates that all occurrences of this event on and after 
April 1st 2007 should occur at 1330 UTC instead of 1400 UTC.

Common sense dictates that future occurrences should NOT have their date 
set to April 1st 2007, but nowhere is this explicitly mentioned in RFC 2445.

Furthermore, in the case of a YEARLY recurrence it makes sense to use 
the month and date (all future occurrences should be moved to April 
1st), but not the year.

There seems to be a correlation between the recurrence FREQUENCY and 
what date-time fields should be applied to the master component, I think 
it would be beneficial to have these rules enumerated in RFC 2445 (if 
this is in fact the desired behavior).

Caleb Richardson

Bernard Desruisseaux wrote:
> In section 4.2.13 Recurrence Identifier Range of RFC 2445 it says:
> 
>  > Description: The parameter can be specified on a property that
>  > specifies a recurrence identifier. The parameter specifies the
>  > effective range of recurrence instances that is specified by the
>  > property. The effective range is from the recurrence identified
>  > specified by the property. If this parameter is not specified an
>  > allowed property, then the default range is the single instance
>  > specified by the recurrence identifier value of the property. The
>  > parameter value can be "THISANDPRIOR" to indicate a range defined by
>  > the recurrence identified value of the property and all prior
>  > instances. The parameter value can also be "THISANDFUTURE" to
>  > indicate a range defined by the recurrence identifier and all
>  > subsequent instances.
> 
> I have two issues with the RANGE parameter:
> 
> 1- We should clarify the meaning of "all prior instances" and "all
>    subsequence instances". Should it be based on the RECURRENCE-ID
>    or the DTSTART value of the recurrence instances?
> 
> 2- If an iCalendar object defines (1) a "master component" that
>    defines a recurrence set, (2) an "exception component" that
>    makes use of RANGE=THISANDFUTURE, and (3) another "exception
>    component" for an instance subsequent to the "exception component"
>    that make use of RANGE=THISANDFUTURE. Should the 3rd component
>    that only makes reference to a specific recurrence instance
>    override the component with RANGE=THISANDFUTURE?
> 
> Anybody thinks the RANGE parameter is important?  Do we want to
> address the issues mentioned above or should we simply deprecate
> the RANGE parameter?
> 
> Cheers,
> Bernard
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Date: Mon, 02 Oct 2006 16:56:44 -0400
From: Bernard Desruisseaux <[email-masked]>
To: Calsify WG <[email-masked]>
Subject: [Ietf-calsify] Section 4.2.13 Recurrence Identifier Range: Should we deprecate the RANGE parameter?

In section 4.2.13 Recurrence Identifier Range of RFC 2445 it says:

 > Description: The parameter can be specified on a property that
 > specifies a recurrence identifier. The parameter specifies the
 > effective range of recurrence instances that is specified by the
 > property. The effective range is from the recurrence identified
 > specified by the property. If this parameter is not specified an
 > allowed property, then the default range is the single instance
 > specified by the recurrence identifier value of the property. The
 > parameter value can be "THISANDPRIOR" to indicate a range defined by
 > the recurrence identified value of the property and all prior
 > instances. The parameter value can also be "THISANDFUTURE" to
 > indicate a range defined by the recurrence identifier and all
 > subsequent instances.

I have two issues with the RANGE parameter:

1- We should clarify the meaning of "all prior instances" and "all
    subsequence instances". Should it be based on the RECURRENCE-ID
    or the DTSTART value of the recurrence instances?

2- If an iCalendar object defines (1) a "master component" that
    defines a recurrence set, (2) an "exception component" that
    makes use of RANGE=THISANDFUTURE, and (3) another "exception
    component" for an instance subsequent to the "exception component"
    that make use of RANGE=THISANDFUTURE. Should the 3rd component
    that only makes reference to a specific recurrence instance
    override the component with RANGE=THISANDFUTURE?

Anybody thinks the RANGE parameter is important?  Do we want to
address the issues mentioned above or should we simply deprecate
the RANGE parameter?

Cheers,
Bernard

Date: Mon, 02 Oct 2006 15:56:58 -0400
From: Cyrus Daboo <[email-masked]>
To: Eliot Lear <[email-masked]>, Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] jabber session next week?
Cc: [email-masked]

Hi Eliot,

--On October 2, 2006 9:47:29 PM +0200 Eliot Lear <[email-masked]> wrote:

> We would like to try a calsify jabber session tomorrow  (Tuesday)
> starting at 5:00pm CEST / 8:00am PDT.  This will be for one hour.  We
> will try this several times to close remaining issues.

Sorry am out all morning tomorrow.

If you want to reschedule for this week - Wednesday and Friday are bad for 
me, but Thursday morning (EST) is OK.

-- 
Cyrus Daboo

To: CALSIFY Mailinglist <[email-masked]>
From: Eliot Lear <[email-masked]>
Date: Mon, 2 Oct 2006 21:48:34 +0200
Subject: [Ietf-calsify] iCal event invitation: IETF-Calsify Jabber Session

--Apple-Mail-1--1024795179
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Eliot Lear has invited you to the iCal event: IETF-Calsify Jabber  
Session, scheduled for October 3, 2006 at 5:00 PM (Europe/Zurich). To  
accept or decline this invitation, click the link below.

--Apple-Mail-1--1024795179
Content-Transfer-Encoding: quoted-printable
Content-Type: text/calendar; x-unix-mode=0644; name=iCal-20061002-214831.ics
Content-Disposition: attachment;
	filename=iCal-20061002-214831.ics

BEGIN:VCALENDAR=0D=0APRODID:-//Apple=20Computer\,=20Inc//iCal=202.0//EN=0D=
=0AMETHOD:REQUEST=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A=
BEGIN:VTIMEZONE=0D=0ATZID:Europe/Zurich=0D=0A=
LAST-MODIFIED:20061002T194831Z=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20060326T010000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0000=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0ABEGIN:STANDARD=0D=0A=
DTSTART:20061029T030000=0D=0ATZOFFSETTO:+0100=0D=0ATZOFFSETFROM:+0200=0D=0A=
TZNAME:CET=0D=0AEND:STANDARD=0D=0ABEGIN:DAYLIGHT=0D=0A=
DTSTART:20070325T030000=0D=0ATZOFFSETTO:+0200=0D=0ATZOFFSETFROM:+0100=0D=0A=
TZNAME:CEST=0D=0AEND:DAYLIGHT=0D=0AEND:VTIMEZONE=0D=0ABEGIN:VEVENT=0D=0A=
ATTENDEE;CN=3D"CALSIFY=20=
Mailinglist":mailto:[email-masked]=0D=0A=
LOCATION:[email-masked]=0D=0ADTSTAMP:20061002T194822Z=0D=0A=
UID:F951B64A-448B-40D8-A9B4-B4BD3F09A612=0D=0ASEQUENCE:6=0D=0A=
DTSTART;TZID=3DEurope/Zurich:20061003T170000=0D=0ASUMMARY:IETF-Calsify=20=
Jabber=20Session=0D=0ADTEND;TZID=3DEurope/Zurich:20061003T180000=0D=0A=
DESCRIPTION:Agenda:\n\nDiscuss=20remaining=20open=20items.=0D=0A=
ORGANIZER;CN=3D"Eliot=20Lear":mailto:[email-masked]=0D=0AEND:VEVENT=0D=0A=
END:VCALENDAR=0D=0A=

--Apple-Mail-1--1024795179--

Date: Mon, 02 Oct 2006 21:47:29 +0200
From: Eliot Lear <[email-masked]>
To: Bernard Desruisseaux <[email-masked]>
Subject: Re: [Ietf-calsify] jabber session next week?
Cc: "[email-masked]" <[email-masked]>

Dear all,

We would like to try a calsify jabber session tomorrow  (Tuesday)
starting at 5:00pm CEST / 8:00am PDT.  This will be for one hour.  We
will try this several times to close remaining issues.

To get in, use your favorite jabber client and join the chat at
"[email-masked]".

Look for an invitation shortly.

Thanks,

Eliot

Date: Mon, 02 Oct 2006 08:17:44 +0200
From: Eliot Lear <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [Ietf-calsify] San Diego Meeting Slot

$CHAIR HAT ON$

Hi All,

I've just received word that we are currently slated for Monday November
6th from 1:00pm to 3:00pm.  This is opposite ENUM, EMU, MIP6, DCCP,
L2VPN, and the EDU WGs.  That's about as good as we could have asked
for, and so I'm expecting it to change, Murphy's Law being what it is. 
Let me stress this point: the IETF agenda is not set in stone until a
working group meeting starts.  Changes can occur up until the day of the
meeting.  It is still possible we could end up with a Friday morning slot.

For the brave, I've created a draft IETF calendar file that you may
subscribe to at  http://www.ofcourseimright.com/pages/lear/ietf67.ics. 
Bugs to me, not to the list.

And thanks for your participation,

Eliot