tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5545

 
 
 

Internet Calendaring and Scheduling Core Object Specification (iCalendar)

Part 7 of 7, p. 144 to 168
Prev RFC Part

 


prevText      Top      Up      ToC       Page 144 
4.  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
   2:30 P.M. UTC, September 18, 1996 and ends at 10:00 P.M. UTC,
   September 20, 1996.

       BEGIN:VCALENDAR
       PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN
       VERSION:2.0
       BEGIN:VEVENT
       DTSTAMP:19960704T120000Z
       UID:uid1@example.com
       ORGANIZER:mailto:jsmith@example.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 begins
   at 8:30 AM EST on March 12, 1998 and ends 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:America/New_York
       BEGIN:STANDARD
       DTSTART:19981025T020000
       TZOFFSETFROM:-0400
       TZOFFSETTO:-0500
       TZNAME:EST
       END:STANDARD
       BEGIN:DAYLIGHT
       DTSTART:19990404T020000
       TZOFFSETFROM:-0500
       TZOFFSETTO:-0400

Top      Up      ToC       Page 145 
       TZNAME:EDT
       END:DAYLIGHT
       END:VTIMEZONE
       BEGIN:VEVENT
       DTSTAMP:19980309T231000Z
       UID:guid-1.example.com
       ORGANIZER:mailto:mrbig@example.com
       ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
        mailto:employee-A@example.com
       DESCRIPTION:Project XYZ Review Meeting
       CATEGORIES:MEETING
       CLASS:PUBLIC
       CREATED:19980309T130000Z
       SUMMARY:XYZ Project Review
       DTSTART;TZID=America/New_York:19980312T083000
       DTEND;TZID=America/New_York: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@example.com
       FROM:jdoe@example.com
       MIME-VERSION:1.0
       MESSAGE-ID:<id3@example.com>
       CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT"

       BEGIN:VCALENDAR
       METHOD:xyz
       VERSION:2.0
       PRODID:-//ABC Corporation//NONSGML My Product//EN
       BEGIN:VEVENT
       DTSTAMP:19970324T120000Z
       SEQUENCE:0
       UID:uid3@example.com
       ORGANIZER:mailto:jdoe@example.com
       ATTENDEE;RSVP=TRUE:mailto:jsmith@example.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

Top      Up      ToC       Page 146 
       ATTACH;FMTTYPE=application/postscript:ftp://example.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@example.com
       ORGANIZER:mailto:unclesam@example.com
       ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com
       DUE:19980415T000000
       STATUS:NEEDS-ACTION
       SUMMARY:Submit Income Taxes
       BEGIN:VALARM
       ACTION:AUDIO
       TRIGGER:19980403T120000Z
       ATTACH;FMTTYPE=audio/basic:http://example.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@example.com
       ORGANIZER:mailto:jsmith@example.com
       STATUS:DRAFT
       CLASS:PUBLIC
       CATEGORIES:Project Report,XYZ,Weekly Meeting
       DESCRIPTION:Project xyz Review Meeting Minutes\n
        Agenda\n1. Review of project version 1.0 requirements.\n2.

Top      Up      ToC       Page 147 
         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
   http://www.example.com/calendar/busytime/jsmith.ifb.

       BEGIN:VCALENDAR
       VERSION:2.0
       PRODID:-//RDU Software//NONSGML HandCal//EN
       BEGIN:VFREEBUSY
       ORGANIZER:mailto:jsmith@example.com
       DTSTART:19980313T141711Z
       DTEND:19980410T141711Z
       FREEBUSY:19980314T233000Z/19980315T003000Z
       FREEBUSY:19980316T153000Z/19980316T163000Z
       FREEBUSY:19980318T030000Z/19980318T040000Z
       URL:http://www.example.com/calendar/busytime/jsmith.ifb
       END:VFREEBUSY
       END:VCALENDAR

5.  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.  When the combination of the "RRULE" and "RDATE" properties in a
       recurring component produces multiple instances having the same
       start DATE-TIME value, they should be collapsed to, and
       considered as, a single instance.  If the "RDATE" property is
       specified as a PERIOD value the duration of the recurrence
       instance will be the one specified by the "RDATE" property, and
       not the duration of the recurrence instance defined by the
       "DTSTART" property.

   3.  When a calendar user receives multiple requests for the same
       calendar component (e.g., REQUEST for a "VEVENT" calendar

Top      Up      ToC       Page 148 
       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) of which mailing list they are a member.

   4.  An implementation can truncate a "SUMMARY" property value to 255
       octets, but it MUST NOT truncate the value in the middle of a
       UTF-8 multi-octet sequence.

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

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

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

   8.  Some possible English values for the "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.

