RFC 3297
Content Negotiation for Messaging Services based on Email
RFC 3297: Content Negotiation for Messaging Services based on Email 💌
Okay bestie, this one is from the Network Working Group and it's giving Standards Track 💅 Written by G. Klyne (Clearswift Corporation), R. Iwazaki (Toshiba TEC) and D. Crocker (Brandenburg InternetWorking), dated July 2002. The title block doesn't list anything it obsoletes or updates, so this one stands on its own 🦋
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice 🎀
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 🌸
This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email.
Services like fax and voice messaging have to keep up with new message content formats 😭 but they also need to make sure the receiving agent can actually render whatever arrives. The mechanism here is built to handle both of those things, and it's fully compatible with how Internet email already behaves and what people already expect from it 💖
Table of Contents 🧚
1. Introduction................................................... 3
1.1 Structure of this document ................................. 4
1.2 Document terminology and conventions ....................... 4
1.2.1 Terminology............................................ 4
1.2.2 Design goals........................................... 5
1.2.3 Other document conventions............................. 5
2. Background and goals........................................... 5
2.1 Background ................................................. 5
2.1.1 Fax and email.......................................... 5
2.1.2 Current facilities in Internet Fax..................... 6
2.2 Closing the loop ........................................... 6
2.3 Goals for content negotiation .............................. 8
3. Framework for content negotiation..............................10
3.1 Send data with an indication of alternatives ...............11
3.1.1 Choice of default data format..........................12
3.1.2 MDN request indicating alternate data formats..........12
3.1.3 Information about alternative data formats.............13
3.2 Receiver options ...........................................14
3.2.1 Alternatives not recognized............................14
3.2.2 Alternative not desired................................14
3.2.3 Alternative preferred..................................14
3.3 Send alternative message data ..............................16
3.4 Confirm receipt of resent message data .....................17
4. The Content-alternative header.................................18
5. The Original-Message-ID message header.........................18
6. MDN extension for alternative data.............................19
6.1 Indicating readiness to send alternative data ..............19
6.2 Indicating a preference for alternative data ...............20
6.3 Indicating alternative data is no longer available .........21
6.4 Indicating loss of original data ...........................22
6.5 Automatic sending of MDN responses .........................22
7. Internet Fax Considerations....................................22
8. Examples.......................................................23
8.1 Sending enhanced Internet Fax image ........................23
8.2 Internet fax with initial data usable ......................27
8.3 Negotiate to lower receiver capability .....................28
8.4 Sending an alternative content type ........................32
9. IANA Considerations............................................36
9.1 New message headers ........................................36
9.2 MDN extensions .............................................36
9.2.1 Notification option 'Alternative-available'............36
9.2.2 Notification option 'Alternative-not-available'........36
9.2.3 Disposition modifier 'Alternative-preferred'...........37
9.2.4 Disposition modifier 'Original-lost'...................37
10. Internationalization considerations...........................37
11. Security Considerations.......................................37
12. Acknowledgements..............................................38
13. References....................................................38
Appendix A: Implementation issues.................................40
A.1 Receiver state .............................................40
A.2 Receiver buffering of message data .........................41
A.3 Sender state ...............................................42
A.4 Timeout of offer of alternatives ...........................42
A.5 Timeout of receiver capabilities ...........................42
A.6 Relationship to timely delivery ............................43
A.7 Ephemeral capabilities .....................................43
A.8 Situations where MDNs must not be auto-generated ...........44
Appendix B: Candidates for further enhancements...................44
Authors' Addresses................................................45
Full Copyright Statement..........................................461. Introduction 💖
This memo describes a mechanism for email based content negotiation. It gives Internet fax a facility that's comparable to traditional facsimile, and other messaging services that need similar facilities can use it too 📠
"Extended Facsimile using Internet Mail" [1] specifies how image data gets transferred using Internet email protocols. "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] describes a mechanism that tells the sender about a receiver's capabilities. If the sender stores that capability information, it can be reused in later transfers between the same sender and receiver ✨
Plenty of communications are one-off or infrequent transfers between a given sender and receiver, though, so they can't benefit from this "do better next time" approach 🙈
Email already has an alternative facility, though not many implementations use it. The sender can use 'multipart/alternative' [15] to send a message in several different formats and let the receiver pick one. Aside from the obvious cost in network bandwidth, this approach doesn't by itself let the sender really tailor its message to a given receiver, or confirm that any of the alternatives it sent was usable by the receiver 💅
This memo describes a mechanism that lets better-than-baseline data formats be sent in the first communication between a sender and receiver. The same mechanism can also achieve a usable message transfer when the sender based the initial transmission on incorrect information about the receiver's capabilities. It lets the sender of a message indicate that alternative formats are available, and lets the receiver indicate that an alternative format should be provided to replace the message data originally transmitted 🦋
When the sender doesn't have the correct information about a receiver's capabilities, this mechanism may add an extra message round trip. An important goal here is to provide enough information to determine whether that extra round trip is actually required 🫶
1.1 Structure of this document 🌈
The main part of this memo covers the following areas:
Section 2 gives some background and sets out specific goals that this specification addresses.
Section 3 describes the content negotiation framework and shows the flow of information between a sender and receiver.
Section 4 contains a detailed description of the 'Content-alternative' header, which conveys information about alternative available formats. This description is meant to stand independently of the rest of this specification, so it can be used alongside other content negotiation protocols 🧠
Section 5 describes a new mail message header, 'Original-Message-ID'. It correlates alternative data sent during negotiation with the original message data, and it tells the continuation of an old message transaction apart from the start of a new one 📨
Section 6 describes extensions to the Message Disposition Notification (MDN) framework [4] that support negotiation between the communicating parties ✨
1.2 Document terminology and conventions 🍓
1.2.1 Terminology
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 RFC 2119 [22].
Capability exchange An exchange of information between communicating parties indicating the kinds of information they can generate or consume.
Capability identification Information provided by a receiving agent that indicates the kinds of message data it can accept for presentation to a user.
Content negotiation An exchange of information (negotiation metadata) which leads to selection of the appropriate representation (variant) when transferring a data resource.
Message transaction A sequence of exchanges between a message sender and receiver that accomplish the transfer of message data.
RFC 2703 [17] introduces several other terms related to content negotiation 🤓
1.2.2 Design goals 🎀
When discussing goals for content negotiation, the {1}, {2} and {3} notation is used, per RFC 2542, "Terminology and Goals for Internet Fax" [3]. Those notations mean:
- {1} there is general agreement that this is a critical characteristic of any definition of content negotiation for Internet Fax.
- {2} most believe that this is an important characteristic of content negotiation for Internet Fax.
- {3} there is general belief that this is a useful feature of content negotiation for Internet Fax, but that other factors might override it; a definition that does not provide this element is acceptable.
1.2.3 Other document conventions 🙈
NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth.
2. Background and goals 🦋
2.1 Background 🌸
2.1.1 Fax and email ✨
okay so bestie, one of the big goals behind defining a facsimile service over Internet mail was bringing the best parts of traditional Group 3 Fax into email 📠💖. Group 3 Fax leans super hard on the idea that the two machines chat before any message data gets sent, so the sender learns what the receiver can handle first. Iconic, honestly 💅.
Internet mail is kinda the opposite vibe 🫠. It was built to work without any expectation that sender and receiver will exchange info before the message transfers. The consequence? Every mail message has to contain some kind of meaningful message data. Messages sent just to poke a receiving message handling agent for info are not generally acceptable in the Internet mail environment. Not me being picky, the email world is strict 🙈.
To guarantee some level of interoperability, Group 3 Fax and Internet mail both rely on every receiver being able to handle some baseline format (a basic image format for fax, plain ASCII text for email). Capability exchange or content negotiation exists so that better-than-baseline stuff can be used where available ✨.
Now, the challenge this spec tackles is how to adapt the email environment to provide a fax-like service. A sender must not make any a priori assumption that the receiver can recognize anything other than a simple email message. There are some important email uses that are fundamentally incompatible with the fax model of message passing and content negotiation (mailing lists, notably 📬). So we need a way to recognize when content negotiation is possible without breaking the existing email model. Main quest energy 👑.
2.1.2 Current facilities in Internet Fax 🌸
"Extended Facsimile using Internet Mail" [1] gives a limited amount of receiver capability info to the sender of a message. It does this with an extension to Message Disposition Notifications [2,4], employing media feature tags [5] and media feature expressions [6].
Here's the catch 😭: this mechanism only discloses receiver capabilities after a message has been received and processed. That info can be used for subsequent transmissions to the same receiver, but lots of communications are one-off messages from a given sender to a given receiver, so they can't benefit from it at all.
2.2 Closing the loop 🔁
Classic Internet mail is an "open loop" process: no information is returned to the point the message was sent from. This has been unkindly --but accurately-- characterized as "send and pray" 💀, since it lacks confirmation.
Sending a message and getting confirmation that it was received is a "closed loop" process: the confirmation sent back to the sender creates a loop around which information gets passed. 🫶
Lots of Internet email agents are not designed to participate in a closed loop process, so they have no responsibility to respond to receipt of a message. Later additions to Internet standards, notably Delivery Service Notification [18] and Message Disposition Notification [4], specify means for certain confirmation responses to be sent back to the sender, thereby closing the loop. However, conformance to these enhancements is optional and full deployment is still in the future 🔮.
DSN must be fully implemented by the entire infrastructure. Further, when support is lacking, the message is still sent on in open-loop fashion. Sometimes, transmission and delivery should instead be aborted and the fact reported to the sender.
Due to privacy considerations for end-users, MDN usage is entirely voluntary 🙈.
Content negotiation is a closed loop function (for the purposes of this proposal -- see section 2.3, item (f)), and requires that the recipient of a message make some response to the sender. Since content negotiation has to retro-fit a closed-loop function over Internet mail's voluntary and high-latency environment, the challenge for content negotiation in email is to establish that consenting parties can recognize a closed loop situation, and hence recognize their responsibilities to close the loop 🧠.
Three different loops can be identified in a content negotiation:
Sender Receiver
| |
Initial message ------>------------ v
| |
(1) ------------<--- Request alternative data
| |
Send alternative ------>------------ (2)
| |
(3) ------------<------ Confirm receipt
of usable data- (1) Sender receives acknowledgement that negotiable content has been received
- (2) Receiver receives confirmation that its request for data has been received.
- (3) Sender receives confirmation that received data is processable, or has been processed.
Although the content negotiation process is initiated by the sender, it is not established until loop (1) is closed with an indication that the receiver desires alternative content. 🎀
If content sent with the original message from the sender is processable by the receiver, and a confirmation is sent, then the entire process is reduced to a simple send/confirm loop:
Sender Receiver
| |
Initial message ------>------------ v
| |
(3) ------------<------ Confirm receipt
of usable data2.3 Goals for content negotiation 🎯
The primary goal {1} is to provide a mechanism that allows arbitrary enhanced content features to be used with Internet fax systems. The mechanism should {2} support introduction of new features over time, particularly those that are adopted for Group 3 fax. 🌈
Further goals are:
(a) Must {1} interwork with existing simple mode Internet fax systems. 🍓
(b) Must {1} interwork with existing email clients.
The term "interwork" used above means that the mechanism must be introduced in a way that may be ignored by existing systems, and systems enhanced to use the negotiation mechanisms will behave in a fashion that is expected by existing systems. (I.e., existing clients are not expected in any way to participate in or be aware of content negotiation.)
(c) Must {1} avoid transmission of "administrative non messages". (I.e., only messages that contain meaningful content for the end user may be sent unless it is known that the receiving system will interpret them, and not attempt to display them.) This requirement has been stated very strongly by the email community. 📬
This means that a sender must not assume that a receiver can understand the capability exchange protocol elements, so must always start by sending some meaningful message data. 💜
(d) Avoid {1} multiple renderings of a message. In situations where multiple versions of a message are transferred, the receiver must be able to reliably decide on a single version to be displayed. 👑
(e) Minimize {2} round trips needed to complete a transmission. Ideally {3} every enhanced transmission will result in simply sending data that the recipient can process, and receiving a confirmation response. 🦋
(f) The solution adopted should not {3} transmit multiple versions of the same data. In particular, it must not {1} rely on routinely sending multiple instances of the same data in a single message.
This does not prohibit sending multiple versions of the same data, but it must not be a requirement to do so. A sender may choose to send multiple versions together (e.g., plain text and some other format), but the capability exchange mechanism selected must not depend on such behaviour. 🧚
(g) The solution adopted should {2} be consistent with and applicable to other Internet email based applications; e.g., regular email, voice messaging, unified messaging, etc. ⭐
(h) Allow for a graceful recovery from stale cache information. A sender might use historic information to send non-baseline data with an initial message. If this turns out to be unusable by the recipient, it should still be possible {3} for the baseline data, or some other acceptable format, to be selected and transferred. 🫠
(i) The mechanism defined should {2} operate cleanly in conjunction with the mechanisms already defined for extended mode Internet fax (extended DSN and MDN [2], etc.). ✨
(j) As much as possible, existing email mechanisms should {3} be used rather than inventing new ones. (It is clear that some new mechanisms will be needed, but they should be defined cautiously.) 🌸
(k) The mechanism should {2} be implementable in low memory devices. That is, it should not depend on any party being able to buffer arbitrary amounts of message data.
(It may not be possible to completely satisfy this goal in a sending system. But if the sender does not have enough memory to buffer some given message, it can choose to not offer content negotiation.) 💅
3. Framework for content negotiation ✨
okay so this section is the big-picture bit 🖼️ It starts with an outline of the whole negotiation process, and then the sub-sections zoom in on each stage. let's gooo 💅
- The sender sends its initial message data with a heads-up about the alternative formats it has (section 3.1) 🎀 The initial data MAY be a baseline, or just a guess at what the recipient can handle.
- The receiver has three main options 🫶
- (a) It doesn't recognize the optional alternative formats, so it passively accepts the data as sent (section 3.2.1).
- (b) It does recognize the alternatives offered, and actively accepts the data as sent (section 3.2.2).
- (c) It recognizes the alternatives offered and decides it prefers an alternative format. It sends an MDN response that (i) says the original data was not processed, and (ii) contains its receiver capability information, so the sender can pick a suitable alternative (section 3.2.3).
Note that only recipients named in to:, cc: or bcc: headers in the original message may request alternative data formats this way. Recipients not named in the original message headers MUST NOT attempt to initiate content negotiation.
NOTE: the prohibition on initiation of negotiation by recipients other than those explicitly addressed is there to stop the sender from having to deal with negotiation requests from unexpected parties. 🙅♀️
- On receipt of an MDN response indicating a preference for an alternative data format, the sender MUST select and transmit message data that matches the receiver's declared capabilities, or send an indication that the receiver's request cannot be honoured. When sending alternative data, the sender suppresses the indication that alternative data is available, so the negotiation process can't loop 🔁💀
- When the receiver gets final data from the sender, it sends an MDN response indicating acceptance (or otherwise) of the data received ✅
NOTE: the receiver does not choose the particular data format to be received. That choice rests with the sender! We find this approach simpler than having the receiver choose an alternative, because it builds on existing mechanisms in email and follows the same pattern as a traditional Group 3 fax. It also deals with situations where the range of alternatives is hard to describe. 📠✨ This approach is similar to server-driven negotiation in HTTP using "Accept" headers [13]. It's different from the agent-driven style of negotiation provided for HTTP as part of Transparent Content Negotiation [14], or which might be built in email using "multipart/alternative" and "message/external-body" MIME types [15]. 🦋
3.1 Send data with an indication of alternatives
A sender that is prepared to provide alternative message data formats MUST send the following message elements:
- (a) a default message data format,
- (b) message identification, in the form of a
Message-IDheader, - (c) appropriate
Content-featuresheader(s) [7] describing the default message data sent, - (d) a request for Message Disposition Notification [4],
- (e) an indication that it is prepared to send different message data, using an
Alternative-availableMDN option field [9], and - (f) an indication of the alternative data formats available, in the form of
Content-alternativeheader(s) [8]. Note: more than oneContent-alternativeheader MAY be specified; see section 3.1.3 for more information. 🌈
Once the sender has said alternative formats are available, it's expected to hold the necessary information for some time, so the receiver has a chance to request that data 🕰️ But unless it says otherwise (see [9]), the sender isn't expected to hold this info forever. The exact length of time it should be held isn't specified here. So a request for alternative info might arrive too late, and then the sender will send an indication that the data is no longer available 😭 If message transfer is being completed within a predetermined time interval (e.g., using [21]), the sender should normally keep the data for at least that long 🧚
3.1.1 Choice of default data format
The normal default format is text/plain. This is the format sent unless the sender has prior knowledge or expectation of other content formats the recipient supports. Some uses of email assume a different default format (e.g. Internet fax [1] has TIFF profile S [11] as its default format; see section 7 of this document) 📄
"Extended Facsimile Using Internet Mail" [1] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] describe a possible mechanism for a sender to have prior knowledge of receiver capabilities. This specification builds on the mechanism described there 🔍
As always, the sender may gather information about the receiver in other ways beyond the scope of this document (e.g., a directory service or the suggested RESCAP protocol) 💅
3.1.2 MDN request indicating alternate data formats
When a sender is indicating it's prepared to send alternative message data, it MUST request a Message Disposition Notification (MDN) [4] 📬
It signals that it's ready to send alternative message data by including the MDN option Alternative-available [9] with the MDN request. Having this MDN request option just means the sender is prepared to send a different data format if it has more accurate or up-to-date info about the receiver's capabilities. On its own, this option doesn't say whether the alternatives are likely to be better or worse than the default data sent. That info comes from the Content-alternative header(s) [8] 🤷♀️
When using the Alternative-available option in an MDN request, the message MUST also contain a Message-ID: header with a unique message identifier 🆔
3.1.3 Information about alternative data formats
A sender can share info about the alternative message data it has by putting one or more Content-alternative headers on the message body parts that have alternative data available. Each one indicates media features [5,6] of an available alternative 🎨
The point of this info is to let a receiver decide whether any of the available alternatives are preferable, or likely to be preferable, to the default message data provided 🤔
Not every available alternative is required to be described this way. But the sender should include enough info to let a receiver work out whether it can expect more useful message data if it picks an alternative that matches its capabilities 💖
Alternative formats will often be variations of the content-type originally sent. When different content-types can be provided, they should be indicated in a corresponding Content-alternative header using the type media feature tag [24]. (See example 8.4.) 🌸
NOTE: the sender isn't necessarily expected to describe every single alternative format that's available. Honestly, when content is generated on-the-fly rather than picked from a list of possibilities, that might be impossible. The sender is expected to use one or moreContent-alternativeheaders to reasonably indicate the range of alternative formats available. The final format actually sent will always be selected by the sender, based on the receiver's capabilities. TheContent-alternativeheaders are only there so the receiver can make a reasonable decision about whether to request an alternative format that better matches its capabilities 🧠 ALSO NOTE: this header is meant to be usable independently of the MDN extension that says the sender is prepared to send alternative formats. It could be used with a different protocol that has nothing to do with email or MDN. So theContent-alternativeheader gives info about alternative data formats without actually saying if or how they can be obtained 🦋 Further, theContent-alternativeheader applies to a MIME body part, whereas the MDNAlternative-availableoption applies to the message as a whole 👑
The example sections of this memo show how the Content-features: and Content-alternative: MIME headers may be used to describe the content provided and the available alternatives 🎀
3.2 Receiver options
A negotiation-aware system that receives message data without any indication of alternative data formats MUST process that message the same way as a standard Internet fax system or email user agent 📠
When there's an indication of alternative data format options, the receiver has three main options:
- (a) don't recognize the alternatives: passively accept what is provided,
- (b) don't prefer the alternatives: actively accept what is provided, or
- (c) prefer some alternative format. 💜
3.2.1 Alternatives not recognized
This is the case where the receiver is a simple-mode Internet fax recipient [12], or a traditional email user agent 📧
The receiver doesn't recognize the alternatives offered, or chooses not to recognize them, and simply accepts the data as sent. A standard MDN response [4] or an extended MDN response [2] MAY be generated, at the receiver's option 🙌
3.2.2 Alternative not desired
The receiver does recognize the alternatives offered, but specifically chooses to accept the data originally offered. An MDN response SHOULD be sent indicating acceptance of the data, and it should also contain the receiver's capabilities 🫶
This is the same as the defined behaviour of an Extended Internet Fax receiver [1,2]. ✨
3.2.3 Alternative preferred ✨
Okay so this one is the "I'd actually like a different version, please" case 💅. It extends Extended Internet Fax [1,2] so the receiver can ask for a different form of the same message 🎀. Here's the catch: this option may be followed ONLY if the original message carried an 'Alternative-available' MDN option (alternative data re-sends may not use this option). It also only works if the recipient is explicitly addressed in the headers ('to:', 'cc:' or 'bcc:') 🌸.
So the receiver spots that alternative data exists, looks at the info it was given, and decides an alternative format would be better 🦋. Then it sends an MDN response [4] that MUST contain:
- an
Alternative-preferreddisposition modifier [9], saying some data format other than the one originally sent is preferred, - an
Original-Message-ID:field [4] carrying the message identifier from the received message, and - receiver capabilities, per RFC 2530 [2].
Once that response is sent, the receiver MAY throw away the message data it got, because it's expecting an alternative to show up 🫶. BUT, if the sender set a limited lifetime for the alternative data, and the original data is something the receiver can actually display, the receiver SHOULD NOT toss it. And if the receiver doesn't have enough memory to hang onto the original for as long as the alternative could reasonably take to arrive, it SHOULD accept and display the original data. If the original data is something the receiver can't display, then it SHOULD discard the original and request an alternative format 😭.
NOTE: These rules exist so the content negotiation framework never ends up losing data that could have been received and displayed. Protect the data, bestie! 🔥
Once the receiver has asked for an alternative and hasn't displayed the original, it MUST remember that fact and be ready to fix things if the alternative never arrives in a reasonable amount of time (for example, if the MDN response or the alternative data got lost in transit) 💀.
The possible fixes are:
- (a) re-send the MDN response, and keep waiting for an alternative,
- (b) present the data originally supplied (if it is still available), or
- (c) generate an error response indicating loss of data.
When it's clear the alternative isn't coming, option (b) is the favourite 👑, but receivers with limited memory might not be able to pull that off.
Check Appendix A for more on receiver behaviour options 🧚.
NOTE: A cache control indicator on recipient capabilities was considered, but it is not included in this specification. Sometimes a recipient only wants to offer certain capabilities in certain situations and doesn't want them remembered for later, like not wanting colour images for routine messages 🌈.
NOTE: The receiver never actually gets to pick a specific data format from what the sender offers. The sender makes the final call, based on the receiver's declared capabilities. This approach: - (a) more closely matches the style of T.30 content negotiation, - (b) integrates cleanly with the current extended mode Internet fax specification, - (c) builds on existing email mechanisms in a consistent way, and - (d) allows for cases (e.g., dynamically generated content) where it isn't practical for the sender to list every alternative available 🦋.
3.3 Send alternative message data 🍓
So the sender offered alternative data with an 'Alternative-available' option on the original MDN request, and now it's gotten back an MDN response saying Alternative-preferred 🎉. The sender SHOULD send the alternative message data that best matches what the receiver said it can handle. (In the rare case that the response asking for an alternative doesn't include receiver capabilities, a baseline format should be selected.)
Here's a sneaky one 👀: if any part of that best-matching data is the same as what was originally sent, it MUST still be re-transmitted anyway, because the receiver may have tossed the original. Any data sent in response to an 'Alternative-preferred' response should include an MDN request but SHOULD NOT include an 'Alternative-available' disposition notification modifier 💜.
If the sender can't send message data anymore, for whatever reason, it MUST send a message telling the receiver the transfer failed. It SHOULD also generate a report for the receiver about the failure, which contains an MDN request and an 'Alternative-not-available' disposition notification modifier 😭.
Any message sent in response to a request for alternative data MUST include an 'Original-Message-ID:' header [23], holding the Original-message-ID value from the received disposition notification (which is the 'Message-ID:' from the original message). This header is what ties the re-send (or failure message) back to the original, and it also tells a re-send apart from an original message 🔗.
3.4 Confirm receipt of resent message data 🫶
When resent data shows up (you can tell because there's an 'original-message-ID:' header field), the receiver processes it and sends an MDN response with the final disposition of the data it got. That response also shares capabilities that may be used for future messages, per RFC 2530 [2] and RFC 2532 [1] ✨.
If the re-send says alternative data is no longer available (with an 'Alternative-not-available' disposition notification modifier), and the receiver still has the original data, it should display or process the original data and send an MDN response with the final disposition of that. So a response to 'Alternative-not-available' can totally be a successful disposition notification 🎀.
If the re-send says alternative data is no longer available (with an 'Alternative-not-available' disposition notification modifier), and the receiver has already thrown the original away, it SHOULD:
- (a) display or process the failure message received, OR
- (b) construct and display a message saying the message data has been lost, ideally including the sender, time, subject, message identifier and any other info that could help the user figure out which message went missing 🥺.
Then it sends a message disposition response with a final message disposition of "deleted" 💀.
4. The Content-alternative header 🌷
The 'Content-alternative:' header is a MIME header that can be attached to a MIME body part to say that some alternative form of the data in that part is available 🦋. It doesn't, on its own, say how you'd actually access that alternative form 🙈.
The syntax is written in ABNF notation from RFC 2234 [10], and it goes like this:
Content-alternative-header =
"Content-alternative" ":" Alternative-feature-expression
Alternative-feature-expression =
<As defined for 'Filter' by RFC 2533 [6]>You can attach more than one 'Content-alternative:' header to a MIME body part. When you do, each one describes a separate alternative data format that's available 💖.
A content-alternative header gets used alongside some MIME-encapsulated data, and it's read in that context. Its job is to point out possible variations of that data. It isn't supposed to be a complete, standalone description of one specific available version 🌈. What it does need is enough info for a receiver to figure out two things: (a) whether the alternative is likely to be an upgrade on the data it actually got, and (b) whether it's likely the receiver can process it 🧚.
So when a receiver reads a Content-alternative header value, it may assume that any features it doesn't mention are the same in the alternative as in the data supplied. For example, if a Content-alternative header doesn't mention an alternative MIME content-type, the receiver may assume the alternative uses the same content-type as the supplied data 🍓.
See also the example in section 8.4 ✨.
5. The Original-Message-ID message header 🔗
The 'Original-Message-ID' header is how any response or re-send gets linked back to the original message it's about (see also sections 3.2.3, 3.3) 💜. A re-send is its own separate message, so it MUST have its own unique Message-ID value (per RFC 2822, section 3.6.4) 👑.
The syntax for this header is:
"Original-Message-ID" ":" msg-idwhere 'msg-id' is defined by RFC 2822 as:
msg-id = "<" id-left "@" id-right ">"The 'msg-id' value given must be identical to the one in the Message-ID: header of the original message that the current message is responding to or re-sending 🎀.
6. MDN extension for alternative data 🦋
Here we define two extensions to the Message Disposition Notification (MDN) protocol [4] 💅. One lets a sender say it's ready to send alternative message data formats. The other lets a receiver say which alternative format it prefers 🌸.
This section doesn't cover how to indicate which alternatives are available or preferred. That job belongs to the 'Content-alternative' MIME header [8] and to "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] 🫶.
6.1. Indicating readiness to send alternative data 💖
okay so if a sender wants to say "hey, I've got other formats ready if you want them" 🎀, they have to ask for an MDN response using the MDN Disposition-Notification-To: header [4].
The MDN request also comes with a Disposition-Notification-Options: header that has the parameter Alternative-available with an importance value of optional. The optional part is the key bit 🔑: receiving agents that don't know about this option won't send back random failure responses. Bestie, that's so thoughtful 🥹
This spec defines a value for attribute to use in an MDN Disposition-Notification-Options: header [4]:
attribute =/ "Alternative-available"So a sender includes these headers to say that alternative message data is available:
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-available=optional,<lifetime>The <lifetime> slot is either transient or permanent, and it tells the receiver whether the alternative data is only hanging around for a little bit or is going to stick around for ages 🕰️. permanent means the data lives in long term storage and you can expect it to be there for at least several days, and probably weeks or months. transient means the alternative data can be thrown out at any time, though it would normally be kept for the expected duration of a message transaction.
NOTE: the <lifetime> parameter is provided to help low-memory receivers (which are unable to store received data) avoid loss of information through requesting an alternative data format that may become unavailable.
A message sent with a request for an MDN with an Alternative-available option MUST also contain a Message-ID: header field [20]. No skipping this one, periodt 🙅♀️
6.2. Indicating a preference for alternative data 🌸
The MDN spec [4] has a bunch of message disposition options that a receiver can report back. Here's the lineup 💅:
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extensionThis spec adds one more value for disposition-modifier-extension:
disposition-modifier-extension =/
"Alternative-preferred"When a receiver wants an alternative format sent over, it sends an MDN with this Disposition: field:
Disposition:
<action-mode>/<sending-mode>,
deleted/alternative-preferredFor example, an automatically generated response might look like this:
Disposition:
automatic-action/MDN-sent-automatically,
deleted/alternative-preferredAn MDN response with an alternative-preferred disposition modifier MUST also contain an Original-message-ID: field [4] with the Message-ID: value from the original message. That's how the sender knows which message you're talking about ✨
An MDN response with an alternative-preferred disposition modifier SHOULD also contain a Media-accept-features: field [2]. That field tells the sender which capabilities to use when picking an alternative form of message data 🎯. If it isn't supplied, the sender should assume some baseline feature capabilities.
Receiver capabilities sent with an alternative-preferred disposition notification MUST NOT be cached: they may apply to the current transaction only. 🫣
6.3. Indicating alternative data is no longer available 🥀
If a sender gets a request for alternative data that's gone, or can't provide any alternative data that matches the receiver's capabilities, it MUST respond and say so. It sends a message containing data that describes the failure 😭
That message MUST specify the MDN Disposition-Notification-To: header [4], along with a Disposition-Notification-Options: header that has the parameter Alternative-not-available with an importance value of required.
This spec defines a value for attribute to use in an MDN Disposition-Notification-Options: header [4]:
attribute =/ "Alternative-not-available"So a sender includes these headers to say that the alternative message data it offered earlier isn't available anymore:
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-not-available=required,(TRUE)A message sent with a request for an MDN with an Alternative-not-available option MUST also contain an Original-message-ID: header [23] holding the value from the Message-ID: header of the original message.
6.4. Indicating loss of original data 🙀
This spec adds one more value for disposition-modifier-extension:
disposition-modifier-extension =/
"original-lost"Sometimes a receiver loses message data because it doesn't have enough memory to store the original while it waits for an alternative to be sent. When that happens, it sends an MDN with this field:
Disposition:
<action-mode>/<sending-mode>,
deleted/original-lostFor example, an automatically generated response might look like this:
Disposition:
automatic-action/MDN-sent-automatically,
deleted/original-lostAn MDN response with an original-lost disposition modifier MUST also contain an Original-message-ID: field [4] with the Message-ID: value from the resent message, or from the original message if no re-send has been received 🔁
6.5. Automatic sending of MDN responses 🛡️
When you send an MDN response that asks for alternative data, the security concerns in RFC 2298 [4] (sections 2.1 and 6.2) about automatic MDN responses must be respected. This part is serious, so please read it 👀. In particular, a system that can do content negotiation MUST have an option that lets its user turn off negotiation responses, either generally, on a per-message basis, or both. Nobody gets trapped in auto-replies on my watch 🚫
7. Internet Fax Considerations 📠
Internet fax is an app that uses email to swap document images (see RFC RFC 2305 [12] and RFC 2532 [1]). It's giving vintage but it's still very much alive 🍓
Both the sender and receiver parts of this spec use media feature expressions. For Internet fax, any such expressions SHOULD use the feature tags defined in "Content feature schema for Internet fax" [16]. In a wider email context, any valid media features MAY be used 🌈
For Internet fax [12], "image/tiff" is the assumed content-type for message data. All Internet fax devices are presumed to be able to send and receive the TIFF profile S capabilities (Section 3 of [11]). When two Internet fax devices are talking to each other, that capability may be assumed. But when you're dealing with devices that go past the capabilities defined for Internet fax (like generic email agents with fax features), it would be better not to assume fax capabilities, and for the negotiating parties to be explicit about all of their capabilities 💅
Even Internet fax devices would do better not to assume they're talking to other fax devices. With Internet email there's no reliable way to establish that fact 🤷♀️. So for any Internet fax device that might reasonably exchange messages with any other email agent, it is RECOMMENDED that Internet fax capabilities (such as image/tiff baseline format handling) are not assumed but stated explicitly ✨
In particular, the Media-Accept-Features: header in receiver MDN responses SHOULD explicitly indicate (type="image/tiff") and baseline TIFF capabilities, rather than just assuming they're understood 🎀
8. Examples 🧚
8.1. Sending enhanced Internet Fax image ✨
okay so picture this 💖 Jane is a sender with a profile-F image (A4, 400x400dpi, MMR) and she wants to send it to Tom. The baseline for Internet fax is 200x200dpi with MH compression, so Jane starts by offering the baseline version and attaching the fancier one as an alternative. Tom then asks for the alternative. 🫶
Sender's initial message:
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
Content-alternative:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
[TIFF-FX Profile-S message goes here]
--RAA14128.773615765/ example.com--Receiver sends MDN response to initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@example.org> with subject "Internet
FAX Full Mode Content Negotiation" has been received. An
alternative form of the message data is requested.
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615766/example.org--Sender's message with enhanced content:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
[TIFF-FX profile-F message goes here]
--RAA14128.773615768/ example.com--Receiver sends MDN confirmation of enhanced message content:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject " Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/example.org--8.2. Internet fax with initial data usable 🦋
this one is the sequel 🎀 It shows how the second and later transfers between the same two systems from the previous example might go. Now that they've already swapped notes, Jane knows what Tom likes, so she includes the profile-F data right away in her very first message. No back-and-forth needed, bestie. 💅
Sender's initial message:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
Content-alternative:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
[TIFF-FX Profile-F message goes here]
--RAA14128.773615765/ example.com--Receiver sends MDN confirmation of received message content:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject "Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/example.org--8.3. Negotiate to lower receiver capability 🔽✨
okay so this one is about a sender who was a little too optimistic 🙈 Jane assumes Tom's fax machine is fancier than it actually is, so she has to send a lower-capability version after Tom tells her what he can really handle. bestie, it's giving "I'll just send the good stuff and see what happens" 💅
Here's the setup. An Internet fax sends a profile-F image (A4, 400x400dpi, MMR). If the receiver can't handle that, the sender falls back to baseline profile-S. Since baseline is the default format, nobody has to declare that capability in the original message. And if a receiver gets data it can't process from a sender who's negotiating, the best it can do is reply with a description of what it actually supports and let the sender figure out what happens next. The receiver doesn't get to pick the outcome, periodt 🧚
Let's walk through the thread.
Jane's first message is the big, fancy profile-F one. She asks for MDN responses to go back to her and lists the alternative-available options she's open to:
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
[TIFF-FX Profile-F message goes here]
--RAA14128.773615765/ example.com--Tom's machine can't handle that, so he sends back an MDN saying he'd like an alternative form of the message. His report says the image was deleted and that an alternative is preferred, and it includes his media accept features so Jane knows what he can take:
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Negotiate Down
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@example.org> with subject "Internet
FAX Full Mode Content Negotiation" has been received. An
alternative form of the message data is requested.
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615766/example.org--Jane gets the hint loud and clear 🫶 Her next message is the baseline version. It points back to her original with Original-Message-Id, so Tom can connect the dots:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
[TIFF-FX profile-S message goes here]
--RAA14128.773615768/ example.com--Last but not least, Tom confirms that he processed the lower-capability message. His MDN says it was processed in Internet FAX Full Mode and lists his media accept features again:
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject " Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615769/example.org--So the vibe check is complete ✨ Jane tried to go big, Tom politely said "not quite," and Jane pivoted to baseline and got a clean "processed" back. That's the whole negotiate-down energy, and honestly iconic 👑🦋
8.4 Sending an alternative content type
Okay so, remember section 4? 🦋 The sender can offer the same data using a different MIME content-type, and this example is giving main character energy. Jane offers a profile-F image (A4, 400x400dpi, MMR) and a limited-colour PDF as alternatives to a baseline image/TIFF. 💅
Sender's initial message:
(Note that the MIME content type is not specified for the
image/tiff alternative, being the same as that provided, but
is mentioned for the application/pdf alternative.)
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
Content-alternative:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
Content-alternative:
(& (type="application/pdf")
(color=Limited)
(dpi=400)
(paper-size=A4)
(ua-media=stationery) )
[TIFF-FX Profile-S message goes here]
--RAA14128.773615765/ example.com--Receiver sends MDN response to initial message:
(Note that this response indicates an ability to handle the
PDF MIME content-types, but with only binary colour.)
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to
Tom Recipient <Tom_Recipient@example.org> with subject "Internet
FAX Full Mode Content Negotiation" has been received. An
alternative form of the message data is requested.
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615766/example.org--Resend with alternative content-type:
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: application/pdf
Content-Transfer-Encoding: base64
[PDF data goes here]
--RAA14128.773615768/ example.com--Receiver sends MDN confirmation of enhanced message content:
(Also indicating the PDF capability for future messages.)
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom
Recipient <Tom_Recipient@example.org> with subject " Internet FAX
Full Mode Image Transmission" has been processed in Internet FAX
Full Mode.
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615769/example.org--9. IANA Considerations 📋✨
9.1 New message headers
This spec defines two brand-new email/MIME message headers, so bestie, these are the ones IANA needs to know about:
Content-alternative
Original-Message-IDHere's the tea: there's no registry of email headers, so this counts as an update to the specifications of RFC 2822 and RFC 2045. 🌸
9.2 MDN extensions
This spec also adds extensions to the Message Disposition Notification (MDN) protocol. The sections below are the registration templates for those extensions, as required by RFC 2298 [4], section 10. 🎀
9.2.1 Notification option 'Alternative-available'
(a) Disposition-notification-option name:
Alternative-available
(b) Syntax:
(see this document, section 6.1)
(c) Character-encoding:
US-ASCII characters only are used
(d) Semantics:
(see this document, section 6.1)9.2.2 Notification option 'Alternative-not-available'
(a) Disposition-notification-option name:
Alternative-not-available
(b) Syntax:
(see this document, section 6.1)
(c) Character-encoding:
US-ASCII characters only are used
(d) Semantics
(see this document, section 6.3)9.2.3 Disposition modifier 'Alternative-preferred'
(a) Disposition-modifier name:
Alternative-preferred
(b) Semantics:
(see this document, section 6.2)9.2.4 Disposition modifier 'Original-lost'
(a) Disposition-modifier name:
Original-lost
(b) Semantics:
(see this document, section 6.4)10. Internationalization considerations 🌍💜
This spec is all about protocol exchanges between mail user agents, so it's not really about human-readable text. 🤖 Still, not every user agent will automatically handle these protocol elements, and some might try to show the text from them to the user.
The big one here is the text that comes with a disposition notification response asking for alternative information. Normally the protocol is designed so the recipient can process that response automatically, but every once in a while a receiving agent might display it to a user. 🫶
11. Security Considerations 🔐😱
Okay, security time, and honestly it's giving serious. 💀 The security considerations here split into two main areas:
- Privacy concerns with automated MDN response generation: see section 6.5 of this document, and the security considerations section of RFC 2298 [4].
- Risks of negotiation: see the security considerations section transaction. If alternative data arrives subsequently, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender.
Please read these carefully, bestie. Privacy and negotiation risks are not a vibe to skip! 🚨
12. Acknowledgements 🙏🌷
The basic structure of the negotiation described here was first documented in a draft by Mr. Toru Maeda of Canon. ✨
Helpful comments on earlier drafts came from Mr Hiroshi Tamura, Ted Hardie and Larry Masinter. Thank you, besties! 🫶💖
13. References ✨
- [1] Masinter, L. and D. Wing, "Extended Facsimile using Internet Mail", RFC 2532, March 1999. 📠
- [2] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999. 🦋
- [3] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999. 🌸
- [4] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. 💌
- [5] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999. 🏷️
- [6] Klyne, G., "A syntax for describing media feature sets", BCP 31, RFC 2533, March 1999. 📚
- [7] Klyne, G., "Indicating media features for MIME content", RFC 2938, September 2000. 🎀
- [8] 'Content-alternative' header (this memo, section 4) 💖
- [9] MDN extension for alternative data (this memo, section 6) ✨
- [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🧩
- [11] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons, G. and J. Rafferty, "File format for Internet fax", RFC 2301, March 1998. 🗂️
- [12] Toyoda K., Ohno H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. 🍓
- [13] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 🌐
- [14] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998. 🤝
- [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media types", RFC 2046, November 1996. 💜
- [16] Klyne, G. and L. McIntyre, "Content feature schema for Internet fax V2", RFC 2879, August 2000. 🫶
- [17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999. 🔥
- [18] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. 📬
- [19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. 📮
- [20] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 🎟️
- [21] Klyne, G. and D. Crocker, "Timely Delivery for Facsimile Using Internet Mail", Work in Progress. ⏰
- [22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
- [23] 'Original-Message-ID' header for mail messages (this memo, section 5) 🆔
- [24] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000. 🌈
Appendix A: Implementation issues 🧚
This appendix isn't part of the normative spec, so think of it as bestie advice. It digs into some of the stuff we considered while designing this, written for the implementers who'll be building it. 🫶
A.1 Receiver state
Okay, so the biggest thing that changes for implementers compared with regular mail user agents is that you need to keep some kind of state info at the receiver while content is being negotiated. 😭
By "receiver state", we mean the receiver has to remember two things: that it got an initial message AND that it asked for an alternative form of the data. Without that memory, if the receiver asks for another format and the response never reaches the sender, the message can be silently lost even though it was delivered to the receiving MTA. Yikes. 💀
This matters a LOT because we wanted low-memory systems to be able to join the negotiation too. Old-school T.30 fax does the whole negotiation within one connection, but in email, a negotiation can take a while, so state has to be kept for every outstanding negotiation at any time, and there's no theoretical upper limit on how many there could be. 🌊
Keeping receiver state is probably no biggie for systems with high-capacity storage to hold the message data and state info. The rest of this section talks about strategies small-system designers could use to put an upper bound on the memory reserved for this. When a receiver is really short on memory, message loss is still possible, but these mechanisms should make sure it never happens silently. 🎯
So what even is this "receiver state"? It must contain, at a minimum:
- the fact that message data was received, and alternative data has been requested,
- a unique message identifier, and
- the time at which an alternative format request was sent.
This lets the receiver re-issue a request, or report an error, if the requested alternative data doesn't show up in a reasonable time. 🔁
Receiver state may also include:
- a copy of the data originally received. This lets the receiver display the original data if an alternative never arrives. 🖼️
- details of the data format supplied, and alternatives offered. This allows better diagnostics if alternative data isn't received. 🔍
If a receiver of a message with alternative content available doesn't have enough memory to hold new negotiation state, it may fall back to non-negotiation behaviour, accept the data it received, and send an MDN saying what happened to that data (see sections 3.2.1, 3.2.2). 🤷♀️
If a receiving system runs low on memory after it has already entered a negotiation, there are a few options it might take:
- display or print the buffered data, if there is any, and complete the transaction. If alternative data shows up later, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender. ✅
- discard the buffered data, and keep waiting for alternative data. If alternative data doesn't arrive afterward, a message transfer failure should be declared. ⏳
- abort the transfer and declare a message transfer failure: a diagnostic message must be displayed to the local user, and a failure notification sent to the sender. 🚨
A.2 Receiver buffering of message data
If a receiver can buffer the received message data while it waits for an alternative, that's the way to go, because it keeps the option of displaying that data if no alternative arrives (see above). 🛟
Partial message data should not be buffered for this purpose. Showing part of the original message is NOT an allowable substitute for showing all of the received data. (Keeping some of the original message data might still be worthwhile for diagnostic purposes.) 🙅♀️
If a receiver starts buffering message data while a negotiation is pending, and then finds the entire message is too big to buffer, it may choose to fall back to "extended mode" and display the incoming data as it arrives. 📺
When a sender says alternative data is available, it also says whether that availability is permanent or transient. The idea is that if the alternative is transient, a receiver shouldn't throw away the original data it received. If needed, it should just display the original data without asking for an alternative. 💅
A.3 Sender state
When a sender says it can offer an alternative format of the message content, it takes on some responsibility for making sure that alternative is actually available if someone requests it. So the message content (both the original and any alternative) should be stored for a reasonable period, along with any matching Message-ID value(s). 📦
A request for retransmission must be accompanied by an Original-Message-ID value that the sender can use to match it up with the message data it originally sent. 🔗
A.4 Timeout of offer of alternatives
If the sender has a high-capacity message storage device (e.g., a disk drive) and normally holds onto the data for long stretches (several days or weeks), it should indicate that the alternative data is permanently available (see 6.1). That way, a recipient who sees this can discard the original data, knowing the sender will most likely be able to retransmit. 🏛️
If the sender has limited memory and is likely to hold the data for no more than a few minutes or hours, it should indicate that the alternative data is transiently available (see 6.1). And if there's any doubt about a sender's ability to keep the message content, it should indicate that availability of any alternative is transient. 🫣
A.5 Timeout of receiver capabilities
Don't assume receiver capabilities declared during a negotiation will be available forever. 🙃
Specifically, any receiver capabilities declared on a final message confirmation should be treated as definitive, even if they differ from the capabilities associated with the message that was just accepted. These may be stored for future use. 📝
Any receiver capabilities declared when requesting an alternative format should NOT be stored for future use, since the receiver might be picky about the purposes those capabilities can be used for. 🚫
A.6 Relationship to timely delivery
Some of the sender state maintenance issues get simpler if content negotiation is used alongside a timely delivery facility (e.g., [21]). If there's a known time window in which a response should arrive, the sender can be less conservative about keeping info on outstanding offers of alternative data for long periods. A sender that uses timely delivery this way should indicate that the alternative is transiently available. ⏱️
A.7 Ephemeral capabilities
Ephemeral capabilities can cause some special problems. Think about selecting a particular content variant that depends on an ephemeral setting. 🌫️
Imagine someone sending a basic fax to a colour fax machine, and saying a colour alternative is available. The colour fax throws away the content and sends an MDN saying "deleted/alternative-preferred" back to the originator. Then it runs out of coloured ink. The originating fax sends a new message, and the colour fax can't print it. 🖨️💀
Or take the email client on a phone with sound on/off as a related problem. When sound is ON, the phone may be able to accept voice messages by email. 🔊
This negotiation framework wasn't designed with ephemeral capabilities in mind, but with some care it may be adaptable to handle them. 🛠️
A.8 Situations where MDNs must not be auto-generated
Keep privacy in mind here, implementers. Systems should NOT automatically enter into a negotiation exchange in a way that could reveal the recipient's whereabouts without first getting explicit permission. For example, if receiving a message depends in any way on the user being physically present, automatic negotiation should not be performed. 🕵️♀️
It's fine for an unattended fax machine to run automated negotiation, but it's NOT okay for a PC software package to do it without the user's explicit permission, since the PC may only be switched on when the user is present. So default settings here should take the type of system into account. 🖥️✨
Appendix B: Candidates for further enhancements ✨
okay so this appendix is basically the "we thought about it but absolutely not yet" list 🙈 these are features of content negotiation that got considered and then left out of the current spec. most of the time it was for two reasons: (a) they could add complexities nobody saw coming, and (b) nobody could point to a compelling requirement for them 💅
- Cache control indicator for recipient capabilities. this would tell the sender (or some other message system piece) that the capability info in the current message is only for this one transaction, and should NOT be remembered for future transactions. like, a recipient might not want colour capability used for routine messages 🎨 (see also section A.5 above.)
- Use of q-values [6] in media feature expressions for indicating preference among alternatives available and/or receiver preferences. basically, "I'd prefer this one, but that one works too" energy 💜
- Partial re-sends. there are proposals in progress for "partial MDN" responses that can report disposition status per message part 🧩 that opens the door to partial re-sends when alternative formats are only requested for some of the body parts. but the current spec assumes that either none or all of the message gets re-sent when content negotiation is used 🫠
- Allow negotiation with parties other than the originally addressed recipients of a message. ooh, bold, but not yet 👀
- Negotiation response might indicate a different receiver endpoint with different capabilities. so the reply could point you to a whole other endpoint 🦋
Authors' Addresses 🖊️
Graham Klyne (editor)
Clearswift Corporation,
1310 Waterside,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Ryuji Iwazaki
TOSHIBA TEC CORPORATION
2-4-1, Shibakoen, Minato-ku,
Tokyo, 105-8524 Japan
Phone: +81 3 3438 6866
Fax: +81 3 5402 6355
EMail: iwa@rdl.toshibatec.co.jp
Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA 94086 USA
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@brandenburg.comFull Copyright Statement 🎀
Copyright (C) The Internet Society (2002). 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: rfc3297 2002-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms