Network Working Group E. Burger
Request for Comments: 3459 SnowShore Networks
Updates: 3204 January 2003
Category: Standards Track
Network Working Group E. Burger
Request for Comments: 3459 SnowShore Networks
Updates: 3204 January 2003
Category: Standards Track
Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
关键内容多用途Internet邮件扩展（MIME）参数
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.
本文档描述了如何使用一种机制来识别发件人认为在多部分Internet邮件消息中至关重要的身体部位。所描述的机制是内容配置的参数，如RFC 3204所描述的。
By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that 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
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
19. Intellectual Property Notice..................................23
20. Author's Address..............................................23
21. Full Copyright Statement......................................24
This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.
本文件泛指男性信息的发送者（他/他/他的）和女性信息的接收者（她/她/她的）。此约定纯粹是为了方便起见，不对消息发送者或接收者的性别进行假设。
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].
本文件中的关键词“必须”、“不得”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[2]中的说明进行解释。
The word "REQUIRED" in this document does not follow the definition found in RFC 2119. This is because this document defines a parameter named "REQUIRED". There is no requirement in this document that is "REQUIRED", so there is no confusion.
本文件中的“必需”一词不符合RFC 2119中的定义。这是因为该文档定义了一个名为“REQUIRED”的参数。本文件中没有“必需”的要求，因此不存在混淆。
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, of lesser capability than the sending agent.
在本文档中，“发送代理”是消息的发起人。它可以是用于Internet消息的邮件用户代理（MUA），也可以是用于SIP[3]消息的SIP用户代理客户端（UAC）。“端点”是接收设备，其性能低于发送代理。
NOTE: Notes, such as this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices.
注：注释（如本注释）提供了额外的非重要信息，读者可以跳过这些信息而不遗漏任何重要信息。这些非必要注释的主要目的是传达有关本文件基本原理的信息，或将本文件置于适当的历史或演变背景中。其唯一目的是构造一致性实现的读者可以跳过此类信息。然而，对于那些希望理解我们为什么做出某些设计选择的人来说，这可能是有用的。
The specification of Critical Content is small and compact. For the benefit of developers, the specification comes first, the rationale after.
关键内容的规格小而紧凑。为了开发人员的利益，规范是第一位的，基本原理是第二位的。
One concept that an implementer must understand is the content gateway. Section 10 describes the content gateway. In brief, a content gateway has knowledge of the receiving system's capabilities. The content gateway passes messages the receiving system can process, render or store. The content gateway can modify a message, for example by deleting unrenderable or storable body parts, for delivery
实现者必须理解的一个概念是内容网关。第10节描述了内容网关。简言之，内容网关了解接收系统的功能。内容网关传递接收系统可以处理、呈现或存储的消息。内容网关可以修改消息，例如通过删除不可渲染或可存储的身体部位来进行传递
to the receiving system. Finally, the content gateway can reject a message that the receiving system cannot handle.
发送到接收系统。最后，内容网关可以拒绝接收系统无法处理的消息。
Although Critical Content processing is not an OPES service, the protocol machinery described in this document meets all of the OPES IAB requirements as stated by RFC 3238 [4]. Section 14 describes this in detail. In particular, unlike the current situation where content gateways silently modified messages, or had abstract rules for modifying them (see the content transformation rules in VPIM, for example), the Critical Content mechanism allows for the sending user to explicitly indicate desired content handling by content gateways
尽管关键内容处理不是OPES服务，但本文件中描述的协议机制符合RFC 3238[4]中规定的所有OPES IAB要求。第14节对此进行了详细描述。特别是，与当前内容网关以静默方式修改消息或具有修改消息的抽象规则（例如，请参见VPIM中的内容转换规则）不同，关键内容机制允许发送用户明确指示内容网关所需的内容处理
NOTE: This document updates RFC 3204 [5] to separate the Handling parameter from the ISUP/QSIG transport mechanism. The protocol described here is identical in functionality to RFC 3204 with respect to SIP. Future versions of RFC 3204 should reference this document for the Handling parameter, as it is orthogonal to the tunneling of signaling.
注：本文件更新了RFC 3204[5]，将处理参数与ISUP/QSIG传输机制分开。这里描述的协议在SIP方面的功能与rfc3204相同。RFC 3204的未来版本应参考本文档的处理参数，因为它与信令的隧道正交。
The Handling parameter is a Content-Disposition [6] parameter inserted by the sending agent to indicate to the content gateway whether to consider the marked body part critical.
处理参数是由发送代理插入的内容配置（6）参数，以指示内容网关是否考虑标记的正文部分关键。
A REQUIRED body part is one the sender requires the receiving system to deliver for him to consider the message delivered.
一个需要的身体部分是发送者要求接收系统传递给他以考虑传递的信息。
An OPTIONAL body part is one the sender doesn't care whether the receiving system delivers it or not. A content gateway can silently delete such body parts if the receiving system cannot deliver the part.
一个可选的身体部位是发送者不关心接收系统是否发送的部位。如果接收系统无法交付这些身体部位，内容网关可以无声地删除这些身体部位。
The terms "entity" and "body part" have the meanings defined in [6].
术语“实体”和“身体部位”具有[6]中定义的含义。
"Handling=REQUIRED" signifies that this body part is critical to the sender.
“Handling=REQUIRED”表示该身体部位对发送者至关重要。
If the content gateway cannot 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 this case, the appropriate action is to silently discard the message. In addition, as a general MIME parameter, the MIME body part may not be in an Internet Mail message.
注意：我们称之为“适当的操作”，因为发送方可能已禁止所有通知。在这种情况下，适当的操作是以静默方式丢弃消息。此外，作为一般MIME参数，MIME正文部分可能不在Internet邮件消息中。
Moreover, in the SIP case, the appropriate notification is a status return code, not a delivery notification.
此外，在SIP情况下，适当的通知是状态返回码，而不是传递通知。
"Handling=OPTIONAL" signifies that the sender does not care about notification reports for this body part.
“Handling=OPTIONAL”表示发件人不关心此正文部分的通知报告。
If the content gateway cannot 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.
如果内容网关无法通过标记为可选的正文部分，则接收系统可以静默删除正文部分。接收系统不得返回交付故障，除非标记为“需要”的零件也出现故障。
The default value for Handling for a given body part is REQUIRED. This enables the existing notification mechanisms to work for sending agents that do not know about the content notification entity. All body parts are critical, because they have the default marking of REQUIRED.
指定身体部位的处理默认值是必需的。这使现有的通知机制能够用于发送不知道内容通知实体的代理。所有身体部位都是关键部位，因为它们具有“必需”的默认标记。
NOTE: In the case of Internet mail, critical content processing is a function of the content gateway and not the mail transfer agent (MTA) or user agent (UA). Often, the entity performing content gateway processing is the receiving UA. However, in this case the UA is acting as a content gateway. Thus the default action for any Content-Disposition [6]-compliant user agent to ignore unrecognized disposition parameters ensures that this mechanism is compatible with the Internet architecture.
注意：对于Internet邮件，关键内容处理是内容网关的功能，而不是邮件传输代理（MTA）或用户代理（UA）。通常，执行内容网关处理的实体是接收UA。然而，在这种情况下，UA充当内容网关。因此，任何内容处置[6]兼容的用户代理忽略未识别的处置参数的默认操作可确保此机制与Internet体系结构兼容。
NOTE: This parameter is fully backwards compatible and works as expected for Internet mail and SIP.
注意：此参数完全向后兼容，并在Internet邮件和SIP中正常工作。
NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from the Internet. However, these systems are really acting in the capacity of an Internet Voice Mail system. In this case, one would expect the implementation to provide Internet Voice Mail semantics to Internet Voice Mail messages.
注意：某些VPIMv2实现可以从Internet接收任意电子邮件。然而，这些系统实际上是以互联网语音邮件系统的能力运行的。在这种情况下，可以期望实现为Internet语音邮件消息提供Internet语音邮件语义。
The content gateway MUST treat unrecognized values as REQUIRED. This is to provide backward compatibility with future uses of the Content-Criticality entity.
内容网关必须根据需要处理无法识别的值。这是为了提供与内容关键性实体未来使用的向后兼容性。
NOTE: A possible new value is IMPORTANT. An IMPORTANT body part is something the sender wants the receiver to get, but would not want the message rejected outright if the IMPORTANT body part fails, but
注意：可能的新值很重要。重要正文部分是发送方希望接收方获得的内容，但如果重要正文部分失败，则发送方不希望消息被彻底拒绝，但
they do want notification of the failure. However, as no implementations do IMPORTANT, it is not important to this version of this document.
他们确实希望得到失败的通知。但是，由于没有任何实现是重要的，因此它对于本文档的这个版本并不重要。
The format of the collected syntax is in accordance with the ABNF of [7]. Note that per RFC 2183 [6], the HANDLING Content-Disposition parameter is not case sensitive. In addition, the notification-type is not case sensitive.
收集的语法格式符合[7]的ABNF。请注意，根据RFC 2183[6]，处理内容处置参数不区分大小写。此外，通知类型不区分大小写。
"handling" "=" notification-type CRLF
处理“=”通知类型CRLF
notification-type = "REQUIRED" / "OPTIONAL" /
other-handling / generic-param
notification-type = "REQUIRED" / "OPTIONAL" /
other-handling / generic-param
other-handling = token
other-handling = token
One obvious application of critical content is generating a (non-) delivery notification in the Internet mail environment. If the value of the field is OPTIONAL, the content gateway MUST NOT generate a notification. If the value of the field is REQUIRED, the content gateway MAY generate a notification, based on the normal notification request mechanisms. Normal notification request mechanisms include specifying the NOTIFY parameter to the SMTP RCPT command [8] and the Disposition-Notification-To header [9].
关键内容的一个明显应用是在Internet邮件环境中生成（非）传递通知。如果该字段的值是可选的，则内容网关不得生成通知。如果字段的值是必需的，则内容网关可以基于正常的通知请求机制生成通知。正常的通知请求机制包括指定SMTP RCPT命令[8]的NOTIFY参数和头[9]的处置通知。
In SIP, all requests have responses. These responses provide notification in the status code of the response. For the RFC 3204 case, a content gateway generates a 415 (Unsupported Media Type) response if the field is REQUIRED.
在SIP中，所有请求都有响应。这些响应在响应的状态代码中提供通知。对于rfc3204情况，如果字段是必需的，则内容网关生成415（不支持的媒体类型）响应。
If the sending system requests a notification, and a REQUIRED part fails, the content gateway MUST generate a notification for the whole message. Conversely, if the gateway cannot pass on a body part marked OPTIONAL, the gateway MUST NOT generate a notification.
如果发送系统请求通知，而所需部分失败，则内容网关必须为整个消息生成通知。相反，如果网关无法传递标记为可选的身体部位，则网关不得生成通知。
NOTE: This implies that the content gateway must examine the entire message to determine whether it needs to generate a notification. However, the content gateway need not examine the message if it knows it can store and forward all media types. 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, such as application/ms-word. The voice mail content gateway, in this example, would be scanning for non-renderable body parts in any event.
注意：这意味着内容网关必须检查整个消息，以确定是否需要生成通知。但是，如果内容网关知道它可以存储和转发所有媒体类型，则无需检查消息。换句话说，默认情况下，Internet电子邮件MTA或网关可以处理任意MIME封装类型。另一方面，一些语音邮件系统根本无法存储二进制附件，例如application/ms word。在本例中，语音邮件内容网关将在任何情况下扫描不可渲染的身体部位。
The content gateway generates a delivery status notification (DSN) [9] if it operates as a gateway. The content gateway 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 is a MTA that "delivers" the message to the content gateway for processing, the MTA takes responsibility for DSN processing. In this case, the only option available to the content gateway is to generate MDNs. If the content gateway operates as a MTA, then it generates DSNs. DSN generation is the preferred option.
如果内容网关作为网关运行，则会生成传递状态通知（DSN）[9]。如果内容网关作为邮件用户代理运行，它将生成消息处置通知（MDN）[10]。第6节描述了内容网关的操作模式。简而言之，如果有MTA将邮件“传递”到内容网关进行处理，MTA将负责DSN处理。在这种情况下，内容网关可用的唯一选项是生成MDN。如果内容网关作为MTA运行，则会生成DSN。DSN生成是首选选项。
If the content gateway is part of a SIP endpoint, then it generates the appropriate success or error response code.
如果内容网关是SIP端点的一部分，那么它将生成相应的成功或错误响应代码。
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.
注意：本节是规范性的：它建议内容网关应该放入DSN或MDN中。
NOTE: In the case of SIP, this section is informative. See RFC 3204 for the normative set of actions on failure.
注：对于SIP，本节内容仅供参考。参见RFC 3204，了解故障时的标准操作集。
Table 1 - Expected Actions
表1-预期行动
+--------------------------------------+
| Sending UA Has Marked Body Part |
|---------------------+----------------|
| REQUIRED | OPTIONAL |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Deliverable | Appropriate Action | ignore |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Undeliverable | Fail Entire Message | ignore |
+--------------------+--------------------------------------+
+--------------------------------------+
| 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 the action the content gateway would take given the context of execution. For example, if a sender requests 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 cannot deliver the body part and the body part is critical, the content gateway generates the appropriate DSN or MDN.
“适当的操作”是指给定执行上下文的内容网关将采取的操作。例如，如果发送方请求返回收据，而接收方读取处理主体部分，则接收UA必须生成适当的MDN（遵循MDN规则）。同样，如果内容网关无法交付正文部分，并且正文部分非常重要，则内容网关将生成相应的DSN或MDN。
"Optional" means the content gateway ignores the disposition of the body part. The content gateway treats the message as if the body part was not present in the message.
“可选”表示内容网关忽略主体部分的配置。内容网关将邮件视为邮件中不存在正文部分。
RFC 1847 [11] describes how to apply digital signatures to a MIME body part. In brief, a multipart/signed body part encapsulates the body part of interest, or the "content object", in a MIME body part and the control information needed to verify the object, or the "protocol" in the lexicon of RFC 1847, in a second MIME body part. Here is an example taken from RFC 1847.
RFC 1847[11]描述了如何将数字签名应用于MIME主体部分。简言之，多部分/签名的主体部分将感兴趣的主体部分或“内容对象”封装在MIME主体部分中，并将验证对象或RFC 1847词典中的“协议”所需的控制信息封装在第二MIME主体部分中。下面是一个取自RFC1847的示例。
Content-Type: multipart/signed; protocol="TYPE/STYPE";
micalg="MICALG"; boundary="Signed Boundary"
Content-Type: multipart/signed; protocol="TYPE/STYPE";
micalg="MICALG"; boundary="Signed Boundary"
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
--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
协议“类型/STYPE”的控制信息将显示在此处
--Signed Boundary--
--有符号边界--
Figure 1 - Signed Content MIME Type
图1-签名内容MIME类型
There are three places where one may place the criticality indicator for a multipart/signed body part. One could mark the multipart/signed object, the content object, the control object, or any combination of the three.
有三个地方可以放置多部分/签名身体部位的临界指示器。可以标记多部分/签名对象、内容对象、控制对象或三者的任意组合。
The disposition of REQUIRED body parts follow the guidelines found in RFC 2480 [12].
所需身体部位的处置遵循RFC 2480[12]中的指南。
A critical content indicator on a multipart/signed body part means the sending party requires true end-to-end signature verification. Thus the gateway needs to pass the enclosure intact. If the system or network of lesser capability cannot do signature verification and the signed enclosure is REQUIRED, the gateway MUST reject the message.
多部分/签名正文部分上的关键内容指示符表示发送方需要真正的端到端签名验证。因此，网关需要完整地通过机柜。如果功能较低的系统或网络无法进行签名验证，并且需要签名的机柜，则网关必须拒绝该消息。
A critical content indicator on a signature means that 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 does not pass verification, the gateway MUST reject the message.
签名上的关键内容指示器意味着接收端点必须能够进行签名验证，或者网关需要在转发消息之前验证签名。如果内容未通过验证，网关必须拒绝该消息。
A critical content indicator on the enclosed material specifies 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 information if the system or network of lesser capability cannot do signature verification. However, if possible, we STRONGLY RECOMMEND the gateway do signature verification and indicate tampering to the recipient.
随附材料上的关键内容指示器指定该材料对整个邮件是否至关重要。如果签名标记为可选，且随附材料标记为必需，则如果能力较弱的系统或网络无法进行签名验证，网关可能会删除签名信息。但是，如果可能，我们强烈建议网关进行签名验证，并向收件人指示篡改。
RFC 1847 [11] describes how to encrypt a MIME body part. In brief, a multipart/encrypted body part encapsulates the control information ("protocol" in the lexicon of RFC 1847) for the encrypted object and the second containing the encrypted data (application/octet-stream). Here is an example taken from RFC 1847.
RFC1847[11]描述了如何加密MIME主体部分。简言之，多部分/加密主体部分封装加密对象的控制信息（“RFC 1847词典中的协议”），第二部分包含加密数据（应用程序/八位字节流）。下面是一个取自RFC1847的示例。
Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
boundary="Encrypted Boundary"
Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
boundary="Encrypted Boundary"
--Encrypted Boundary Content-Type: TYPE/STYPE
--加密的边界内容类型：类型/STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
协议“类型/STYPE”的控制信息将显示在此处
--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.
内容类型：文本/纯文本；charset=“us ascii”所有缩进文本，包括缩进标题，都将无法读取，因为它将由协议“TYPE/STYPE”加密。此外，这些加密数据可以是任何类型的数据，当然也可以相应地进行标记。
--Encrypted Boundary--
--加密边界--
One may sensibly place a criticality indicator on the encrypted enclosure (multipart/encrypted) body part. If the endpoint can decrypt the message, then the gateway passes the body part in its entirety.
可以在加密外壳（多部分/加密）主体部分合理放置临界指示器。如果端点可以解密消息，那么网关将整体传递正文部分。
If one marks the control object REQUIRED, then the sending UA requires end-to-end encryption. If the endpoint cannot decrypt the message, then the gateway MUST reject the message.
如果将控制对象标记为必需，则发送UA需要端到端加密。如果端点无法解密消息，则网关必须拒绝该消息。
If the control object is OPTIONAL, and the endpoint cannot decrypt the message, and the gateway can decrypt the message, then the gateway MAY decrypt the message and forward the cleartext message. The sending user has explicitly given permission for the gateway to decrypt the message by marking the control object OPTIONAL. Recall that the default indication for MIME body parts is REQUIRED. Thus if the user takes no explicit action, the content gateway will assume the user wished end-to-end encryption.
如果控制对象是可选的，并且端点不能解密消息，而网关可以解密消息，那么网关可以解密消息并转发明文消息。发送用户已通过将控制对象标记为可选，明确授予网关解密消息的权限。回想一下，MIME主体部分的默认指示是必需的。因此，如果用户没有采取明确的操作，内容网关将假定用户希望进行端到端加密。
Marking the encrypted content, without marking the encrypted enclosure, is problematic. This is because the gateway has to decrypt the encrypted data to retrieve the header. However, it is unlikely for the gateway to have the capability (e.g., keys) to decrypt the encrypted data. If a sending UA wishes to mark encrypted data as not REQUIRED, the sending UA MUST mark the encrypted content as not REQUIRED. Clearly, if the sending UA marks the encrypted content as REQUIRED, the gateway will apply the REQUIRED processing rules. Moreover, if the sending UA does not mark the encrypted content as REQUIRED, the gateway, unless it can decrypt the data, will treat the encrypted content as REQUIRED. This occurs because gateways always treat unmarked content as REQUIRED (see Section 3.3).
标记加密内容而不标记加密的附件是有问题的。这是因为网关必须解密加密数据才能检索报头。然而，网关不太可能具有解密加密数据的能力（例如，密钥）。如果发送UA希望将加密数据标记为非必需，则发送UA必须将加密内容标记为非必需。显然，如果发送UA将加密内容标记为所需，网关将应用所需的处理规则。此外，如果发送UA未按要求标记加密内容，则网关（除非其能够解密数据）将按要求处理加密内容。这是因为网关总是按要求处理未标记的内容（请参见第3.3节）。
The critical content indication, in itself, does not guarantee any notification. Notification follows the rules described in [3], [8], and [9].
关键内容指示本身并不保证任何通知。通知遵循[3]、[8]和[9]中描述的规则。
NOTE: The content of actual DSNs or MDNs are beyond the scope of this document. This document only specifies how to mark a critical body part. On the other hand, 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.
注：实际DSN或MDN的内容超出本文档的范围。本文档仅指定如何标记关键车身零件。另一方面，我们确实设想了合理的DSN和MDN内容。例如，DSN应包括[13]中列举的相应故障代码。同样，MDN应该在MDN“failure:”字段中包含故障代码。
If the receiving system is to generate a notification based on its inability to render or store the media type, the notification should use the status code 5.6.1, "Media not supported", from [10].
如果接收系统根据其无法呈现或存储媒体类型生成通知，通知应使用[10]中的状态代码5.6.1“不支持媒体”。
For the SIP case, all requests have notification provided by the status response message. Per RFC 3204, a content gateway generates a 415 (Unsupported Media Type) response.
对于SIP情况，所有请求都有状态响应消息提供的通知。根据RFC 3204，内容网关生成415（不支持的媒体类型）响应。
This section is informative.
本节内容丰富。
The need for a critical content identification mechanism comes about because of the internetworking of Internet mail systems with messaging systems that do not fulfill all of the semantics of Internet mail. Such legacy systems have a limited ability to render or store all parts of a given message. This document will use the case of an Internet mail system exchanging electronic messages with a legacy voice messaging system for illustrative purposes.
由于Internet邮件系统与不满足Internet邮件所有语义的消息传递系统之间的互联，因此需要一种关键的内容识别机制。此类遗留系统呈现或存储给定消息的所有部分的能力有限。为了便于说明，本文档将使用Internet邮件系统与传统语音消息系统交换电子消息的情况。
Electronic mail has historically been text-centric. Extensions such as MIME [14] enable the user agents to send and receive multi-part, multimedia messages. Popular multimedia data types include binary word processing documents, binary business presentation graphics, voice, and video.
电子邮件历来以文本为中心。MIME[14]等扩展允许用户代理发送和接收多部分的彩信。流行的多媒体数据类型包括二进制字处理文档、二进制业务表示图形、语音和视频。
Voice mail has historically been audio-centric. Many voice-messaging systems only render voice. Extensions such as fax enable the voice mail system to send and receive fax images as well as create multi-part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax technology. Although theoretically possible, none can today render video.
语音邮件历来以音频为中心。许多语音信息系统只提供语音。传真等扩展使语音邮件系统能够发送和接收传真图像，以及创建多部分语音和传真消息。一些语音邮件系统可以使用文本到语音或文本到传真技术呈现文本。虽然理论上是可能的，但现在没有人可以渲染视频。
An important aspect of the interchange between voice messaging services and desktop e-mail client applications is that the rendering capability of the voice-messaging platform is often much less than the rendering capability of a desktop e-mail client. In the e-mail case, the sender has the expectation that the recipient receives all components of a multimedia message. This is so even if the recipient cannot render all body parts. In most cases, the recipient can either find the appropriate rendering tool or tell the sender that she cannot read the particular attachment.
语音消息服务和桌面电子邮件客户端应用程序之间交换的一个重要方面是，语音消息平台的呈现能力通常远低于桌面电子邮件客户端的呈现能力。在电子邮件的情况下，发件人希望收件人收到彩信的所有组件。即使收件人无法渲染所有身体部位，也是如此。在大多数情况下，收件人可以找到适当的呈现工具，或者告诉发件人她无法阅读特定的附件。
This is an important issue. By definition, a MIME-enabled user agent, conforming to [15], will present or make available all of the body parts to the recipient. However, a voice mail system may not be capable of storing non-voice objects. Moreover, the voice mail system may not be capable of notifying the recipient that there were undeliverable message parts.
这是一个重要问题。根据定义，符合[15]的支持MIME的用户代理将向收件人呈现或提供所有身体部位。但是，语音邮件系统可能无法存储非语音对象。此外，语音邮件系统可能无法通知接收者存在无法传送的消息部分。
The inability of the receiving system to render a body part is usually a permanent failure. Retransmission of the message will not improve the likelihood of a future successful delivery. Contrast this with the case with normal data delivery. Traditional message
接收系统无法呈现身体部位通常是永久性故障。消息的重新传输不会提高未来成功传递的可能性。将此与正常数据传输的情况进行对比。传统信息
failures, such as a garbled message or disabled link will benefit from retransmission.
失败（如消息混乱或链路被禁用）将受益于重新传输。
This situation is fundamentally different from normal Internet mail. In the Internet mail case, either the system delivered the message, or it didn't. There is no concept of a system partially delivering a message.
这种情况与普通的互联网邮件有根本的不同。在互联网邮件案例中，要么系统发送了邮件，要么没有。没有系统部分传递消息的概念。
In addition, there are many situations where the sender would not mind if the system did not deliver non-critical parts of a message. For example, the sender's user agent may add body parts to a message unbeknownst to the sender. If the receiving system rejected the message because it could not render a hidden body part, the sender would be understandably confused and upset.
此外，在许多情况下，如果系统没有传递消息的非关键部分，发送者不会介意。例如，发件人的用户代理可以在发件人不知道的情况下向邮件添加正文部分。如果接收系统拒绝了消息，因为它无法呈现隐藏的身体部位，那么发送者会感到困惑和不安，这是可以理解的。
Thus, there is a need for a method of indicating to a Mail Transfer Agent (MTA) or User Agent (UA) that the sender considers parts of a message to be critical. From the sender's perspective, he would not consider the message delivered if the system did not deliver the critical parts.
因此，需要一种向邮件传输代理（MTA）或用户代理（UA）表明发件人认为邮件的某些部分是关键的方法。从发送者的角度来看，如果系统没有传递关键部分，他不会考虑传递的信息。
One method of indicating critical content of a message is to define a profile. The profile defines rules for silently deleting mail body parts based on knowledge of the UA capabilities. Citing the example above, a voice profile can easily declare that MTAs or UAs can silently delete TNEF data and yet consider the message successfully delivered. This is, in fact, the approach taken by VPIMv2 [16].
指示消息关键内容的一种方法是定义概要文件。该概要文件定义了基于UA能力的静默删除邮件正文部分的规则。引用上面的示例，语音配置文件可以很容易地声明MTAs或UAS可以默默地删除TNEF数据，但还可以考虑成功传递的消息。事实上，这是VPIMv2采取的方法[16]。
Since one aspect of the issue is deciding when to notify the sender that the system cannot deliver part of a message, one could use a partial non-delivery notification mechanism to indicate a problem with delivering a given body part. However, this requires the user request a delivery notification. In addition, the sender may not be aware of parts added by the sending user agent. In this case, a failure notice would mystify the sender.
由于问题的一个方面是决定何时通知发送方系统无法传递消息的一部分，因此可以使用部分未传递通知机制来指示传递给定正文部分的问题。但是，这需要用户请求传递通知。此外，发送方可能不知道由发送用户代理添加的部分。在这种情况下，失败通知会使发送者感到迷惑。
A straightforward alternative implementation method 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.
将身体部位标记为关键的一种简单的替代实现方法是使用关键内容MIME实体。这样做的好处是关键性是身体部位的元信息。但是，IMAP服务器尤其需要将关键内容放入BODYSTRUCTURE方法，或者创建一个新方法来检索任意MIME实体。考虑到试图让IMAP供应商接受内容位置的经验，我们选择不走这条路。
What we need is a way of letting the sender indicate what body parts he considers 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.
我们需要的是让发送者指出他认为重要的身体部位。该机制不得向发送方发送非关键身体部位的故障通知。该机制必须符合肯定或否定通知的一般通知状态请求机制。当收到请求时，当接收系统无法交付关键身体部位时，该机构必须向发送方发出指示。
This section is informative.
本节内容丰富。
In this section, we use the definition found in RFC 2156 [17] for the term "gateway."
在本节中，我们使用RFC 2156[17]中对术语“网关”的定义
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, that mostly deals with transformations of the SMTP information.
我们没有严格使用RFC 2821[18]中对术语“网关”的定义。特别是，RFC 2821讨论的网关不应检查消息本身。RFC2821网关是一个传输网关，主要处理SMTP信息的转换。
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.
内容网关是将第一网络连接到第二网络的网关。第二个网络的容量通常比第一个网络小。规范拓扑如下。带方括号的“[MTA]”表示可选组件。
+---------+
+---------+ +-----+ | | +-------+ +-----------+
| Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
| UA | +-----+ | Gateway | +-------+ | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
+---------+
+---------+ +-----+ | | +-------+ +-----------+
| Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
| UA | +-----+ | Gateway | +-------+ | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
Figure 2 - Content Gateway Topology
图2-内容网关拓扑
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.
内容网关可以是接收MTA之前的最后一个跃点。内容网关可以位于网络之间，因此不是接收MTA之前的最后一个跃点。内容网关可以是发送UA联系人的第一个MTA。最后，内容网关可以是接收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.
对于SIP情况，将每个MTA视为SIP代理、发送UA作为SIP用户代理客户端，以及接收UA作为SIP用户代理服务器。
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
+---------------------+
+---------+ +-----+ | : |
| Sending |=...=|[MTA]|===| Content : Receiving |
| UA | +-----+ | Gateway : UA |
+---------+ | : |
+---------------------+
First Network Second Network
Figure 3 - Integrated Content Gateway
图3-集成内容网关
The processing of ISUP and QSIG objects, as described in [5], is an example of an integrated gateway.
如[5]所述，ISUP和QSIG对象的处理是集成网关的一个示例。
A degenerate case, although one that does occur, is 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.
内容网关位于最终MTA后面，这是一种退化的情况，尽管确实发生过。当实现内容网关作为正常交付的后处理步骤时，就会发生这种情况。例如，可以将邮件处理系统配置为将邮件传递到队列或目录，内容网关进程在其中拾取邮件。如果有任何DSN处理指令，则交付MTA将执行这些指令。例如，邮件可能已请求成功传递时的通知。传递MTA，将消息传递给队列，将考虑传递的消息，从而通知发送者。但是，内容网关进程随后可能会发现接收UA无法呈现消息。在这种情况下，内容网关生成NDN，因为它是唯一可用的选项。
Delivered
| +---------+
+---------+ +-----+ v | | +-----------+
| Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
| UA | +-----+ | Gateway | | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
Delivered
| +---------+
+---------+ +-----+ v | | +-----------+
| Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
| UA | +-----+ | Gateway | | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
Figure 4 - Disaggregated Delivery Network
图4——分类交付网络
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.
DSN需要ESMTP。如果从发送UA到接收UA的路径中的MTA不支持ESMTP，则该MTA将拒绝DSN请求。此外，消息将默认为延迟或故障通知。虽然不理想，但发送方将知道DSN不可用，并且失败的关键内容将得到通知。
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.
与所有内容处置参数一样，处理仅对选定的备选方案有效。如果所选备选方案具有关键内容指示器，则整个备选方案具有指示的关键性。也就是说，如果选择的备选方案具有HANDLING=OPTIONAL，则内容网关不得生成任何传递通知。
NOTE: This statement explicitly shows that HANDLING overrides the DSN and MDN request mechanisms.
注意：此语句明确显示处理覆盖DSN和MDN请求机制。
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.
如果所选备选方案是包含多部分MIME消息的消息/rfc822，或者所选备选方案本身是多部分MIME类型，则各个顶级主体部分遵循本文档中描述的处理机制。
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.
临界性与多部分/相关结构非常吻合。例如，考虑由Macintosh数据叉和Macintosh资源分叉组成的多部分/相关消息。对于MicrosoftWord文档，数据分叉可能非常关键。接收系统可以安全地忽略资源分支。
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].
嵌入人体部件中的临界指示器。这避免了转发消息触发或抑制不需要的报告的情况。这只是实现了[6]中描述的过程。
See Section 6.
见第6节。
See Section 7.
见第7节。
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.
我们将研究两个案例。它们是内容网关处理消息的方式以及分类内容网关处理消息的方式。
Content gateways examine the contents of a message from a first network before the gateway forwards the message to a second network. For the purposes of this example, we assume the second network has less capability than the first network. In particular, we expect there will be certain message body types that the gateway cannot pass onto the second network.
内容网关在网关将消息转发到第二个网络之前检查来自第一个网络的消息内容。在本例中，我们假设第二个网络的容量小于第一个网络。特别是，我们期望网关无法将某些消息体类型传递到第二个网络。
Consider a gateway between the Internet and a text-only short message service. A message comes through the gateway containing a text part and a tnef part. The sender marks the text part REQUIRED. The gateway, knowing the capability of the short message service, silently deletes the non-critical, tnef part, passing the critical content to the short message service network. Any subsequent notifications, such as failure notices or delivery notices, follow the normal rules for notification.
考虑Internet和纯文本短消息服务之间的网关。消息通过包含文本部分和tnef部分的网关发送。发件人将文本部分标记为必需。网关知道短消息服务的能力，会默默地删除非关键的tnef部分，将关键内容传递给短消息服务网络。任何后续通知（如故障通知或交付通知）均遵循正常的通知规则。
Note the gateway, by silently deleting non-critical content, may affect proprietary message correlation schemes. One can envision the sending UA inserting a body part for tracking purposes. By deleting non-critical content, the content gateway will break such a scheme. If a sending UA understands how to mark critical content, it should use Internet standard mechanisms for tracking messages, such as Message-ID [19].
注意：网关通过静默删除非关键内容，可能会影响专有消息关联方案。人们可以设想发送UA插入身体部位以进行跟踪。通过删除非关键内容，内容网关将破坏这种方案。如果发送UA了解如何标记关键内容，则应使用互联网标准机制来跟踪消息，如消息ID[19]。
What if no body parts have critical content indicators? In this case, the entire message is critical. Thus, when the gateway sees the tnef part, it will reject the entire message, generating a DSN with a status code 5.6.1, "Media not supported".
如果没有身体部位有关键内容指示器怎么办？在这种情况下，整个消息是至关重要的。因此，当网关看到tnef部分时，它将拒绝整个消息，生成状态代码为5.6.1“不支持媒体”的DSN。
Likewise, consider a three part message with a text annotation (part 1) to a voice message (part 2) with a vCard [20] (part 3). The sender marks the first two parts REQUIRED. Now, let us assume the receiving MTA (gateway) is a voice mail only system, without even the capability to store text. In this case, the gateway, acting as the receiving MTA, will reject the message, generating a DSN with the status code 5.6.1, "Media not supported".
同样，考虑一个带有文本注释的三部分消息（第1部分）到VCARD（20）的语音消息（第2部分）（第3部分）。发送器标记所需的前两部分。现在，让我们假设接收MTA（网关）是一个仅限语音邮件的系统，甚至没有存储文本的功能。在这种情况下，作为接收MTA的网关将拒绝邮件，并生成状态代码为5.6.1“不支持介质”的DSN。
For this example, we will examine the processing of a three-part message. The first part is a text annotation of the second part, an audio message. The third part is the sender's vCard. The sender marks the first and second parts REQUIRED. In addition, the sender marks the message for read receipt.
对于本例，我们将检查由三部分组成的消息的处理。第一部分是文本注释，第二部分是音频消息。第三部分是寄件人的电子名片。发送器标记所需的第一和第二部分。此外，发件人将邮件标记为已读回执。
For the purposes of example, the telephone user interface (TUI) does not perform 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).
出于示例的目的，电话用户界面（TUI）不执行文本到语音的转换。TUI是一种邮件用户代理（UA），它使用DTMF按键数字进行输入，使用音频进行输出（显示）。
The TUI is unable to render the first part of the message, the text part. In addition, it is unable to render the third part of the message, the vCard part. Since the sender did not mark the third part of the message REQUIRED, the system ignores the failure of the TUI to render the third part of the message. However, since the sender did mark the first part REQUIRED, and the TUI is unable to render text, the message fails.
TUI无法呈现消息的第一部分，即文本部分。此外，它无法呈现消息的第三部分vCard部分。由于发送方没有标记所需消息的第三部分，因此系统忽略TUI未能呈现消息的第三部分。但是，由于发送方确实标记了第一个必需部分，并且TUI无法呈现文本，因此消息失败。
What happens next is implementation dependent. If the TUI is part of a unified messaging system, a reasonable action is to hold the message for the user. The user can access the message at a later time from a terminal that can render all of the critical body parts. It would be reasonable for the TUI to notify the user about the undeliverable body part.
接下来发生的事情取决于实现。如果TUI是统一消息系统的一部分，则合理的操作是为用户保留消息。用户可以稍后从可以渲染所有关键身体部位的终端访问消息。TUI通知用户无法交付的身体部位是合理的。
If the TUI is part of a voice messaging system, or if the user does not 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)".
如果TUI是语音消息传递系统的一部分，或者如果用户未订阅文本到语音服务，则合理的操作是TUI返回MDN，其处置方式为“failed”，故障修饰符为“5.6.1（不支持媒体）”。
Critical Content processing is not a web service. However, some in the Internet community may draw parallels between web services that modify content and an e-mail, SIP, or other MIME-transport service that modifies content.
关键内容处理不是web服务。但是，Internet社区中的一些人可能会将修改内容的web服务与修改内容的电子邮件、SIP或其他MIME传输服务进行比较。
This section will analyze the Critical Content protocol machinery against the requirements stated in RFC 3238 [4]. The summary is that the protocol described in this document meets all of the requirements of RFC 3238.
本节将根据RFC 3238[4]中规定的要求分析关键内容协议机制。总结是，本文件中描述的协议满足RFC 3238的所有要求。
This is the heart of Critical Content. Critical Content enables the sending party to give consent to have the message modified. Gateways that conform to this document will ensure that gateways only modify messages that the sending party has given consent to modify.
这是关键内容的核心。关键内容使发送方能够同意修改邮件。符合本文档要求的网关将确保网关仅修改发送方同意修改的消息。
The content gateway is an addressable IP-entity. Moreover, all of the relevant protocols (SMTP, SIP, HTTP, etc.) all explicitly make the presence of the gateway known to the endpoints.
内容网关是一个可寻址的IP实体。此外，所有相关协议（SMTP、SIP、HTTP等）都明确表示端点知道网关的存在。
Again, this is the point of this document. The sender explicitly gets notification if the gateway would remove a Critical Content body part.
这也是本文件的重点。如果网关将删除关键内容主体部分，则发送方将显式收到通知。
The nature of the receiving system dictates that end users understand that the messages have been changed.
接收系统的性质决定了最终用户了解消息已被更改。
By definition, the endpoint cannot receive non-modified content, so this requirement does not apply.
根据定义，端点不能接收未修改的内容，因此此要求不适用。
Clearly, one is sending mail (SMTP), a message (SIP), or fetching a document (HTTP). The machinery described in this document does not alter the content itself or the access mechanism. Thus it is compliant with this requirement.
显然，一种是发送邮件（SMTP）、消息（SIP）或获取文档（HTTP）。本文档中描述的机制不会改变内容本身或访问机制。因此，它符合这一要求。
Since the protocol described in this document does not alter the content itself, inter- and intra-document references are not altered. However, intra-document references to removed body parts will fail. On the other hand, the sender explicitly marked those body parts as being disposable. Thus the sender is aware of the possibility the parts may not arrive at the receiver.
由于本文档中描述的协议不会改变内容本身，因此文档间和文档内引用不会改变。但是，对已删除的车身板件的文档内引用将失败。另一方面，发送者明确地将这些身体部位标记为一次性的。因此，发送方意识到零件可能无法到达接收方。
Since the protocol described in this document meets Considerations 4.1 and 4.2, this requirement does not apply.
由于本文件中描述的协议符合第4.1和4.2条的考虑，因此本要求不适用。
The privacy policy of this protocol is explicit. In particular, the protocol honors end-to-end security.
该协议的隐私策略是明确的。特别是，该协议尊重端到端安全性。
Sending UA's can use signatures over critical content indicators to ensure the integrity of the indicator.
发送UA可以在关键内容指标上使用签名，以确保指标的完整性。
The gateway MUST honor signature processing. In particular, if the sending UA marks the signature components REQUIRED, and the endpoint cannot do MIME signature processing, the gateway MUST establish an appropriate signature mechanism between the gateway and the endpoint. In this case, the gateway must be secure, as it can become a target point for tampering with the signed components of the message.
网关必须遵守签名处理。特别是，如果发送UA标记所需的签名组件，并且端点无法进行MIME签名处理，则网关必须在网关和端点之间建立适当的签名机制。在这种情况下，网关必须是安全的，因为它可能成为篡改消息的已签名组件的目标点。
Receiving systems and users should not place any authentication value on the Handling parameter.
接收系统和用户不应在处理参数上设置任何身份验证值。
Note that by design, and under the sending user's request, a content gateway will silently delete unimportant body parts. Critical content gives the sender the ability to determine the acceptable level integrity of the delivered message. That is, the message as the content gateway actually passes it on is, in fact, representative of the sender's intentions.
请注意，根据设计，在发送用户的请求下，内容网关将自动删除不重要的身体部位。关键内容使发件人能够确定所传递邮件的可接受完整性级别。也就是说，内容网关实际传递的消息实际上代表了发送者的意图。
RFC 3204 already registered the Handling parameter. It is collected here only for reference and as a placeholder for use both for further expansion in the future and as the normative reference for other documents that need to reference the Handling parameter.
RFC 3204已注册处理参数。此处收集该文件仅供参考，并作为占位符，用于将来进一步扩展，以及作为需要参考处理参数的其他文件的规范性参考。
Per section 9 of [6], here is the IANA registration for Handling.
根据[6]第9节，这里是IANA注册处理。
To: IANA@IANA.ORG Subject: Registration of new Content-Disposition parameter
致：IANA@IANA.ORG主题：注册新内容处置参数
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.
描述：将身体部位标记为交付所需（必需）或可以自动丢弃（可选）。参见RFC<this document>和RFC 3204。
Per RFC 2183, the Content-Disposition parameter name is not case sensitive. Per RFC 3459, the values of the parameter are also not case sensitive.
根据RFC 2183，内容处置参数名称不区分大小写。根据RFC 3459，参数值也不区分大小写。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[3] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，P.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[4] IAB, Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4] IAB，Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[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.
[5] Zimmerer，E.，Peterson，E.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[6] Troost, R., Dorner, S. and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[6] Troost，R.，Dorner，S.和K.Moore，Ed.，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
[7] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker，D.和P.Overell，编辑，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[8] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[8] Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 3461，2003年1月。
[9] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[9] Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[10] Fajman，R.，“用于消息处置通知的可扩展消息格式”，RFC 2298，1998年3月。
[11] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[11] Galvin，J.，Murphy，S.，Crocker，S.和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[12] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[12] 弗里德，N.，“网关和MIME安全多部分”，RFC2480，1999年1月。
[13] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[13] Vaudreuil，G.，“增强型邮件系统状态代码”，RFC 3463，2003年1月。
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[14] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[15] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[16] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998.
[16] Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版”，RFC 24211998年9月。
[17] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[17] Kille，S.，“混音器（Mime互联网X.400增强中继）：X.400和RFC 822/Mime之间的映射”，RFC 2156，1998年1月。
[18] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[18] 《简单邮件传输协议》，RFC 28212001年4月。
[19] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[19] Crocker，D.，“ARPA互联网文本信息格式标准”，RFC 822，1982年8月。
[20] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[20] Dawson，F.和T.Howes，“vCard MIME目录配置文件”，RFC24261998年9月。
Emily Candell of Comverse Network Systems was instrumental in helping work out the base issues in the -00 document in Adelaide.
Comverse网络系统公司的Emily Candell在帮助解决阿德莱德的-00文件中的基本问题方面发挥了重要作用。
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指出，这种机制是关于关键性的，而不是通知。这种洞察力使得概念和描述更加直观。如果它仍然令人困惑，那是我的错！
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.
Ned Freed还帮助编写了关于多部分/签名和多部分/加密的章节。作为广告，他提供了宝贵的评论，以帮助该文件的进展。
Keith Moore for helped tighten-up the explanations, and he approved of the use of Content-Disposition.
基思·摩尔（Keith Moore for）帮助加强了解释，他赞成使用内容处理。
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.
Harald Alvestrand和Chris Newman提出了一些实现示例。
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.
Greg White提出了一个关键问题，让我们认识到关键内容处理是一个网关功能，而不是MTA或UA功能。
Jon Peterson cleared up how handling actually does work in the SIP environment.
Jon Peterson澄清了处理实际上是如何在SIP环境中工作的。
An enormous thank you to Michelle S. Cotton at IANA for helping me craft the original IANA Considerations section in 2000, and for catching the functional overlap with RFC 3204 in January 2002.
非常感谢IANA的Michelle S.Cotton在2000年帮助我设计了最初的IANA注意事项部分，并在2002年1月捕获了RFC 3204的功能重叠。
Any errors, omissions, or silliness are my fault.
任何错误、遗漏或愚蠢都是我的错。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
Eric Burger SnowShore Networks，Inc.美国马萨诸塞州切姆斯福德Billerica路285号01824-4120
Phone: +1 978 367 8400
Fax: +1 603 457 5944
EMail: e.burger@ieee.org
Phone: +1 978 367 8400
Fax: +1 603 457 5944
EMail: e.burger@ieee.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。