RFC 1806

Part 1 of 2 🌸

RFC 1806: Communicating Presentation Information in Internet Messages: The Content-Disposition Header ✨

Okay bestie, let's start with the vibes 💅 This is RFC 1806, a Request for Comments from the Network Working Group 💻, and it's titled Communicating Presentation Information in Internet Messages: The Content-Disposition Header. R. Troost from New Century Systems and S. Dorner from QUALCOMM Incorporated wrote it together 👑. It's categorised as Experimental 🧪 and it's dated June 1995 🗓️.

Status of This Memo ✨

So this memo is an Experimental Protocol 🧪 for the whole Internet community. It is not an Internet standard of any kind 🙈 The authors actually want your thoughts and suggestions for making it better 💌 And distribution is unlimited, so share away 🦋

Abstract 🎀

Okay so this memo gives messages that follow the [RFC 1521] ("MIME") spec a way to say how they'd like to be presented 💖 The big new thing is a "Content-Disposition" header 🎀 It's optional, and it works on any [RFC 1521] entity, whether that's a "message" or a "body part" ✨ There are two values described here: one for ordinary linear presentation of the body part 🌊, and one for using mail to transfer files 📎 More values are expected down the road, and there are procedures for adding them 🔮

This doc is an extension of [RFC 1521] 🧩 so you're assumed to already know [RFC 1521] and [RFC 822] 📚 Everything here adds to those docs, it doesn't replace them 💜

1. Introduction 🌸

[RFC 1521] gives us a standard format for stuffing multiple pieces of data into one Internet message 📦 But it doesn't talk about presentation styles at all! It's more of a framework for swapping message content around, and it leaves all the presentation decisions up to the mail user agent (MUA) implementors 🫠

There are two common ways to show a multipart message: as a main document with a list of separate attachments, or as one document with all the parts expanded and displayed inline 🧵 Showing an attachment usually takes a deliberate action from the reader 👆, while inline pieces just show up when the message is viewed ✨ So the sender needs a way to say what they want, and that's where Content-Disposition comes in 🏷️ It lets every component of a message get tagged with its desired presentation semantics 💅

Tagging things like this will often be enough for basic formatting 💁‍♀️ For fancier stuff, though, you'll want something more powerful and flexible 🚀 Designing that is out of scope for this memo, but those approaches can totally benefit from extra Content-Disposition values and parameters, to be defined at a later date 🔮

Also, she might want to pass along a default archival name for the part, which is a filename 📁 That's what the optional "filename" parameter is for 🗂️

2. The Content-Disposition Header Field 💅

Content-Disposition is an optional header 🎀 If it's not there, the MUA MAY use whatever presentation method it deems suitable 🤷‍♀️

We want the set of possible disposition types to stay small and well defined so things don't get messy 🧹 Still, real-world usage will probably call for new disposition types or parameters, so the set of disposition values is extensible. More on that below 🦋

Here's the extended BNF notation from [RFC 822] that defines the Content-Disposition header field 🧠

disposition := "Content-Disposition" ":"
               disposition-type
               *(";" disposition-parm)

disposition-type := "inline"
                  / "attachment"
                  / extension-token
                  ; values are not case-sensitive

disposition-parm := filename-parm / parameter

filename-parm := "filename" "=" value;

Extension-token, parameter and value are all defined by [RFC 822] and [RFC 1521] 📚

2.1. The Inline Disposition Type 🌊

A bodypart SHOULD be marked inline if it's meant to be displayed automatically when the message is displayed 🌊 Inline bodyparts SHOULD be presented in the order they occur, following the normal semantics of multipart messages 🔁

2.2. The Attachment Disposition Type 📎

Bodyparts can be designated attachment to show they're separate from the main body of the mail 📎 Their display SHOULD NOT be automatic, and it depends on some further action from the user 👆 The MUA might instead show a bitmap-terminal user an iconic representation of the attachments 🖼️ Or, on character terminals, it might hand over a list of attachments to pick from for viewing or storage 💾

2.3. The Filename Parameter 📁

The sender may want to suggest a filename to be used if the entity is detached and stored in a separate file 📁 If the receiving MUA writes the entity to a file, the suggested filename SHOULD be used as a basis for the actual filename, where possible ✨

It is super important that the receiving MUA doesn't just blindly use the suggested filename 🚨 The suggested filename SHOULD be checked (and maybe changed) to make sure it conforms to local filesystem conventions, doesn't overwrite an existing file, and isn't a security problem (see Security Considerations below) 🔐

The receiving MUA SHOULD NOT respect any directory path information that seems to be present in the filename parameter 🙅 The filename SHOULD be treated as a terminal component only 🍒 Portable specification of directory paths might possibly be done in the future through a separate Content-Disposition parameter, but this draft doesn't make any provision for it 🔮

