RFC 3458
Message Context for Internet Mail
Message Context for Internet Mail 💌
Okay bestie, so this is RFC 3458, and it's called "Message Context for Internet Mail" 🎀
It was written by E. Burger (SnowShore Networks), E. Candell (Comverse), C. Eliot (Microsoft Corporation), and G. Klyne (Nine by Nine) 👯
It's a Standards Track doc, dated January 2003 📅
It doesn't obsolete or update anything, since there are no Obsoletes or Updates entries in the header ✨
Status of this Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the 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 🌸
Copyright Notice ⚖️
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
This memo describes a brand new RFC 2822 message header called "Message-Context". It gives info about the context and presentation characteristics of a message, which is so useful 😭
A receiving user agent (UA) may use this info as a hint to present the message in the best way possible 💅
Table of Contents 🗂️
1. Introduction....................................................2
2. Conventions used in this document...............................3
3. Motivation......................................................3
4. Functional Requirements.........................................5
5. Determining the Message Context.................................6
6. Message-Context Reference Field.................................7
6.1. Message-Context Syntax......................................7
6.2. message-context-class Syntax................................7
6.2.1. voice-message...........................................8
6.2.2. fax-message.............................................8
6.2.3. pager-message...........................................8
6.2.4. multimedia-message......................................8
6.2.5. text-message............................................8
6.2.6. none....................................................8
7. Security Considerations.........................................9
8. IANA Considerations.............................................9
8.1. Message Content Type Registrations..........................9
8.2. Registration Template......................................10
8.3. Message-Context Registration...............................11
9. APPENDIX: Some messaging scenarios.............................12
9.1. Internet e-mail............................................12
9.2. Pager service..............................................12
9.3. Facsimile..................................................13
9.4. Voice mail.................................................14
9.5. Multimedia message.........................................14
10. References....................................................15
10.1 Normative References.......................................15
10.2 Informative References.....................................15
11. Acknowledgments...............................................15
12. Authors' Addresses............................................16
13. Full Copyright Statement......................................171. Introduction 🌷
This doc describes a mechanism that lets senders of an Internet mail message share the message's contextual info 📨 Once the receiving user agent (UA) has that info, it can make decisions that make the message look better for the user, in the context the sender and receiver both expect 💖
Here, the "message context" tells you how the user expects to interact with the message 🧚 A message might be e-mail, voice mail, fax mail, and so on. A smart UA can have special behaviour based on the context of the message, and that's giving main character energy 👑
This doc specifies an RFC 2822 header called "Message-Context" ✨
The mechanism is kinda similar to the Content-Disposition MIME entity described in [6]. Content-Disposition gives the receiving User Agent (UA) clues about how to display a given body part. Message-Context gives the receiving UA clues about how to present the whole message 🎀 That way the receiving UA can show the message to the recipient in a meaningful and helpful way 🫶
Typical uses for this mechanism include:
- Selecting a special viewer for a given message.
- Selecting an icon that shows the kind of message in a displayed list of messages 🦋
- Arranging messages in an inbox display.
- Filtering the messages the UA shows when the user has limited access 🙈
2. Conventions used in this document 🎀
This doc refers to the sender of a message in the masculine (he/him/his), and to the recipient in the feminine (she/her/hers). This is purely for convenience and makes no assumption about the gender of a message sender or recipient 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2] 🔥
FORMATTING NOTE: Notes, such at this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices 🤓
3. Motivation 🌈
Multimedia messaging systems get messages that a UA may present in a variety of ways. Traditional e-mail uses simple text messages that the recipient displays and edits 💌 One UA might automatically print fax images 🖨️ Another UA might play voice messages through a telephone handset 📞 A receiving desktop computer might also process or present documents sent over e-mail using a local application 💻 Emerging and future developments may deliver other forms of information, each with their own characteristics for user presentation, like video messages and pager messages 🍓
A super-requested feature for multimedia messaging systems is a "universal inbox", where received messages get collected and offered to the user as one combined list 📥
In the context of "unified messaging", different message contexts can have different implied semantics. For example, some users might feel voicemail carries an implicit assumption of urgency 🚨 So they may want to gather those together and process them before other messages. This means the end-user receiving agent needs to be able to identify voicemail and tell it apart from other messages 👀
This kind of presentation characteristic for each message has several uses:
- Display an indication to the user (for example, a suitably evocative icon along with other summary fields),
- Auto-forward a given message type into another messaging environment (for example, a page to a mobile short message service),
- Prioritize and group messages in an inbox display list,
- Suggest appropriate default handling for presentation,
- Suggest appropriate default handling for reply, forward, and so on.
Here's the tricky part 😭 It's not always easy to decide the context of a received message. Consider these scenarios:
- A message that contains audio and image data: Is this a fax message that happens to have some voice commentary? Is it a voice message that comes with some supplementary diagrams? Or is it a fully multimedia message, where all the parts are expected to carry equal significance?
- A message containing text and audio data: Is this e-mail with an MP3 music attachment? Or is it a voice message that happens to have been generated with an initial text header for the benefit of non-voice-enabled e-mail receivers?
The message context does relate to the message media content, but it's not the same thing 💅 As shown above, the media type used in a message isn't enough to indicate the message context. You can't figure out ahead of time which media types to use in alternative (gateway) messages 🙃 And what if the user cares about telling traditional e-mail text apart from SMS messages? Both are the same media type, text, but they have different user contexts 💀
4. Functional Requirements 📋
The goals stated above lead to the following functional requirements.
For receivers:
- Identify a message as belonging to a message class.
- Incorrect or invalid message classification must not result in failure to transfer or inability to present a message.
For senders:
- Specify message classes by the originating user's choice of authoring tool or simple user interaction.
For both:
- Specify a well-defined set of message classes to make interoperability between mail user agents (UAs) possible 🫶
- Message classification information has to be interpretable in reasonable fashion by many different user agent systems.
- The mechanism should be extensible to allow for the introduction of new kinds of messages ✨
NOTE: We specifically do not specify user agent behavior when the user agent forwards a message. Clearly, the user agent, being message-context-aware, should provide a meaningful message-context. It is obvious what to do for the easy cases. Messages that the user simply forwards will most likely keep the context unchanged. However, it is beyond the scope of this document to specify the user agent behavior for any other scenario 🙈
5. Determining the Message Context ✨
okay so one way to figure out what kind of message you're looking at is to check the media types inside it 🧐. the catch is that the UA has to scan the entire message before it can decide anything 😩. that's extra painful for multi-media mail, because voice and especially video mail objects are huge 🐘.
we considered registering a multipart/* MIME subtype (Content-Type) for this 🎀. for example, the VPIM Work Group registered multipart/voice-message to say a message is mainly voice mail [7]. but multipart/voice-message is literally identical in syntax to multipart/mixed 💀. the only difference is that VPIM mail transfer agents and user agents know they can do special handling because it's voice mail. plus, Content-Type is about one MIME body part, not the message as a whole 🙅♀️.
we want to avoid scanning the whole message 🙈. we also want to avoid making a pile of aliases for multipart/mixed every time someone invents a new primary content type 😤. those aliases are a no-go because they'd kill the option of marking a message as multipart/alternate, multipart/parallel, or multipart/encrypted, for example 🚫.
since message context is an attribute of the whole message, it makes sense to define a new top-level (RFC 2822 [3]) message attribute 👑. so this document introduces the message attribute "Message-Context" 🦋.
Message-Context only identifies the message context 💅. it doesn't tell the UA what content it has to be able to deliver, and it doesn't imply any message disposition or delivery notification. there's a related effort to define Critical Content of Internet Mail [8] that you could use for those jobs 📬.
Message-Context is only an indicator 🫶. we don't intend for it to carry info that's critical for presenting the message. goofy example: a message marked "voice-message" with no audio body part 🤪. even then, the contents not matching the context does not mean the receiving system should generate an error report or fail to deliver or process the message. no drama 🌸.
6. Message-Context Reference Field 🎀
The Message-Context reference field is a top-level header that the sending UA inserts to show the context of the message 💌.
A receiving user agent MUST NOT depend on the indicated message-context value in a way that prevents proper presentation of the message. if the value is wrong or doesn't match the message content, the receiving user agent MUST still be capable of displaying the message content at least as meaningfully as it would if no Message-Context value were present 🙌.
one can picture a well-formed message that ends up without a media type you'd expect from its context 🤔. say a voice messaging system records a voice message and also runs speech-to-text on it 🎙️. then the message goes through a content gateway, like a firewall, that strips non-critical body parts over a certain length. the receiving UA gets a message in the voice-message context with only a text part and no audio. even without audio, it's still in the voice message context 💜.
said differently, the receiving UA can use the message-context to decide whether, when, and possibly where to display a message 🗓️. but the message-context should not affect the actual rendering or presentation 🎨. for example, if the message is in the voice-message context, don't try to send it to a fax terminal 📠🚫. flip it around: a message in the voice-message context gets delivered to a multimedia voice terminal with a printer, but this message only has fax content. here, the "voice-message" context should not stop the terminal from rendering the message properly ✨.
6.1. Message-Context Syntax
The syntax of the Message-Context field, described using the ABNF [4], is as follows. Note that the Message-Context header field name and message-context-class values are not case sensitive 🔤.
"Message-Context" ":" message-context-class CRLF6.2. message-context-class Syntax
The message-context-class indicates the context of the message. it's an IANA registered value 📚. the current values for message-context-class are below 👇.
message-context-class = ( "voice-message"
/ "fax-message"
/ "pager-message"
/ "multimedia-message"
/ "text-message"
/ "none"
)Note: The values for Message-Context MUST be IANA registered values following the directions in the IANA Considerations section below. 📌
6.2.1. voice-message
The voice-message class states the message is a voice mail message 🎤.
6.2.2. fax-message
The fax-message class states the message is a facsimile mail message 📠.
6.2.3. pager-message
The pager-message class states the message is a page, such as a text or numeric pager message or a traditional short text message service (SMS) message 📟.
6.2.4. multimedia-message
The multimedia-message class states the message is an aggregate multimedia message, such as a message specified by [9] 🌈. this helps identify a message in a multimedia context. for example, a MIME multipart/related [10] data part and resource part look the same as a multimedia MHTML multipart/related. however, the semantics are quite different 🙃.
6.2.5. text-message
The text-message class states the message is a traditional internet mail message 💌. it consists of text, possibly richly formatted, with or without attachments 📝.
6.2.6. none
The none class states there is no context information for this message 🫥.
If a message has no Message-Context reference field, a receiving user agent MUST treat it the same as it would if the message had a "none" value 🤍.
7. Security Considerations 🔒
The intention for this header is to be an indicator of message context only 🛑. one can imagine someone creating an "Application" Message-Context. a poorly designed user agent could blindly execute a mailed program based on the Message-Context.
Don't do that! 😱
one can also envision a denial of service attack, where a receiver gets bombed with messages whose Message-Context doesn't fit the profile of the actual body parts 💣. this is why the receiver considers the Message-Context to be a hint only 🫶.
8. IANA Considerations 📋
Section 8.3 is a registration for a new top-level RFC 2822 [3] message header, "Message-Context" 🎀.
This document creates an extensible set of context types. to promote interoperability and coherent interpretations of different types, a central repository has been established for well-known context types 🌟.
The IANA has created a repository for context types called "Internet Message Context Types". following the policies outlined in [5], this repository is "Specification Required" by RFC. Section 8.1 describes the initial values for this registry 🗂️.
To create a new message context type, you MUST publish an RFC to document the type. in the RFC, include a copy of the registration template found in Section 8.2 of this document. put the template in your IANA Considerations section, filling in the appropriate fields. You MUST describe any interoperability and security issues in your document 🔥.
8.1. Message Content Type Registrations
Internet Message Content Types
==============================
Value Description Reference
----- ----------- ---------
voice-message Indicates a message whose primary This RFC
content is a voice mail message. The
primary content is audio data. The
context is usually a message recorded
from a voice telephone call.
fax-message Indicates a message whose primary This RFC
content is a fax mail message. The
primary content is image data. The
context is usually a message recorded
from a facsimile telephone call.
pager-message Indicates a message whose primary This RFC
content is a page. The primary
content is text data. The context is
an urgent message usually of a
limited length.
multimedia-message Indicates a message whose primary This RFC
content is a multimedia message. The
primary content is multimedia, most
likely MHTML. The context is often
spam or newsletters.
text-message Indicates a classic, text-based, This RFC
Internet message.
None Indicates an unknown message context. This RFC8.2. Registration Template
In the following template, a pipe symbol, "|", precedes instructions or other helpful material 🧩. be sure to replace "<classname>" with the class name you are defining 🖊️.
Message-Context class name:
<classname>
Summary of the message class:
| Include a short (no longer than 4 lines) description or summary
| Examples:
| "Palmtop devices have a 320x160 pixel display, so we can..."
| "Color fax is so different than black & white that..."
Person & email address to contact for further information:
| Name & e-mail8.3. Message-Context Registration
To: iana@iana.org
Subject: Registration of New RFC 2822 Header
RFC 2822 Header Name:
Message-Context
Allowable values for this parameter:
Please create a new registry for Primary Context Class
registrations. See section 8.1 of this document for the initial
values.
RFC 2822 Section 3.6 Repeat Value:
Field Min Number Max Number Notes
Message-Context 0 1
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org9. APPENDIX: Some messaging scenarios 🧚
This section is not a normative part of this document 📖. we include it here as a historical perspective on the issue of multimedia message types 🕰️.
These scenarios are neither comprehensive nor fixed 🌈. for example, e-mails being typically text-based doesn't mean they can't convey a voice-message. this very mutability serves to underline the desirability of providing some explicit message context hint 💖.
9.1. Internet e-mail 📧
Okay so Internet e-mail carries textual information 💌 and sometimes it even carries computer application data of arbitrary size, which is kind of wild.
You usually use e-mail for non-urgent messages. The recipient grabs them and deals with them whenever it's convenient for her 💅
The usual device for receiving and processing e-mail is some kind of personal computer 💻 Modern ones tend to come with a reasonably large display and an alphanumeric keyboard. Audio, video, and printing capabilities are not necessarily available, so don't count on them 🙈
E-mail works for communication between two parties (one-to-one), a small number of known parties (one-to-few), or, through an e-mail distribution list, between larger numbers of unknown parties (one-to-many) 🌈
The thing I'm obsessed with is how e-mail lets the recipient forward all or part of a message to another party, with or without extra comments 🦋 It's super common for an e-mail to have snippets from several earlier messages stacked inside it. Replying works in a similar way ✨
9.2. Pager service 🔔
One uses a pager message to send notifications and alerts ⚡ For the most part these are textual, and they're limited in size. The typical limit is 160 characters. People use pages for relatively urgent messages that the sender wants the receiver to see and maybe respond to within a short time 🚨 Pager messages are often used to get users' attention for something that needs it. For example, a system can use a page to tell a subscriber there's a voicemail waiting for her 📞
Example devices for sending and receiving a pager message are a mobile telephone with a small character display, or a text pager 📟 Personal computers and personal digital assistants (PDAs) can join in on pager messaging too 🧚
Right now, the most common use of pager messages is between just two parties (one-to-one) 💜
One delivery method for pager messages is the short text messaging service (SMS) 📱 SMS grew up around mobile telephones and has an associated per-message transmission charge. Note that the focus here is on the notification aspect of SMS. SMS was envisioned as more than a simple pager service from the very beginning, and operators can use it to provision the phone, for example 🛠️ From the subscriber's point of view, SMS has evolved a lot from its pure pager replacement origins. With mobile originate service, people can have two-way text chat sessions over SMS on a mobile phone 💬 There are also SMS-enabled handsets that can display pictures 🖼️ Still, for the purposes of this document, we need to capture the essence of a "highly urgent, short-text, notification or alert" service ⭐
Users often send pager messages in isolation rather than as part of a longer exchange 🫶 One use for them is as a prompt or invitation to communicate by some more convenient and content-rich method, such as a telephone call ☎️
9.3. Facsimile 📠
People use facsimile to convey image information of moderate size, usually a small number of pages. Sometimes people use it for larger documents 📄
Facsimile usually runs over circuit-switched telephone circuits, with connection-time charges 💸 Message transfer happens in real time, so people often reach for facsimile when something is urgent 🔥
The normal device for sending and receiving a facsimile is a self-contained scanning and printing device connected to a telephone line, or a desktop computer 🖨️
Most facsimiles are between just two parties (one-to-one). That said, a significant portion of facsimile service is broadcast between multiple parties (one-to-many) 📣
Most facsimile exchanges happen in isolation rather than as part of a longer exchange. Facsimile data is typically not suitable for further processing by computer 🙃
9.4. Voice mail 🎙️
People use voice mail to convey audio information, which is almost exclusively human speech 🗣️
Voice mail usually runs over circuit-switched telephone circuits, with modest connection-time charges. It's often used for moderately urgent messages 💅 A common use is as a prompt or invitation to communicate by some more convenient method, such as a telephone call. In most, but not all, cases, the sender of a voice message doesn't actually want to send a message at all 😭 They wanted a real-time conversation!
The normal device for sending and receiving voice mail is a telephone handset ☎️
Voice messages are usually sent between just two parties (one-to-one) 🫶
Voice mail data is not generally suitable for further processing by computer 🎧
9.5. Multimedia message 🌸
We define a multimedia message as a message containing more than one basic media type (text, image, audio, video, model, application) 🎀
Here are some characteristics of a multimedia message:
In some cases, a multimedia message is just e-mail with an attachment that a multimedia display application presents. For example, I can send you an MP3 of something I recorded in my garage today 🎸
In other cases, a multimedia message is a convergence of two or more of the scenarios described above. For example, a voice message with an accompanying diagram, or a talking head video message, is a multimedia message 🧚♀️
The characteristics will vary somewhat with the intent of the sender, and that can affect the user agent or application used to render the message 👑
10. References 📚
10.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 🌟
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
[3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 💌
[4] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🧩
[5] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 📋
10.2 Informative References
[6] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997. 🎀
[7] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type Registration", RFC 2423, September 1998. 🎙️
[8] Burger, E., "Critical Content of Internet Mail", RFC 3459, January 2003. 💖
[9] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999. 🌈
[10] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. 🦋
11. Acknowledgments 🫶
Many of the ideas here came originally from a discussion with Jutta Degener 💜
We'd also like to thank Keith Moore for helping us tighten up our explanations ✨
In the last round, we got some rather good advice from Caleb Clausen and Dave Aronson 🙌
Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae helped distill the essence of the pager service vis a vis SMS 📱
We offer an extra special thanks to Greg Vaudreuil for pulling RFC 2557 out of his hat 🎩👑
12. Authors' Addresses 💅
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 978 367 8403
EMail: e.burger@ieee.org
Emily Candell
Comverse Network Systems
200 Quannapowitt Pkwy.
Wakefield, MA 01880
USA
Phone: +1 781 213 2324
EMail: emily.candell@comverse.com
Graham Klyne
Nine by Nine
United Kingdom
EMail: GK-IETF@ninebynine.org
Charles Eliot
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
USA
Phone: +1 425 706 9760
EMail: charle@Microsoft.com13. Full Copyright Statement ⚖️
Okay, this part is the legal fine print, so I'm keeping it word for word. No cap, it matters 🫡
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is 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.
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society 💖
📦 where this page comes from
- ietf: rfc3458 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms