Charset specifications are subtype-specific, not protocol-specific, because each 'text/*' subtype has unique structural properties that determine how charset is conveyed. Placing charset defaults in protocol specifications (as HTTP did with ISO-8859-1) creates confusion and conflicts with subtype-level definitions.

email, http

If a new text subtype must define a default charset despite the SHOULD NOT recommendation, UTF-8 is prescribed as the preferred default because it is the most widely deployed and interoperable Unicode encoding for new text formats.

email

The document does not change charset defaults for any currently registered media type, limiting its normative impact to future registrations. This avoids disrupting deployed implementations while correcting the rules going forward.

email, bcp

The RFC 2046 rule that the default charset for 'text/*' is 'US-ASCII' is considered outdated. Many complex subtypes such as 'text/html' and 'text/xml' have internal charset mechanisms, and existing user agents already ignore the US-ASCII default for those types. Additionally, RFC 2616 introduced a conflicting 'ISO-8859-1' default for HTTP, creating ambiguity about which specification is authoritative.

email, http

Each subtype of the 'text' media type that uses the 'charset' parameter can define its own default value, including the absence of any default. This replaces the RFC 2046 blanket US-ASCII default with a per-subtype regime.

email

Existing 'text/*' registrations that fail to specify how the charset is determined still default to US-ASCII, preserving backward compatibility for deployed implementations while new registrations must follow the updated rules.

email

All new 'text/*' registrations MUST clearly specify how the charset is determined; relying on the Section 4.1.2 of RFC 2046 US-ASCII default is no longer permitted for new registrations.

email, registry

New subtypes of the 'text' media type SHOULD NOT define a default 'charset' value. If there is a strong reason to define one, the 'UTF-8' charset SHOULD be used as the default.

email

New 'text/*' media type registrations SHOULD either specify that the 'charset' parameter is not used (because charset is carried inside the payload) or require explicit unconditional inclusion of the 'charset' parameter, eliminating the need for a default value.

email, registry

Protocols that use MIME MUST NOT override default charset values for 'text/*' media types for their specific protocol. Protocol definitions MUST leave charset default determination to the subtype definitions.

email, http

Registrations for 'text/*' media types that can transport charset information inside their payloads (e.g., 'text/html', 'text/xml') SHOULD NOT specify the use of a 'charset' parameter or any default value, to avoid conflicting interpretations when the parameter value and the in-payload value disagree.

email

The default 'charset' parameter value for 'text/plain' is explicitly preserved as 'US-ASCII', unchanged from RFC 2046, as a specific application of the new per-subtype rule.

email

IANA updated the 'text' subregistry of the Media Types registry to add a preamble referencing RFC 6657 for guidance on 'charset' parameter handling for text media types. IANA also added this RFC to the list of references in the Application for Media Type form.

registry, email

Conflicting charset information in-band versus out-of-band can lead to security problems. This document recommends using in-band charset information (specified within the payload) as it is more likely to be correct than out-of-band values.

security, email

Guessing the 'charset' parameter can lead to security issues such as content buffer overflows, denial of service, or bypass of filtering mechanisms. This document discourages guessing and encourages using charset information explicitly specified by the sender.

security, email