Commit 302b94e5 authored by Mark Stenglein's avatar Mark Stenglein

Add notes from Chapter 3.1 (Content Lines)

- Should be clear to implement the content line interface.
parent ab487c5c
......@@ -15,6 +15,106 @@ This file tracks how far into the RFC document the project has made it to.
### 3.1. Content Lines
The iCalendar object is organized into lines of text, called **content lines**.
Content lines **SHOULD NOT** be longer than **75 octets**, excluding the line
breaks.
- Content lines **SHOULD** be split into multiple line representations via
*folding*. This can be done by inserting a **CRLF** immediately followed by a
single whitespace character. For this library we will use a space.
> For example:
>
> ```
> DESCRIPTION:This is a long description that exists on a long line.
> ```
>
> Can be represented as:
>
> ```
> DESCRIPTION:This is a lo
> ng description that exi
> sts on a long
> line.
> ```
- When *unfolding* the content lines back to their single line representation,
simply look for each instance of a **CRLF** followed by a single whitespace
and remove both.
- **Note:** In when parsing, it should look for **any** whitespace, not
just the whitespace character used by this library's generation scheme.
- **Note:** Simple *(read: poor)* implementations can generate improperly
folded lines in the middle of UTF-8 multi-octed sequences. When implementing
the line parser be sure to properly restore mangled sequences.
> 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
> ; 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
- Each property value of a component line has a format defined in that
property's specific section. Go there to see the more specific definitions.
- All names of properties, parameters, enumerated property values, and
property parameter values are **case-insensitive**.
- All other property values, unless otherwise stated, are **case-sensitive**.
#### 3.1.1. List and Field Separators
#### 3.1.2. Multiple Values
#### 3.1.3. Binary Content
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment