4.8.5 Recurrence Component Properties

   The following properties specify recurrence information in calendar
   components.

4.8.5.1 Exception Date/Times

   Property Name: EXDATE

   Purpose: This property defines the list of date/time exceptions for a
   recurring calendar component.

   Value Type: The default value type for this property is DATE-TIME.
   The value type can be set to DATE.

   Property Parameters: Non-standard, value data type and time zone
   identifier property parameters can be specified on this property.

   Conformance: This property can be specified in an iCalendar object
   that includes a recurring calendar component.

   Description: The exception dates, if specified, are used in computing
   the recurrence set. The recurrence set is the complete set of
   recurrence instances for a calendar component. 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. Multiple instances of the "RRULE" and
   "EXRULE" properties can also be specified to define more
   sophisticated recurrence sets. 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 then excluding any
   start date and times which fall within the union of start date and
   times generated by any specified "EXRULE" and "EXDATE" properties.
   This implies that start date and times within exclusion related
   properties (i.e., "EXDATE" and "EXRULE") take precedence over those
   specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where
   duplicate instances are generated by the "RRULE" and "RDATE"
   properties, only one recurrence is considered. Duplicate instances
   are ignored.

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

   Format Definition: The property is defined by the following notation:

     exdate     = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF

     exdtparam  = *(

                ; the following are optional,
                ; but MUST NOT occur more than once

                (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /

                (";" tzidparam) /

                ; the following is optional,
                ; and MAY occur more than once

                (";" xparam)

                )

     exdtval    = date-time / date
     ;Value MUST match value type

   Example: The following is an example of this property:

     EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z

4.8.5.2 Exception Rule

   Property Name: EXRULE

   Purpose: This property defines a rule or repeating pattern for an
   exception to a recurrence set.

   Value Type: RECUR

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in "VEVENT", "VTODO" or
   "VJOURNAL" calendar components.

   Description: The exception rule, if specified, is used in computing
   the recurrence set. The recurrence set is the complete set of
   recurrence instances for a calendar component. 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" defines the first instance
   in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
   properties can also be specified to define more sophisticated
   recurrence sets. 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 and times which
   fall within the union of start date and times generated by any
   specified "EXRULE" and "EXDATE" properties. This implies that start
   date and times within exclusion related properties (i.e., "EXDATE"
   and "EXRULE") take precedence over those specified by inclusion

   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
   generated by the "RRULE" and "RDATE" properties, only one recurrence
   is considered. Duplicate instances are ignored.

   The "EXRULE" 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".

   Format Definition: The property is defined by the following notation:

     exrule     = "EXRULE" exrparam ":" recur CRLF

     exrparam   = *(";" xparam)

   Example: The following are examples of this property. Except every
   other week, on Tuesday and Thursday for 4 occurrences:

     EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH

   Except daily for 10 occurrences:

     EXRULE:FREQ=DAILY;COUNT=10

   Except yearly in June and July for 8 occurrences:

     EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7

4.8.5.3 Recurrence Date/Times

   Property Name: RDATE

   Purpose: This property defines the list of date/times for a
   recurrence set.

   Value Type: The default value type for this property is DATE-TIME.
   The value type can be set to DATE or PERIOD.

   Property Parameters: Non-standard, value data type and time zone
   identifier property parameters can be specified on this property.

   Conformance: The property can be specified in "VEVENT", "VTODO",
   "VJOURNAL" or "VTIMEZONE" calendar components.

   Description: This property can appear along with the "RRULE" property
   to define an aggregate set of repeating occurrences. When they both
   appear in an iCalendar object, the recurring events are defined by
   the union of occurrences defined by both the "RDATE" and "RRULE".

   The recurrence dates, if specified, are used in computing the
   recurrence set. The recurrence set is the complete set of recurrence
   instances for a calendar component. 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. Multiple instances of the "RRULE" and "EXRULE"
   properties can also be specified to define more sophisticated
   recurrence sets. 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. This implies that start date/times
   within exclusion related properties (i.e., "EXDATE" and "EXRULE")
   take precedence over those specified by inclusion properties (i.e.,
   "RDATE" and "RRULE"). Where duplicate instances are generated by the
   "RRULE" and "RDATE" properties, only one recurrence is considered.
   Duplicate instances are ignored.

   Format Definition: The property is defined by the following notation:

     rdate      = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF

     rdtparam   = *(

                ; the following are optional,
                ; but MUST NOT occur more than once

                (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
                (";" tzidparam) /

                ; the following is optional,
                ; and MAY occur more than once

                (";" xparam)

                )

     rdtval     = date-time / date / period
     ;Value MUST match value type

   Example: The following are examples of this property:

     RDATE:19970714T123000Z

     RDATE;TZID=US-EASTERN:19970714T083000

     RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
      19960404T010000Z/PT3H

     RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
      19970526,19970704,19970901,19971014,19971128,19971129,19971225

4.8.5.4 Recurrence Rule

   Property Name: RRULE

   Purpose: This property defines a rule or repeating pattern for
   recurring events, to-dos, or time zone definitions.

   Value Type: RECUR

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified one or more times in
   recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It
   can also be specified once in each STANDARD or DAYLIGHT sub-component
   of the "VTIMEZONE" calendar component.

   Description: The recurrence rule, if specified, is used in computing
   the recurrence set. The recurrence set is the complete set of
   recurrence instances for a calendar component. 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. Multiple instances of the "RRULE" and
   "EXRULE" properties can also be specified to define more
   sophisticated recurrence sets. 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. This implies that
   start date/times within exclusion related properties (i.e., "EXDATE"
   and "EXRULE") take precedence over those specified by inclusion
   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
   generated by the "RRULE" and "RDATE" properties, only one recurrence
   is considered. Duplicate instances are ignored.

   The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
   property pair, specified within the iCalendar object defines the
   first instance of the recurrence. When used with a recurrence rule,
   the "DTSTART" and "DTEND" properties MUST be specified in local time
   and the appropriate set of "VTIMEZONE" calendar components MUST be
   included. For detail on the usage of the "VTIMEZONE" calendar
   component, see the "VTIMEZONE" calendar component definition.

   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.

   Format Definition: This property is defined by the following
   notation:

     rrule      = "RRULE" rrulparam ":" recur CRLF

     rrulparam  = *(";" xparam)

   Example: All examples assume the Eastern United States time zone.

   Daily for 10 occurrences:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=DAILY;COUNT=10

     ==> (1997 9:00 AM EDT)September 2-11

   Daily until December 24, 1997:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=DAILY;UNTIL=19971224T000000Z

     ==> (1997 9:00 AM EDT)September 2-30;October 1-25
         (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23

   Every other day - forever:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=DAILY;INTERVAL=2
     ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30;
          October 2,4,6...20,22,24
         (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
          Dec 1,3,...

   Every 10 days, 5 occurrences:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5

     ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12

   Everyday in January, for 3 years:

     DTSTART;TZID=US-Eastern:19980101T090000
     RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z;
      BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
     or
     RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1

     ==> (1998 9:00 AM EDT)January 1-31
         (1999 9:00 AM EDT)January 1-31
         (2000 9:00 AM EDT)January 1-31

   Weekly for 10 occurrences

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=WEEKLY;COUNT=10

     ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
         (1997 9:00 AM EST)October 28;November 4

   Weekly until December 24, 1997

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z

     ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
         (1997 9:00 AM EST)October 28;November 4,11,18,25;
                           December 2,9,16,23
   Every other week - forever:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU

     ==> (1997 9:00 AM EDT)September 2,16,30;October 14
         (1997 9:00 AM EST)October 28;November 11,25;December 9,23
         (1998 9:00 AM EST)January 6,20;February
     ...

   Weekly on Tuesday and Thursday for 5 weeks:

    DTSTART;TZID=US-Eastern:19970902T090000
    RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
    or

    RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH

    ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2

   Every other week on Monday, Wednesday and Friday until December 24,
   1997, but starting on Tuesday, September 2, 1997:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
      BYDAY=MO,WE,FR
     ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
     1,3,13,15,17
         (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
                           December 8,10,12,22

   Every other week on Tuesday and Thursday, for 8 occurrences:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH

     ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16

   Monthly on the 1st Friday for ten occurrences:

     DTSTART;TZID=US-Eastern:19970905T090000
     RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR

     ==> (1997 9:00 AM EDT)September 5;October 3
         (1997 9:00 AM EST)November 7;Dec 5
         (1998 9:00 AM EST)January 2;February 6;March 6;April 3
         (1998 9:00 AM EDT)May 1;June 5

   Monthly on the 1st Friday until December 24, 1997:

     DTSTART;TZID=US-Eastern:19970905T090000
     RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR

     ==> (1997 9:00 AM EDT)September 5;October 3
         (1997 9:00 AM EST)November 7;December 5

   Every other month on the 1st and last Sunday of the month for 10
   occurrences:

     DTSTART;TZID=US-Eastern:19970907T090000
     RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU

     ==> (1997 9:00 AM EDT)September 7,28
         (1997 9:00 AM EST)November 2,30

         (1998 9:00 AM EST)January 4,25;March 1,29
         (1998 9:00 AM EDT)May 3,31

   Monthly on the second to last Monday of the month for 6 months:

     DTSTART;TZID=US-Eastern:19970922T090000
     RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO

     ==> (1997 9:00 AM EDT)September 22;October 20
         (1997 9:00 AM EST)November 17;December 22
         (1998 9:00 AM EST)January 19;February 16

   Monthly on the third to the last day of the month, forever:

     DTSTART;TZID=US-Eastern:19970928T090000
     RRULE:FREQ=MONTHLY;BYMONTHDAY=-3

     ==> (1997 9:00 AM EDT)September 28
         (1997 9:00 AM EST)October 29;November 28;December 29
         (1998 9:00 AM EST)January 29;February 26
     ...

   Monthly on the 2nd and 15th of the month for 10 occurrences:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15

     ==> (1997 9:00 AM EDT)September 2,15;October 2,15
         (1997 9:00 AM EST)November 2,15;December 2,15
         (1998 9:00 AM EST)January 2,15

   Monthly on the first and last day of the month for 10 occurrences:

     DTSTART;TZID=US-Eastern:19970930T090000
     RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1

     ==> (1997 9:00 AM EDT)September 30;October 1
         (1997 9:00 AM EST)October 31;November 1,30;December 1,31
         (1998 9:00 AM EST)January 1,31;February 1

   Every 18 months on the 10th thru 15th of the month for 10
   occurrences:

     DTSTART;TZID=US-Eastern:19970910T090000
     RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
      15

     ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15

         (1999 9:00 AM EST)March 10,11,12,13

   Every Tuesday, every other month:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU

     ==> (1997 9:00 AM EDT)September 2,9,16,23,30
         (1997 9:00 AM EST)November 4,11,18,25
         (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
     ...

   Yearly in June and July for 10 occurrences:

     DTSTART;TZID=US-Eastern:19970610T090000
     RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
     ==> (1997 9:00 AM EDT)June 10;July 10
         (1998 9:00 AM EDT)June 10;July 10
         (1999 9:00 AM EDT)June 10;July 10
         (2000 9:00 AM EDT)June 10;July 10
         (2001 9:00 AM EDT)June 10;July 10
     Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
     are specified, the day is gotten from DTSTART

   Every other year on January, February, and March for 10 occurrences:

     DTSTART;TZID=US-Eastern:19970310T090000
     RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3

     ==> (1997 9:00 AM EST)March 10
         (1999 9:00 AM EST)January 10;February 10;March 10
         (2001 9:00 AM EST)January 10;February 10;March 10
         (2003 9:00 AM EST)January 10;February 10;March 10

   Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:

     DTSTART;TZID=US-Eastern:19970101T090000
     RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200

     ==> (1997 9:00 AM EST)January 1
         (1997 9:00 AM EDT)April 10;July 19
         (2000 9:00 AM EST)January 1
         (2000 9:00 AM EDT)April 9;July 18
         (2003 9:00 AM EST)January 1
         (2003 9:00 AM EDT)April 10;July 19
         (2006 9:00 AM EST)January 1

   Every 20th Monday of the year, forever:

     DTSTART;TZID=US-Eastern:19970519T090000
     RRULE:FREQ=YEARLY;BYDAY=20MO

     ==> (1997 9:00 AM EDT)May 19
         (1998 9:00 AM EDT)May 18
         (1999 9:00 AM EDT)May 17
     ...

   Monday of week number 20 (where the default start of the week is
   Monday), forever:

     DTSTART;TZID=US-Eastern:19970512T090000
     RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO

     ==> (1997 9:00 AM EDT)May 12
         (1998 9:00 AM EDT)May 11
         (1999 9:00 AM EDT)May 17
     ...

   Every Thursday in March, forever:

     DTSTART;TZID=US-Eastern:19970313T090000
     RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH

     ==> (1997 9:00 AM EST)March 13,20,27
         (1998 9:00 AM EST)March 5,12,19,26
         (1999 9:00 AM EST)March 4,11,18,25
     ...

   Every Thursday, but only during June, July, and August, forever:

     DTSTART;TZID=US-Eastern:19970605T090000
     RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8

     ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
                       August 7,14,21,28
         (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
                       August 6,13,20,27
         (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
                       August 5,12,19,26
     ...

   Every Friday the 13th, forever:

     DTSTART;TZID=US-Eastern:19970902T090000
     EXDATE;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13

     ==> (1998 9:00 AM EST)February 13;March 13;November 13
         (1999 9:00 AM EDT)August 13
         (2000 9:00 AM EDT)October 13
     ...

   The first Saturday that follows the first Sunday of the month,
    forever:

     DTSTART;TZID=US-Eastern:19970913T090000
     RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13

     ==> (1997 9:00 AM EDT)September 13;October 11
         (1997 9:00 AM EST)November 8;December 13
         (1998 9:00 AM EST)January 10;February 7;March 7
         (1998 9:00 AM EDT)April 11;May 9;June 13...
     ...

   Every four years, the first Tuesday after a Monday in November,
   forever (U.S. Presidential Election day):

     DTSTART;TZID=US-Eastern:19961105T090000
     RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
      5,6,7,8

     ==> (1996 9:00 AM EST)November 5
         (2000 9:00 AM EST)November 7
         (2004 9:00 AM EST)November 2
     ...

   The 3rd instance into the month of one of Tuesday, Wednesday or
   Thursday, for the next 3 months:

     DTSTART;TZID=US-Eastern:19970904T090000
     RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3

     ==> (1997 9:00 AM EDT)September 4;October 7
         (1997 9:00 AM EST)November 6

   The 2nd to last weekday of the month:

     DTSTART;TZID=US-Eastern:19970929T090000
     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2

     ==> (1997 9:00 AM EDT)September 29
         (1997 9:00 AM EST)October 30;November 27;December 30
         (1998 9:00 AM EST)January 29;February 26;March 30
     ...

   Every 3 hours from 9:00 AM to 5:00 PM on a specific day:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z

     ==> (September 2, 1997 EDT)09:00,12:00,15:00

   Every 15 minutes for 6 occurrences:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6

     ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15

   Every hour and a half for 4 occurrences:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4

     ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30

   Every 20 minutes from 9:00 AM to 4:40 PM every day:

     DTSTART;TZID=US-Eastern:19970902T090000
     RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
     or
     RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16

     ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
                                ... 16:00,16:20,16:40
         (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
                               ...16:00,16:20,16:40
     ...

   An example where the days generated makes a difference because of
   WKST:

     DTSTART;TZID=US-Eastern:19970805T090000
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO

     ==> (1997 EDT)Aug 5,10,19,24

     changing only WKST from MO to SU, yields different results...

     DTSTART;TZID=US-Eastern:19970805T090000
     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
     ==> (1997 EDT)August 5,17,19,31

4.8.6 Alarm Component Properties

   The following properties specify alarm information in calendar
   components.

4.8.6.1 Action

   Property Name: ACTION

   Purpose: This property defines the action to be invoked when an alarm
   is triggered.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property MUST be specified once in a "VALARM"
   calendar component.

   Description: Each "VALARM" calendar component has a particular type
   of action associated with it. This property specifies the type of
   action

   Format Definition: The property is defined by the following notation:

     action     = "ACTION" actionparam ":" actionvalue CRLF

     actionparam        = *(";" xparam)

     actionvalue        = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
                        / iana-token / x-name

   Example: The following are examples of this property in a "VALARM"
   calendar component:

     ACTION:AUDIO

     ACTION:DISPLAY

     ACTION:PROCEDURE

4.8.6.2 Repeat Count

   Property Name: REPEAT

   Purpose: This property defines the number of time the alarm should be
   repeated, after the initial trigger.

   Value Type: INTEGER

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in a "VALARM" calendar
   component.

   Description: If the alarm triggers more than once, then this property
   MUST be specified along with the "DURATION" property.

   Format Definition: The property is defined by the following notation:

     repeatcnt  = "REPEAT" repparam ":" integer CRLF
     ;Default is "0", zero.

     repparam   = *(";" xparam)

   Example: The following is an example of this property for an alarm
   that repeats 4 additional times with a 5 minute delay after the
   initial triggering of the alarm:

     REPEAT:4
     DURATION:PT5M

4.8.6.3 Trigger

   Property Name: TRIGGER

   Purpose: This property specifies when an alarm will trigger.

   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.

   Property Parameters: Non-standard, value data type, time zone
   identifier or trigger relationship property parameters can be
   specified on this property. The trigger relationship property
   parameter MUST only be specified when the value type is DURATION.

   Conformance: This property MUST be specified in the "VALARM" calendar
   component.

   Description: Within the "VALARM" calendar component, this property
   defines when the alarm will trigger. The default value type is
   DURATION, specifying a relative time for the trigger of the alarm.
   The default duration is relative to the start of an event or to-do
   that the alarm is associated with. The duration can be explicitly set

   to trigger from either the end or the start of the associated event
   or to-do with the "RELATED" parameter. A value of START will set the
   alarm to trigger off the start of the associated event or to-do. A
   value of END will set the alarm to trigger off the end of the
   associated event or to-do.

   Either a positive or negative duration may be specified for the
   "TRIGGER" property. An alarm with a positive duration is triggered
   after the associated start or end of the event or to-do. An alarm
   with a negative duration is triggered before the associated start or
   end of the event or to-do.

   The "RELATED" property parameter is not valid if the value type of
   the property is set to DATE-TIME (i.e., for an absolute date and time
   alarm trigger). If a value type of DATE-TIME is specified, then the
   property value MUST be specified in the UTC time format. If an
   absolute trigger is specified on an alarm for a recurring event or
   to-do, then the alarm will only trigger for the specified absolute
   date/time, along with any specified repeating instances.

   If the trigger is set relative to START, then the "DTSTART" property
   MUST be present in the associated "VEVENT" or "VTODO" calendar
   component. If an alarm is specified for an event with the trigger set
   relative to the END, then the "DTEND" property or the "DSTART" and
   "DURATION' properties MUST be present in the associated "VEVENT"
   calendar component. If the alarm is specified for a to-do with a
   trigger set relative to the END, then either the "DUE" property or
   the "DSTART" and "DURATION' properties MUST be present in the
   associated "VTODO" calendar component.

   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.

   Format Definition: The property is defined by the following notation:

     trigger    = "TRIGGER" (trigrel / trigabs)

     trigrel    = *(

                ; the following are optional,
                ; but MUST NOT occur more than once

                  (";" "VALUE" "=" "DURATION") /
                  (";" trigrelparam) /

                ; the following is optional,

                ; and MAY occur more than once

                  (";" xparam)
                  ) ":"  dur-value

     trigabs    = 1*(

                ; the following is REQUIRED,
                ; but MUST NOT occur more than once

                  (";" "VALUE" "=" "DATE-TIME") /

                ; the following is optional,
                ; and MAY occur more than once

                  (";" xparam)

                  ) ":" date-time

   Example: A trigger set 15 minutes prior to the start of the event or
   to-do.

     TRIGGER:-P15M

   A trigger set 5 minutes after the end of the event or to-do.

     TRIGGER;RELATED=END:P5M

   A trigger set to an absolute date/time.

     TRIGGER;VALUE=DATE-TIME:19980101T050000Z

4.8.7 Change Management Component Properties

   The following properties specify change management information in
   calendar components.

4.8.7.1 Date/Time Created

   Property Name: CREATED

   Purpose: This property specifies the date and time that the calendar
   information was created by the calendar user agent in the calendar
   store.

        Note: This is analogous to the creation date and time for a file
        in the file system.

   Value Type: DATE-TIME

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified once in "VEVENT", "VTODO"
   or "VJOURNAL" calendar components.

   Description: The date and time is a UTC value.

   Format Definition: The property is defined by the following notation:

     created    = "CREATED" creaparam ":" date-time CRLF

     creaparam  = *(";" xparam)

   Example: The following is an example of this property:

     CREATED:19960329T133000Z

4.8.7.2 Date/Time Stamp

   Property Name: DTSTAMP

   Purpose: The property indicates the date/time that the instance of
   the iCalendar object was created.

   Value Type: DATE-TIME

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property MUST be included in the "VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components.

   Description: The value MUST be specified in the UTC time format.

   This property is also useful to protocols such as [IMIP] that have
   inherent latency issues with the delivery of content. This property
   will assist in the proper sequencing of messages containing iCalendar
   objects.

   This property is different than the "CREATED" and "LAST-MODIFIED"
   properties. These two properties are used to specify when the
   particular calendar data in the calendar store was created and last
   modified. This is different than when the iCalendar object
   representation of the calendar service information was created or
   last modified.

   Format Definition: The property is defined by the following notation:

     dtstamp    = "DTSTAMP" stmparam ":" date-time CRLF

     stmparam   = *(";" xparam)

   Example:

     DTSTAMP:19971210T080000Z

4.8.7.3 Last Modified

   Property Name: LAST-MODIFIED

   Purpose: The property specifies the date and time that the
   information associated with the calendar component was last revised
   in the calendar store.

        Note: This is analogous to the modification date and time for a
        file in the file system.

   Value Type: DATE-TIME

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: This property can be specified in the "EVENT", "VTODO",
   "VJOURNAL" or "VTIMEZONE" calendar components.

   Description: The property value MUST be specified in the UTC time
   format.

   Format Definition: The property is defined by the following notation:

     last-mod   = "LAST-MODIFIED" lstparam ":" date-time CRLF

     lstparam   = *(";" xparam)

   Example: The following is are examples of this property:

     LAST-MODIFIED:19960817T133000Z

4.8.7.4 Sequence Number

   Property Name: SEQUENCE

   Purpose: This property defines the revision sequence number of the
   calendar component within a sequence of revisions.

   Value Type: integer

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property can be specified in "VEVENT", "VTODO" or
   "VJOURNAL" calendar component.

   Description: When a calendar component is created, its sequence
   number is zero (US-ASCII decimal 48). It is monotonically incremented
   by the "Organizer's" CUA each time the "Organizer" makes a
   significant revision to the calendar component. 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"

   In addition, changes made by the "Organizer" to other properties can
   also force the sequence number to be incremented. The "Organizer" CUA
   MUST increment the sequence number when ever it makes changes to
   properties in the calendar component that the "Organizer" deems will
   jeopardize the validity of the participation status of the
   "Attendees". For example, changing the location of a meeting from one
   locale to another distant locale could effectively impact the
   participation status of the "Attendees".

   The "Organizer" includes this property in an iCalendar object that it
   sends to an "Attendee" to specify the current version of the calendar
   component.

   The "Attendee" includes this property in an iCalendar object that it
   sends to the "Organizer" to specify the version of the calendar
   component that the "Attendee" is referring to.

   A change to the sequence number is not the mechanism that an
   "Organizer" uses to request a response from the "Attendees". The
   "RSVP" parameter on the "ATTENDEE" property is used by the
   "Organizer" to indicate that a response from the "Attendees" is
   requested.

   Format Definition: This property is defined by the following
   notation:

     seq = "SEQUENCE" seqparam ":" integer CRLF
     ; Default is "0"

     seqparam   = *(";" xparam)

   Example: The following is an example of this property for a calendar
   component that was just created by the "Organizer".

     SEQUENCE:0

   The following is an example of this property for a calendar component
   that has been revised two different times by the "Organizer".

     SEQUENCE:2

4.8.8 Miscellaneous Component Properties

   The following properties specify information about a number of
   miscellaneous features of calendar components.

4.8.8.1 Non-standard Properties

   Property Name: Any property name with a "X-" prefix

   Purpose: This class of property provides a framework for defining
   non-standard properties.

   Value Type: TEXT

   Property Parameters: Non-standard and language property parameters
   can be specified on this property.

   Conformance: This property can be specified in any calendar
   component.

   Description: The MIME Calendaring and Scheduling Content Type
   provides a "standard mechanism for doing non-standard things". This
   extension support is provided for implementers to "push the envelope"
   on the existing version of the memo. Extension properties are

   specified by property and/or property parameter names that have the
   prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER
   X character followed by the HYPEN-MINUS character). It is recommended
   that vendors concatenate onto this sentinel another short prefix text
   to identify the vendor. This will facilitate readability of the
   extensions and minimize possible collision of names between different
   vendors. User agents that support this content type are expected to
   be able to parse the extension properties and property parameters but
   can ignore them.

   At present, there is no registration authority for names of extension
   properties and property parameters. The data type for this property
   is TEXT. Optionally, the data type can be any of the other valid data
   types.

   Format Definition: The property is defined by the following notation:

     x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
        ; Lines longer than 75 octets should be folded

   Example: The following might be the ABC vendor's extension for an
   audio-clip form of subject property:

     X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav

4.8.8.2 Request Status

   Property Name: REQUEST-STATUS

   Purpose: This property defines the status code returned for a
   scheduling request.

   Value Type: TEXT

   Property Parameters: Non-standard and language property parameters
   can be specified on this property.

   Conformance: The property can be specified in "VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar component.

   Description: This property is used to return status code information
   related to the processing of an associated iCalendar object. The data
   type for this property is TEXT.

   The value consists of a short return status component, a longer
   return status description component, and optionally a status-specific
   data component. The components of the value are separated by the
   SEMICOLON character (US-ASCII decimal 59).

   The short return status is a PERIOD character (US-ASCII decimal 46)
   separated 3-tuple of integers. For example, "3.1.1". The successive
   levels of integers provide for a successive level of status code
   granularity.

   The following are initial classes for the return status code.
   Individual iCalendar object methods will define specific return
   status codes for these classes. In addition, other classes for the
   return status code may be defined using the registration process
   defined later in this memo.

     |==============+===============================================|
     | Short Return | Longer Return Status Description              |
     | Status Code  |                                               |
     |==============+===============================================|
     |    1.xx      | Preliminary success. This class of status     |
     |              | of status code indicates that the request has |
     |              | request has been initially processed but that |
     |              | completion is pending.                        |
     |==============+===============================================|
     |    2.xx      | Successful. This class of status code         |
     |              | indicates that the request was completed      |
     |              | successfuly. However, the exact status code   |
     |              | can indicate that a fallback has been taken.  |
     |==============+===============================================|
     |    3.xx      | Client Error. This class of status code       |
     |              | indicates that the request was not successful.|
     |              | The error is the result of either a syntax or |
     |              | a semantic error in the client formatted      |
     |              | request. Request should not be retried until  |
     |              | the condition in the request is corrected.    |
     |==============+===============================================|
     |    4.xx      | Scheduling Error. This class of status code   |
     |              | indicates that the request was not successful.|
     |              | Some sort of error occurred within the        |
     |              | calendaring and scheduling service, not       |
     |              | directly related to the request itself.       |
     |==============+===============================================|

   Format Definition: The property is defined by the following notation:

     rstatus    = "REQUEST-STATUS" rstatparam ":"
                  statcode ";" statdesc [";" extdata]

     rstatparam = *(

                ; the following is optional,
                ; but MUST NOT occur more than once

                (";" languageparm) /

                ; the following is optional,
                ; and MAY occur more than once

                (";" xparam)

                )

     statcode   = 1*DIGIT *("." 1*DIGIT)
     ;Hierarchical, numeric return status code

     statdesc   = text
     ;Textual status description

     extdata    = text
     ;Textual exception data. For example, the offending property
     ;name and value or complete property line.

   Example: The following are some possible examples of this property.
   The COMMA and SEMICOLON separator characters in the property value
   are BACKSLASH character escaped because they appear in a  text value.

     REQUEST-STATUS:2.0;Success

     REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01

     REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
      as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2

     REQUEST-STATUS:4.1;Event conflict. Date/time is busy.

     REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
      MAILTO:jsmith@host.com

5 iCalendar Object Examples

   The following examples are provided as an informational source of
   illustrative iCalendar objects consistent with this content type.

   The following example specifies a three-day conference that begins at
   8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
   1996.

     BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
     1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
     UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
     DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED

     CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
     DESCRIPTION:Networld+Interop Conference
       and Exhibit\nAtlanta World Congress Center\n
      Atlanta, Georgia END:VEVENT END:VCALENDAR

   The following example specifies a group scheduled meeting that begin
   at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
   1998. The "Organizer" has scheduled the meeting with one or more
   calendar users in a group. A time zone specification for Eastern
   United States has been specified.

     BEGIN:VCALENDAR
     PRODID:-//RDU Software//NONSGML HandCal//EN
     VERSION:2.0
     BEGIN:VTIMEZONE
     TZID:US-Eastern
     BEGIN:STANDARD
     DTSTART:19981025T020000
     RDATE:19981025T020000
     TZOFFSETFROM:-0400
     TZOFFSETTO:-0500
     TZNAME:EST
     END:STANDARD
     BEGIN:DAYLIGHT
     DTSTART:19990404T020000
     RDATE:19990404T020000
     TZOFFSETFROM:-0500
     TZOFFSETTO:-0400
     TZNAME:EDT
     END:DAYLIGHT
     END:VTIMEZONE
     BEGIN:VEVENT
     DTSTAMP:19980309T231000Z
     UID:guid-1.host1.com
     ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
     ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
      MAILTO:employee-A@host.com
     DESCRIPTION:Project XYZ Review Meeting
     CATEGORIES:MEETING
     CLASS:PUBLIC
     CREATED:19980309T130000Z
     SUMMARY:XYZ Project Review
     DTSTART;TZID=US-Eastern:19980312T083000
     DTEND;TZID=US-Eastern:19980312T093000
     LOCATION:1CP Conference Room 4350
     END:VEVENT
     END:VCALENDAR

   The following is an example of an iCalendar object passed in a MIME
   message with a single body part consisting of a "text/calendar"
   Content Type.

     TO:jsmith@host1.com
     FROM:jdoe@host1.com
     MIME-VERSION:1.0
     MESSAGE-ID:<id3@host1.com>
     CONTENT-TYPE:text/calendar

     BEGIN:VCALENDAR
     METHOD:xyz
     VERSION:2.0
     PRODID:-//ABC Corporation//NONSGML My Product//EN
     BEGIN:VEVENT
     DTSTAMP:19970324T1200Z
     SEQUENCE:0
     UID:uid3@host1.com
     ORGANIZER:MAILTO:jdoe@host1.com
     ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
     DTSTART:19970324T123000Z
     DTEND:19970324T210000Z
     CATEGORIES:MEETING,PROJECT
     CLASS:PUBLIC
     SUMMARY:Calendaring Interoperability Planning Meeting
     DESCRIPTION:Discuss how we can test c&s interoperability\n
      using iCalendar and other IETF standards.
     LOCATION:LDB Lobby
     ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
      conf/bkgrnd.ps
     END:VEVENT
     END:VCALENDAR

   The following is an example of a to-do due on April 15, 1998. An
   audio alarm has been specified to remind the calendar user at noon,
   the day before the to-do is expected to be completed and repeat
   hourly, four additional times. The to-do definition has been modified
   twice since it was initially created.

     BEGIN:VCALENDAR
     VERSION:2.0
     PRODID:-//ABC Corporation//NONSGML My Product//EN
     BEGIN:VTODO
     DTSTAMP:19980130T134500Z
     SEQUENCE:2
     UID:uid4@host1.com
     ORGANIZER:MAILTO:unclesam@us.gov
     ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com

     DUE:19980415T235959
     STATUS:NEEDS-ACTION
     SUMMARY:Submit Income Taxes
     BEGIN:VALARM
     ACTION:AUDIO
     TRIGGER:19980403T120000
     ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-
      files/ssbanner.aud
     REPEAT:4
     DURATION:PT1H
     END:VALARM
     END:VTODO
     END:VCALENDAR

   The following is an example of a journal entry.

     BEGIN:VCALENDAR
     VERSION:2.0
     PRODID:-//ABC Corporation//NONSGML My Product//EN
     BEGIN:VJOURNAL
     DTSTAMP:19970324T120000Z
     UID:uid5@host1.com
     ORGANIZER:MAILTO:jsmith@host.com
     STATUS:DRAFT
     CLASS:PUBLIC
     CATEGORY:Project Report, XYZ, Weekly Meeting
     DESCRIPTION:Project xyz Review Meeting Minutes\n
      Agenda\n1. Review of project version 1.0 requirements.\n2.
     Definition
      of project processes.\n3. Review of project schedule.\n
      Participants: John Smith, Jane Doe, Jim Dandy\n-It was
       decided that the requirements need to be signed off by
       product marketing.\n-Project processes were accepted.\n
      -Project schedule needs to account for scheduled holidays
       and employee vacation time. Check with HR for specific
       dates.\n-New schedule will be distributed by Friday.\n-
      Next weeks meeting is cancelled. No meeting until 3/23.
     END:VJOURNAL
     END:VCALENDAR

   The following is an example of published busy time information. The
   iCalendar object might be placed in the network resource
   www.host.com/calendar/busytime/jsmith.ifb.

     BEGIN:VCALENDAR
     VERSION:2.0
     PRODID:-//RDU Software//NONSGML HandCal//EN
     BEGIN:VFREEBUSY

     ORGANIZER:MAILTO:jsmith@host.com
     DTSTART:19980313T141711Z
     DTEND:19980410T141711Z
     FREEBUSY:19980314T233000Z/19980315T003000Z
     FREEBUSY:19980316T153000Z/19980316T163000Z
     FREEBUSY:19980318T030000Z/19980318T040000Z
     URL:http://www.host.com/calendar/busytime/jsmith.ifb
     END:VFREEBUSY
     END:VCALENDAR

6 Recommended Practices

   These recommended practices should be followed in order to assure
   consistent handling of the following cases for an iCalendar object.

   1.  Content lines longer than 75 octets SHOULD be folded.

   2.  A calendar entry with a "DTSTART" property but no "DTEND"
       property does not take up any time. It is intended to represent
       an event that is associated with a given calendar date and time
       of day, such as an anniversary. Since the event does not take up
       any time, it MUST NOT be used to record busy time no matter what
       the value for the "TRANSP" property.

   3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
       "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
       "VTODO" calendar components, have the same value data type (e.g.,
       DATE-TIME), they SHOULD specify values in the same time format
       (e.g., UTC time format).

   4.  When the combination of the "RRULE" and "RDATE" properties on an
       iCalendar object produces multiple instances having the same
       start date/time, they should be collapsed to, and considered as,
       a single instance.

   5.  When a calendar user receives multiple requests for the same
       calendar component (e.g., REQUEST for a "VEVENT" calendar
       component) as a result of being on multiple mailing lists
       specified by "ATTENDEE" properties in the request, they SHOULD
       respond to only one of the requests. The calendar user SHOULD
       also specify (using the "MEMBER" parameter of the "ATTENDEE"
       property) which mailing list they are a member of.

   6.  An implementation can truncate a "SUMMARY" property value to 255
       characters.

   7.  If seconds of the minute are not supported by an implementation,
       then a value of "00" SHOULD be specified for the seconds
       component in a time value.

   8.  If the value type parameter (VALUE=) contains an unknown value
       type, it SHOULD be treated as TEXT.

   9.  TZURL values SHOULD NOT be specified as a FILE URI type. This URI
       form can be useful within an organization, but is problematic in
       the Internet.

   10.  Some possible English values for CATEGORIES property include
        "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
        "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
        IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
        OCCASION", "TRAVEL", "VACATION". Categories can be specified in
        any registered language.

   11.  Some possible English values for RESOURCES property include
        "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
        PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
        PHONE", "VEHICLE". Resources can be specified in any registered
        language.

7 Registration of Content Type Elements

   This section provides the process for registration of MIME
   Calendaring and Scheduling Content Type iCalendar object methods and
   new or modified properties.

7.1 Registration of New and Modified iCalendar Object Methods

   New MIME Calendaring and Scheduling Content Type iCalendar object
   methods are registered by the publication of an IETF Request for
   Comments (RFC). Changes to an iCalendar object method are registered
   by the publication of a revision of the RFC defining the method.

7.2 Registration of New Properties

   This section defines procedures by which new properties or enumerated
   property values for the MIME Calendaring and Scheduling Content Type
   can be registered with the IANA. Non-IANA properties can be used by
   bilateral agreement, provided the associated properties names follow
   the "X-" convention.

   The procedures defined here are designed to allow public comment and
   review of new properties, while posing only a small impediment to the
   definition of new properties.

   Registration of a new property is accomplished by the following
   steps.

7.2.1 Define the property

   A property is defined by completing the following template.

     To: ietf-calendar@imc.org

     Subject: Registration of text/calendar MIME property XXX

     Property name:

     Property purpose:

     Property value type(s):

     Property parameter (s):

     Conformance:

     Description:

     Format definition:

     Examples:

   The meaning of each field in the template is as follows.

   Property name: The name of the property, as it will appear in the
   body of an text/calendar MIME Content-Type "property: value" line to
   the left of the colon ":".

   Property purpose: The purpose of the property (e.g., to indicate a
   delegate for the event or to-do, etc.). Give a short but clear
   description.

   Property value type (s): Any of the valid value types for the
   property value needs to be specified. The default value type also
   needs to be specified. If a new value type is specified, it needs to
   be declared in this section.

   Property parameter (s): Any of the valid property parameters for the
   property needs to be specified.

   Conformance: The calendar components that the property can appear in
   needs to be specified.

   Description: Any special notes about the property, how it is to be
   used, etc.

   Format definition: The ABNF for the property definition needs to be
   specified.

   Examples: One or more examples of instances of the property needs to
   be specified.

7.2.2 Post the Property definition

   The property description MUST be posted to the new property
   discussion list, ietf-calendar@imc.org.

7.2.3   Allow a comment period

   Discussion on the new property MUST be allowed to take place on the
   list for a minimum of two weeks. Consensus MUST be reached on the
   property before proceeding to the next step.

7.2.4 Submit the property for approval

   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the property, the
   registration application should be submitted to the Method Reviewer
   for approval. The Method Reviewer is appointed to the Application
   Area Directors and can either accept or reject the property
   registration. An accepted registration should be passed on by the
   Method Reviewer to the IANA for inclusion in the official IANA method
   registry. The registration can be rejected for any of the following
   reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
   Technical deficiencies raised on the list or elsewhere have not been
   addressed. The Method Reviewer's decision to reject a property can be
   appealed by the proposer to the IESG, or the objections raised can be
   addressed by the proposer and the property resubmitted.

7.3 Property Change Control

   Existing properties can be changed using the same process by which
   they were registered.

        1.           Define the change

        2.           Post the change

        3.           Allow a comment period

        4.           Submit the property for approval

   Note that the original author or any other interested party can
   propose a change to an existing property, but that such changes
   should only be proposed when there are serious omissions or errors in
   the published memo. The Method Reviewer can object to a change if it
   is not backward compatible, but is not required to do so.

   Property definitions can never be deleted from the IANA registry, but
   properties which are no longer believed to be useful can be declared
   OBSOLETE by a change to their "intended use" field.

8 References

   [IMIP]     Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
              Message-based Interoperability Protocol (IMIP)", RFC 2447,
              November 1998.

   [ITIP]     Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
              "iCalendar Transport-Independent Interoperability Protocol
              (iTIP) : Scheduling Events, Busy Time, To-dos and Journal
              Entries", RFC 2446, November 1998.

   [ISO 8601] ISO 8601, "Data elements and interchange formats-
              Information interchange--Representation of dates and
              times", International Organization for Standardization,
              June, 1988.

   [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support
              Facilities--Registration Procedures for Public Text Owner
              Identifiers", Second Edition, International Organization
              for Standardization, April 1991.

   [RFC 822]  Crocker, D., "Standard for the Format of ARPA Internet
              Text Messages", STD 11, RFC 822, August 1982.

   [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
              Resource Locators (URL)", RFC 1738, December 1994.

   [RFC 1766] Alvestrand, H., "Tags for the Identification of
              Languages", RFC 1766, March 1995.

   [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
              Extensions (MIME) - Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
              Extensions (MIME) - Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) - Part Four: Registration
              Procedures", RFC 2048, January 1997.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

   [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type
              for Directory Information", RFC 2425, September 1998.

   [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
              RFC 2426, September 1998.

   [TZ]       Olson, A.D., et al, Time zone code and data,
              ftp://elsie.nci.nih.gov/pub/, updated periodically.

   [VCAL]     Internet Mail Consortium, "vCalendar - The Electronic
              Calendaring and Scheduling Exchange Format",
              http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.

9 Acknowledgments

   A hearty thanks to the IETF Calendaring and Scheduling Working Group
   and also the following individuals who have participated in the
   drafting, review and discussion of this memo:

   Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John
   Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre
   Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross
   Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck
   Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman,
   Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch,
   Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve
   Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman,
   John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert
   Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod
   Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg,
   William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov,
   James L. Weiner, Mike Weston, William Wyatt.

10 Authors' and Chairs' Addresses

   The following address information is provided in a MIME-VCARD,
   Electronic Business Card, format.

   The authors of this memo are:

   BEGIN:VCARD
   VERSION:3.0
   N:Dawson;Frank
   FN:Frank Dawson
   ORG:Lotus Development Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;
    Raleigh;NC;27613-3502;USA
   TEL;TYPE=WORK,MSG:+1-919-676-9515
   TEL;TYPE=WORK,FAX:+1-919-676-9564
   EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
   EMAIL;TYPE=INTERNET:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:VCARD

   BEGIN:VCARD
   VERSION:3.0
   N:Stenerson;Derik
   FN:Derik Stenerson
   ORG:Microsoft Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
    Redmond;WA;98052-6399;USA
   TEL;TYPE=WORK,MSG:+1-425-936-5522
   TEL;TYPE=WORK,FAX:+1-425-936-7329
   EMAIL;TYPE=INTERNET:deriks@Microsoft.com
   END:VCARD

   The iCalendar object is a result of the work of the Internet
   Engineering Task Force Calendaring and Scheduling Working Group. The
   chairmen of that working group are:

   BEGIN:VCARD
   VERSION:3.0
   N:Ganguly;Anik
   FN:Anik Ganguly
   ORG: Open Text Inc.
   ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
    Livonia;MI;48152;USA
   TEL;TYPE=WORK,MSG:+1-734-542-5955
   EMAIL;TYPE=INTERNET:ganguly@acm.org
   END:VCARD

   The co-chairman of that working group is:

   BEGIN:VCARD
   VERSION:3.0
   N:Moskowitz;Robert
   FN:Robert Moskowitz
   EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
   END:VCARD

11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.