headers
Reinhold Kainhofer | 1 Jun 2005 17:34
Favicon
Gravatar

Questions regarding details of recurrence rules

Hi Guys,

I already sent this to ietf-calendar, but didn't get any definitive response 
so far. It may be a bit off-topic here, but I'm still hoping for an answer 
that helps me getting RFC 2445-RRULEs completely correct. For the most part, 
the RFC is clear to me, but there are some details that are not clear. I 
encountered them when I tested my new recurrence implementation which tries 
to implement every aspect of rrules, exrules, rdates and exdates.

The examples below sometimes might look like nitpicking, but I deliberately 
designed them to make little details of the RFC clear.

These issues might be a language problem on my side, or an unclear wording in 
the RFC. In any case, I'd like to know how the RFC really meant those things 
to work. 

1) About the BYDAY rule part: Let's start with some examples
  RRULE:FREQ=YEARLY;BYDAY=3SU
Okay, that's the third sunday of the year. But what exactly is
  RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2
Is this the fith sunday in the year, if it is also in february? Or is it the
fifth sunday in february? And it can be even less clear from rfc 2445. What
is
  RRULE:FREQ=YEARLY;BYDAY=5SU;BYMONTH=2,7
Is this the fifth sunday of the year, if it's in either February or July?
Or is it the fifth sunday of both february and July?
Or is it the fifth sunday of febrary and july together (i.e. in feb if the
 feb in a leap year has 5 sundays, or the first sunday of july in all other
 years)?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Thewlis | 13 Jun 2005 20:46
Favicon

Reminder -- Questionnaire on Implementation of Timezones -- Calconnect and Calsify

Dear Folks, This is a followup reminder to my e-mail of May 24th requesting assistance in responding to a Calconnect questionnaire on Timezones. Our original target date for responses was June 10th. We're received several responses but hope that with a little more time others will be able to help us. If you've not responded but have a calendaring implementation, we would appreciate it very much if you could take a few minutes to respond to our questionnaire. We've extended the target date another week to Monday, June 20th -- and so you don't have to rummage around and find my previous e-mail, the questionniare (which is in e-mail format so you can fill it out and e-mail it back) is included below. Thank you very much for your help. 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 · Dave.Thewlis <at> calconnect.org ------------------------------------------------------------------------------------------ Questionnaire on Timezones in iCalendar Introduction: This questionnaire is being used to determine support for iCalendar (RFC2445) timezone support. The specific sections in RFC2445 that are being queried are: 4.6.5 Time Zone Component 4.8.2.4 Date/Time Start 4.8.3 Time Zone Component Properties ( and sub-sections ) 4.8.5.3 Recurrence Date/Times 4.8.5.4 Recurrence Rule 4.8.7.3 Last Modified 4.8.8.1 Non-standard Properties These may involve reference to other sections. How to answer: Please copy the text from the '-------' divider below to the end of this message into a new message and address it to: <mailto:questionnaire <at> calconnect.org> To fill it out: For 'y/n/o': 'y' means yes 'n' means no 'o' means other or not applicable Delete two letters to leave the one for your answer. If you have specific comments you can add about your answers, please do so at the end and reference the question number to which the comment applies. For _____________________: enter text for the answer. ------- Product Details: P1: Product/Implementation Name: _____________________ Components supported: Consume Produce Q1: VTIMEZONE y/n/o y/n/o Q1.1: STANDARD y/n/o y/n/o Q1.2: DAYLIGHT y/n/o y/n/o Properties supported: In VTIMEZONE Consume Produce Q2.1: TZID y/n/o y/n/o Q2.2: LAST-MODIFIED y/n/o y/n/o Q2.3: TZURL y/n/o y/n/o Q2.4: XPROP y/n/o y/n/o In STANDARD Consume Produce Q3.1: DTSTART y/n/o y/n/o Q3.2: TZOFFSETTO y/n/o y/n/o Q3.3: TZOFFSETFROM y/n/o y/n/o Q3.4: COMMENT y/n/o y/n/o Q3.5: RDATE y/n/o y/n/o Q3.6: RRULE y/n/o y/n/o Q3.7: TZNAME y/n/o y/n/o Q3.8: XPROP y/n/o y/n/o In DAYLIGHT Consume Produce Q4.1: DTSTART y/n/o y/n/o Q4.2: TZOFFSETTO y/n/o y/n/o Q4.3: TZOFFSETFROM y/n/o y/n/o Q4.4: COMMENT y/n/o y/n/o Q4.5: RDATE y/n/o y/n/o Q4.6: RRULE y/n/o y/n/o Q4.7: TZNAME y/n/o y/n/o Q4.8: XPROP y/n/o y/n/o General: Q5: Do you always send DATE-TIME values with a timezone? y/n/o Q6: Do you always send DATE-TIME values in UTC or floating? y/n/o Q7: Do you provide a standard set of timezones built-in to your product? y/n/o if yes to Q7, then { Q8: Where did you get your timezone definitions? _____________________ Q9: How many timezone definitions do you have? _____________________ Q10: Do you have a special naming scheme for TZIDs, and if so what is it? _____________________ Q11: Do you provide a mechanism for updating built-in timezones? y/n/o if yes to Q11, then { Q12: Do you adjust future times to account for timezone definition changes? y/n/o } } Q13: Do you accept and use timezone definitions from imported iCalendar data? y/n/o if yes to Q13, then { Q14: Do you attempt to merge timezone definitions with the same TZID when importing iCalendar data? y/n/o } Q15: When exporting timezones in iCalendar data (either to a file or via iTIP) do you send the entire timezone definition or just the set of dates needed for coverage of the event? _____________________ Q16: Would you use timezone definitions from a standard timezone registry if one were created? y/n/o Q17: What problems would be involved in changing a timezone definition if DST was changed at some point in the future? _____________________ C1: Comments on specific answers (include Q number for cross-reference to original question): _____________________ C2: Comments on the format and ease of use of this questionnaire: _____________________ C3: Are there any additional questions we should be asking, and if so what are they? _____________________ 

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |
headers
Doug Royer | 19 Jun 2005 05:45

iCal-Basic -03 has been submitted.


I made the changes to DURATION that was discussed on the CALSIFY mailing
list and submitted them to the IETF. The changes are in :

	4.3.6  Duration
	4.10.3  Recurrence Date/Times

Copies at:

	http://inet-consulting.com/draft-royer-ical-basic-03.txt

	http://inet-consulting.com/draft-royer-ical-basic-03.html

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards
Attachment (Doug.vcf): text/x-vcard, 373 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 2 comments |
headers
Doug Royer | 19 Jun 2005 06:10

VERSION value in iCal-Basic


It is by belief that iCal-Basic is compatible to implementations.
That is the changes are clarifying existing components, properties,
and parameters and reduces the number of them.

I believe that it is possible for an RFC-2445 implementation
to have generated an iCal-Basic object (except new properties
which it would ignore per 2445).

So, I am proposing that iCal-Basic have a VERSION value
of:

	VERSION:2.0;2.1

Specifying that it is newer (2.1) and can be read by existing (2.0)
parsers and implementations.

There is no change to the 2445 VERSION property needed to support this
value. The existing 2445 VERSION property supports a range
of VERSION property values.

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards
Attachment (Doug.vcf): text/x-vcard, 373 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 3 comments |
headers
Reinhold Kainhofer | 19 Jun 2005 10:55
X-Face
Favicon
Gravatar

Re: VERSION value in iCal-Basic

Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> It is by belief that iCal-Basic is compatible to implementations.
> That is the changes are clarifying existing components, properties,
> and parameters and reduces the number of them.
>
> I believe that it is possible for an RFC-2445 implementation
> to have generated an iCal-Basic object (except new properties
> which it would ignore per 2445).
>
> So, I am proposing that iCal-Basic have a VERSION value
> of:
>
> 	VERSION:2.0;2.1
>
> Specifying that it is newer (2.1) and can be read by existing (2.0)
> parsers and implementations.
>
> There is no change to the 2445 VERSION property needed to support this
> value. The existing 2445 VERSION property supports a range
> of VERSION property values.

