MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
obsoleted by
- rfc-2231 — MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
updates
- rfc-2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
- rfc-2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
- rfc-2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
Extracted elements (23)
Extensions are designed to be completely syntactically compatible with existing MIME implementations so they have as little impact as possible on existing uses. This backward compatibility was a primary design constraint.
Language information is needed in addition to character set because some use cases (e.g., text-to-speech for accessibility) require knowing the language of a string, not just its encoding. RFC 2130 is cited as identifying this requirement.
The asterisk-plus-count continuation scheme was chosen because the obvious solution — multiple parameters with a distinguished naming convention — is the only approach that satisfies both the no-syntax-change and no-ordering-dependence constraints simultaneously.
These mechanisms are described as 'somewhat gibbous' in practice, so use SHOULD be reserved for situations where a real need exists; they should not be used lightly.
A continued parameter value may contain a mixture of encoded segments (ending in `*`) and unencoded segments, allowing partial adoption of encoding within a single logical parameter value.
Quotes around parameter values are part of value syntax and are NOT part of the value itself; it is explicitly permitted to mix quoted and unquoted continuation fields within a single continued parameter value.
Any parameter continuation mechanism MUST NOT change the syntax of MIME media type and disposition lines, ensuring full syntactic compatibility with existing MIME processors.
Any parameter continuation mechanism MUST NOT depend on parameter ordering, since MIME specifies that parameters are not order-sensitive and may be reordered during user agent processing.
If and when character sets provide facilities for inline language labelling, those facilities SHOULD be used in preference to the language-labelling mechanisms defined in this specification, as inline labelling allows language switching mid-string.
If the first segment of a continued parameter value is encoded, the charset and language field delimiters (single quotes) MUST be present even when those fields are left blank.
IMAP4 servers SHOULD decode parameter value continuations when generating the BODY and BODYSTRUCTURE fetch attributes, presenting a unified parameter value to clients.
Leaving charset or language blank in an extended parameter MUST NOT be used to indicate a default; parameter field definitions MUST NOT assign a default character set or language.
The single-quote delimiters separating charset, language, and value in an extended parameter MUST be present even when the charset or language field is omitted (left blank). They are never optional.
When combining character set/language information with parameter continuations, the first segment of a continued parameter value MUST be encoded if language and character set information are given.
Language and character set information appear only at the beginning of a given parameter value and cannot be changed mid-value. A continued parameter value may contain a mixture of encoded and unencoded segments, but only one character set and one language may be used per parameter value.
Parameter value continuations use an asterisk followed by a decimal count (starting at 0) appended to the parameter name to split a single logical value across multiple parameters. The original value is recovered by concatenating sections in order. Neither leading zeroes nor gaps in the sequence are allowed.
The encoded-word format from RFC 2047 is extended to carry language information by suffixing the charset with an asterisk and a language tag: `=?charset*language?encoding?encoded-text?=`. For example: `=?US-ASCII*EN?Q?Keith_Moore?=`.
RFC 2184 does not discuss security issues and is not believed to raise any security issues beyond those already endemic in electronic mail and present in fully conforming MIME implementations.
An extended parameter is encoded as `name*=charset'language'encoded-value` where an asterisk at the end of the parameter name signals that character set and language information precede the actual value, delimited by single quotes. Octets are percent-encoded using `%XX` hexadecimal notation.
Continuation section numbers are encoded as `*0`, `*1`, … with `initial-section := "*1"` treated specially and `other-sections` covering values 2–9 plus multi-digit extensions. The `*0` section is used for the first (or only) chunk of a continued value.
The `extended-initial-value` production is: `[charset] "'" [language] "'" extended-other-values`, where `extended-other-values` is zero or more `ext-octet` or `attribute-char` tokens. An `ext-octet` is `"%"` followed by exactly two hexadecimal digits.
The updated ABNF for `parameter` distinguishes `regular-parameter` (name with optional section index, equals, value) from `extended-parameter` (name ending in `*`, equals, charset'language'encoded-value). The `attribute-char` production excludes SPACE, CTLs, `*`, `'`, `%`, and tspecials.
The updated encoded-word ABNF changes from `"=?" charset "?" encoding "?" encoded-text "?="` to `"=?" charset ["*" language] "?" encoded-text "?="`, adding an optional asterisk-delimited language tag immediately after the charset.