Keep media rules and application safety separate
08Encoding labels describe how to recover character values. They do not override the surrounding media type or authorize executing decoded content.
Separate security boundary: decoding can produce character values while an application refuses an unsafe action. Unknown/control characters, active content and malformed-pair recovery need deliberate handling. No code or external object is executed here.
Source for this drawing: RFC 2781 · Read RFC source: Appendix A ↗
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.
RFC2781 AppendixA registers UTF-16BE, UTF-16LE and UTF-16 and marks them unsuitable for MIME top-level text because of MIME line-ending requirements.
- RFC2781 AppendixA registers UTF-16BE, UTF-16LE and UTF-16 and marks them unsuitable for MIME top-level text because of MIME line-ending requirements.
- AppendixA separately notes an HTTP exception to that MIME restriction. This is not blanket permission for every HTTP media type or protocol to use UTF-16.
- §8 warns about unknown characters, control characters, externally processed content and illegal surrogate sequences. Decoding text successfully is not permission to execute it.
This publication describes Unicode3.0-era context and version-independent charset registrations, not every modern Unicode or media-type rule. Sections6/8 and AppendixA discuss repertoire evolution and safe processing. This is not normalization, authorization, cryptography or a production text sanitizer.
Read the RFC section ↗