RFC 3459

Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter

📅 published January 2003, from ietf

RFC 3459: Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter 💖

Part 1 of 5 🎀

Okay bestie, so this one is RFC 3459 and it was written by E. Burger at SnowShore Networks in January 2003 ✨ It's a Standards Track doc, which means it's a real protocol spec and not just vibes. It updates RFC 3204, and the title block doesn't list anything it obsoletes 💅

Status of this Memo 🦋

This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. Check the current edition of the "Internet Official Protocol Standards" (STD 1) for where this protocol stands in standardization. Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 💜

Okay so this doc describes a way to mark which body parts a sender thinks are critical in a multi-part Internet mail message 📬 The mechanism is a parameter to Content-Disposition, as defined in RFC 3204.

Why does that matter? If you know which parts the sender considers critical, a content gateway can handle multi-part messages smartly when it's serving systems with less capability ✨ Critical content helps the gateway decide what to forward, how hard it should try to deliver a body part, and which body parts are safe to quietly delete when a less capable system gets the message. It can also help the gateway choose the notification strategy for the receiving system 🔥 And if the sender expects the destination to process a body part, critical content lets the sender mark the parts the receiver must process 🫶

Table of Contents 🎀

1.  Conventions used in this document..............................3
2.  Introduction...................................................3
3.  Handling Parameter.............................................4
    3.1. REQUIRED..................................................4
    3.2. OPTIONAL..................................................5
    3.3. Default Values............................................5
    3.4. Other Values..............................................5
4.  Collected Syntax...............................................6
5.  Notification...................................................6
    5.1. DSN vs. MDN Generation....................................7
    5.2. Summary...................................................7
6.  Signed Content.................................................8
7.  Encrypted Content..............................................9
8.  Status Code...................................................10
9.  Requirements for Critical Content.............................11
    9.1. Needs....................................................11
    9.2. Current Approaches.......................................12
10. The Content Gateway...........................................13
    10.1. Integrated Content Gateway..............................14
    10.2. Disaggregated Delivery Network..........................14
11. Backward Compatibility Considerations.........................15
12. MIME Interactions.............................................15
    12.1. multipart/alternative...................................15
    12.2. multipart/related.......................................15
    12.3. message/rfc822..........................................15
    12.4. multipart/signed........................................16
    12.5. multipart/encrypted.....................................16
13. Implementation Examples.......................................16
    13.1. Content Gateways........................................16
    13.2. Disaggregated Content Gateway...........................17
14. OPES Considerations...........................................18
    14.1. Consideration (2.1): One-Party Consent..................18
    14.2. Consideration (2.2): IP-layer Communications............18
    14.3. Consideration (3.1): Notification - Sender..............18
    14.4. Consideration (3.2): Notification - Receiver............18
    14.5. Consideration (3.3): Non-Blocking.......................18
    14.6. Consideration (4.1): URI Resolution.....................18
    14.7. Consideration (4.2): Reference Validity.................19
    14.8. Consideration (4.3): Architecture Extensions............19
    14.9. Consideration (5.1): Privacy............................19
15. Security Considerations.......................................19
16. IANA Considerations...........................................19
17. References....................................................20
    17.1 Normative References.....................................20
    17.2 Informative Reference....................................21
18. Acknowledgments...............................................22
19. Intellectual Property Notice..................................23
20. Author's Address..............................................23
21. Full Copyright Statement......................................24

1. Conventions used in this document ✨

In this doc, the sender of a message is called "he" (he/him/his) and the recipient is called "she" (she/her/hers). It's just for convenience, so it makes no assumption about anyone's gender 💅

The key words "MUST", "MUST NOT", "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].

The word "REQUIRED" in this document does not follow the definition found in RFC 2119. That's because this document defines a parameter named "REQUIRED". There's no requirement in this document that is "REQUIRED", so there's no confusion 🙈

In this document, the "sending agent" is the originator of the message. It could be a mail user agent (MUA) for an Internet message, or a SIP User Agent Client (UAC) for a SIP [3] message. The "endpoint" is the receiving device, which has less capability than the sending agent 🦋

NOTE: Notes, such as this one, provide additional nonessential information that the reader may skip without missing anything essential. The main purpose of these non-essential notes is to share the rationale behind this document, or to place it in its historical or evolutionary context. Readers whose only goal is to build a conformant implementation may skip this information. It could still help anyone who wants to understand why certain design choices were made 🧚

2. Introduction 🌸

The specification of Critical Content is small and compact. For the benefit of developers, the specification comes first and the rationale comes after 💖

