parameter value
Click on the red underlined text to get to the source
... a continuation mechanism for long parameter values to
avoid problems with header line wrapping.
...
... header fields are folded according to
RFC 822std11(-> 2822prop) folding rules. This makes long parameter values
problematic.
...
... US-ASCII, and the encoded-word mechanisms
of RFC 2047draft are not available to parameter values. This makes
it impossible to have parameter values in character sets ...
... 2047draft are not available to parameter values. This makes
it impossible to have parameter values in character sets other
than US-ASCII ...
... text string aloud. The language the text is written in is
needed for this to be done correctly. Some parameter values
may need to be displayed, hence there is a need to allow for
the inclusion of language ...
... Parameter Value Continuations ...
...
Long MIME media type or disposition parameter values do not interact
well with header line wrapping conventions. In particular, proper
...
... header line wrapping depends on there being places where linear
whitespace (LWSP) is allowed, which may or may not be present in a
parameter value, and even if present may not be recognizable as such
since specific knowledge of parameter value syntax may not be
...
... parameter value, and even if present may not be recognizable as such
since specific knowledge of parameter value syntax may not be
available to the agent doing the line wrapping. The result is that
...
... available to the agent doing the line wrapping. The result is that
long parameter values may end up getting truncated or otherwise
damaged by incorrect line wrapping implementations.
...
...
A mechanism is therefore needed to break up parameter values into
smaller units that are amenable to line wrapping. Any such mechanism
MUST be compatible with existing MIME ...
...
The obvious solution, then, is to use multiple parameters to contain
a single parameter value and to use some kind of distinguished name
to indicate when this is being done. And this obvious solution is
...
... by a decimal count is employed to indicate that multiple parameters
are being used to encapsulate a single parameter value. The count
starts at 0 and increments by 1 for each subsequent section of the
...
... starts at 0 and increments by 1 for each subsequent section of the
parameter value. Decimal values are used and neither leading zeroes
nor gaps in the sequence are allowed.
...
...
The original parameter value is recovered by concatenating the
various sections of the parameter, in order. For example, the
content-type ...
...
Note that quotes around parameter values are part of the value
syntax; they are NOT part of the value itself. Furthermore, it is
explicitly permitted to have a mixture of quoted and unquoted
...
... addition, a lightweight encoding mechanism is needed to accomodate 8
bit information in parameter values.
...
... character set and language
information at the beginning of the parameter value. Percent signs
("%") are used as the encoding flag, which agrees with RFC 2047draft ...
... character set and language information may appear at
the beginning of the parameter value. A single quote is used to
separate the character set, language ...
... language, and actual value information in
the parameter value string, and an percent sign is used to flag
octets encoded in hexadecimal. For example:
...
... character set, language, or both
are not relevant to the parameter value at hand. This MUST NOT be
done in order to indicate a default character set or language ...
... Language and character set information only appear at
the beginning of a given parameter value.
...
... If the first segment of a continued parameter value is
encoded the language and character set ...
... IMAP4 Handling of Parameter Values ...
... IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations
when generating the BODY and BODYSTRUCTURE fetch attributes.
...
