RFC 5545
Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Pages: 168
Proposed Standard
→ Errata
Obsoletes: 2445
Updated by: 5546 6868 7529 7953 7986 9073 9074 9253
Proposed Standard
→ Errata
Obsoletes: 2445
Updated by: 5546 6868 7529 7953 7986 9073 9074 9253
Part 7 of 7 – Pages 144 to 168
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
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
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.
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
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],
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.
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.
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.
Change controller: IETF8.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.
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.
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.
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 |
+-----------+---------+-------------------------+
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 |
| | | |
| 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 |
| | | |
| 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 |
| | | |
| 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 |
+-----------------+---------+--------------------------+
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 | +---------------------+---------+-------------------------+
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 | +-------------------+---------+--------------------------+
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 | +----------------+---------+---------------------------+
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.
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.
[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.
[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>.
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.
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/