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