6.  Internationalization Considerations

   Applications MUST generate iCalendar streams in the UTF-8 charset and
   MUST accept an iCalendar stream in the UTF-8 or US-ASCII charset.

7.  Security Considerations

   Because calendaring and scheduling information is very privacy-
   sensitive, the protocol used for the transmission of calendaring and
   scheduling information should have capabilities to protect the
   information from possible threats, such as eavesdropping, replay,
   message insertion, deletion, modification, and man-in-the-middle
   attacks.

   As this document only defines the data format and media type of text/
   calendar that is independent of any calendar service or protocol, it
   is up to the actual protocol specifications such as iTIP [2446bis],

Top      Up      ToC       Page 149 
   iMIP [2447bis], and "Calendaring Extensions to WebDAV (CalDAV)"
   [RFC4791] to describe the threats that the above attacks present, as
   well as ways in which to mitigate them.

8.  IANA Considerations

8.1.  iCalendar Media Type Registration

   The Calendaring and Scheduling Core Object Specification is intended
   for use as a MIME content type.

   To: ietf-types@iana.org

   Subject: Registration of media type text/calendar

   Type name:  text

   Subtype name:  calendar

   Required parameters:  none

   Optional parameters:  charset, method, component, and optinfo

      The "charset" parameter is defined in [RFC2046] for subtypes of
      the "text" media type.  It is used to indicate the charset used in
      the body part.  The charset supported by this revision of
      iCalendar is UTF-8.  The use of any other charset is deprecated by
      this revision of iCalendar; however, note that this revision
      requires that compliant applications MUST accept iCalendar streams
      using either the UTF-8 or US-ASCII charset.

      The "method" parameter is used to convey the iCalendar object
      method or transaction semantics for the calendaring and scheduling
      information.  It also is an identifier for the restricted set of
      properties and values of which the iCalendar object consists.  The
      parameter is to be used as a guide for applications interpreting
      the information contained within the body part.  It SHOULD NOT be
      used to exclude or require particular pieces of information unless
      the identified method definition specifically calls for this
      behavior.  Unless specifically forbidden by a particular method
      definition, a text/calendar content type can contain any set of
      properties permitted by the Calendaring and Scheduling Core Object
      Specification.  The "method" parameter MUST be specified and MUST
      be set to the same value as the "METHOD" component property of the
      iCalendar objects of the iCalendar stream if and only if the
      iCalendar objects in the iCalendar stream all have a "METHOD"
      component property set to the same value.

Top      Up      ToC       Page 150 
      The value for the "method" parameter is defined as follows:

       method  = 1*(ALPHA / DIGIT / "-")
       ; IANA-registered iCalendar object method

      The "component" parameter conveys the type of iCalendar calendar
      component within the body part.  If the iCalendar object contains
      more than one calendar component type, then multiple component
      parameters MUST be specified.

      The value for the "component" parameter is defined as follows:

       component = "VEVENT"
                 / "VTODO"
                 / "VJOURNAL"
                 / "VFREEBUSY"
                 / "VTIMEZONE"
                 / iana-token
                 / x-name

      The "optinfo" parameter conveys optional information about the
      iCalendar object within the body part.  This parameter can only
      specify semantics already specified by the iCalendar object and
      that can be otherwise determined by parsing the body part.  In
      addition, the optional information specified by this parameter
      MUST be consistent with that information specified by the
      iCalendar object.  For example, it can be used to convey the
      "Attendee" response status to a meeting request.  The parameter
      value consists of a string value.

      The parameter can be specified multiple times.

      The value for the "optinfo" parameter is defined as follows:

       optinfo    = infovalue / qinfovalue

       infovalue  = iana-token / x-name

       qinfovalue = DQUOTE (infovalue) DQUOTE

   Encoding considerations:  This media type can contain 8bit
      characters, so the use of quoted-printable or base64 MIME Content-
      Transfer-Encodings might be necessary when iCalendar objects are
      transferred across protocols restricted to the 7bit repertoire.
      Note that a text valued property in the content entity can also
      have content encoding of special characters using a BACKSLASH
      character escapement technique.  This means that content values
      can end up being encoded twice.

