RFC 2049

Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples 💖

Okay bestie, this is RFC 2049 🎀. It's the fifth and last part of the MIME set, and it's all about conformance criteria and examples. Here's the vibe check on the title block: N. Freed (Innosoft) and N. Borenstein (First Virtual) wrote it in November 1996 as a Standards Track document 👑, which means it's a real Internet standards protocol. It obsoletes RFC 1521, RFC 1522, and RFC 1590 💅, so those are officially retired. The header doesn't list anything it updates.

---

Status of this Memo ✨

So this doc specifies an Internet standards track protocol for the Internet community, and it wants your feedback and suggestions for improvements 🫶. For the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Abstract 🦋

Okay, so STD 11 (RFC 822) is the message format that's super detailed about US-ASCII message headers, but it basically leaves the message content, aka the message body, as plain flat US-ASCII text 🙈. The whole MIME set, which is what people call MIME for short, redefines message formats so you can get:

• (1) textual message bodies in character sets other than US-ASCII,
• (2) an extensible set of different formats for non-textual message bodies,
• (3) multi-part message bodies, and
• (4) textual header information in character sets other than US-ASCII.

These docs build on earlier work in RFC 934, STD 11, and RFC 1049 🍓, but they extend and revise it. RFC 822 said so little about message bodies that MIME is mostly orthogonal to it (it sits alongside it, not as a revision of it) 🧚.

The first doc in the set, RFC 2045, covers the various headers used to describe the structure of MIME messages 💜. The second doc defines the general structure of the MIME media typing system and sets up an initial set of media types ✨. The third doc, RFC 2047, extends RFC 822 so non-US-ASCII text data can show up in Internet mail header fields 🌸. The fourth doc, RFC 2048, lays out the various IANA registration procedures for MIME-related facilities 📝. This fifth and final doc is the one we're on now 🎀. It covers MIME conformance criteria, plus some illustrative examples of MIME message formats, acknowledgements, and the bibliography 💅.

These docs are revisions of RFCs 1521, 1522, and 1590, which were themselves revisions of RFCs 1341 and 1342 🔥. Appendix B has the full rundown of the differences and changes from previous versions 👑.

Table of Contents 🌈

   1. Introduction ..........................................    2
   2. MIME Conformance ......................................    2
   3. Guidelines for Sending Email Data .....................    6
   4. Canonical Encoding Model ..............................    9
   5. Summary ...............................................   12
   6. Security Considerations ...............................   12
   7. Authors' Addresses ....................................   12
   8. Acknowledgements ......................................   13
   A. A Complex Multipart Example ...........................   15
   B. Changes from RFC 1521, 1522, and 1590 .................   16
   C. References ............................................   20

1. Introduction ✨

Okay so the first and second docs in this set are the ones that define the MIME header fields and the starter list of MIME media types 🦋. The third doc is the one that stretches RFC822 formats so they can handle character sets other than US-ASCII 💖. This doc is the one that spells out what parts of MIME a conformant MIME implementation must support 🎀. It also calls out some pitfalls of contemporary messaging systems, plus the canonical encoding model that MIME is built on 🧚. Lowkey the most important part of the whole series, ngl 💜.

2. MIME Conformance ✨

Okay bestie, so the MIME stuff is super open-ended 🦋 Nobody is expected to support every media type or share the same extensions. BUT to keep things interoperable, the spec defines a vibe called "MIME-conformance". It's the minimum level of implementation that lets messages with non-US-ASCII content actually work together 💌 This section lays out what that conformance requires.

A mail user agent that is MIME-conformant MUST:

(1) Always generate a MIME-Version: 1.0 header field in any message it creates. Non-negotiable 💅

(2) Recognize the Content-Transfer-Encoding header field and decode all received data encoded by either quoted-printable or base64 implementations. The identity transformations 7bit, 8bit, and binary must also be recognized.