One concept that an implementer must understand is the content gateway, and Section 10 describes it. In brief, a content gateway knows what the receiving system is capable of. It passes along messages the receiving system can process, render, or store. It can modify a message, for example by deleting body parts that can't be rendered or stored, before delivering it to the receiving system. Finally, the content gateway can reject a message that the receiving system can't handle 🔥

Critical Content processing isn't an OPES service, but the protocol machinery in this document meets all of the OPES IAB requirements stated in RFC 3238 [4]. Section 14 covers this in detail. The big difference is this: content gateways used to modify messages silently, or follow abstract rules for changing them (look at the content transformation rules in VPIM, for example). The Critical Content mechanism lets the sending user explicitly say how content gateways should handle the content 👑

NOTE: This document updates RFC 3204 [5] to separate the Handling parameter from the ISUP/QSIG transport mechanism. The protocol described here works exactly the same, functionally, as RFC 3204 does with respect to SIP. Future versions of RFC 3204 should reference this document for the Handling parameter, since it's orthogonal to the tunneling of signaling 🎀

3. Handling Parameter 💅

The Handling parameter is a Content-Disposition [6] parameter. The sending agent inserts it to tell the content gateway whether to treat the marked body part as critical ✨

A REQUIRED body part is one the sender needs the receiving system to deliver before he can consider the message delivered 💖

An OPTIONAL body part is one the sender doesn't care about, meaning he doesn't mind whether the receiving system delivers it. A content gateway can silently delete such a body part if the receiving system can't deliver it 🦋

The terms "entity" and "body part" have the meanings defined in [6] 🌈

3.1. REQUIRED 🔥

Handling=REQUIRED signifies that this body part is critical to the sender 💜

If the content gateway can't pass a body part marked REQUIRED, then the entire message has failed. In this case, the content gateway MUST take the appropriate failure action 😭

NOTE: We say "appropriate action" because the sender may have suppressed all notifications. In that case, the appropriate action is to silently discard the message. Also, as a general MIME parameter, the MIME body part may not be in an Internet Mail message 🙈 Moreover, in the SIP case, the appropriate notification is a status return code, not a delivery notification 🧚

3.2. OPTIONAL 🌸

Handling=OPTIONAL signifies that the sender doesn't care about notification reports for this body part 🍓

If the content gateway can't pass a body part marked OPTIONAL, the receiving system may silently delete the body part. The receiving system MUST NOT return a delivery failure, unless parts marked REQUIRED have also failed 💀

3.3. Default Values 🎀

The default value for Handling for a given body part is REQUIRED. This lets the existing notification mechanisms work for sending agents that don't know about the content notification entity. Every body part is critical, since they all have the default marking of REQUIRED 👑

NOTE: In the case of Internet mail, critical content processing is a function of the content gateway, not the mail transfer agent (MTA) or user agent (UA). Often the entity doing content gateway processing is the receiving UA. In that case, though, the UA is acting as a content gateway. So the default behavior for any Content-Disposition [6]-compliant user agent, which is to ignore unrecognized disposition parameters, keeps this mechanism compatible with the Internet architecture ✨ NOTE: This parameter is fully backwards compatible and works as expected for Internet mail and SIP 💖 NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from the Internet. However, these systems are really acting as an Internet Voice Mail system. In that case, you'd expect the implementation to give Internet Voice Mail messages Internet Voice Mail semantics 🦋

3.4. Other Values ✨

okay so the content gateway MUST treat unrecognized values as REQUIRED 🔒 why? so future uses of the Content-Criticality entity still work with older gateways 🫶

NOTE: a possible new value is IMPORTANT 🌸 an IMPORTANT body part is something the sender really wants the receiver to get, but they'd rather NOT have the whole message rejected if that part fails. they DO want to be told when it fails. however, no implementations do IMPORTANT yet, so it's not important to this version of this document 💅

4. Collected Syntax 🎀

the format of the collected syntax follows the ABNF of [7]. quick heads up: per RFC 2183 [6], the HANDLING Content-Disposition parameter is not case sensitive 🙈 the notification-type is also not case sensitive, so no stress about capitals ✨

      "handling" "=" notification-type CRLF

      notification-type = "REQUIRED" / "OPTIONAL" /
                          other-handling / generic-param

      other-handling    =  token

5. Notification 🔔

the most obvious use for critical content is generating a (non-)delivery notification in the Internet mail environment 📬 if the field is OPTIONAL, the content gateway MUST NOT generate a notification. if the field is REQUIRED, the content gateway MAY generate one, based on the normal notification request mechanisms. those normal mechanisms include specifying the NOTIFY parameter to the SMTP RCPT command [8] and the Disposition-Notification-To header [9] 💖

