Display text without changing header structure
05Decode recognized words for display after parsing the structured header. Whitespace joining and error recovery must preserve the surrounding message.
Under RFC6532’s separate extension, generation SHOULD NOT use encoded words. Conversion MAY be done when incorporating another message, but processors MUST NOT generate syntactically invalid fields. This is not automatic permission for every transport.
Source for this drawing: RFC 2047 · Read RFC section 6.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Adds optional *language after charset; the encoding component remains (verified erratum478). RFC2184 is the earlier updater obsoleted by 2231.
Read the updated RFC section ↗Decoded display text must stay separate from parsed structure.
- Decoded display text must stay separate from parsed structure.
- Linear white space between adjacent encoded words is ignored for display. To display a space between them, encode it in one word. The ignored white space is not a license to remove spaces next to ordinary text.
- A reader need not display incorrectly formed words but MUST NOT prevent message display or handling because of them. Unsupported encodings or charsets have the fallback options in §6.2; a successful display does not authenticate a sender.
RFC2231 §5 adds optional *language after charset; verified RFC 2231 erratum 478 retains the ?encoding? field. RFC2184 is the historical updater later obsoleted by 2231; neither obsoletes2047. RFC6532 §3.6 separately recommends against encoded words when generating its direct UTF-8 headers, permits conversion, and requires converted fields remain syntactically valid. Only printable/white-space text should be encoded, and readers should avoid unwanted terminal side effects from decoded data (§5). Direct UTF-8 transport needs an authorized environment (§3.7); do not decode and blindly reparse a header. Historical charset recommendations are not a general modern-generation mandate.
Read the RFC section ↗