Top      Up      ToC       Page 151 
   Security considerations:  See Section 7.

   Interoperability considerations:  This media type is intended to
      define a common format for conveying calendaring and scheduling
      information between different systems.  It is heavily based on the
      earlier [VCAL] industry specification.

   Published specification:  This specification.

   Applications that use this media type:  This media type is designed
      for widespread use by Internet calendaring and scheduling
      applications.  In addition, applications in the workflow and
      document management area might find this content-type applicable.
      The iTIP [2446bis], iMIP [2447bis], and CalDAV [RFC4791] Internet
      protocols directly use this media type also.

   Additional information:

      Magic number(s):  None.

      File extension(s):  The file extension of "ics" is to be used to
         designate a file containing (an arbitrary set of) calendaring
         and scheduling information consistent with this MIME content
         type.

         The file extension of "ifb" is to be used to designate a file
         containing free or busy time information consistent with this
         MIME content type.

      Macintosh file type code(s):  The file type code of "iCal" is to
         be used in Apple MacIntosh operating system environments to
         designate a file containing calendaring and scheduling
         information consistent with this MIME media type.

         The file type code of "iFBf" is to be used in Apple MacIntosh
         operating system environments to designate a file containing
         free or busy time information consistent with this MIME media
         type.

   Person & email address to contact for further information:  See the
      "Author's Address" section of this document.

   Intended usage:  COMMON

   Restrictions on usage:  There are no restrictions on where this media
      type can be used.

   Author:  See the "Author's Address" section of this document.

Top      Up      ToC       Page 152 
   Change controller:  IETF

8.2.  New iCalendar Elements Registration

   This section defines the process to register new or modified
   iCalendar elements, that is, components, properties, parameters,
   value data types, and values, with IANA.

8.2.1.  iCalendar Elements Registration Procedure

   The IETF will create a mailing list, icalendar@ietf.org, which can be
   used for public discussion of iCalendar elements proposals prior to
   registration.  Use of the mailing list is strongly encouraged.  The
   IESG will appoint a designated expert who will monitor the
   icalendar@ietf.org mailing list and review registrations.

   Registration of new iCalendar elements MUST be reviewed by the
   designated expert and published in an RFC.  A Standards Track RFC is
   REQUIRED for the registration of new value data types that modify
   existing properties, as well as for the registration of participation
   status values to be used in "VEVENT" calendar components.  A
   Standards Track RFC is also REQUIRED for registration of iCalendar
   elements that modify iCalendar elements previously documented in a
   Standards Track RFC.

   The registration procedure begins when a completed registration
   template, defined in the sections below, is sent to
   icalendar@ietf.org and iana@iana.org.  The designated expert is
   expected to tell IANA and the submitter of the registration within
   two weeks whether the registration is approved, approved with minor
   changes, or rejected with cause.  When a registration is rejected
   with cause, it can be re-submitted if the concerns listed in the
   cause are addressed.  Decisions made by the designated expert can be
   appealed to the IESG Applications Area Director, then to the IESG.
   They follow the normal appeals procedure for IESG decisions.

8.2.2.  Registration Template for Components

   A component is defined by completing the following template.

   Component name:  The name of the component.

   Purpose:  The purpose of the component.  Give a short but clear
      description.

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

Top      Up      ToC       Page 153 
   Description:  Any special notes about the component, how it is to be
      used, etc.

   Example(s):  One or more examples of instances of the component need
      to be specified.

8.2.3.  Registration Template for Properties

   A property is defined by completing the following template.

   Property name:  The name of the property.

   Purpose:  The purpose of the property.  Give a short but clear
      description.

   Value type:  Any of the valid value types for the property value need
      to be specified.  The default value type also needs to be
      specified.

   Property parameters:  Any of the valid property parameters for the
      property MUST be specified.

   Conformance:  The calendar components in which the property can
      appear MUST 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.

   Example(s):  One or more examples of instances of the property need
      to be specified.

8.2.4.  Registration Template for Parameters

   A parameter is defined by completing the following template.

   Parameter name:  The name of the parameter.

   Purpose:  The purpose of the parameter.  Give a short but clear
      description.

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

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

Top      Up      ToC       Page 154 
   Example(s):  One or more examples of instances of the parameter need
      to be specified.

8.2.5.  Registration Template for Value Data Types

   A value data type is defined by completing the following template.

   Value name:  The name of the value type.

   Purpose:  The purpose of the value type.  Give a short but clear
      description.

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

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

   Example(s):  One or more examples of instances of the value type need
      to be specified.

8.2.6.  Registration Template for Values

   A value is defined by completing the following template.

   Value:  The value literal.

   Purpose:  The purpose of the value.  Give a short but clear
      description.

   Conformance:  The calendar properties and/or parameters that can take
      this value need to be specified.

   Example(s):  One or more examples of instances of the value need to
      be specified.

   The following is a fictitious example of a registration of an
   iCalendar value:

   Value:  TOP-SECRET

   Purpose:  This value is used to specify the access classification of
      top-secret calendar components.

   Conformance:  This value can be used with the "CLASS" property.