Any non-7bit data that is sent without encoding must be properly labelled with a content-transfer-encoding of 8bit or binary, as appropriate. If the underlying transport doesn't support 8bit or binary (SMTP [RFC-821] doesn't, bestie 😭), the sender is required to both encode and label the data with an appropriate Content-Transfer-Encoding, like quoted-printable or base64.

(3) Must treat any unrecognized Content-Transfer-Encoding as if it had a Content-Type of application/octet-stream, regardless of whether the actual Content-Type is recognized. Unknown encoding? Treat it as raw bytes. Period 🔒

(4) Recognize and interpret the Content-Type header field, and avoid showing users raw data with a Content-Type other than text. Implementations must be able to send at least text/plain messages, with the character set specified by the charset parameter if it isn't US-ASCII. ✨

(5) Ignore any content type parameters whose names they don't recognize. Not your problem, not your parameter 🙈

(6) Explicitly handle the following media type values, to at least the following extents:

• Text:
  • Recognize and display text mail with the character set US-ASCII.
  • Recognize other character sets at least to the extent of being able to tell the user which character set the message uses.
  • Recognize the ISO-8859-* character sets to the extent of being able to display those characters that are common to ISO-8859-* and US-ASCII, namely all characters represented by octet values 1-127.
  • For unrecognized subtypes in a known character set, show or offer to show the user the "raw" version of the data after converting the content from canonical form to local form.
  • Treat material in an unknown character set as if it were application/octet-stream.
• Image, audio, and video:
  • At a minimum, provide facilities to treat any unrecognized subtypes as if they were application/octet-stream.
• Application:
  • Offer the ability to remove either the quoted-printable or base64 encodings defined in this document if they were used, and put the resulting information in a user file.
• Multipart:
  • Recognize the mixed subtype. Display all relevant information at the message level and the body part header level, then display (or offer to display) each of the body parts individually.
  • Recognize the alternative subtype, and avoid showing the user redundant parts of multipart/alternative mail.
  • Recognize the multipart/digest subtype, specifically using message/rfc822 rather than text/plain as the default media type for body parts inside multipart/digest entities.
  • Treat any unrecognized subtypes as if they were mixed.
• Message:
  • Recognize and display at least the RFC 822 message encapsulation (message/rfc822) in a way that preserves any recursive structure. That means displaying (or offering to display) the encapsulated data according to its media type 🪞
  • Treat any unrecognized subtypes as if they were application/octet-stream.

(7) Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of application/octet-stream with no parameter sub-arguments. How that data gets handled is up to the implementation, but likely options include offering the user a chance to write it into a file (decoded from its mail transport format), or offering the user a chance to name a program the decoded data should be passed to as input 🧚

(8) Conformant user agents are required, if they provide non-standard support for non-MIME messages using character sets other than US-ASCII, to do so on received messages only. Conforming user agents must not send non-MIME messages containing anything other than US-ASCII text.

In particular, using non-US-ASCII text in mail messages without a MIME-Version field is strongly discouraged, because it impedes interoperability when messages go between regions with different localization conventions 🌍 Conforming user agents MUST include proper MIME labelling when sending anything other than plain text in the US-ASCII character set.

Also, non-MIME user agents should be upgraded, if at all possible, to include appropriate MIME header information in the messages they send, even if nothing else in MIME is supported. This upgrade will have little, if any, effect on non-MIME recipients, and it will help MIME display those messages correctly. It also gives a smooth transition path to eventually adopting the other MIME capabilities 🌸

(9) Conforming user agents must ensure that any string of non-white-space printable US-ASCII characters within a *text or *ctext that begins with =? and ends with ?= is a valid encoded-word. ("Begins" means: at the start of the field-body or immediately after linear-white-space. "Ends" means: at the end of the field-body or immediately before linear-white-space.) On top of that, any word within a phrase that begins with =? and ends with ?= must be a valid encoded-word. Lots of rules, but they're all about not letting broken encoded words slip through 🫶

