RFC 2184

Okay bestie, let's get into RFC 2184 🎀 It's called MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations 💖 Written by N. Freed of Innosoft and K. Moore of the University of Tennessee, it came out in August 1997 as a Standards Track doc for the Network Working Group 📜 It updates RFC 2045, RFC 2047, and RFC 2183, and it doesn't obsolete anything. The whole vibe is "make email headers less cursed" 💅

Status of this Memo ✨

This is an Internet standards track protocol for the whole Internet community 🌐 The authors are literally asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📖 And distribution of this memo is unlimited, so share away 🦋

1. Abstract 🌸

This memo glows up two existing mechanisms, the RFC 2045 media type parameter value mechanism and the RFC 2183 disposition parameter value mechanism, so they can do three new things:

1. specify parameter values in character sets other than US-ASCII,
2. specify the language to be used should the value be displayed, and
3. use a continuation mechanism for long parameter values, so header line wrapping stops breaking them 😭

This memo also extends the encoded words defined in RFC 2047 so you can specify the language used for display, not just the character set 💜

2. Introduction 🧚

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

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 now widely deployed and used by a variety of Internet protocols, including, of course, Internet email 💌 But MIME's success means it needs extra mechanisms that the original spec never provided 📈

Existing MIME mechanisms already give you named media type (content-type field) parameters and named disposition (content-disposition field) parameters 🎀 A MIME media type can carry any number of parameters for all of its subtypes, and any specific subtype can add its own extra ones. A MIME disposition value can carry any number of associated parameters too, and the most important one is probably the attachment disposition's filename parameter 📎

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

1. Lines in Internet email header fields are folded according to RFC 822 folding rules, so long parameter values get messy.
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 to parameter values. So you can't have parameter values in other character sets without inventing some private per-parameter encoding 🙃
3. It's become clear that character set info isn't enough to display some kinds of information, and language info 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 for that to be done correctly. Some parameter values may need to be displayed, so there's a need to include language information 🗣️

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

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

IMPORTANT NOTE: These mechanisms end up being somewhat gibbous (that's the RFC's word, bestie, and it means clunky 😭) when they actually get used. So use of these mechanisms should not be used lightly; they should be reserved for situations where a real need for them exists.

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. You can find a discussion of what these terms mean in [RFC-2119] 🧐

3. Parameter Value Continuations 🔗

Long MIME media type or disposition parameter values do not play nicely with header line wrapping. Proper header line wrapping depends on there being places where linear whitespace (LWSP) is allowed. That whitespace may or may not be in a parameter value, and even when it's there, it may not be recognizable as such, because the agent doing the line wrapping may not know anything about parameter value syntax. The result is that long parameter values can get 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 safe to line wrap. 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 are not order sensitive. Note that while MIME does prohibit modification of MIME headers during transport, parameters can still get reordered when user agent level processing happens 🙈

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

You get the original parameter value back 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 this one:

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

Quotes around parameter values are part of the value syntax, and they are NOT part of the value itself. It's also explicitly allowed to mix quoted and unquoted continuation fields 🎀

4. Parameter Value Character Set and Language Information 🌍

Some parameter values may need to be qualified with character set or language information. A distinguished parameter name is clearly needed to show when that information is present, along with a specific syntax for that information inside the value itself. On top of that, we need a lightweight encoding mechanism so 8 bit information can fit into parameter values 🙌

An asterisk ("*") gets reused to say that language and character set information is present and encoding is being used. A single quote ("'") separates the character set and language information at the start of the parameter value. A percent sign ("%") is the encoding flag, which matches RFC 2047 🫶

More specifically, an asterisk at the end of a parameter name signals that character set and language information may appear at the start of the parameter value. A single quote separates the character set, language, and actual value information in the parameter value string, and a percent sign flags octets that are 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 perfectly permissible to leave either the character set or the language field blank 🧚 But the single quote delimiters MUST be present even when one of the field values is omitted. You leave a field out when the character set, the language, or both aren't relevant to the parameter value at hand. This MUST NOT be done to indicate a default character set or language. Parameter field definitions MUST NOT assign a default character set or language 🚫

4.1. Combining Character Set, Language, and Parameter Continuations 🧩

Character set and language information can be combined with the parameter continuation mechanism. For example:

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

Note that:

1. Language and character set information only appear at the beginning 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 with multiple continuations may contain 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, you sometimes need to attach language information to encoded words as well as the character set. This specification extends the encoded word definition to include that information, and it's super simple: you suffix the character set specification with an asterisk followed by the language tag. 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 MIME ABNF from RFC 2045 is the grammar for parameter values, and it's giving very simple vibes 💅

parameter := attribute "=" value

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

This spec gives it a glow-up 🦋 Here's the new version:

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 := "*1"
other-sections := "*" (("2" / "3" / "4" / "5" /
                        "6" / "7" / "8" / "9") *DIGIT) /
                       ("1" 1*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 encoded-word grammar from RFC 2047 also gets updated, so the language tag can ride along 🌸

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

And the new version:

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

---

8. Character sets which allow specification of language 🌈

ngl this part is so forward-thinking 🧚 Some character sets are probably going to get built-in facilities for inline language labelling later on. Those are way more flexible than what's defined here, because they let you switch languages right in the middle of a string.

So if and when those facilities show up, they SHOULD be used instead of the language labelling mechanisms in this document. Also, every mechanism defined here lets you leave out the language label, which is what keeps the door open for that future usage 🫶

9. Security Considerations 🙈

This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of MIME. 💀 Plot twist: no new security drama here, just the same old email drama we already have 📧

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 Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual Holdings, December 1996.

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

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

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

[RFC-2049] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, 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., Svanberg, P., "Report from the IAB Character Set Workshop", RFC 2130, April 1997.

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

11. Authors' Addresses 💌

Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
 tel: +1 818 919 3600           fax: +1 818 919 3614
 email: ned@innosoft.com

Keith Moore
Computer Science Dept.
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
 email: moore@cs.utk.edu