Top      Up      ToC       Page 155 
   Example(s):  The following is an example of this value used with the
      "CLASS" property:

     CLASS:TOP-SECRET

8.3.  Initial iCalendar Elements Registries

   The IANA created and maintains the following registries for iCalendar
   elements with pointers to appropriate reference documents.

8.3.1.  Components Registry

   The following table has been used to initialize the components
   registry.

             +-----------+---------+-------------------------+
             | Component | Status  | Reference               |
             +-----------+---------+-------------------------+
             | VCALENDAR | Current | RFC 5545, Section 3.4   |
             |           |         |                         |
             | VEVENT    | Current | RFC 5545, Section 3.6.1 |
             |           |         |                         |
             | VTODO     | Current | RFC 5545, Section 3.6.2 |
             |           |         |                         |
             | VJOURNAL  | Current | RFC 5545, Section 3.6.3 |
             |           |         |                         |
             | VFREEBUSY | Current | RFC 5545, Section 3.6.4 |
             |           |         |                         |
             | VTIMEZONE | Current | RFC 5545, Section 3.6.5 |
             |           |         |                         |
             | VALARM    | Current | RFC 5545, Section 3.6.6 |
             |           |         |                         |
             | STANDARD  | Current | RFC 5545, Section 3.6.5 |
             |           |         |                         |
             | DAYLIGHT  | Current | RFC 5545, Section 3.6.5 |
             +-----------+---------+-------------------------+

Top      Up      ToC       Page 156 
8.3.2.  Properties Registry

   The following table is has been used to initialize the properties
   registry.

      +------------------+------------+----------------------------+
      | Property         | Status     | Reference                  |
      +------------------+------------+----------------------------+
      | CALSCALE         | Current    | RFC 5545, Section 3.7.1    |
      | METHOD           | Current    | RFC 5545, Section 3.7.2    |
      |                  |            |                            |
      | PRODID           | Current    | RFC 5545, Section 3.7.3    |
      |                  |            |                            |
      | VERSION          | Current    | RFC 5545, Section 3.7.4    |
      |                  |            |                            |
      | ATTACH           | Current    | RFC 5545, Section 3.8.1.1  |
      |                  |            |                            |
      | CATEGORIES       | Current    | RFC 5545, Section 3.8.1.2  |
      |                  |            |                            |
      | CLASS            | Current    | RFC 5545, Section 3.8.1.3  |
      |                  |            |                            |
      | COMMENT          | Current    | RFC 5545, Section 3.8.1.4  |
      |                  |            |                            |
      | DESCRIPTION      | Current    | RFC 5545, Section 3.8.1.5  |
      |                  |            |                            |
      | GEO              | Current    | RFC 5545, Section 3.8.1.6  |
      |                  |            |                            |
      | LOCATION         | Current    | RFC 5545, Section 3.8.1.7  |
      |                  |            |                            |
      | PERCENT-COMPLETE | Current    | RFC 5545, Section 3.8.1.8  |
      |                  |            |                            |
      | PRIORITY         | Current    | RFC 5545, Section 3.8.1.9  |
      |                  |            |                            |
      | RESOURCES        | Current    | RFC 5545, Section 3.8.1.10 |
      |                  |            |                            |
      | STATUS           | Current    | RFC 5545, Section 3.8.1.11 |
      |                  |            |                            |
      | SUMMARY          | Current    | RFC 5545, Section 3.8.1.12 |
      |                  |            |                            |
      | COMPLETED        | Current    | RFC 5545, Section 3.8.2.1  |
      |                  |            |                            |
      | DTEND            | Current    | RFC 5545, Section 3.8.2.2  |
      |                  |            |                            |
      | DUE              | Current    | RFC 5545, Section 3.8.2.3  |
      |                  |            |                            |
      | DTSTART          | Current    | RFC 5545, Section 3.8.2.4  |
      |                  |            |                            |
      | DURATION         | Current    | RFC 5545, Section 3.8.2.5  |

Top      Up      ToC       Page 157 
      |                  |            |                            |
      | FREEBUSY         | Current    | RFC 5545, Section 3.8.2.6  |
      |                  |            |                            |
      | TRANSP           | Current    | RFC 5545, Section 3.8.2.7  |
      |                  |            |                            |
      | TZID             | Current    | RFC 5545, Section 3.8.3.1  |
      |                  |            |                            |
      | TZNAME           | Current    | RFC 5545, Section 3.8.3.2  |
      |                  |            |                            |
      | TZOFFSETFROM     | Current    | RFC 5545, Section 3.8.3.3  |
      |                  |            |                            |
      | TZOFFSETTO       | Current    | RFC 5545, Section 3.8.3.4  |
      |                  |            |                            |
      | TZURL            | Current    | RFC 5545, Section 3.8.3.5  |
      |                  |            |                            |
      | ATTENDEE         | Current    | RFC 5545, Section 3.8.4.1  |
      |                  |            |                            |
      | CONTACT          | Current    | RFC 5545, Section 3.8.4.2  |
      |                  |            |                            |
      | ORGANIZER        | Current    | RFC 5545, Section 3.8.4.3  |
      |                  |            |                            |
      | RECURRENCE-ID    | Current    | RFC 5545, Section 3.8.4.4  |
      |                  |            |                            |
      | RELATED-TO       | Current    | RFC 5545, Section 3.8.4.5  |
      |                  |            |                            |
      | URL              | Current    | RFC 5545, Section 3.8.4.6  |
      |                  |            |                            |
      | UID              | Current    | RFC 5545, Section 3.8.4.7  |
      |                  |            |                            |
      | EXDATE           | Current    | RFC 5545, Section 3.8.5.1  |
      |                  |            |                            |
      | EXRULE           | Deprecated | [RFC2445], Section 4.8.5.2 |
      |                  |            |                            |
      | RDATE            | Current    | RFC 5545, Section 3.8.5.2  |
      |                  |            |                            |
      | RRULE            | Current    | RFC 5545, Section 3.8.5.3  |
      |                  |            |                            |
      | ACTION           | Current    | RFC 5545, Section 3.8.6.1  |
      |                  |            |                            |
      | REPEAT           | Current    | RFC 5545, Section 3.8.6.2  |
      |                  |            |                            |
      | TRIGGER          | Current    | RFC 5545, Section 3.8.6.3  |
      |                  |            |                            |
      | CREATED          | Current    | RFC 5545, Section 3.8.7.1  |
      |                  |            |                            |
      | DTSTAMP          | Current    | RFC 5545, Section 3.8.7.2  |
      |                  |            |                            |
      | LAST-MODIFIED    | Current    | RFC 5545, Section 3.8.7.3  |

Top      Up      ToC       Page 158 
      |                  |            |                            |
      | SEQUENCE         | Current    | RFC 5545, Section 3.8.7.4  |
      |                  |            |                            |
      | REQUEST-STATUS   | Current    | RFC 5545, Section 3.8.8.3  |
      +------------------+------------+----------------------------+

8.3.3.  Parameters Registry

   The following table has been used to initialize the parameters
   registry.

          +----------------+---------+--------------------------+
          | Parameter      | Status  | Reference                |
          +----------------+---------+--------------------------+
          | ALTREP         | Current | RFC 5545, Section 3.2.1  |
          |                |         |                          |
          | CN             | Current | RFC 5545, Section 3.2.2  |
          |                |         |                          |
          | CUTYPE         | Current | RFC 5545, Section 3.2.3  |
          |                |         |                          |
          | DELEGATED-FROM | Current | RFC 5545, Section 3.2.4  |
          |                |         |                          |
          | DELEGATED-TO   | Current | RFC 5545, Section 3.2.5  |
          |                |         |                          |
          | DIR            | Current | RFC 5545, Section 3.2.6  |
          |                |         |                          |
          | ENCODING       | Current | RFC 5545, Section 3.2.7  |
          |                |         |                          |
          | FMTTYPE        | Current | RFC 5545, Section 3.2.8  |
          |                |         |                          |
          | FBTYPE         | Current | RFC 5545, Section 3.2.9  |
          |                |         |                          |
          | LANGUAGE       | Current | RFC 5545, Section 3.2.10 |
          |                |         |                          |
          | MEMBER         | Current | RFC 5545, Section 3.2.11 |
          |                |         |                          |
          | PARTSTAT       | Current | RFC 5545, Section 3.2.12 |
          |                |         |                          |
          | RANGE          | Current | RFC 5545, Section 3.2.13 |
          |                |         |                          |
          | RELATED        | Current | RFC 5545, Section 3.2.14 |
          |                |         |                          |
          | RELTYPE        | Current | RFC 5545, Section 3.2.15 |
          |                |         |                          |
          | ROLE           | Current | RFC 5545, Section 3.2.16 |
          |                |         |                          |
          | RSVP           | Current | RFC 5545, Section 3.2.17 |
          |                |         |                          |

Top      Up      ToC       Page 159 
          | SENT-BY        | Current | RFC 5545, Section 3.2.18 |
          |                |         |                          |
          | TZID           | Current | RFC 5545, Section 3.2.19 |
          |                |         |                          |
          | VALUE          | Current | RFC 5545, Section 3.2.20 |
          +----------------+---------+--------------------------+

