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 1 of 7 – Pages 1 to 13
Network Working Group B. Desruisseaux, Ed. Request for Comments: 5545 Oracle Obsoletes: 2445 September 2009 Category: Standards Track Internet Calendaring and Scheduling Core Object Specification (iCalendar)Abstract
This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other than English.Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49
3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50
3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51
3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52
3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 55
3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 57
3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 59
3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 62
3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 71
3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 76
3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 76
3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 77
3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 78
3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 79
3.8. Component Properties . . . . . . . . . . . . . . . . . . 80
3.8.1. Descriptive Component Properties . . . . . . . . . . 80
3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 80
3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 81
3.8.1.3. Classification . . . . . . . . . . . . . . . . . 82
3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 83
3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 84
3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 85
3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 87
3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 88
3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 89
3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 91
3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 92
3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 93
3.8.2. Date and Time Component Properties . . . . . . . . . 94
3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 94
3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 95
3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 96
3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 97
3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 99
3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 100
3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 101
3.8.3. Time Zone Component Properties . . . . . . . . . . . 102
3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 102
3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 103
3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 104
3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 105
3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 106
3.8.4. Relationship Component Properties . . . . . . . . . . 106
3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 107
3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 109
3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 111
3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 112
3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 115
3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 116
3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 117
3.8.5. Recurrence Component Properties . . . . . . . . . . . 118
3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 118
3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 120
3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 122
3.8.6. Alarm Component Properties . . . . . . . . . . . . . 132
3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 132
3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 133
3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 133
3.8.7. Change Management Component Properties . . . . . . . 136
3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 136
3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 137
3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 138
3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 138
3.8.8. Miscellaneous Component Properties . . . . . . . . . 139
3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 140
3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 140
3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 141
4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144
5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147
6. Internationalization Considerations . . . . . . . . . . . . . 148
7. Security Considerations . . . . . . . . . . . . . . . . . . . 148
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149
8.1. iCalendar Media Type Registration . . . . . . . . . . . . 149
8.2. New iCalendar Elements Registration . . . . . . . . . . . 152
8.2.1. iCalendar Elements Registration Procedure . . . . . . 152
8.2.2. Registration Template for Components . . . . . . . . 152
8.2.3. Registration Template for Properties . . . . . . . . 153
8.2.4. Registration Template for Parameters . . . . . . . . 153
8.2.5. Registration Template for Value Data Types . . . . . 154
8.2.6. Registration Template for Values . . . . . . . . . . 154
8.3. Initial iCalendar Elements Registries . . . . . . . . . . 155
8.3.1. Components Registry . . . . . . . . . . . . . . . . . 155
8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 156
8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 158
8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 159
8.3.5. Calendar User Types Registry . . . . . . . . . . . . 160
8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 160
8.3.7. Participation Statuses Registry . . . . . . . . . . . 161
8.3.8. Relationship Types Registry . . . . . . . . . . . . . 161
8.3.9. Participation Roles Registry . . . . . . . . . . . . 162
8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 162
8.3.11. Classifications Registry . . . . . . . . . . . . . . 162
8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 163
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 164 10.1. Normative References . . . . . . . . . . . . . . . . . . 164 10.2. Informative References . . . . . . . . . . . . . . . . . 165 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167 A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167 A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167 A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 1671. Introduction
The use of calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. This memo is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications. This memo defines a MIME content type for exchanging electronic calendaring and scheduling information. The Internet Calendaring and Scheduling Core Object Specification, or iCalendar, allows for the capture and exchange of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager (PIM) or a Group-Scheduling product. The iCalendar format is suitable as an exchange format between applications or systems. The format is defined in terms of a MIME content type. This will enable the object to be exchanged using several transports, including but not limited to SMTP, HTTP, a file system, desktop interactive protocols such as the use of a memory- based clipboard or drag/drop interactions, point-to-point asynchronous communication, wired-network transport, or some form of unwired transport such as infrared. The memo also provides for the definition of iCalendar object methods that will map this content type to a set of messages for supporting calendaring and scheduling operations such as requesting, replying to, modifying, and canceling meetings or appointments, to-dos, and journal entries. The iCalendar object methods can be used to define other calendaring and scheduling operations such as requesting for and replying with free/busy time data. Such a scheduling protocol is defined in the iCalendar Transport-independent Interoperability Protocol (iTIP) defined in [2446bis]. The memo also includes a formal grammar for the content type based on the Internet ABNF defined in [RFC5234]. This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. Additional restrictions
that could not easily be expressed with the ABNF syntax are specified as comments in the ABNF. Comments with normative statements should be treated as such.2. Basic Grammar and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC5234]. Readers intending on implementing the format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values, and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. The format for the iCalendar object is based on the syntax of the text/directory media type [RFC2425]. While the iCalendar object is not a profile of the text/directory media type [RFC2425], it does reuse a number of the elements from the [RFC2425] specification.2.1. Formatting Conventions
The elements defined in this memo are defined in prose. Many of the terms used to describe these have common usage that is different than the standards usage of this memo. In order to reference, within this memo, elements of the calendaring and scheduling model, core object (this memo), or interoperability protocol [2446bis] some formatting conventions have been used. Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in uppercase. For example, "Organizer" refers to a role of a "Calendar User" within the scheduling protocol defined by [2446bis]. Calendar components defined by this memo are referred to
with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component, and "VJOURNAL" refers to the daily journal calendar component. Scheduling methods defined by iTIP [2446bis] are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified, and "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component. The properties defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a calendar user. Property parameters defined by this memo are referred to with lowercase, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default value type for a property value. Enumerated values defined by this memo are referred to with capitalized text, either alone or followed by the word "value". For example, the "MINUTELY" value can be used with the "FREQ" component of the "RECUR" value type to specify repeating components based on an interval of one minute or more. The following table lists the different characters from the [US-ASCII] character set that is referenced in this document. For each character, the table specifies the character name used throughout this document, along with its US-ASCII decimal codepoint.
+------------------------+-------------------+
| Character name | Decimal codepoint |
+------------------------+-------------------+
| HTAB | 9 |
| LF | 10 |
| CR | 13 |
| DQUOTE | 22 |
| SPACE | 32 |
| PLUS SIGN | 43 |
| COMMA | 44 |
| HYPHEN-MINUS | 45 |
| PERIOD | 46 |
| SOLIDUS | 47 |
| COLON | 58 |
| SEMICOLON | 59 |
| LATIN CAPITAL LETTER N | 78 |
| LATIN CAPITAL LETTER T | 84 |
| LATIN CAPITAL LETTER X | 88 |
| LATIN CAPITAL LETTER Z | 90 |
| BACKSLASH | 92 |
| LATIN SMALL LETTER N | 110 |
+------------------------+-------------------+
2.2. Related Memos
Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and
scheduling standards. This memo specifies a core specification of
objects, value types, properties, and property parameters.
o iTIP [2446bis] specifies an interoperability protocol for
scheduling between different implementations;
o iCalendar Message-Based Interoperability Protocol (iMIP) [2447bis]
specifies an Internet email binding for [2446bis].
This memo does not attempt to repeat the specification of concepts or
definitions from these other memos. Where possible, references are
made to the memo that provides for the specification of these
concepts or definitions.
3. iCalendar Object Specification
The following sections define the details of a Calendaring and
Scheduling Core Object Specification. The Calendaring and Scheduling
Core Object is a collection of calendaring and scheduling
information. Typically, this information will consist of an
iCalendar stream with one or more iCalendar objects. The body of the
iCalendar object consists of a sequence of calendar properties and one or more calendar components. Section 3.1 defines the content line format; Section 3.2 defines the property parameter format; Section 3.3 defines the data types for property values; Section 3.4 defines the iCalendar object format; Section 3.5 defines the iCalendar property format; Section 3.6 defines the calendar component format; Section 3.7 defines calendar properties; and Section 3.8 defines calendar component properties. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory-, or network-based transport mechanisms.3.1. Content Lines
The iCalendar object is organized into individual lines of text, called content lines. Content lines are delimited by a line break, which is a CRLF sequence (CR character followed by LF character). Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white-space character (i.e., SPACE or HTAB). Any sequence of CRLF followed immediately by a single linear white-space character is ignored (i.e., removed) when processing the content type. For example, the line: DESCRIPTION:This is a long description that exists on a long line. Can be represented as: DESCRIPTION:This is a lo ng description that exists on a long line. The process of moving from this folded multiple-line representation to its single-line representation is called "unfolding". Unfolding is accomplished by removing the CRLF and the linear white-space character that immediately follows.
When parsing a content line, folded lines MUST first be unfolded
according to the unfolding procedure described above.
Note: It is possible for very simple implementations to generate
improperly folded lines in the middle of a UTF-8 multi-octet
sequence. For this reason, implementations need to unfold lines
in such a way to properly restore the original sequence.
The content information associated with an iCalendar object is
formatted using a syntax similar to that defined by [RFC2425]. That
is, the content information consists of CRLF-separated content lines.
The following notation defines the lines of content in an iCalendar
object:
contentline = name *(";" param ) ":" value CRLF
; This ABNF is just a general definition for an initial parsing
; of the content line into its property name, parameter list,
; and value string
; When parsing a content line, folded lines MUST first
; be unfolded according to the unfolding procedure
; described above. When generating a content line, lines
; longer than 75 octets SHOULD be folded according to
; the folding procedure described above.
name = iana-token / x-name
iana-token = 1*(ALPHA / DIGIT / "-")
; iCalendar identifier registered with IANA
x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
; Reserved for experimental use.
vendorid = 3*(ALPHA / DIGIT)
; Vendor identification
param = param-name "=" param-value *("," param-value)
; Each property defines the specific ABNF for the parameters
; allowed on the property. Refer to specific properties for
; precise parameter ABNF.
param-name = iana-token / x-name
param-value = paramtext / quoted-string
paramtext = *SAFE-CHAR
value = *VALUE-CHAR
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
; Any character except CONTROL and DQUOTE
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
/ NON-US-ASCII
; Any character except CONTROL, DQUOTE, ";", ":", ","
VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
; Any textual character
NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4
; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629]
CONTROL = %x00-08 / %x0A-1F / %x7F
; All the controls except HTAB
The property value component of a content line has a format that is
property specific. Refer to the section describing each property for
a definition of this format.
All names of properties, property parameters, enumerated property
values and property parameter values are case-insensitive. However,
all other property values are case-sensitive, unless otherwise
stated.
3.1.1. List and Field Separators
Some properties and parameters allow a list of values. Values in a
list of values MUST be separated by a COMMA character. There is no
significance to the order of values in a list. For those parameter
values (such as those that specify URI values) that are specified in
quoted-strings, the individual quoted-strings are separated by a
COMMA character.
Some property values are defined in terms of multiple parts. These
structured property values MUST have their value parts separated by a
SEMICOLON character.
Some properties allow a list of parameters. Each property parameter
in a list of property parameters MUST be separated by a SEMICOLON
character.
Property parameters with values containing a COLON character, a
SEMICOLON character or a COMMA character MUST be placed in quoted
text.
For example, in the following properties, a SEMICOLON is used to
separate property parameters from each other and a COMMA character is
used to separate property values in a value list.
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto:
jsmith@example.com
RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
3.1.2. Multiple Values
Some properties defined in the iCalendar object can have multiple
values. The general rule for encoding multi-valued items is to
simply create a new content line for each value, including the
property name. However, it should be noted that some properties
support encoding multiple values in a single property by separating
the values with a COMMA character. Individual property definitions
should be consulted for determining whether a specific property
allows multiple values and in which of these two forms. Multi-valued
properties MUST NOT be used to specify multiple language variants of
the same value. Calendar applications SHOULD display all values.
3.1.3. Binary Content
Binary content information in an iCalendar object SHOULD be
referenced using a URI within a property value. That is, the binary
content information SHOULD be placed in an external MIME entity that
can be referenced by a URI from within the iCalendar object. In
applications where this is not feasible, binary content information
can be included within an iCalendar object, but only after first
encoding it into text using the "BASE64" encoding method defined in
[RFC4648]. Inline binary content SHOULD only be used in applications
whose special circumstances demand that an iCalendar object be
expressed as a single entity. A property containing inline binary
content information MUST specify the "ENCODING" property parameter.
Binary content information placed external to the iCalendar object
MUST be referenced by a uniform resource identifier (URI).
The following example specifies an "ATTACH" property that references
an attachment external to the iCalendar object with a URI reference:
ATTACH:http://example.com/public/quarterly-report.doc
The following example specifies an "ATTACH" property with inline
binary encoded content information:
ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:VGhlIH
F1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4
3.1.4. Character Set
There is not a property parameter to declare the charset used in a
property value. The default charset for an iCalendar stream is UTF-8
as defined in [RFC3629].
The "charset" Content-Type parameter MUST be used in MIME transports
to specify the charset being used.
(page 13 continued on part 2)