RFC 6657 Proposed Standard Message format

Update to MIME regarding "charset" Parameter Handling in Textual Media Types

This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. [STANDARDS-TRACK]

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
July 2012
Authors
A. Melnikov, J. Reschke
Read it
rfc-editor.org · DOI

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 3 must, 4 should, 0 may.

3 New Rules for Default "charset" Parameter Values for "text/*" Media

  • SHOULDIn order to improve interoperability with deployed agents, "text/*" media type registrations SHOULD either
  • SHOULD NOTIn accordance with option (a) above, registrations for "text/*" media types that can transport charset information inside the corresponding payloads (such as "text/html" and "text/xml") SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the "charset" parameter value and the value specified in the payload disagree.
  • SHOULD NOTThus, new subtypes of the "text" media type SHOULD NOT define a default "charset" value.
  • SHOULDIf there is a strong reason to do so despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as the default.
  • MUSTRegardless of what approach is chosen, all new "text/*" registrations MUST clearly specify how the charset is determined; relying on the default defined in Section 4.1.2 of [RFC2046] is no longer permitted.
  • MUST NOTProtocols that use MIME, therefore, MUST NOT override default charset
  • MUSTThe protocol definitions MUST leave that to the subtype definitions.

Every current email RFC