Connected: An Internet Encyclopedia
RFC 822 - 3.1.1. LONG HEADER FIELDS

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 822
Up: 3. LEXICAL ANALYSIS OF MESSAGES
Up: 3.1. GENERAL DESCRIPTION
Prev: 3.1. GENERAL DESCRIPTION
Next: 3.1.2. STRUCTURE OF HEADER FIELDS

### 3.1.1. LONG HEADER FIELDS

Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called "folding". The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may instead be inserted. Thus, the single line

                To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN

can be represented as:

                To:  "Joe & J. Harvey" <ddd @ Org>,
                        JJV@BBN

and

                To:  "Joe & J. Harvey"
                                <ddd@ Org>, JJV
                 @BBN

and

                To:  "Joe &
                 J. Harvey" <ddd @ Org>, JJV @ BBN

The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by regarding CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char.

Note: While the standard permits folding wherever linear-white-space is permitted, it is recommended that structured fields, such as those containing addresses, limit folding to higher-level syntactic breaks. For address fields, it is recommended that such folding occur between addresses, after the separating comma.

Next: 3.1.2. STRUCTURE OF HEADER FIELDS

Connected: An Internet Encyclopedia
RFC 822 - 3.1.1. LONG HEADER FIELDS