8.3.4.  Value Data Types Registry

   The following table has been used to initialize the value data types
   registry.

         +-----------------+---------+--------------------------+
         | Value Data Type | Status  | Reference                |
         +-----------------+---------+--------------------------+
         | BINARY          | Current | RFC 5545, Section 3.3.1  |
         |                 |         |                          |
         | BOOLEAN         | Current | RFC 5545, Section 3.3.2  |
         |                 |         |                          |
         | CAL-ADDRESS     | Current | RFC 5545, Section 3.3.3  |
         |                 |         |                          |
         | DATE            | Current | RFC 5545, Section 3.3.4  |
         |                 |         |                          |
         | DATE-TIME       | Current | RFC 5545, Section 3.3.5  |
         |                 |         |                          |
         | DURATION        | Current | RFC 5545, Section 3.3.6  |
         |                 |         |                          |
         | FLOAT           | Current | RFC 5545, Section 3.3.7  |
         |                 |         |                          |
         | INTEGER         | Current | RFC 5545, Section 3.3.8  |
         |                 |         |                          |
         | PERIOD          | Current | RFC 5545, Section 3.3.9  |
         |                 |         |                          |
         | RECUR           | Current | RFC 5545, Section 3.3.10 |
         |                 |         |                          |
         | TEXT            | Current | RFC 5545, Section 3.3.11 |
         |                 |         |                          |
         | TIME            | Current | RFC 5545, Section 3.3.12 |
         |                 |         |                          |
         | URI             | Current | RFC 5545, Section 3.3.13 |
         |                 |         |                          |
         | UTC-OFFSET      | Current | RFC 5545, Section 3.3.14 |
         +-----------------+---------+--------------------------+

Top      Up      ToC       Page 160 
8.3.5.  Calendar User Types Registry

   The following table has been used to initialize the calendar user
   types registry.

        +--------------------+---------+-------------------------+
        | Calendar User Type | Status  | Reference               |
        +--------------------+---------+-------------------------+
        | INDIVIDUAL         | Current | RFC 5545, Section 3.2.3 |
        |                    |         |                         |
        | GROUP              | Current | RFC 5545, Section 3.2.3 |
        |                    |         |                         |
        | RESOURCE           | Current | RFC 5545, Section 3.2.3 |
        |                    |         |                         |
        | ROOM               | Current | RFC 5545, Section 3.2.3 |
        |                    |         |                         |
        | UNKNOWN            | Current | RFC 5545, Section 3.2.3 |
        +--------------------+---------+-------------------------+

8.3.6.  Free/Busy Time Types Registry

   The following table has been used to initialize the free/busy time
   types registry.

        +---------------------+---------+-------------------------+
        | Free/Busy Time Type | Status  | Reference               |
        +---------------------+---------+-------------------------+
        | FREE                | Current | RFC 5545, Section 3.2.9 |
        |                     |         |                         |
        | BUSY                | Current | RFC 5545, Section 3.2.9 |
        |                     |         |                         |
        | BUSY-UNAVAILABLE    | Current | RFC 5545, Section 3.2.9 |
        |                     |         |                         |
        | BUSY-TENTATIVE      | Current | RFC 5545, Section 3.2.9 |
        +---------------------+---------+-------------------------+

Top      Up      ToC       Page 161 
8.3.7.  Participation Statuses Registry

   The following table has been used to initialize the participation
   statuses registry.

        +--------------------+---------+--------------------------+
        | Participant Status | Status  | Reference                |
        +--------------------+---------+--------------------------+
        | NEEDS-ACTION       | Current | RFC 5545, Section 3.2.12 |
        |                    |         |                          |
        | ACCEPTED           | Current | RFC 5545, Section 3.2.12 |
        |                    |         |                          |
        | DECLINED           | Current | RFC 5545, Section 3.2.12 |
        |                    |         |                          |
        | TENTATIVE          | Current | RFC 5545, Section 3.2.12 |
        |                    |         |                          |
        | DELEGATED          | Current | RFC 5545, Section 3.2.12 |
        |                    |         |                          |
        | COMPLETED          | Current | RFC 5545, Section 3.2.12 |
        |                    |         |                          |
        | IN-PROCESS         | Current | RFC 5545, Section 3.2.12 |
        +--------------------+---------+--------------------------+