in SIP, every request gets a response, and those responses tell you what happened in the status code 🧚 for the RFC 3204 case, a content gateway generates a 415 (Unsupported Media Type) response if the field is REQUIRED.

if the sending system asks for a notification and a REQUIRED part fails, the content gateway MUST generate a notification for the whole message 😭 and the other way around: if the gateway can't pass on a body part marked OPTIONAL, the gateway MUST NOT generate a notification. no notification for you, bestie 🙅‍♀️

NOTE: this means the content gateway has to look at the entire message to figure out whether it needs to generate a notification. BUT, the content gateway doesn't need to look at the message if it already knows it can store and forward every media type. said differently, Internet e-mail MTAs or gateways can, by default, handle any arbitrary MIME-encapsulated type. some voice mail systems, on the other hand, cannot store binary attachments at all, like application/ms-word. the voice mail content gateway, in this example, would be scanning for non-renderable body parts in any event 🥹

5.1. DSN vs. MDN Generation 💌

the content gateway generates a delivery status notification (DSN) [9] if it operates as a gateway. it generates a Message Disposition Notification (MDN) [10] if it operates as a mail user agent. Section 6 describes the operating modes of a content gateway 👑 in short: if there's an MTA that "delivers" the message to the content gateway for processing, that MTA takes responsibility for DSN processing. in that case, the only option left for the content gateway is to generate MDNs. if the content gateway operates as an MTA, then it generates DSNs. DSN generation is the preferred option 🌈

if the content gateway is part of a SIP endpoint, it generates the appropriate success or error response code 💅

5.2. Summary 📋

the following table summarizes the actions expected of a conforming content gateway 🍓

NOTE: this section is normative. it suggests what a content gateway should put into the DSN or MDN.
NOTE: in the case of SIP, this section is informative. see RFC 3204 for the normative set of actions on failure.
                  Table 1 - Expected Actions

                        +--------------------------------------+
                        |    Sending UA Has Marked Body Part   |
                        |---------------------+----------------|
                        |      REQUIRED       |    OPTIONAL    |
   +--------------------+---------------------+----------------+
   | Body Part is       |                     |                |
   | Deliverable        | Appropriate Action  |     ignore     |
   +--------------------+---------------------+----------------+
   | Body Part is       |                     |                |
   | Undeliverable      | Fail Entire Message |     ignore     |
   +--------------------+--------------------------------------+

the "Appropriate Action" is whatever action the content gateway would take given the context it's running in 🎯 for example, if a sender requests a return receipt and the receiver reads a HANDLING body part, the receiving UA must generate the appropriate MDN (following the rules for MDN). likewise, if the content gateway can't deliver the body part and that body part is critical, the content gateway generates the appropriate DSN or MDN 🫶

"Optional" means the content gateway ignores the disposition of the body part. the content gateway treats the message as if that body part wasn't there at all 🙈

6. Signed Content ✍️

