RFC 2231

RFC 2231: MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations 💖

Okay bestie, this one is literally the MIME parameter glow-up 🦋 Here's the title block so you know who's behind it:

• Network Working Group: the crew that cooked this up
• Request for Comments: 2231
• Authors: N. Freed (Innosoft) and K. Moore (University of Tennessee) 👑
• Category: Standards Track
• Date: November 1997
• Updates: 2045, 2047, 2183
• Obsoletes: 2184

---

Status of this Memo ✨

This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright Notice 🌸

Copyright (C) The Internet Society (1997). All Rights Reserved.

1. Abstract 💅

So this memo basically extends the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms to give us three big things:

(1) a way to specify parameter values in character sets other than US-ASCII,

(2) a way to specify the language to be used if the value gets displayed, and

(3) a continuation mechanism for long parameter values, so header line wrapping stops being a whole disaster 😭

It also extends the encoded words from RFC 2047 so you can specify the language used for display, not just the character set. Iconic. 🎀

2. Introduction 🧚

MIME, the Multipurpose Internet Mail Extensions [RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049], defines a message format that allows for:

(1) textual message bodies in character sets other than US-ASCII,

(2) non-textual message bodies,

(3) multi-part message bodies, and

(4) textual header information in character sets other than US-ASCII.

MIME is widely deployed now, and it's used by a bunch of Internet protocols, including, of course, Internet email. But MIME's success means we need extra mechanisms that the original spec never gave us 💜

Specifically, MIME already has named media type (content-type field) parameters and named disposition (content-disposition field) parameters. A MIME media type can specify any number of parameters for all of its subtypes, and any specific subtype can add extra parameters for its own use. A MIME disposition value can have any number of parameters too, and the most important one is probably the filename parameter on the attachment disposition.

These parameter names and values end up in the content-type and content-disposition header fields in Internet email, and that comes with three big limitations 🙈

(1) Lines in Internet email header fields are folded according to RFC 822 folding rules. That makes long parameter values a problem.

(2) MIME headers, like the RFC 822 headers they usually live in, are limited to 7bit US-ASCII, and the encoded-word mechanisms of RFC 2047 aren't available for parameter values. So you can't have parameter values in other character sets without making up some private per-parameter encoding.

(3) It's become clear that character set information isn't enough to display some kinds of information, and language information is needed too [RFC-2130]. For example, support for handicapped users may require reading text aloud, and the language the text is written in is needed to do that correctly. Some parameter values may need to be displayed, so there's a need to include language information.

The last problem on that list also affects the encoded words defined by RFC 2047, since encoded words are mainly meant for display purposes.

This document defines extensions that fix all of these limitations. Every one of them is implemented in a way that's totally compatible at the syntax level with existing MIME implementations, and they're designed to have as little impact as possible on existing uses of MIME. Slay 👑

IMPORTANT NOTE: These mechanisms end up being somewhat gibbous (aka clunky) when they actually get used. So you shouldn't reach for them lightly. Save them for situations where there's a real need. 🥲

2.1. Requirements notation 📝

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they're being used to indicate particular requirements of this specification. A discussion of what these terms mean appears in [RFC- 2119].

3. Parameter Value Continuations 🎀

Long MIME media type or disposition parameter values don't play nicely with header line wrapping. Proper header wrapping depends on there being places where linear whitespace (LWSP) is allowed. A parameter value may or may not have those places, and even if it does, they might not be recognizable as such, because the agent doing the wrapping may not know anything about parameter value syntax. The result is that long parameter values can end up getting truncated or otherwise damaged by wrapping implementations that get it wrong 😭

So we need a mechanism that breaks parameter values into smaller units that are friendly to line wrapping. Any such mechanism MUST be compatible with existing MIME processors. That means:

(1) the mechanism MUST NOT change the syntax of MIME media type and disposition lines, and

(2) the mechanism MUST NOT depend on parameter ordering, since MIME says parameters aren't order sensitive. MIME does prohibit modifying MIME headers during transport, but parameters can still get reordered when user agent level processing happens.