8.3.8.  Relationship Types Registry

   The following table has been used to initialize the relationship
   types registry.

        +-------------------+---------+--------------------------+
        | Relationship Type | Status  | Reference                |
        +-------------------+---------+--------------------------+
        | CHILD             | Current | RFC 5545, Section 3.2.15 |
        |                   |         |                          |
        | PARENT            | Current | RFC 5545, Section 3.2.15 |
        |                   |         |                          |
        | SIBLING           | Current | RFC 5545, Section 3.2.15 |
        +-------------------+---------+--------------------------+

Top      Up      ToC       Page 162 
8.3.9.  Participation Roles Registry

   The following table has been used to initialize the participation
   roles registry.

         +-----------------+---------+--------------------------+
         | Role Type       | Status  | Reference                |
         +-----------------+---------+--------------------------+
         | CHAIR           | Current | RFC 5545, Section 3.2.16 |
         |                 |         |                          |
         | REQ-PARTICIPANT | Current | RFC 5545, Section 3.2.16 |
         |                 |         |                          |
         | OPT-PARTICIPANT | Current | RFC 5545, Section 3.2.16 |
         |                 |         |                          |
         | NON-PARTICIPANT | Current | RFC 5545, Section 3.2.16 |
         +-----------------+---------+--------------------------+

8.3.10.  Actions Registry

   The following table has been used to initialize the actions registry.

          +-----------+------------+----------------------------+
          | Action    | Status     | Reference                  |
          +-----------+------------+----------------------------+
          | AUDIO     | Current    | RFC 5545, Section 3.8.6.1  |
          |           |            |                            |
          | DISPLAY   | Current    | RFC 5545, Section 3.8.6.1  |
          |           |            |                            |
          | EMAIL     | Current    | RFC 5545, Section 3.8.6.1  |
          |           |            |                            |
          | PROCEDURE | Deprecated | [RFC2445], Section 4.8.6.1 |
          +-----------+------------+----------------------------+

8.3.11.  Classifications Registry

   The following table has been used to initialize the classifications
   registry.

         +----------------+---------+---------------------------+
         | Classification | Status  | Reference                 |
         +----------------+---------+---------------------------+
         | PUBLIC         | Current | RFC 5545, Section 3.8.1.3 |
         |                |         |                           |
         | PRIVATE        | Current | RFC 5545, Section 3.8.1.3 |
         |                |         |                           |
         | CONFIDENTIAL   | Current | RFC 5545, Section 3.8.1.3 |
         +----------------+---------+---------------------------+

Top      Up      ToC       Page 163 
8.3.12.  Methods Registry

   No values are defined in this document for the "METHOD" property.

9.  Acknowledgments

   The editor of this document wishes to thank Frank Dawson and Derik
   Stenerson, the original authors of RFC 2445, as well as the following
   individuals who have participated in the drafting, review, and
   discussion of this memo:

   Joe Abley, Hervey Allen, Steve Allen, Jay Batson, Oliver Block,
   Stephane Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus
   Daboo, Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Lars Eggert,
   Gren Eliot, Pasi Eronen, Ben Fortuna, Ned Freed, Neal Gafter, Ted
   Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Paul B. Hill, Thomas
   Hnetila, Russ Housley, Leif Johansson, Ciny Joy, Bruce Kahn, Reinhold
   Kainhofer, Martin Kiff, Patrice Lapierre, Michiel van Leeuwen,
   Jonathan Lennox, Jeff McCullough, Bill McQuillan, Alexey Melnikov,
   John W. Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette,
   Arnaud Quillaud, Robert Ransdell, Julian F. Reschke, Caleb
   Richardson, Sam Roberts, Dan Romascanu, Mike Samuel, George Sexton,
   Nigel Swinson, Clint Talbert, Simon Vaillancourt, Magnus Westerlund,
   and Sandy Wills.

   A special thanks to the working group chairs Aki Niemi and Eliot Lear
   for their support and guidance.

   The editor would also like to thank the Calendaring and Scheduling
   Consortium for advice with this specification, and for organizing
   interoperability testing events to help refine it.

Top      Up      ToC       Page 164 
10.  References

10.1.  Normative References

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

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

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

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

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

   [RFC2368]              Hoffman, P., Masinter, L., and J. Zawinski,
                          "The mailto URL scheme", RFC 2368, July 1998.

   [RFC3629]              Yergeau, F., "UTF-8, a transformation format
                          of ISO 10646", STD 63, RFC 3629,
                          November 2003.

   [RFC3986]              Berners-Lee, T., Fielding, R., and L.
                          Masinter, "Uniform Resource Identifier (URI):
                          Generic Syntax", STD 66, RFC 3986,
                          January 2005.

   [RFC4288]              Freed, N. and J. Klensin, "Media Type
                          Specifications and Registration Procedures",
                          BCP 13, RFC 4288, December 2005.

   [RFC4648]              Josefsson, S., "The Base16, Base32, and Base64
                          Data Encodings", RFC 4648, October 2006.

