Existing MIME mechanisms are limited to 7-bit US-ASCII and the RFC 2047 encoded-word mechanism is unavailable for parameter values, making it impossible to use non-ASCII values without private per-parameter encoding. Additionally, character set information alone is insufficient for correct display—language information is also required, e.g., for text-to-speech accessibility.

email

Long MIME parameter values interact poorly with header line wrapping because proper folding requires linear whitespace (LWSP) that may not be present or recognizable in parameter values, causing truncation or damage by incorrect implementations. A continuation mechanism is therefore needed that breaks values into smaller units without altering the MIME header syntax.

email

The asterisk character was chosen as the indicator for both the continuation count suffix and the character-set/language encoding suffix, reusing a symbol already excluded from parameter attribute syntax. Percent-sign encoding was reused from RFC 2047 to provide a lightweight mechanism for 8-bit octets in parameter values.

email

The note in Section 2 warns that these mechanisms 'end up being somewhat gibbous when they actually are used' and therefore SHOULD NOT be used lightly—they should be reserved for situations where a real need exists. This acknowledges the syntactic complexity introduced by combined continuations and charset/language encoding.

email

All extensions defined in this document are implemented in a fashion that is completely syntactically compatible with existing MIME implementations, and are designed to have as little impact as possible on existing MIME uses. Existing processors that do not understand the extensions will see the raw continuation segments as separate (unknown) parameters.

email

In the future, some character sets may provide facilities for inline language labeling, which would be inherently more flexible than the mechanisms defined here (allowing language switching mid-string). If and when such facilities are developed, they SHOULD be used in preference to the language labeling specified in this document.

email

A continuation mechanism for MIME parameter values MUST NOT change the syntax of MIME media type and disposition lines, and MUST NOT depend on parameter ordering, since MIME states parameters are not order-sensitive and parameters may be reordered during user-agent processing.

email

IMAP4 servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes, reassembling the full parameter value for clients that may not implement this extension.

email

Omitting the charset or language field in an extended parameter MUST NOT be used to indicate a default charset or language. Correspondingly, parameter field definitions MUST NOT assign a default character set or language.

email

The first segment of a continued parameter value MUST be encoded (using the extended-value format with percent encoding) if language and character set information are present. Furthermore, the language and character set field delimiters MUST be present in the first segment even when those fields are left blank.

email

When character set or language information is present in an extended parameter value, the single-quote delimiters MUST be present even when one or both of the charset or language fields is left blank. This ensures parsers can reliably locate the value portion.

email

Character set and language information may be combined with the parameter continuation mechanism. When combined, charset and language information appear only at the beginning of the parameter value (first segment), continuations do not support multiple character sets or languages within a single value, and a continued value may mix encoded and unencoded segments.

email

Parameter value continuations are indicated by appending an asterisk followed by a decimal count to the parameter name (e.g., URL*0, URL*1). The count starts at 0, increments by 1, and neither leading zeroes nor gaps in the sequence are allowed. The original value is recovered by concatenating all sections in order.

email

RFC 2047 encoded words are extended to carry language information by suffixing the character set specification with an asterisk and a language tag: "=?" charset ["*" language] "?" encoding "?" encoded-text "?=". For example: =?US-ASCII*EN?Q?Keith_Moore?=.

email

RFC 2231 does not introduce new security issues beyond those already present in electronic mail and fully conforming MIME implementations. No additional security mechanisms are defined or required.

security, email

An extended parameter value begins with an optional registered character set name, followed by a single quote, an optional RFC 1766 language tag, a second single quote, and the value encoded with percent-sign hex escaping for non-ASCII octets (e.g., title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A). The asterisk suffix on the parameter name signals this encoding.

email

attribute-char is defined as any US-ASCII CHAR except SPACE, CTLs, "*", "'", "%", or tspecials. This updated definition reserves those characters to support the extension syntax while remaining otherwise compatible with existing MIME attribute parsing.

email

The ABNF for extended-initial-name is: attribute [initial-section] "*", where initial-section is "*0" and other-sections is "*" followed by a non-zero digit and optional additional digits. The extended-initial-value is: [charset] "'" [language] "'" extended-other-values, where ext-octet is "%" followed by two hex digits.

email

The updated ABNF for encoded-word changes the RFC 2047 form from "=?" charset "?" encoding "?" encoded-text "?=" to "=?" charset ["*" language] "?" encoded-text "?=", where language is a registered RFC 1766 language tag. The language portion is optional.

email