Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5545

Internet Calendaring and Scheduling Core Object Specification (iCalendar)

Pages: 168
Proposed Standard
Errata
Obsoletes:  2445
Updated by:  55466868752979537986907390749253
Part 7 of 7 – Pages 144 to 168
First   Prev   None

Top   ToC   RFC5545 - Page 144   prevText

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