Top      Up      ToC       Page 165 
   [RFC5234]              Crocker, D. and P. Overell, "Augmented BNF for
                          Syntax Specifications: ABNF", STD 68,
                          RFC 5234, January 2008.

   [RFC5646]              Phillips, A., Ed., and M. Davis, Ed., "Tags
                          for Identifying Languages", BCP 47, RFC 5646,
                          September 2009.

   [US-ASCII]             American National Standards Institute, "Coded
                          Character Set - 7-bit American Standard Code
                          for Information Interchange", ANSI X3.4, 1986.

10.2.  Informative References

   [2446bis]              Daboo, C., "iCalendar Transport-Independent
                          Interoperability Protocol (iTIP)", Work
                          in Progress, April 2009.

   [2447bis]              Melnikov, A., "iCalendar Message-Based
                          Interoperability Protocol (iMIP)", Work
                          in Progress, June 2008.

   [ANSI INCITS 61-1986]  International Committee for Information
                          Technology, "Representation of Geographic
                          Point Locations for Information Interchange
                          (formerly ANSI X3.61-1986 (R1997))", ANSI
                          INCITS 61-1986 (R2007), 2007.

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

   [RFC2392]              Levinson, E., "Content-ID and Message-ID
                          Uniform Resource Locators", RFC 2392,
                          August 1998.

   [RFC2397]              Masinter, L., "The "data" URL scheme",
                          RFC 2397, August 1998.

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

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

Top      Up      ToC       Page 166 
   [RFC2445]              Dawson, F. and Stenerson, D., "Internet
                          Calendaring and Scheduling Core Object
                          Specification (iCalendar)", RFC 2445,
                          November 1998.

   [RFC2616]              Fielding, R., Gettys, J., Mogul, J., Frystyk,
                          H., Masinter, L., Leach, P., and T. Berners-
                          Lee, "Hypertext Transfer Protocol --
                          HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]              Rescorla, E., "HTTP Over TLS", RFC 2818,
                          May 2000.

   [RFC4516]              Smith, M. and T. Howes, "Lightweight Directory
                          Access Protocol (LDAP): Uniform Resource
                          Locator", RFC 4516, June 2006.

   [RFC4791]              Daboo, C., Desruisseaux, B., and L. Dusseault,
                          "Calendaring Extensions to WebDAV (CalDAV)",
                          RFC 4791, March 2007.

   [TZDB]                 Eggert, P. and A.D. Olson, "Sources for Time
                          Zone and Daylight Saving Time Data",
                          July 2009,
                          <http://www.twinsun.com/tz/tz-link.htm>.

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

Top      Up      ToC       Page 167 
Appendix A.  Differences from RFC 2445

   This appendix contains a list of changes that have been made in the
   Internet Calendaring and Scheduling Core Object Specification from
   RFC 2445.

A.1.  New Restrictions

   1.  The "DTSTART" property SHOULD be synchronized with the recurrence
       rule, if specified.

   2.  The "RRULE" property SHOULD NOT occur more than once in a
       component.

   3.  The BYHOUR, BYMINUTE, and BYSECOND rule parts MUST NOT be
       specified in the "RRULE" property when the "DTSTART" property is
       specified as a DATE value.

   4.  The value type of the "DTEND" or "DUE" properties MUST match the
       value type of "DTSTART" property.

   5.  The "DURATION" property can no longer appear in "VFREEBUSY"
       components.

A.2.  Restrictions Removed

   1.  The "DTSTART" and "DTEND" properties are no longer required to be
       specified as date with local time and time zone reference when
       used with a recurrence rule.

A.3.  Deprecated Features

   1.  The "EXRULE" property can no longer be specified in a component.

   2.  The "THISANDPRIOR" value can no longer be used with the "RANGE"
       parameter.

   3.  The "PROCEDURE" value can no longer be used with the "ACTION"
       property.

   4.  The value type RECUR no longer allows multiple values to be
       specified by a COMMA-separated list of values.

   5.  x-name rule parts can no longer be specified in properties of
       RECUR value type (e.g., "RRULE"). x-param can be used on RECUR
       value type properties instead.

Top      Up      ToC       Page 168 
Author's Address

   Bernard Desruisseaux (editor)
   Oracle Corporation
   600 blvd. de Maisonneuve West
   Suite 1900
   Montreal, QC  H3A 3J2
   CANADA

   EMail: bernard.desruisseaux@oracle.com
   URI:   http://www.oracle.com/