Current [RFC 1521] grammar restricts parameter values (and so Content-Disposition filenames) to US-ASCII 🔤 We totally recognize how desirable it is to allow arbitrary character sets in filenames 💖 but defining the necessary mechanisms is beyond the scope of this document. We expect the basic [RFC 1521] value specification will someday be amended to allow non-US-ASCII characters 🌍 At that point, the same mechanism SHOULD be used in the Content-Disposition filename parameter ✨

Beyond the US-ASCII limit, the sending MUA MAY wish to bear in mind the limitations of common filesystems 💾 Many have severe length and character set restrictions. Short alphanumeric filenames are the least likely to need modification by the receiving system 🔤✨

The presence of the filename parameter does not force an implementation to write the entity to a separate file 🙌 It's perfectly acceptable for implementations to leave the entity as part of the normal mail stream unless the user asks otherwise 📬 So the parameter MAY be used on any MIME entity, even inline ones 🎯 These won't normally be written to files, but the parameter can still provide a filename if the receiving user should choose to write the part to a file 💾

2.4. Future Extensions and Unrecognized Disposition Types 🦋

In the likely event that new parameters or disposition types are needed, they SHOULD be registered with the IANA, in the manner specified in [RFC 1521], appendix E 📝

Once new disposition types and parameters are defined, implementations will probably run into disposition types and parameters they don't understand 🤷 And since x-tokens are allowed, they might also run into entirely unregistered disposition types and parameters 👀

Unrecognized parameters SHOULD be ignored 🙈 Unrecognized disposition types SHOULD be treated as attachment 📎 The reason is that a sender who goes to the trouble of producing a Content-Disposition header with a new disposition type is more likely aiming for something fancier than inline presentation 💅

Unless noted otherwise in the definition of a parameter, Content-Disposition parameters are valid for all dispositions 🌈 (This is different from [RFC 1521] content-type parameters, which are defined on a per-content-type basis.) So, for example, the filename parameter still means the name of the file to which the part should be written, even if the disposition itself is unrecognized 🎀

2.5. Content-Disposition and Multipart 🧩

If a Content-Disposition header is used on a multipart body part, it applies to the multipart as a whole, not the individual subparts 🧩 The disposition types of the subparts don't need to be consulted until the multipart itself is presented 🙅 When the multipart is displayed, the dispositions of the subparts SHOULD be respected 💖

If the inline disposition is used, the multipart SHOULD be displayed as normal; however, an attachment subpart SHOULD require action from the user to display 👆

If the attachment disposition is used, presentation of the multipart SHOULD NOT proceed without explicit user action 🛑 Once the user has chosen to display the multipart, the individual subpart dispositions SHOULD be consulted to figure out how to present the subparts 🔍

2.6. Content-Disposition and the Main Message 💌

It is permissible to use Content-Disposition on the main body of an [RFC 822] message ✅

…to be continued in Part 2 💜

4. Summary ✨

okay so bestie, Content-Disposition only has two values: inline and attachment 💖. inline basically means "show this to the user right away" 👀, and attachment means the user has to do something extra before they can see it 🎀.

The filename parameter is the sender's little suggestion for what to call the bodypart if the user wants to save it to an external file 📁🦋.

5. Security Considerations 🔐

okay this part is SO important, so pay attention 💅. Any time users swap data there are security issues. This memo doesn't make them smaller, and it doesn't change the status quo either, except in one instance 😭.

Since this memo lets the sender suggest a filename, a receiving MUA must take care that the suggested filename doesn't turn into a hazard. Using UNIX as the example, some hazards are:

• Creating startup files (e.g., ".login").
• Creating or overwriting system files (e.g., "/etc/passwd").
• Overwriting any existing file.
• Placing executable files into any command search path (e.g., "~/bin/more").
• Sending the file to a pipe (e.g., "| sh").

In general, the receiving MUA should never name or place the file in a way that gets it interpreted or executed without the user explicitly starting that action 🙈.

It is very important to note that this is NOT an exhaustive list! It's just a small set of examples. Implementors must be alert to the potential hazards on their target systems 💀

6. References 📚

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

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

7. Acknowledgements 🫶

we gratefully acknowledge the help these people gave during the preparation of this draft 🌈:

• Nathaniel Borenstein
• Ned Freed
• Keith Moore
• Dave Crocker
• Dan Pritchett

8. Authors' Addresses 🌸

and here are the people who wrote it, with their contact details 🧚:

Rens Troost
New Century Systems
324 East 41st Street #804
New York, NY, 10017 USA

Phone: +1 (212) 557-2050
Fax: +1 (212) 557-2049
EMail: rens@century.com


Steve Dorner
QUALCOMM Incorporated
6455 Lusk Boulevard
San Diego, CA 92121
USA

EMail: sdorner@qualcomm.com

---

that's the whole thing, bestie! 👑✨