Add notes from Chapter 3.1 (Content Lines)

- Should be clear to implement the content line interface.

PROGRESS.md

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