2.1.  iTIP

2.2.  Rules and Rdates

RDATE is not supported at all (WHY?)

The iCalendar Recurrence rule section is very elaborate. I’m not aware of any product that conforms to it fully. Specifically, most products recognize only one RRULE and the others are ignored.

There is more than one way to specify recurrences. For example, we can specify a daily event as a FREQ=WEEKLY event with weekday = su, mo…​sa or as a FREQ=DAILY. It is relatively easy to implement a recurrence engine to generate events using the rules, but we find it hard to recognize it as a daily event to be displayed in User Interface.

What is the acceptability of interpreting one rule as another (e.g. reinterpret yearly as every 12 months repeat)?

No support for multiple RRULEs.

No support for EXRULEs.

Cannot modify the RRULE attribute (But RDATEs and EXDATEs can be added).

No support/limited support for these attributes: INFINITE, SECONDLY.

Vendor supports a special recurrence option for monthly meetings where an instance that falls on a weekend can be shifted to a weekday, either the preceding Friday, the following Monday, or whichever is closer. There is no way to sufficiently represent this in iCalendar. Hypothetically, a complex series of RRULEs can come close, but in cases where the adjustment would cross a month boundary there is no recourse.

Vendor is using a lot the RECURRENCE-ID / UID identification in data model to represent “detached” events, specialization for a given occurrence in a recurrence. This is apparently a much debated point in the interpretation of the specification. Vendor would like to stress the fact that iTIP support is great for invitation interoperability, but the first level should be even before invitations handling, just representation of a given calendar (“PUBLISH” support) so entire calendars can be published, stored, subscribed and imported.

Some other problematic points with recurrences, as seen by Vendor:

2.3.  Date handling

DTEND property was not well defined. For example, if we have event with DTSTART=20040404T100000 and DURATION=PT2H, it is not clear if the DTEND should be 120000 or 115900. We have seen iCalendars with both the conventions.

All times are written in UTC (even when the event/todo has an RRULE) — (WHY?)

2.4.  Timezones

Though not directly linked to recurrences, the timezone is one of most difficult part to implement and least useful for majority of users. Many users just use one timezone.

The big piece of hard functionality from 2445 that vendor hasn’t implemented is timezones.

Standard C library APIs deal well with only two timezones: UTC, and the local timezone (whatever that is). So, vendor’s library works well in these two cases, including with RRULEs that cross DST shifts. Vendor needs to implement a date-time abstraction that uses timezones as specified by VTIMEZONE. Vendor Vendor hasn’t had the time yet. Suspects that the widespread lack of good APIs to deal with timezones will be the biggest interop headache for many implementations. But, vendor feels that we can’t take timezones out of the spec, they are critical to how time is measured/used, and we need a protocol that will work properly between CUAs in various timezones. This is hard, but necessary.

Vendor confused by 4.6.5.c and posted two possible answers:

2.5.  CPL

Vendor implements a subset of RFC 2445, primarily RRULE reoccurrence to do time handling as specified in CPL in CPL (RFC 3880) — which in turn refers to RFC 2445 for it’s implementation. CPL is a script language which allows for the declaration of complex call forwarding behaviors, in IP telephony systems.

2.6.  Sequence Number

Vendor has not seen any product that uses the sequence number field correctly.

2.7.  vTo Dos and vJournal

Partial support for VTODOs (Intending on improving it).

Support for VJOURNALs in our internal API but not in iCalendar.

Vendor does not support VJOURNAL (little customer interest)

2.8.  General Comments

It’s not clear if the questions are for reading or for writing Vendor’s product really doesn’t implement an iCalendar protocol.

Vendor licenses its operating system as a platform for handset manufacturers to build their products with. The answers to the questionnaire describe what conformance is enabled by the PIM data stores provided in a particular version of the vendor’s operating system Other versions do not provide iCalendar parsing/generation or RFC 2446 implementation — this functionality will be provided by handset manufacturers.

Vendor has created a toolkit, which at its lowest level is built on an RFC 2425 encoder/decoder, so it’s possible to encode ANYTHING. An app built on this toolkit may encode according to the MUST rules, or may not, so many of the questions don’t really apply. You can do it right, or you can do it wrong, and on decoding, vendor tries and be liberal in what is accepted. So, most of answers are either OTHER or NO. Despite this, vendor feels compliance is pretty good (in the things implemented), it’s just that it’s very hard to write a flexible toolkit that makes it impossible to generate calendars that break the rules.

Lots of stuff vendor hasn’t done are easy, just haven’t had the time or need for them yet.

In general, vendor does not always return errors for incorrect data input. However, they consume correct data properly, and produce right data in most of the above cases.

Vendor has always considered it unusual that monthly recurrence rules that might fall outside the range of shorter months result in the instance being skipped. Vendor actually forbids such a meeting, but if iCalendar is to allow such a recurrence rule, it should follow the lead of many other applications and pull the instance back to the last day of the month. Currently, it’s just a little silly. If a company’s employees get paid on the 15th and 30th of every month, shouldn’t my iCalendar-compliant accounting application be capable of doing “the right thing” in February?

Vendor’s resource scheduler product does not accept iCal documents, only generates them. Currently does not create recurrence data.

Vendor’s library provides applications with support for recurrences mainly in three areas:

Everything else is expected to be handled by the application.

More tests are needed. This is a direct consequence of the extreme complexity of the specification and the many corner cases that need to be tested.
(What are the complex areas and what corner cases need to be flushed out?)

4.1.  Part 1. Product/Implementation being reported

Please specify the product or implementation name, your name, and your e-mail address. We will contact you via e-mail if we have any questions or are unclear about any of your responses.

4.2.  Part 2. Specific Implementation Information

This table contains elements for specific rules from RFC 2445. For each one, please indicate whether the implementation does (Yes) or does not (No) conform to the stated rule. If you have comments, issues or questions about this rule please enter in the Comment line under the rule.

RFC 2445 — iCalendar elements
4.3.10.a Recurrence Rule ○ Yes ○ No ○ Other	MUST	Individual rule parts MUST only be specified once.
4.3.10.b Recurrence Rule ○ Yes ○ No ○ Other	MUST	The FREQ rule part identifies the type of recurrence rule. This rule part MUST be specified in the recurrence rule.
4.3.10.c Recurrence Rule ○ Yes ○ No ○ Other	MUST	If UNTIL is specified as a date-time value, then it MUST be specified in a UTC time format.
4.3.10.d Recurrence Rule ○ Yes ○ No ○ Other	MUST	BYSETPOS MUST only be used in conjunction with another BYxxx rule part.
4.6.1.a Event Component ○ Yes ○ No ○ Other	MUST NOT	The following are optional but MUST NOT occur more than once: class / created / description / dtstart / geo / last-mod / location / organizer / priority / dstamp / seq / status / summary / transp / uid / url / recurid.
4.6.1.b Event Component ○ Yes ○ No ○ Other	MAY	The following are optional and MAY occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-pro.
4.6.2.a To-do Component ○ Yes ○ No ○ Other	MUST NOT	The following are optional, but MUST NOT occur more than once: class / completed / created / description / dstamp / dtstart / geo / last-mod / location / organizer / percent / priority / recurid / seq / status / summary / uid / ur.
4.6.2.b To-do Component ○ Yes ○ No ○ Other	MAY	The following are optional, and MAY occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-pro.
4.6.3.a Journal Component ○ Yes ○ No ○ Other	MUST NOT	The following are optional, but MUST NOT occur more than once: class / created / description / dtstart / dstamp / last-mod / organizer / recurid / seq / status / summary / uid / url.
4.6.3.b Journal Component ○ Yes ○ No ○ Other	MAY	The following are optional, and MAY occur more than once: attach / attendee / categories / comment / contact / exdate / exrule / related / rdate / rrule / rstatus / x-pro.
4.6.4.a Free/Busy Component ○ Yes ○ No ○ Other	MUST NOT	The recurrence properties (’RRULE’,’EXRULE’,’RDATE’,’EXDATE’) are not permitted within a ‘VFREEBUSY’ calendar component. Any recurring events are resolved into their individual busy time periods using the ‘FREEBUSY’ property.
4.6.5.a Time Zone Component ○ Yes ○ No ○ Other	MUST	The ‘VTIMEZONE’ calendar component MUST be present if the iCalendar object contains an RRULE that generates dates on both sides of a time zone shift.
4.6.5.b Time Zone Component ○ Yes ○ No ○ Other	MAY	A ‘VTIMEZONE’ calendar component MAY be present if the iCalendar object does not contain an RRULE that generates dates on both sides of a time zone shift.
4.6.5.c Time Zone Component ○ Yes ○ No ○ Other	MUST	If an RRULE that generates dates on both sides of a time zone shift is present, there MUST be valid time zone information for all recurrence instances.
4.6.6.a Alarm Component ○ Yes ○ No ○ Other	MUST NOT	‘DURATION’ and ‘REPEAT’ are both optional, and MUST NOT occur more than once each, but if one occurs, so MUST the other.
4.6.6.b Alarm Component ○ Yes ○ No ○ Other	MUST	A definition of an alarm with a repeating trigger MUST include both the ‘DURATION’ and ‘REPEAT’ properties.
4.6.6.c Alarm Component ○ Yes ○ No ○ Other	MUST	Both ‘DURATION’ and ‘REPEAT’ properties MUST be present in order to specify a repeating alarm. If one of these two properties is absent, then the alarm will not repeat beyond the initial trigger.
4.8.4.4.a Recurrence ID ○ Yes ○ No ○ Other	MUST	If the value of the ‘DTSTART’ property is a ‘DATE’ type value, then the value MUST be the calendar date for the recurrence instance.
4.8.4.4.b Recurrence ID ○ Yes ○ No ○ Other	MUST NOT	The following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATE-TIME” / “DATE”), tzidparam, rangeparam.
4.8.4.4.c Recurrence ID ○ Yes ○ No ○ Other	MAY	The following are optional, and MAY occur more than once: xparam.
4.8.5.1.a Exception Date/Times ○ Yes ○ No ○ Other	MUST	The “EXDATE” property can be used to exclude the value specified in “DTSTART”. However, in such cases the original “DTSTART” date MUST still be maintained by the calendaring and scheduling system because the original “DTSTART” value has inherent usage dependencies by other properties such as the “RECURRENCE-ID”.
4.8.5.1.b Exception Date/Times ○ Yes ○ No ○ Other	MUST NOT	The following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATE-TIME” / “DATE”), tzidparam.
4.8.5.1.c Exception Date/Times ○ Yes ○ No ○ Other	MAY	The following is optional, and MAY occur more than once: xparam.
4.8.5.3.a Recurrence Date/Times ○ Yes ○ No ○ Other	MUST NOT	The following are optional, but MUST NOT occur more than once: “VALUE” “=” (“DATE-TIME” / “DATE” / “PERIOD”), tzidparam.
4.8.5.3.b Recurrence Date/Times ○ Yes ○ No ○ Other	MAY	The following is optional, and MAY occur more than once: xparam.
4.8.5.4.a Recurrence Rule ○ Yes ○ No ○ Other	MUST	Any duration associated with the iCalendar object applies to all members of the generated recurrence set. Any modified duration for specific recurrences MUST be explicitly specified using the “RDATE” property.
4.8.7.4.a Sequence Number ○ Yes ○ No ○ Other	MUST	When the “Organizer” makes changes to one of the following properties, the sequence number MUST be incremented: “DTSTART”, “DTEND”, “DUE”, “RDATE”, “RRULE”, “EXDATE”, “EXRULE”, “STATUS”.
RFC 2446 — iTIP elements
3.2.4.a VEVENT CANCEL ○ Yes ○ No ○ Other	MUST	To cancel the complete range of a recurring event, the “UID” property value for the event MUST be specified and a “RECURRENCE-ID” MUST NOT be specified in the “CANCEL” method.
3.2.4.b VEVENT CANCEL ○ Yes ○ No ○ Other	MUST	In order to cancel an individual instance of the event, the “RECURRENCE-ID” property value for the event MUST be specified in the “CANCEL” method.
3.2.4.c VEVENT CANCEL ○ Yes ○ No ○ Other	MUST	Cancelling multiple VEVENT instances MUST be done with either “RECURRENCE-ID” and “RANGE” OR multiple “RECURRENCE-ID” values.
3.4.5.a VTODO CANCEL ○ Yes ○ No ○ Other	MUST	To cancel the complete range of a recurring “VTODO” calendar component, the “UID” property value for the “VTODO” calendar component MUST be specified and a “RECURRENCE-ID” MUST NOT be specified in the “CANCEL” method.
3.4.5.b VTODO CANCEL ○ Yes ○ No ○ Other	MUST	In order to cancel an individual instance of a recurring “VTODO” calendar component, the “RECURRENCE-ID” property value for the “VTODO” calendar component MUST be specified in the “CANCEL” method.
3.4.6.a VTODO REFRESH ○ Yes ○ No ○ Other	MUST	A refresh of a recurrence instance of a “VTODO” calendar component may be requested by specifying the “RECURRENCE-ID” property corresponding to the associated “VTODO” calendar component. The “Organizer” responds with the latest description and rendition of the “VTODO” calendar component. In most cases this will be a REQUEST unless the “VTODO” has been cancelled, in which case the ORGANIZER must send a “CANCEL”. This method is intended to facilitate machine processing of requests for updates to a “VTODO” calendar component.
3.5.3.a VJOURNAL CANCEL ○ Yes ○ No ○ Other	MUST	To cancel the complete range of a recurring journal entry, the “UID” property value for the journal entry MUST be specified and a “RECURRENCE-ID” property MUST NOT be specified in the “CANCEL” method.
3.5.3.b VJOURNAL CANCEL ○ Yes ○ No ○ Other	MUST	In order to cancel an individual instance of the journal entry, the “RECURRENCE-ID” property value for the journal entry MUST be specified in the “CANCEL” method.

4.3.  Part 3. Additional Comments or Issues with Recurrences

Please use the following area¹ to provide any additional comments or issues with recurrences that may not be addressed above; known interop issues with a particular other implementation that might conflict with your implementation; etc.

4.4.  Part 4. Feedback on Value of this Questionnaire

We would appreciate your feedback on this questionnaire. Specifically, (1) Would you like to see a similar questionnaire for all of RFCs 2445 and 2446 (knowing that it would be quite large). (2) Was it worthwhile for you to fill this out in the sense that it allows you to compare your implementation to the proposed standards? (3) Can you offer us any additional comments to help us do better in the future?

4.5.  Part 5. Completion and Submission

Please review your completed questionnaire carefully. You may use the “CLEAR” button below to clear the entire form and re-enter all information. Use the “SEND” button to transmit the completed questionnaire to us.

Send	Clear form & start over

This site uses frames.
If you do not see the navigation sidebar on the left, please click Restore to establish the full site.