And since calsify is about using only what is supported by most 
implementations: How many implementations actually support this range?  My 
guess is approximately 0. 
I wonder how implementations behave when they encounter such a VERSION? If 
they accept it and parse it, then fine. But I suspect that there are 
implementations out there that compare the version string with "2.0" and 
produce an error message otherwise. This should not happen, of course.

At least libkcal (KDE's calendar library including support for iCalendar) 
fails with such a VERSION...
Mozilla calendar seems to ignore the VERSION altogether (but hangs while 
importing such a file, no idea what's the exact reason).
And Evolution also ignores the VERSION completely (i.e. if the version is 
"4.0", evolution also imports it just fine... Which it shouldn't, I guess?)

So far, there was no other calendar version that tried to be compatible with 
2445, so this was a working approach, but with calsify things change...

Reinhold

--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: reinhold <at> kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 2 comments |
headers
Doug Royer | 19 Jun 2005 21:43

Re: VERSION value in iCal-Basic


After looking into it, Mozilla uses libical.
So  filed bug:

	https://bugzilla.mozilla.org/show_bug.cgi?id=298177

Reinhold Kainhofer wrote:
> Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> 
>>It is by belief that iCal-Basic is compatible to implementations.
>>That is the changes are clarifying existing components, properties,
>>and parameters and reduces the number of them.
>>
>>I believe that it is possible for an RFC-2445 implementation
>>to have generated an iCal-Basic object (except new properties
>>which it would ignore per 2445).
>>
>>So, I am proposing that iCal-Basic have a VERSION value
>>of:
>>
>>	VERSION:2.0;2.1
>>
>>Specifying that it is newer (2.1) and can be read by existing (2.0)
>>parsers and implementations.
>>
>>There is no change to the 2445 VERSION property needed to support this
>>value. The existing 2445 VERSION property supports a range
>>of VERSION property values.
> 
> 
> And since calsify is about using only what is supported by most 
> implementations: How many implementations actually support this range?  My 
> guess is approximately 0. 
> I wonder how implementations behave when they encounter such a VERSION? If 
> they accept it and parse it, then fine. But I suspect that there are 
> implementations out there that compare the version string with "2.0" and 
> produce an error message otherwise. This should not happen, of course.
> 
> At least libkcal (KDE's calendar library including support for iCalendar) 
> fails with such a VERSION...
> Mozilla calendar seems to ignore the VERSION altogether (but hangs while 
> importing such a file, no idea what's the exact reason).
> And Evolution also ignores the VERSION completely (i.e. if the version is 
> "4.0", evolution also imports it just fine... Which it shouldn't, I guess?)
> 
> So far, there was no other calendar version that tried to be compatible with 
> 2445, so this was a working approach, but with calsify things change...
> 
> Reinhold
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify <at> osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards
Attachment (Doug.vcf): text/x-vcard, 373 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |
headers
Doug Royer | 19 Jun 2005 21:25

Re: VERSION value in iCal-Basic


Reinhold Kainhofer wrote:
> Am Sonntag, 19. Juni 2005 06:10 schrieb Doug Royer:
> 
>>It is by belief that iCal-Basic is compatible to implementations.
>>That is the changes are clarifying existing components, properties,
>>and parameters and reduces the number of them.
>>
>>I believe that it is possible for an RFC-2445 implementation
>>to have generated an iCal-Basic object (except new properties
>>which it would ignore per 2445).
>>
>>So, I am proposing that iCal-Basic have a VERSION value
>>of:
>>
>>	VERSION:2.0;2.1
>>
>>Specifying that it is newer (2.1) and can be read by existing (2.0)
>>parsers and implementations.
>>
>>There is no change to the 2445 VERSION property needed to support this
>>value. The existing 2445 VERSION property supports a range
>>of VERSION property values.
> 
> 
> And since calsify is about using only what is supported by most 
> implementations: How many implementations actually support this range?  My 
> guess is approximately 0. 

By 'this range', do you mean the one that I am proposing as a new one?

> I wonder how implementations behave when they encounter such a VERSION? If 
> they accept it and parse it, then fine. But I suspect that there are 
> implementations out there that compare the version string with "2.0" and 
> produce an error message otherwise. This should not happen, of course.

I do not think we have a choice. Mandating that we never use all of
the VERSION property value types simply because some did not do it
correctly will keep iCal from never being fixed.

For those that ignore it, it will not matter ether way.

For those that look at it and do not support CALSIFY,
it should not matter as they also support 2.0.

For those that support CALSIFY, they now know what to expect.

For those that crash or hang - well that was going to happen at
some point anyway in recent time as that was the entire purpose
of VERSION is to allow content type version control.

> At least libkcal (KDE's calendar library including support for iCalendar) 
> fails with such a VERSION...

Libical is open source so that is easy to fix.

> Mozilla calendar seems to ignore the VERSION altogether (but hangs while 
> importing such a file, no idea what's the exact reason).
> And Evolution also ignores the VERSION completely (i.e. if the version is 
> "4.0", evolution also imports it just fine... Which it shouldn't, I guess?)

I follow the Mozilla development. It will also be an easy fix.

> So far, there was no other calendar version that tried to be compatible with 
> 2445, so this was a working approach, but with calsify things change...

I think we agree. We need to start fixing things so that we have more
compatibility.

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards
Attachment (Doug.vcf): text/x-vcard, 373 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |
headers
Tim Hare | 20 Jun 2005 05:04
Picon

Re: iCal-Basic -03 has been submitted.

Doug, is there anywhere I can find the XML versions of these and the RFCs?

Thanks

At 11:45 PM 6/18/2005, you wrote:

>I made the changes to DURATION that was discussed on the CALSIFY mailing
>list and submitted them to the IETF. The changes are in :
>
>         4.3.6  Duration
>         4.10.3  Recurrence Date/Times
>
>
>Copies at:
>
>         http://inet-consulting.com/draft-royer-ical-basic-03.txt
>
>         http://inet-consulting.com/draft-royer-ical-basic-03.html
>
>--
>
>Doug Royer                     | http://INET-Consulting.com
>-------------------------------|-----------------------------
>
>               We Do Standards - You Need Standards
>
>
>
>
>
>_______________________________________________
>Ietf-calsify mailing list
>Ietf-calsify <at> osafoundation.org
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Tim Hare
Interested Bystander, Non-Inc.
Permalink | Reply | 1 comment |
headers
Doug Royer | 20 Jun 2005 06:04

Re: iCal-Basic -03 has been submitted.

http://inet-consulting.com/draft-royer-ical-basic-03.xml

Tim Hare wrote:
> Doug, is there anywhere I can find the XML versions of these and the RFCs?
> 
> Thanks
> 
> At 11:45 PM 6/18/2005, you wrote:
> 
>> I made the changes to DURATION that was discussed on the CALSIFY mailing
>> list and submitted them to the IETF. The changes are in :
>>
>>         4.3.6  Duration
>>         4.10.3  Recurrence Date/Times
>>
>>
>> Copies at:
>>
>>         http://inet-consulting.com/draft-royer-ical-basic-03.txt
>>
>>         http://inet-consulting.com/draft-royer-ical-basic-03.html
>>
>> -- 
>>
>> Doug Royer                     | http://INET-Consulting.com
>> -------------------------------|-----------------------------
>>
>>               We Do Standards - You Need Standards
>>
>>
>>
>>
>>
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify <at> osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> 
> 
> Tim Hare
> Interested Bystander, Non-Inc.
> 
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify <at> osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards
Attachment (Doug.vcf): text/x-vcard, 373 bytes
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
Permalink | Reply | 0 comments |
headers
Mike Douglass | 21 Jun 2005 17:37
Picon
Favicon

email alarms + description

RFC 2445 states (4.6.6) that the description property is required for an 
email alarm and will be used for the message body.

I'd prefer to see this as an optional property.

I'm implementing automatic mailing of (public) events to subscribed 
users and I'll probably do so by setting alarms on the events.

An appropriate message body is probably a displayable form of the event, 
with the actual event as an ics attachment.

I could populate all the alarm objects with the text form of the event 
but that's a bit wasteful. In any case I'd like the user to be able to 
signify the default mode by just leaving out the property.

The same could be said of the alarm summary. By default I'd fill it with 
the event summary.

--

-- 

Mike Douglass                           douglm <at> rpi.edu
Senior Systems Programmer
Communication & Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Permalink | Reply | 1 comment |

Gmane