kopia lustrzana https://github.com/collective/icalendar
199 wiersze
7.4 KiB
ReStructuredText
199 wiersze
7.4 KiB
ReStructuredText
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.
|