(10) Conforming user agents must be able to tell encoded-words apart from text, ctext, or words, according to the rules in section 4, anytime they show up in appropriate places in message headers. They must support both the B and Q encodings for any character set they support. The program must be able to display the unencoded text if the character set is US-ASCII. For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters that are also in the US-ASCII set 💜

---

A user agent that meets all of the above is said to be MIME-conformant. What that means is it's considered "safe" to send virtually any kind of properly-marked data to users of that mail system. Why? Because those systems will at least be able to treat the data as undifferentiated binary, and they won't just splash it onto the unsuspecting user's screen 😳

There's another sense in which sending MIME-conformant data is always "safe": that data won't break, or get broken by, any known systems that conform to RFC 821 and RFC 822. And MIME-conformant user agents come with the extra guarantee that users will never be shown data that wasn't meant to be viewed as text 🎀

3. Guidelines for Sending Email Data ✨

okay so internet email is not a perfect, uniform system 🫶 mail can get corrupted at several stages on its way to the final destination, and it's giving chaos sometimes. email sent across the Internet may travel over tons of different networking technologies, and a lot of those networking and mail technologies don't support everything the SMTP transport environment can do. so mail going through them is likely to get modified just so it can actually be transported 😭

and there are loads of widely-deployed non-conformant MTAs out there 💀 these MTAs speak SMTP, but they alter messages on the fly to take advantage of the internal data structures of the hosts they run on, or they're just plain broken. not me being shady about it, that's just the reality 🙈

the following guidelines may be useful to anyone designing a data format (media type) that is supposed to survive the widest range of networking technologies and known broken MTAs unscathed 🦋 quick notes: anything encoded in base64 will satisfy these rules, but some well-known mechanisms, notably the UNIX uuencode facility, will not. also, anything encoded in quoted-printable will survive most gateways intact, but possibly not some gateways to systems that use the EBCDIC character set. okay, here are the big ones:

1. Under some circumstances the encoding used for data may change as part of normal gateway or user agent operation. In particular, conversion from base64 to quoted-printable and vice versa may be necessary. This may result in the confusion of CRLF sequences with line breaks in text bodies. As such, the persistence of CRLF as something other than a line break must not be relied on. 🎀
2. Many systems may elect to represent and store text data using local newline conventions. Local newline conventions may not match the RFC822 CRLF convention. systems are known that use plain CR, plain LF, CRLF, or counted records 🌸 the result is that isolated CR and LF characters are not well tolerated in general. they may be lost or converted to delimiters on some systems, and hence must not be relied on.
3. The transmission of NULs (US-ASCII value 0) is problematic in Internet mail. (This is largely the result of NULs being used as a termination character by many of the standard runtime library routines in the C programming language.) The practice of using NULs as termination characters is so entrenched now that messages should not rely on them being preserved. 🧚
4. TAB (HT) characters may be misinterpreted or may be automatically converted to variable numbers of spaces. This is unavoidable in some environments, notably those not based on the US-ASCII character set. Such conversion is STRONGLY DISCOURAGED, but it may occur, and mail formats must not rely on the persistence of TAB (HT) characters. 💅
5. Lines longer than 76 characters may be wrapped or truncated in some environments. Line wrapping or line truncation imposed by mail transports is STRONGLY DISCOURAGED, but unavoidable in some cases. Applications which require long lines must somehow differentiate between soft and hard line breaks. (A simple way to do this is to use the quoted-printable encoding.) ⭐
6. Trailing "white space" characters (SPACE, TAB (HT)) on a line may be discarded by some transport agents, while other transport agents may pad lines with these characters so that all lines in a mail file are of equal length. The persistence of trailing white space, therefore, must not be relied on. 🦋
7. Many mail domains use variations on the US-ASCII character set, or use character sets such as EBCDIC which contain most but not all of the US-ASCII characters. The correct translation of characters not in the "invariant" set cannot be depended on across character converting gateways. For example, this situation is a problem when sending uuencoded information across BITNET, an EBCDIC system. Similar problems can occur without crossing a gateway, since many Internet hosts use character sets other than US-ASCII internally. The definition of Printable Strings in X.400 adds further restrictions in certain special cases. In particular, the only characters that are known to be consistent across all gateways are the 73 characters that correspond to the upper and lower case letters A-Z and a-z, the 10 digits 0-9, and the following eleven special characters:

"'"  (US-ASCII decimal value 39)
"("  (US-ASCII decimal value 40)
")"  (US-ASCII decimal value 41)
"+"  (US-ASCII decimal value 43)
","  (US-ASCII decimal value 44)
"-"  (US-ASCII decimal value 45)
"."  (US-ASCII decimal value 46)
"/"  (US-ASCII decimal value 47)
":"  (US-ASCII decimal value 58)
"="  (US-ASCII decimal value 61)
"?"  (US-ASCII decimal value 63)

A maximally portable mail representation will confine itself to relatively short lines of text in which the only meaningful characters are taken from this set of 73 characters. The base64 encoding follows this rule. 🍓

8. Some mail transport agents will corrupt data that includes certain literal strings. In particular, a period (".") alone on a line is known to be corrupted by some (incorrect) SMTP implementations, and a line that starts with the five characters "From " (the fifth character is a SPACE) are commonly corrupted as well. A careful composition agent can prevent these corruptions by encoding the data (e.g., in the quoted-printable encoding using "=46rom " in place of "From " at the start of a line, and "=2E" in place of "." alone on a line). 👑

---

Please note that the above list is NOT a list of recommended practices for MTAs. RFC 821 MTAs are prohibited from altering the character of white space or wrapping long lines. These BAD and invalid practices are known to occur on established networks, and implementations should be robust in dealing with the bad effects they can cause. 😭🫶

4. Canonical Encoding Model ✨

okay so earlier versions of these docs caused some serious confusion 😭 about when email data gets turned into canonical form and encoded, and especially how that interacts with CRLFs, since every system likes to write newlines its own way 🙈 so this part gives us a canonical model to clear things up 🫶

Composing a MIME entity can be modeled as a series of steps 💅 These steps are roughly similar to the ones used in PEM [RFC-1421], and they're performed for each "innermost level" body:

1. Creation of local form. The body gets created in the system's native format 🌸 The native character set is used and, where it makes sense, local end of line conventions too. The body could be a UNIX-style text file, a Sun raster image, a VMS indexed file, audio data in some system-dependent format that only lives in memory, or literally anything else that matches the local model for representing some form of information. Basically, the data is born in the "native" form that matches the type given by the media type ✨
2. Conversion to canonical form. The entire body gets converted to a universal canonical form, and that includes "out-of-band" information like record lengths and maybe file attributes too 👑 The specific media type and its attributes decide what canonical form gets used. The conversion can involve character set conversion, transformation of audio data, compression, or other operations specific to the media type. If character set conversion is involved, though, you have to understand the semantics of the media type, because those can have big implications for conversion, e.g. with regard to syntactically meaningful characters in a text subtype other than "plain" 🙈

For example, with text/plain data, the text must be converted to a supported character set, and lines must be delimited with CRLF delimiters in accordance with RFC 822 💖 Also note that the line length restriction implied by RFC 822 is eliminated if the next step uses either quoted-printable or base64 encoding 🦋

3. Apply transfer encoding. A Content-Transfer-Encoding that fits this body gets applied 🧚 There's no fixed relationship between the media type and the transfer encoding, which is a very big deal 😭 In particular, it might make sense to pick base64 or quoted-printable based on character frequency counts that are specific to one particular instance of a body 💜
4. Insertion into entity. The encoded body gets inserted into a MIME entity with the appropriate headers 🎀 Then the entity is inserted into the body of a higher-level entity (message or multipart) as needed 🫶

Converting from entity form back to local form is done by reversing these steps 🔄 Note that reversing them may produce different results, since there's no guarantee that the original and final local forms are the same 💀

It is vital to note that these steps are only a model; they are specifically NOT a blueprint for how an actual system would be built 🚨 The model doesn't account for two common designs:

1. In lots of cases, the conversion to canonical form before encoding gets folded into the encoder itself, because the encoder understands local formats directly 🍓 For example, the local newline convention for text bodies might get carried through to the encoder along with knowledge of what that format is 🌈
2. The output of the encoders may need to pass through one or more additional steps before it's transmitted as a message 💅 So the encoder's output may not conform to the formats specified by RFC 822 🥺 In particular, once again, it may make sense for the converter's output to use local newline conventions instead of the standard RFC 822 CRLF delimiters ✨

Other implementation variations are totally conceivable too 🦋 The big takeaway is this: no matter what optimizations, collapsed steps, or extra processing you add, the resulting messages must be consistent with what this model produces 🔥 For example, take a message with these header fields:

Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64

It must first be represented in the text/foo form, then (if necessary) represented in the "bar" character set, and finally transformed via the base64 algorithm into a mail-safe form 💖

NOTE: Some confusion has been caused by systems that represent messages in a format using local newline conventions that differ from the RFC822 CRLF convention 🙈 These formats are not canonical RFC822/MIME 🚫 They're instead encodings of RFC822, where CRLF sequences in the canonical representation of the message get encoded as the local newline convention 🧠 Formats that encode CRLF sequences as, for example, LF are not capable of representing MIME messages that contain binary data with LF octets that aren't part of CRLF line separation sequences 😭 Bestie, that's a whole vibe-check on those formats 💀

---

5. Summary 🌸

This document defines what MIME Conformance means 👑 It also details various problems known to exist in the Internet email system, plus how to use MIME to overcome them 🫶 Finally, it describes MIME's canonical encoding model 🦋 Iconic wrap-up ✨

6. Security Considerations 🔐

Security issues are discussed in the second document in this set, RFC 2046 😭 Go read that one, it's giving serious security energy 💀

7. Authors' Addresses 💌

For more information, the authors of this document are best contacted via Internet mail 💖 Here they are:

Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA

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

Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA

Phone: +1 201 540 8967
Fax:   +1 201 993 3032
EMail: nsb@nsb.fv.com

MIME is a result of the work of the Internet Engineering Task Force
Working Group on RFC 822 Extensions.  The chairman of that group,
Greg Vaudreuil, may be reached at:

Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA

EMail: Greg.Vaudreuil@Octel.Com

8. Acknowledgements 🫶