RFC 1847 [11] explains how to apply digital signatures to a MIME body part 🦋 the short version: a multipart/signed body part wraps the body part you care about (the "content object") in one MIME body part, and the control info needed to verify it (the "protocol" in RFC 1847's lingo) in a second MIME body part. here's an example taken from RFC 1847 🧚

      Content-Type: multipart/signed; protocol="TYPE/STYPE";
              micalg="MICALG"; boundary="Signed Boundary"

      --Signed Boundary
      Content-Type: text/plain; charset="us-ascii"

      This is some text to be signed although it could be
      any type of data, labeled accordingly, of course.

      --Signed Boundary
      Content-Type: TYPE/STYPE

      CONTROL INFORMATION for protocol "TYPE/STYPE" would be here

      --Signed Boundary--

Figure 1 - Signed Content MIME Type

there are three spots where you can put the criticality indicator for a multipart/signed body part 👑 you can mark the multipart/signed object, the content object, the control object, or any combo of the three.

the disposition of REQUIRED body parts follows the guidelines in RFC 2480 [12] 💜

a critical content indicator on a multipart/signed body part means the sending party needs true end-to-end signature verification 🔐 so the gateway has to pass the enclosure through intact. if the system or network of lesser capability can't do signature verification and the signed enclosure is REQUIRED, the gateway MUST reject the message 🚫

a critical content indicator on a signature means one of two things: either the receiving endpoint must be able to do signature verification, or the gateway needs to verify the signature before forwarding the message ✅ if the content doesn't pass verification, the gateway MUST reject the message 💀

a critical content indicator on the enclosed material says whether that material is critical to the message as a whole 🎀 if the signature is marked OPTIONAL and the enclosed material is marked REQUIRED, the gateway MAY strip out the signature info if the system or network of lesser capability can't do signature verification. however, if it's possible, we STRONGLY RECOMMEND that the gateway does signature verification and indicates tampering to the recipient 🚨

7. Encrypted Content 🔐

RFC 1847 [11] also explains how to encrypt a MIME body part 🌸 in brief, a multipart/encrypted body part holds the control info (the "protocol" in RFC 1847's lingo) for the encrypted object, plus a second part containing the encrypted data (application/octet-stream). here's an example taken from RFC 1847 🧚

      Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
              boundary="Encrypted Boundary"

      --Encrypted Boundary
      Content-Type: TYPE/STYPE

      CONTROL INFORMATION for protocol "TYPE/STYPE" would be here

      --Encrypted Boundary
      Content-Type: application/octet-stream

          Content-Type: text/plain; charset="us-ascii"
          All of this indented text, including the indented headers,
          would be unreadable since it would have been encrypted by
          the protocol "TYPE/STYPE".  Also, this encrypted data could
          be any type of data, labeled accordingly, of course.

      --Encrypted Boundary--

it makes sense to put a criticality indicator on the encrypted enclosure (multipart/encrypted) body part 🔑 if the endpoint can decrypt the message, the gateway passes the body part along in its entirety.

if you mark the control object REQUIRED, then the sending UA requires end-to-end encryption 🔒 if the endpoint can't decrypt the message, the gateway MUST reject the message.

if the control object is OPTIONAL, the endpoint can't decrypt the message, and the gateway CAN decrypt it, then the gateway MAY decrypt the message and forward the cleartext 🫣 the sending user has explicitly given the gateway permission to decrypt by marking the control object OPTIONAL. recall that the default indication for MIME body parts is REQUIRED. so if the user takes no explicit action, the content gateway will assume the user wanted end-to-end encryption 🥰

marking the encrypted content without marking the encrypted enclosure is problematic 🙃 this is because the gateway has to decrypt the encrypted data to get at the header. but it's unlikely the gateway has the capability (e.g., keys) to decrypt the encrypted data. if a sending UA wants to mark encrypted data as not REQUIRED, the sending UA MUST mark the encrypted content as not REQUIRED. obviously, if the sending UA marks the encrypted content as REQUIRED, the gateway applies the REQUIRED processing rules. and if the sending UA doesn't mark the encrypted content as REQUIRED, the gateway, unless it can decrypt the data, treats the encrypted content as REQUIRED. this happens because gateways always treat unmarked content as REQUIRED (see Section 3.3) 🧠

8. Status Code 🚦

the critical content indication, all by itself, doesn't guarantee any notification 🙅‍♀️ notification follows the rules described in [3], [8], and [9].

NOTE: the content of actual DSNs or MDNs is beyond the scope of this document. this document only specifies how to mark a critical body part. that said, we do envision sensible DSN and MDN contents 💖 for example, DSNs should include the appropriate failure code as enumerated in [13]. likewise, MDNs should include the failure code in the MDN "Failure:" field.

if the receiving system is going to generate a notification because it can't render or store the media type, the notification should use the status code 5.6.1, "Media not supported", from [10] 🎀

for the SIP case, every request gets notification through the status response message 📞 per RFC 3204, a content gateway generates a 415 (Unsupported Media Type) response 🍒

9. Requirements for Critical Content 📝

this section is informative. 🫶

9.1. Needs ✨

Okay bestie, so why do we even need a critical content identification mechanism? 💅 It's because Internet mail systems keep having to talk to messaging systems that don't do everything Internet mail does. 😭 Those legacy systems can only render or store some parts of a message. This doc uses a super relatable example: an Internet mail system swapping messages with a legacy voice messaging system. 🎀

Electronic mail has always been text-centric, lowkey. MIME [14] came in clutch and let user agents send and receive multi-part, multimedia messages 🌈 Popular multimedia types include binary word processing documents, binary business presentation graphics, voice, and video.

Voice mail has always been audio-centric 🎧 Lots of voice-messaging systems can only render voice. Extensions like fax let the voice mail system send and receive fax images and create multi-part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax tech. Although that's theoretically possible, none can render video today. 🙈

Here's the important bit: the rendering power of a voice-messaging platform is often WAY less than a desktop e-mail client. In email, the sender expects the recipient to receive all components of a multimedia message, even if the recipient can't render every body part. Usually the recipient can either find the right tool or tell the sender they can't read that particular attachment. 💖

This is a big deal 🚨 By definition, a MIME-enabled user agent, conforming to [15], will present or make available all of the body parts to the recipient. But a voice mail system may not be capable of storing non-voice objects. Plus, it may not be able to tell the recipient that there were undeliverable message parts. 😬

When the receiving system can't render a body part, that's usually a permanent failure. Retransmitting the message won't make a future delivery more likely to work. Compare that with normal data delivery, where traditional message failures, like a garbled message or a disabled link, actually benefit from retransmission. 🔁

This is fundamentally different from normal Internet mail. In Internet mail, either the system delivered the message or it didn't. There's no concept of a system partially delivering a message. 🙅

Also, there are lots of situations where the sender wouldn't mind if the system didn't deliver non-critical parts of a message. For example, the sender's user agent may add body parts without the sender even knowing 👀 If the receiving system rejected the whole message because it couldn't render some hidden body part, the sender would be understandably confused and upset. 😤

So there's a real NEED for a way to tell an MTA or UA that the sender considers parts of a message to be critical. From the sender's point of view, the message isn't delivered if the system didn't deliver the critical parts. 💜

9.2. Current Approaches 🧐

One method for marking critical content is to define a profile. The profile sets rules for silently deleting mail body parts based on knowledge of what the UA can handle. Using our voice example, a voice profile can easily declare that MTAs or UAs can silently delete TNEF data and still consider the message successfully delivered. This is, in fact, the approach taken by VPIMv2 [16]. 🎯

Since one part of the issue is deciding when to notify the sender that the system can't deliver part of a message, you could use a partial non-delivery notification mechanism to flag a problem with a given body part. However, this requires the user to request a delivery notification. On top of that, the sender may not be aware of parts added by the sending user agent, so a failure notice would mystify them. 🤷

A straightforward alternative for marking a body part critical is to use a Critical-Content MIME entity. This has the benefit that criticality is meta information for the body part. However, IMAP servers in particular would need to either put Critical-Content into the BODYSTRUCTURE method or create a new method to retrieve arbitrary MIME entities. Given the experience of trying to get Content-Location accepted by IMAP vendors, we chose not to go that route. 🙃

What we need is a way for the sender to indicate what body parts they consider to be critical. The mechanism must not burden the sender with failure notifications for non-critical body parts. The mechanism must conform to the general notification status request mechanism for positive or negative notification. When requested, the mechanism must indicate to the sender when a receiving system cannot deliver a critical body part. 🎀

10. The Content Gateway

This section is informative. 📖

In this section, we use the definition found in RFC 2156 [17] for the term "gateway."

We do not strictly use the definition found in RFC 2821 [18] for the term "gateway." In particular, RFC 2821 is discussing a gateway that should not examine the message itself. An RFC 2821 gateway is a transport gateway, one that mostly deals with transformations of the SMTP information. 🧠

A content gateway is a gateway that connects a first network to a second network. The second network often has lesser capability than the first network. The canonical topology follows. "[MTA]", with square brackets, signifies an optional component. 🗺️

                             +---------+
   +---------+     +-----+   |         |     +-------+   +-----------+
   | Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
   |   UA    |     +-----+   | Gateway |     +-------+   |    UA     |
   +---------+               |         |                 +-----------+
                             +---------+
          First Network                         Second Network

                 Figure 2 - Content Gateway Topology

The content gateway can be the last hop before the receiving MTA. The content gateway can be between networks, and thus not the last hop before the receiving MTA. The content gateway can be the first MTA the sending UA contacts. Finally, the content gateway can be an integrated component of the receiving MTA. 💁‍♀️

For the SIP case, consider each MTA as a SIP Proxy, the Sending UA as a SIP User Agent Client, and the Receiving UA as a SIP User Agent Server. 📞

10.1. Integrated Content Gateway

In this situation, the receiving user agent is integrated with the content gateway. The integrated content gateway knows the capabilities of the user agent. The topology is as follows. 🧩

                             +---------------------+
   +---------+     +-----+   |         :           |
   | Sending |=...=|[MTA]|===| Content : Receiving |
   |   UA    |     +-----+   | Gateway :    UA     |
   +---------+               |         :           |
                             +---------------------+
          First Network           Second Network

                  Figure 3 - Integrated Content Gateway

The processing of ISUP and QSIG objects, as described in [5], is an example of an integrated gateway. 🌸

10.2. Disaggregated Delivery Network

This is a degenerate case, although one that does occur 🙈 It's where the content gateway sits behind the final MTA. This happens when one implements the content gateway as a post-processing step to a normal delivery. For example, one could configure a mail handling system to deliver the message to a queue or directory, where the content gateway process picks up the message. If there were any directives for DSN processing, the delivering MTA would execute them. For example, the message could have requested notification on successful delivery. The delivering MTA, having delivered the message to the queue, would consider the message delivered and thus notify the sender of such. However, the content gateway process could then discover that the receiving UA cannot render the message. In this case, the content gateway generates a NDN, as it is the only option available. 😮‍💨

                           Delivered
                               |      +---------+
   +---------+     +-----+     v      |         |     +-----------+
   | Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
   |   UA    |     +-----+            | Gateway |     |    UA     |
   +---------+                        |         |     +-----------+
                                      +---------+
          First Network              Second Network

              Figure 4 - Disaggregated Delivery Network

11. Backward Compatibility Considerations

DSN requires ESMTP. If MTAs in the path from the sending UA to the receiving UA do not support ESMTP, then that MTA will reject the DSN request. In addition, the message will default to notification on delay or failure. While not ideal, the sender will know that DSN is not available, and that critical content that fails will get notification. 🫶

12. MIME Interactions

12.1. multipart/alternative

As is true for all Content-Disposition parameters, handling is only in effect for the selected alternative. If the selected alternative has the critical content indicator, then the entire alternative takes on the criticality indicated. That is, if the alternative selected has HANDLING=OPTIONAL, then the content gateway MUST NOT generate any delivery notifications. 🚫

NOTE: This statement explicitly shows that HANDLING overrides the DSN and MDN request mechanisms.

It is unlikely for a selected alternative to fail, as the content gateway presumably picks the alternative specifically because it can render it. 🤞

If the selected alternative is a message/rfc822 that encloses a multipart MIME message, or the selected alternative is itself a multipart MIME type, the individual top-level body parts follow the HANDLING mechanism described in this document. 🧁

NOTE: This means that a forwarded message's criticality will not affect the forwarding agent's intentions.

Criticality fits in rather well with the multipart/related construction. For example, consider a multipart/related message consisting of a Macintosh data fork and a Macintosh resource fork. For a Microsoft Word document, the data fork is likely to be critical. The receiving system can safely ignore the resource fork. 💾

12.3. message/rfc822

Criticality only affects the outermost level of the message or, in the case of multipart/alternative, the outermost level of the selected alternative. Specifically, the receiving system ignores criticality indicators in embedded body parts. This avoids the situation of a forwarded message triggering or suppressing undesired reporting. This simply implements the procedures described in [6]. 📨

12.4. multipart/signed

See Section 6.

12.5. multipart/encrypted

See Section 7.

13. Implementation Examples 🎀

This section is an informative part of the definition of Criticality. We hope it helps implementers understand the mechanics of the Handling mechanism. 🛠️

We will examine two cases. They are how a content gateway processes a message and how a disaggregated content gateway processes a message. 👀

13.1. Content Gateways ✨

okay so content gateways are literally the bouncers of the message world 💅 they peek at what's inside a message coming from one network before they forward it to a second network. for this example we're assuming network two is kinda basic compared to network one 🙈 so there are some body types the gateway just can't pass along. no cap, that's the whole drama.

picture a gateway between the Internet and a text-only short message service 📱 a message comes in with a text part AND a tnef part. the sender marks the text part REQUIRED (it's the important one!!). the gateway knows what the short message service can handle, so it quietly deletes the non-critical tnef part and passes the critical stuff through. any notifications after that, like failure notices or delivery notices, just follow the normal rules for notification 💌

BUT here's the tea 🫖 when the gateway silently deletes non-critical content, it can mess up proprietary message correlation schemes. like, you could totally imagine a sending UA slipping in a body part just for tracking purposes, and the gateway deleting it would break that whole setup 😭 so if a sending UA knows how to mark critical content, it should use Internet standard mechanisms for tracking messages instead, like Message-ID [19] 🎀

now what if NO body parts have critical content indicators? 💀 then the entire message counts as critical. so when the gateway spots that tnef part, it rejects the whole message and sends back a DSN with status code 5.6.1, "Media not supported". rude but fair 🙄

and one more scenario 🧚 a three-part message: a text annotation (part 1) on a voice message (part 2), plus a vCard [20] (part 3). the sender marks parts 1 and 2 REQUIRED. now say the receiving MTA (the gateway) is a voice mail only system that can't even store text 😩 the gateway, acting as the receiving MTA, rejects the message and generates a DSN with status code 5.6.1, "Media not supported". absolutely no notes 💅

13.2. Disaggregated Content Gateway 🦋

okay this one is a whole vibe 🌈 we're looking at a three-part message. part one is a text annotation of part two, which is an audio message. part three is the sender's vCard. the sender marks parts one and two REQUIRED, and ALSO asks for a read receipt because she's giving main character energy 👑

quick note so we're on the same page: for this example, the telephone user interface (TUI) can't do text-to-speech conversion 🎧 a TUI is a mail user agent (UA) that uses DTMF touch-tone digits for input and audio for output (display). fancy, right? 📞

so the TUI can't render part one (the text) and it also can't render part three (the vCard). since the sender did NOT mark part three REQUIRED, the system just ignores the TUI's failure on that one 🫶 but part one WAS marked REQUIRED, and the TUI can't render text, so the whole message fails 😭

what happens next is implementation dependent, bestie 🔧 if the TUI is part of a unified messaging system, a reasonable action is to hold the message for the user. they can grab it later from a terminal that can render all the critical body parts ✨ and it would be reasonable for the TUI to notify the user about the undeliverable body part too.

if the TUI is part of a voice messaging system, OR the user doesn't subscribe to a text-to-speech service, a reasonable action is for the TUI to return a MDN with the disposition "failed" and the failure modifier "5.6.1 (Media not supported)" 💌 that's the whole sad story.

14. OPES Considerations 🌸

okay so Critical Content processing is NOT a web service 🙅‍♀️ but some folks in the Internet community might draw parallels between web services that modify content and an e-mail, SIP, or other MIME-transport service that modifies content. totally understandable, but not the same thing!!

this section checks the Critical Content protocol machinery against the requirements in RFC 3238 [4] 📋 and the summary is that the protocol in this document meets all of the RFC 3238 requirements. ✅ we're passing the test, obsessed 😤

this is the heart of Critical Content 💓 it lets the sending party give consent for the message to be modified. gateways that follow this document make sure they ONLY modify messages the sending party has given consent to modify. consent culture, but make it networking 🫶

14.2. Consideration (2.2): IP-layer Communications 🌐

the content gateway is an addressable IP-entity, so it's out there with its own address 📍 and all the relevant protocols (SMTP, SIP, HTTP, etc.) explicitly make the presence of the gateway known to the endpoints. no sneaking around here, periodt 💅

14.3. Consideration (3.1): Notification - Sender 📬

ngl this is literally the point of this whole document 🔥 the sender explicitly gets notification if the gateway would remove a Critical Content body part. so she always knows what's getting dropped. iconic.

14.4. Consideration (3.2): Notification - Receiver 👀

the nature of the receiving system means end users need to understand that the messages have been changed. so yeah, the receiver should know the message got edited 🙈

14.5. Consideration (3.3): Non-Blocking 🚫

by definition, the endpoint can't receive non-modified content in this case, so this requirement just doesn't apply. not every rule is for everyone, bestie 🤷‍♀️

14.6. Consideration (4.1): URI Resolution 🔗

clearly you're sending mail (SMTP), a message (SIP), or fetching a document (HTTP) 📨 the machinery in this document does NOT alter the content itself or the access mechanism. so it's compliant. easy win 🌈

14.7. Consideration (4.2): Reference Validity 🧷

since the protocol here doesn't alter the content itself, inter- and intra-document references aren't altered either ✨ BUT intra-document references to removed body parts will fail, ngl that's a bit of a plot twist 😬 the good news is the sender explicitly marked those body parts as disposable, so she's aware they might not arrive at the receiver. she knew what she was doing 💅

14.8. Consideration (4.3): Architecture Extensions 🏗️

since the protocol in this document meets Considerations 4.1 and 4.2, this requirement doesn't apply. checked off the list, bestie ✔️

14.9. Consideration (5.1): Privacy 🔐

the privacy policy of this protocol is explicit 💜 in particular, the protocol honors end-to-end security. your secrets stay secret, no cap 🤐

15. Security Considerations 🛡️

okay this section is SERIOUS, so pay attention 🚨 sending UAs can use signatures over critical content indicators to make sure the indicator itself hasn't been tampered with. smart, right?

the gateway MUST honor signature processing 😤 specifically, if the sending UA marks the signature components REQUIRED, and the endpoint can't do MIME signature processing, the gateway MUST establish an appropriate signature mechanism between the gateway and the endpoint. and here's the scary part 😱 in this case the gateway has to be secure, because it can become a target for tampering with the signed components of the message. big yikes energy.

receiving systems and users should not place any authentication value on the Handling parameter 🙅‍♀️ it's not a trust badge, friend.

one more thing 🧐 by design, and at the sending user's request, a content gateway will silently delete unimportant body parts. critical content gives the sender the power to decide the acceptable level of integrity for the delivered message 💪 so the message the content gateway actually passes on is, in fact, a faithful representation of the sender's intentions. she's in control, periodt 👑

16. IANA Considerations 📋

RFC 3204 already registered the Handling parameter 🎀 it's collected here just for reference, and as a placeholder for future expansion, and as the normative reference for other documents that need to point at the Handling parameter. basically a bookmark with extra steps 🔖

per section 9 of [6], here's the IANA registration for Handling 💌

To: IANA@IANA.ORG Subject: Registration of new Content-Disposition
parameter

Content-Disposition parameter name: HANDLING

Allowable values for this parameter: REQUIRED OPTIONAL

Description: Marks the body part as required for delivery (REQUIRED)
or can be silently discarded (OPTIONAL).  See RFC <this document> and
RFC 3204.

per RFC 2183, the Content-Disposition parameter name is NOT case sensitive 🌸 and per RFC 3459, the values of the parameter are also NOT case sensitive. so HANDLING, handling, HaNdLiNg, all valid, all vibes 🦋

17. References 📚

17.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] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, P., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [4] IAB, Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
  • [5] Zimmerer, E., Peterson, E., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
  • [6] Troost, R., Dorner, S. and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
  • [7] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [8] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
  • [9] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
  • [10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
  • [11] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
  • [12] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
  • [13] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
  • [14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [16] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998.
  • [17] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
  • [18] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
  • [19] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.

17.2 Informative Reference 🩷

  • [20] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.

18. Acknowledgments 🫶

Okay bestie, the people who helped make this happen deserve a shoutout. 💖

Emily Candell of Comverse Network Systems was instrumental in helping work out the base issues in the -00 document in Adelaide. She was a huge help. 🌸

Ned Freed pointed out that this mechanism was about criticality, not notification. 🤯 That insight made the concept and descriptions infinitely more straightforward. If it's still confusing, it's my fault! 🙈

Ned Freed also was instrumental in crafting the sections on multipart/signed and multipart/encrypted. As AD, he provided invaluable commentary to help progress this document. He's literally iconic. 👑

Keith Moore for helped tighten-up the explanations, and he approved of the use of Content-Disposition. ✨

Dropping the IMPORTANT critical content type took away one of the reasons for partial non-delivery notification. That makes Jutta Degener very happy! 🎀

Harald Alvestrand and Chris Newman suggested some implementation examples. 🧚

Greg White asked THE key question that let us realize that critical content processing was a gateway function, and not a MTA or UA function. That was a whole plot twist. 😭🔥

Jon Peterson cleared up how handling actually does work in the SIP environment. 💜

An enormous thank you to Michelle S. Cotton at IANA for helping craft the original IANA Considerations section in 2000, and for catching the functional overlap with RFC 3204 in January 2002. She's a legend. 🌈

Any errors, omissions, or silliness are my fault. 💅

19. Intellectual Property Rights Notice 🦋

Okay so, the IETF doesn't take a side on whether any intellectual property or other rights that someone might claim over the tech in this document are valid, how far they reach, or whether a license for them is even available. It also doesn't say it has tried to find any such rights. 🫣 If you want to know how the IETF handles rights for standards-track and standards-related documents, check out BCP-11. Copies of any claimed rights that were made available for publication, any promises of licenses, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights can all be obtained from the IETF Secretariat. 📬

The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practice this standard. Send that info to the IETF Executive Director. 💌

20. Author's Address 🖊️

Here's where to find the author, Eric Burger:

Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA  01824-4120
USA

Phone: +1 978 367 8400
Fax:   +1 603 457 5944
EMail: e.burger@ieee.org

Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸

Okay, the copyright rules are pretty chill. You can copy this document and share it with others, and you can make derivative works that comment on or explain it, or help people implement it. You can publish and distribute those in whole or in part with no restrictions at all, as long as the copyright notice and this paragraph are on every copy and derivative work. 🦋

But you can't change this document itself. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The one exception is when you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process. Translating it into languages other than English is also allowed. 🌍

The permissions above are perpetual, and the Internet Society or its successors or assigns won't ever revoke them. ♾️✨

This document and the information in it are 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. 💀 Legally, they're not promising anything, so read it with that energy.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 💜

📦 where this page comes from