So the obvious solution is to use multiple parameters to hold a single parameter value, with some kind of distinguished name to show when that's happening. And that's exactly what this spec does: an asterisk ("*") followed by a decimal count shows that multiple parameters are encapsulating one parameter value. The count starts at 0 and goes up by 1 for each following section of the value. Decimal values are used, and neither leading zeroes nor gaps in the sequence are allowed.

You rebuild the original parameter value by concatenating the sections of the parameter, in order. For example, this content-type field

        Content-Type: message/external-body; access-type=URL;
         URL*0="ftp://";
         URL*1="cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

is semantically identical to

        Content-Type: message/external-body; access-type=URL;
          URL="ftp://cs.utk.edu/pub/moore/bulk-mailer/bulk-mailer.tar"

Quick heads up: quotes around parameter values are part of the value syntax, and they are not part of the value itself 💅 It's also totally explicitly allowed to mix quoted and unquoted continuation fields. Bestie, that's a whole vibe.

4. Parameter Value Character Set and Language Information 🌈

Some parameter values need to be qualified with character set or language information. So we need a distinguished parameter name that shows when that info is present, plus a specific syntax for the info inside the value itself. We also need a lightweight encoding mechanism so 8 bit information can go in parameter values.

Asterisks ("*") get reused to show that language and character set info is present and encoding is in use. A single quote ("'") separates the character set and language info at the start of the parameter value. Percent signs ("%") are the encoding flag, which matches RFC 2047.

Specifically, an asterisk at the end of a parameter name shows that character set and language info might appear at the start of the parameter value. A single quote separates the character set, language, and actual value in the parameter value string, and a percent sign flags octets encoded in hexadecimal. For example:

        Content-Type: application/x-stuff;
         title*=us-ascii'en-us'This%20is%20%2A%2A%2Afun%2A%2A%2A

It's totally fine to leave either the character set or the language field blank. But the single quote delimiters MUST be there even if one of the field values is left out 🫶 You do that when the character set, the language, or both just aren't relevant to the parameter value at hand. You MUST NOT use that to signal a default character set or language, though. Parameter field definitions MUST NOT assign a default character set or language. Nobody gets a default here, periodt 💀

4.1. Combining Character Set, Language, and Parameter Continuations 🧚‍♀️

You can combine character set and language info with the parameter continuation mechanism. For example:

   Content-Type: application/x-stuff
    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"

Some things to keep in mind:

(1) Language and character set info only appear at the start of a given parameter value.

(2) Continuations don't give you a way to use more than one character set or language in the same parameter value.

(3) A value presented using multiple continuations can have a mix of encoded and unencoded segments.

(4) The first segment of a continuation MUST be encoded if language and character set information are given.

(5) If the first segment of a continued parameter value is encoded, the language and character set field delimiters MUST be present even when the fields are left blank.

5. Language specification in Encoded Words 🦋

RFC 2047 supports non-US-ASCII character sets in RFC 822 message header comments, phrases, and any unstructured text field. It does this by defining an encoded word construct that can show up in any of those places. Since these fields are meant for display, it's sometimes necessary to attach language info to encoded words too, not just the character set. This spec extends the encoded word definition so you can include that info. It's done simply by adding an asterisk and the language tag after the character set specification. For example:

          From: =?US-ASCII*EN?Q?Keith_Moore?= <moore@cs.utk.edu>

6. IMAP4 Handling of Parameter Values 📬

IMAP4 [RFC-2060] servers SHOULD decode parameter value continuations when they generate the BODY and BODYSTRUCTURE fetch attributes. 🌸

7. Modifications to MIME ABNF ✨

okay so the ABNF for MIME parameter values in RFC 2045 is giving very simple energy 💅:

parameter := attribute "=" value

attribute := token
             ; Matching of attributes
             ; is ALWAYS case-insensitive.

This spec glow-ups that ABNF into the following 🦋:

parameter := regular-parameter / extended-parameter

regular-parameter := regular-parameter-name "=" value

regular-parameter-name := attribute [section]

attribute := 1*attribute-char
attribute-char := <any (US-ASCII) CHAR except SPACE, CTLs,
                  "*", "'", "%", or tspecials>

section := initial-section / other-sections

initial-section := "*0"

other-sections := "*" ("1" / "2" / "3" / "4" / "5" /
                       "6" / "7" / "8" / "9") *DIGIT)

extended-parameter := (extended-initial-name "="
                       extended-value) /
                      (extended-other-names "="
                       extended-other-values)

extended-initial-name := attribute [initial-section] "*"

extended-other-names := attribute other-sections "*"

extended-initial-value := [charset] "'" [language] "'"
                          extended-other-values

extended-other-values := *(ext-octet / attribute-char)

ext-octet := "%" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

charset := <registered character set name>

language := <registered language tag [RFC-1766]>

The ABNF for encoded-words in RFC 2047 is this 💜:

encoded-word := "=?" charset "?" encoding "?" encoded-text "?="

And this spec changes it to:

encoded-word := "=?" charset ["*" language] "?" encoded-text "?="

---

8. Character sets which allow specification of language 🌸

bestie, so in the future some character sets are probably going to have built-in ways to label language inline 🧚. Those are honestly more flexible than anything in here, because they let you switch languages right in the middle of a string. Iconic behaviour 👑.

If and when those features show up, they SHOULD be used instead of the language labels this spec describes. Also, every mechanism here lets you leave the language label out, so the whole thing can handle that future usage without breaking 🫶.

9. Security Considerations 💀

This RFC doesn't discuss security issues. It's not believed to raise any security issues beyond the ones already endemic to electronic mail and already present in fully conforming MIME implementations. So no new drama here, but the old drama is still very real 😭.

10. References 📚

[RFC-822]
     Crocker, D., "Standard for the Format of ARPA Internet
     Text Messages", STD 11, RFC 822 August 1982.

[RFC-1766]
     Alvestrand, H., "Tags for the Identification of
     Languages", RFC 1766, March 1995.

[RFC-2045]
     Freed, N., and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part One: Format of Internet Message
     Bodies", RFC 2045, December 1996.

[RFC-2046]
     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part Two: Media Types", RFC 2046,
     December 1996.

[RFC-2047]
     Moore, K., "Multipurpose Internet Mail Extensions (MIME)
     Part Three: Representation of Non-ASCII Text in Internet
     Message Headers", RFC 2047, December 1996.

[RFC-2048]
     Freed, N., Klensin, J. and J. Postel, "Multipurpose
     Internet Mail Extensions (MIME) Part Four: MIME
     Registration Procedures", RFC 2048, December 1996.

[RFC-2049]
     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
     Extensions (MIME) Part Five: Conformance Criteria and
     Examples", RFC 2049, December 1996.

[RFC-2060]
     Crispin, M., "Internet Message Access Protocol - Version
     4rev1", RFC 2060, December 1996.

[RFC-2119]
     Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", RFC 2119, March 1997.

[RFC-2130]
     Weider, C., Preston, C., Simonsen, K., Alvestrand, H.,
     Atkinson, R., Crispin, M., and P. Svanberg, "Report from the
     IAB Character Set Workshop", RFC 2130, April 1997.

[RFC-2183]
     Troost, R., Dorner, S. and K. Moore, "Communicating
     Presentation Information in Internet Messages:  The
     Content-Disposition Header", RFC 2183, August 1997.

11. Authors' Addresses 🎀

The authors, with their addresses, are:

Ned Freed
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790
USA

Phone: +1 626 919 3600
Fax:   +1 626 919 3614
EMail: ned.freed@innosoft.com


Keith Moore
Computer Science Dept.
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA

EMail: moore@cs.utk.edu

12. Full Copyright Statement ⭐

Copyright (C) The Internet Society (1997). All Rights Reserved.

Anyone can copy and share this document, and translations of it too. You can also write derivative works that comment on or explain it, or that help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph are included on every copy and derivative work. Still, this document itself may not be modified in any way, such as by removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into a language other than English.

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns.

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🫶