This document is the result of the collective effort of a large number of people 🌈 It came together at several IETF meetings, on the IETF-SMTP and IETF-822 mailing lists, and elsewhere 💜 Any list of names is doomed to have egregious omissions, but the following are among the many contributors to this effort 🎀

  Harald Tveit Alvestrand       Marc Andreessen
  Randall Atkinson              Bob Braden
  Philippe Brandon              Brian Capouch
  Kevin Carosso                 Uhhyung Choi
  Peter Clitherow               Dave Collier-Brown
  Cristian Constantinof         John Coonrod
  Mark Crispin                  Dave Crocker
  Stephen Crocker               Terry Crowley
  Walt Daniels                  Jim Davis
  Frank Dawson                  Axel Deininger
  Hitoshi Doi                   Kevin Donnelly
  Steve Dorner                  Keith Edwards
  Chris Eich                    Dana S. Emery
  Johnny Eriksson               Craig Everhart
  Patrik Faltstrom              Erik E. Fair
  Roger Fajman                  Alain Fontaine
  Martin Forssen                James M. Galvin
  Stephen Gildea                Philip Gladstone
  Thomas Gordon                 Keld Simonsen
  Terry Gray                    Phill Gross
  James Hamilton                David Herron
  Mark Horton                   Bruce Howard
  Bill Janssen                  Olle Jarnefors
  Risto Kankkunen               Phil Karn
  Alan Katz                     Tim Kehres
  Neil Katin                    Steve Kille
  Kyuho Kim                     Anders Klemets
  John Klensin                  Valdis Kletniek
  Jim Knowles                   Stev Knowles
  Bob Kummerfeld                Pekka Kytolaakso
  Stellan Lagerstrom            Vincent Lau
  Timo Lehtinen                 Donald Lindsay
  Warner Losh                   Carlyn Lowery
  Laurence Lundblade            Charles Lynn
  John R. MacMillan             Larry Masinter
  Rick McGowan                  Michael J. McInerny
  Leo Mclaughlin                Goli Montaser-Kohsari
  Tom Moore                     John Gardiner Myers
  Erik Naggum                   Mark Needleman
  Chris Newman                  John Noerenberg
  Mats Ohrman                   Julian Onions
  Michael Patton                David J. Pepper
  Erik van der Poel             Blake C. Ramsdell
  Christer Romson               Luc Rooijakkers
  Marshall T. Rose              Jonathan Rosenberg
  Guido van Rossum              Jan Rynning
  Harri Salminen                Michael Sanderson
  Yutaka Sato                   Markku Savela
  Richard Alan Schafer          Masahiro Sekiguchi
  Mark Sherman                  Bob Smart
  Peter Speck                   Henry Spencer
  Einar Stefferud               Michael Stein
  Klaus Steinberger             Peter Svanberg
  James Thompson                Steve Uhler
  Stuart Vance                  Peter Vanderbilt
  Greg Vaudreuil                Ed Vielmetti
  Larry W. Virden               Ryan Waldron
  Rhys Weatherly                Jay Weber
  Dave Wecker                   Wally Wedel
  Sven-Ove Westberg             Brian Wideen
  John Wobus                    Glenn Wright
  Rayan Zachariassen            David Zimmerman

The authors apologize for any omissions from this list 🥺 Those are certainly unintentional, bestie 🫶💖

Appendix A -- A Complex Multipart Example 🎀

okay so this is the outline of a complex multipart message 😭✨ it has five parts that get displayed one after another (serially): two intro plain text objects, an embedded multipart message, a text/enriched object, and a closing encapsulated text message in a non-ASCII character set 🌈. the embedded multipart message is the real main character 💅 because it holds two objects that get displayed in parallel (a picture and an audio fragment) 🦋

MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Ned Freed <ned@innosoft.com>
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed;
              boundary=unique-boundary-1

This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.

If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.

--unique-boundary-1

  ... Some text appears here ...

[Note that the blank between the boundary and the start
 of the text in this part means no header fields were
 given and this is text in the US-ASCII character set.
 It could have been done with explicit typing as in the
 next part.]

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

This could have been part of the previous part, but
illustrates explicit versus implicit typing of body
parts.

--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64

  ... base64-encoded 8000 Hz single-channel
      mu-law-format audio data goes here ...

--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

  ... base64-encoded image data goes here ...

--unique-boundary-2--

--unique-boundary-1
Content-type: text/enriched

This is <bold><italic>enriched.</italic></bold>
<smaller>as defined in RFC 1896</smaller>

Isn't it
<bigger><bigger>cool?</bigger></bigger>

--unique-boundary-1
Content-Type: message/rfc822

From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable

  ... Additional text in ISO-8859-1 goes here ...

--unique-boundary-1--

---

Appendix B -- Changes from RFC 1521, 1522, and 1590 💖

these documents are a revision of RFC 1521, 1522, and 1590 🧚 so for anyone who knows the older docs, here's the tea ☕ on what changed. fyi, Appendix H in RFC 1521 covered how that doc was different from its ancestor, RFC 1341, if you wanna go full history nerd 🤓

1. Reformatting and splitting! ✨ The whole thing got reformatted and split into multiple documents, so the plain text version (which is the official reference copy) looks way better 📄
2. New BNF for headers 🎀 BNF describing the overall structure of MIME object headers got added. this is a docs-only change, the underlying syntax didn't change at all 🫶
3. Goodbye, type-specific BNF 👋 the specific BNF for the seven MIME media types got removed. it was incorrect, incomplete, and inconsistent with the type-independent BNF 💀 and since the type-independent one already fully covers the syntax of the MIME headers, the type-specific stuff was honestly unnecessary and caused more drama than it solved 🙈
4. US-ASCII, not vibes 🌿 the more specific "US-ASCII" name replaced the informal term ASCII in lots of places 💅
5. Primary subtype? Bye 🍓 the informal concept of a primary subtype got removed 🌸
6. Object, body, entity, oh my 🦋 the word "object" was being used inconsistently 😭 so the definition got clarified, along with "body", "body part", and "entity", and usage got fixed where it needed it 💜
7. CRLF, reorganized 🌊 the multipart BNF got rearranged to make it clear that the CRLF before the boundary marker is actually part of the marker itself, not part of the body part before it ✨
8. No boundary lookalikes! 🚫 the prose and BNF for multipart were changed to make it clear that body parts inside a multipart object MUST NOT contain any lines beginning with the boundary parameter string 🔥
9. Subject rides along 🎟️ when reassembling "message/partial" MIME entities, "Subject" got added to the list of headers taken from the inner message, and the example got updated to show this 🙌
10. Line breaks only ✂️ "message/partial" fragmenters are restricted to splitting MIME objects only at line boundaries 🌿
11. PostScript warning 📜 in the application/postscript section, a new paragraph warns about possible interoperability problems caused by embedding binary data inside a PostScript MIME entity 🫣
12. Equivalent Content-Type, pick your fave 💅 a clarifying note got added to the basic syntax rules for the Content-Type header field, so these two forms are totally equivalent:

Content-type: text/plain; charset=us-ascii (comment)

Content-type: text/plain; charset="us-ascii"

13. MIME-Version warning: deleted 🗑️ this sentence got removed from the MIME-Version discussion: However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME-version is encountered.
14. Typo slay 🧹 a typo got fixed where it said application/external-body instead of message/external-body ✨
15. Character sets, reorganized 🗂️ the definition of a character set got reorganized so the requirements are clearer 💖
16. image/gif moved out 🖼️ the definition of image/gif got moved into a separate document, because of potential conflicts with IETF rules about standardizing patented tech 🙈
17. Bare CR and LF are a no-go 🚫 the definitions of "7bit" and "8bit" got tightened so bare CR and LF can only be used as end-of-line sequences 🌊 the document also no longer requires NUL characters to be preserved, which lines MIME up with real-world implementations 🫶
18. Canonical text gets strict 📏 the definition of canonical text got tightened so line breaks have to be represented by a CRLF sequence 💅 CR and LF characters aren't allowed outside of that usage, and the quoted-printable definition got changed to match 🌸
19. Quoted-printable suggestions 💡 the quoted-printable encoding now has a bunch of suggestions for how encoders can handle improperly encoded material 🙌
20. Transfer-encoding clarity 🌿 prose got added to clarify how the "7bit", "8bit", and "binary" transfer-encodings work on multipart or message entities that wrap "8bit" or "binary" data 🦋
21. Conformance glow-up ✨ in the MIME Conformance section, "multipart/digest" support got added to the minimal conformance list 💜 and the "message/rfc822" requirement got strengthened to make it clear that recognizing recursive structure really matters 🔁
22. Message subtypes, one by one 🎀 the restrictions on subtypes of "message" are now specified entirely subtype by subtype 🫶
23. Headers for message/rfc822 🎟️ the definition of "message/rfc822" changed to say that at least one of the "From", "Subject", or "Date" headers has to be present 💖
24. Unknown subtypes, made clear 🧩 the required handling of unrecognized subtypes as "application/octet-stream" got spelled out more explicitly, both in the type definitions and in the conformance guidelines 🌈
25. richtext to enriched 🍓 examples that used text/richtext got switched over to text/enriched 💅
26. Subtype naming rules 📛 the BNF for subtype got changed to make it clear that a Content-Type header field has to use either an IANA registered subtype or a nonstandard "X-" subtype 🦋
27. Registered vs standardized 🏷️ the MIME BNF now tells apart media types that are simply registered for use from the ones standardized by the IETF 🌊
28. Registration glow-up 🔥 all of the MIME registration procedures got extensively revised 💅 and the IANA registration procedures for character sets moved to a separate document, which isn't included in this set 📚
29. No escapes in US-ASCII or ISO-8859-X 🚫 the use of escape and shift mechanisms in the US-ASCII and ISO-8859-X character sets got clarified: they're not supposed to ever be used with these character sets, and their effect is undefined if they are used anyway 💀
30. AFS is gone 👋 the AFS access-type for message/external-body got removed 🌿
31. multipart/alternative meets message/external-body 🤝 the combo of multipart/alternative and message/external-body is now specifically addressed 💜
32. Security tea for external-body 🔐🌈 security issues specific to message/external-body are now discussed in some detail 😭👑

Appendix C -- References 📚🎀

okay bestie, this is the reading list 🦋 every single source the document leans on, all lined up so you can go check them yourself. I've kept every label, title, number, and date exactly as written, typos and all, because citations are sacred 🫶

[ATK] Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, Prentice-Hall, 1990.

[ISO-2022] International Standard -- Information Processing -- Character Code Structure and Extension Techniques, ISO/IEC 2022:1994, 4th ed.

[ISO-8859] International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets

• Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
• Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
• Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
• Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
• Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st ed.
• Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
• Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
• Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
• Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st ed.

International Standard -- Information Technology -- 8-bit Single-Byte Coded Graphic Character Sets

• Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 1st ed.

[ISO-646] International Standard -- Information Technology -- ISO 7-bit Coded Character Set for Information Interchange, ISO 646:1991, 3rd ed..

[JPEG] JPEG Draft Standard ISO 10918-1 CD.

[MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, 1991.

[PCM] CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies", Geneva, 1972.

[POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985.

[POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990.

[RFC-783] Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, MIT, June 1981.

[RFC-821] Postel, J.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.

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

[RFC-934] Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and NMA, January 1985.

[RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.

[RFC-1049] Sirbu, M., "Content-Type Header Field for Internet Messages", RFC 1049, CMU, March 1988.

[RFC-1154] Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.

[RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.

[RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992.

[RFC-1344] Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, June 1992.

[RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", RFC 1345, Rationel Almen Planlaegning, June 1992.

[RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encryption and Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993.

[RFC-1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-Based Key Management", RFC 1422, IAB IRTF PSRG, IETF PEM WG, February 1993.

[RFC-1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes, and Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993.

[RFC-1424] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail: Part IV -- Key Certification and Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993.

[RFC-1521] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September, 1993.

[RFC-1522] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993.

[RFC-1524] Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information", RFC 1524, Bellcore, September 1993.

[RFC-1543] Postel, J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993.

[RFC-1556] Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC 1556, Israeli Inter-University Computer Center, December 1993.

[RFC-1590] Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March 1994.

[RFC-1602] Internet Architecture Board, Internet Engineering Steering Group, Huitema, C., Gross, P., "The Internet Standards Process -- Revision 2", March 1994.

[RFC-1652] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service Extension for 8bit-MIME transport", RFC 1652, United Nations University, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, March 1994.

[RFC-1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.

[RFC-1741] Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December 1994.

[RFC-1896] Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February, 1996.

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

[RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual Holdings, November 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, November 1996.

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

[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049 (this document), Innosoft, First Virtual Holdings, November 1996.

[US-ASCII] Coded Character Set -- 7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[X400] Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41.

---

That's the whole reference list, bestie! 🌈✨ Every source, every date, all accounted for 💅