Network Working Group E. Burger
Request for Comments: 5438 Unaffiliated
Category: Standards Track H. Khartabil
Ericsson Australia
February 2009
Network Working Group E. Burger
Request for Comments: 5438 Unaffiliated
Category: Standards Track H. Khartabil
Ericsson Australia
February 2009
Instant Message Disposition Notification (IMDN)
即时消息处置通知（IMDN）
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.
即时消息（IM）是指在用户之间实时传输消息。本文档提供了一种机制，通过该机制，端点可以请求即时消息处置通知（IMDN），包括页面模式即时消息的传递、处理和显示通知。
The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.
RFC 3862中指定的公共状态和即时消息（CPIM）数据格式使用新的头字段进行扩展，使端点能够请求IMDNs。还定义了一种新的消息格式来传递IMDNs。
This document also describes how SIP entities behave using this extension.
本文档还描述了SIP实体如何使用此扩展的行为。
Table of Contents
目录
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Terminology .....................................................4
4. Overview ........................................................5
5. Disposition Types ...............................................6
5.1. Delivery ...................................................6
5.2. Processing .................................................6
5.3. Display ....................................................7
6. New CPIM Header Fields ..........................................7
6.1. CPIM Header Field Namespace ................................7
6.2. Disposition-Notification ...................................8
6.3. Message-ID .................................................8
6.4. Original-To ................................................8
6.5. IMDN-Record-Route ..........................................9
6.6. IMDN-Route .................................................9
7. Endpoint Behaviour ..............................................9
7.1. IM Sender ..................................................9
7.1.1. Constructing Instant Messages .......................9
7.1.2. Matching IMs with IMDNs ............................11
7.1.3. Keeping State ......................................11
7.1.4. Aggregation of IMDNs ...............................12
7.2. IM Recipient ..............................................12
7.2.1. Constructing IMDNs .................................12
8. Intermediary Behaviour .........................................15
8.1. Constructing Processing Notifications .....................16
8.2. Constructing Delivery Notifications .......................17
8.3. Aggregation of IMDNs ......................................17
9. Identifying Messages ...........................................19
10. Header Fields Formal Syntax ...................................20
11. IMDN Format ...................................................20
11.1. Structure of an XML-Encoded IMDN Payload .................20
11.1.1. The <message-id> Element ..........................21
11.1.2. The <datetime> Element ............................22
11.1.3. The <recipient-uri> Element .......................22
11.1.4. The <original-recipient-uri> Element ..............22
11.1.5. The <subject> Element .............................22
11.1.6. The <delivery-notification>,
<processing-notification>, and
<display-notification> Elements ...................22
11.1.7. The <status> Element ..............................22
11.1.8. MIME Type for IMDN Payload ........................23
11.1.9. The RelaxNG Schema ................................23
12. Transporting Messages Using SIP ...............................27
12.1. Endpoint Behaviour .......................................27
12.1.1. Sending Requests ..................................27
12.1.2. Sending Responses .................................27
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Terminology .....................................................4
4. Overview ........................................................5
5. Disposition Types ...............................................6
5.1. Delivery ...................................................6
5.2. Processing .................................................6
5.3. Display ....................................................7
6. New CPIM Header Fields ..........................................7
6.1. CPIM Header Field Namespace ................................7
6.2. Disposition-Notification ...................................8
6.3. Message-ID .................................................8
6.4. Original-To ................................................8
6.5. IMDN-Record-Route ..........................................9
6.6. IMDN-Route .................................................9
7. Endpoint Behaviour ..............................................9
7.1. IM Sender ..................................................9
7.1.1. Constructing Instant Messages .......................9
7.1.2. Matching IMs with IMDNs ............................11
7.1.3. Keeping State ......................................11
7.1.4. Aggregation of IMDNs ...............................12
7.2. IM Recipient ..............................................12
7.2.1. Constructing IMDNs .................................12
8. Intermediary Behaviour .........................................15
8.1. Constructing Processing Notifications .....................16
8.2. Constructing Delivery Notifications .......................17
8.3. Aggregation of IMDNs ......................................17
9. Identifying Messages ...........................................19
10. Header Fields Formal Syntax ...................................20
11. IMDN Format ...................................................20
11.1. Structure of an XML-Encoded IMDN Payload .................20
11.1.1. The <message-id> Element ..........................21
11.1.2. The <datetime> Element ............................22
11.1.3. The <recipient-uri> Element .......................22
11.1.4. The <original-recipient-uri> Element ..............22
11.1.5. The <subject> Element .............................22
11.1.6. The <delivery-notification>,
<processing-notification>, and
<display-notification> Elements ...................22
11.1.7. The <status> Element ..............................22
11.1.8. MIME Type for IMDN Payload ........................23
11.1.9. The RelaxNG Schema ................................23
12. Transporting Messages Using SIP ...............................27
12.1. Endpoint Behaviour .......................................27
12.1.1. Sending Requests ..................................27
12.1.2. Sending Responses .................................27
12.1.3. Receiving Requests ................................27
12.2. Intermediary Behaviour ...................................29
13. Transporting Messages using MSRP ..............................30
14. Security Considerations .......................................30
14.1. Forgery ..................................................33
14.2. Confidentiality ..........................................33
14.3. IMDN as a Certified Delivery Service .....................34
15. IANA Considerations ...........................................34
15.1. message/imdn+xml MIME TYPE ...............................34
15.2. XML Registration .........................................35
15.3. URN Registration for IMDN Header Parameters ..............35
15.4. Content-Disposition: notification ........................36
16. Acknowledgements ..............................................36
17. References ....................................................37
17.1. Normative References .....................................37
17.2. Informative References ...................................37
12.1.3. Receiving Requests ................................27
12.2. Intermediary Behaviour ...................................29
13. Transporting Messages using MSRP ..............................30
14. Security Considerations .......................................30
14.1. Forgery ..................................................33
14.2. Confidentiality ..........................................33
14.3. IMDN as a Certified Delivery Service .....................34
15. IANA Considerations ...........................................34
15.1. message/imdn+xml MIME TYPE ...............................34
15.2. XML Registration .........................................35
15.3. URN Registration for IMDN Header Parameters ..............35
15.4. Content-Disposition: notification ........................36
16. Acknowledgements ..............................................36
17. References ....................................................37
17.1. Normative References .....................................37
17.2. Informative References ...................................37
In many user-to-user message exchange systems, message senders often wish to know if the human recipient actually received a message or has the message displayed.
在许多用户对用户的消息交换系统中，消息发送者通常希望知道人类接收者是否实际收到了消息或消息是否已显示。
Electronic mail [RFC5321] offers a solution to this need with Message Disposition Notifications [RFC3798]. After the recipient views the message, her mail user agent generates a Message Disposition Notification, or MDN. The MDN is an email that follows the format prescribed by RFC 3798 [RFC3798]. The fixed format ensures that an automaton can process the message.
电子邮件[RFC5321]通过消息处置通知[RFC3798]为这一需求提供了解决方案。收件人查看邮件后，其邮件用户代理将生成邮件处置通知（MDN）。MDN是一封遵循RFC 3798[RFC3798]规定格式的电子邮件。固定格式确保自动机可以处理消息。
The Common Presence and Instant Messaging (CPIM) format, Message/CPIM [RFC3862], is a message format used to generate instant messages. The Session Initiation Protocol (SIP [RFC3261]) can carry instant messages generated using message/CPIM in SIP MESSAGE requests [RFC3428].
公共状态和即时消息（CPIM）格式Message/CPIM[RFC3862]是用于生成即时消息的消息格式。会话启动协议（SIP[RFC3261]）可以携带在SIP消息请求[RFC3428]中使用消息/CPIM生成的即时消息。
This document extends the Message/CPIM message format in much the same way Message Disposition Notifications extends electronic mail. This extension enables Instant Message Senders to request, create, and send Instant Message Disposition Notifications (IMDN). This mechanism works for page-mode as well as session-mode instant messages. This document only discusses page-mode. Session-mode is left for future standardisation efforts.
本文档扩展消息/CPIM消息格式的方式与消息处置通知扩展电子邮件的方式大致相同。此扩展允许即时消息发送者请求、创建和发送即时消息处置通知（IMDN）。此机制适用于页面模式和会话模式即时消息。本文档仅讨论页面模式。会话模式留给未来的标准化工作。
This specification defines three categories of disposition types: "delivery", "processing", and "display". Specific disposition types provide more detailed information. For example, the "delivery" category includes "delivered" to indicate successful delivery and "failed" to indicate failure in delivery.
本规范定义了三类处置类型：“交付”、“处理”和“显示”。特定的处置类型提供了更详细的信息。例如，“交货”类别包括“已交货”表示交货成功，“未交货”表示交货失败。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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.
本文件泛指男性信息的发送者（他/他/他的）和女性信息的接收者（她/她/她的）。此约定纯粹是为了方便起见，不对消息发送者或接收者的性别进行假设。
o IM: An Instant Message generated using the Message/CPIM format.
o IM：使用Message/CPIM格式生成的即时消息。
o IMDN: An Instant Message Disposition Notification generated using the Message/CPIM format that carries an IMDN XML document.
o IMDN：使用带有imdnxml文档的Message/CPIM格式生成的即时消息处置通知。
o Message: An IM or an IMDN generated using the Message/CPIM format.
o 消息：使用消息/CPIM格式生成的IM或IMDN。
o IM Sender: An endpoint (user agent) generating and sending an IM. Also, the endpoint request IMDNs for an IM. Quite often, the IM Sender is the IMDN Recipient. However, that is not always the case, since the IMDN uses the From header in the CPIM message. That value is often the IM Sender's Address of Record (AOR). This address may in fact resolve to different user agents.
o IM发送者：生成和发送IM的端点（用户代理）。此外，端点还请求IM的IMDNs。通常，IM发送者是IMDN接收者。但是，情况并非总是如此，因为IMDN在CPIM消息中使用From头。该值通常是IM发送者的记录地址（AOR）。该地址实际上可能解析为不同的用户代理。
o IM Recipient: An endpoint (user agent) that receives IMs. The IM Recipient, as the node that presumably renders the IM to the user, generates and sends delivery IMDNs to IMs, if requested by the IM Sender and allowed by the IM Recipient.
o IM收件人：接收IMs的端点（用户代理）。如果IM发送方请求并且IM接收方允许，IM接收方作为可能向用户呈现IM的节点，生成并向IMs发送传递IMDN。
o Endpoint: An IM Sender or an IM Recipient.
o 端点：IM发送者或IM接收者。
o Intermediary: An entity in the network, most often an application server (including URI-List and store-and-forward servers), that forwards an IM to its final destination. Intermediaries also can generate and send processing IMDNs to IMs, if requested by the IM Sender and allowed by policy.
o 中间层：网络中的一个实体，通常是一个应用服务器（包括URI列表和存储转发服务器），将IM转发到其最终目的地。如果IM发送方请求并且策略允许，中介还可以生成处理IMDN并将其发送到IMs。
o Gateway: An intermediary that translates between different IM systems that use different protocols.
o 网关：在使用不同协议的不同IM系统之间进行转换的中介。
o IMDN payload: An XML document carrying the disposition notification information. In this specification, it is of MIME type "message/imdn+xml".
o IMDN有效负载：一个携带处置通知信息的XML文档。在本规范中，它是MIME类型“message/imdn+xml”。
o Disposition type: This specification defines three categories of disposition types: "delivery", "processing", and "display".
o 处置类型：本规范定义了三类处置类型：“交付”、“处理”和“显示”。
o Transport Protocol Message: A SIP or other protocol message that contains an IM or IMDN.
o 传输协议消息：包含IM或IMDN的SIP或其他协议消息。
The diagram below shows the basic protocol flow. An IM Sender creates an IM, adds IMDN request information that the IM Sender is interested in receiving, and then sends the IM. At a certain point in time, the IM Recipient or an intermediary determines that the user or application has received, did not receive, displayed, or otherwise disposed of the IM. The mechanism by which an IM Recipient determines its user has read an IM is beyond the scope of this document. At that point, the IM Recipient or intermediary automatically generates a notification message to the IM Sender. This notification message is the Instant Message Disposition Notification (IMDN).
下图显示了基本协议流程。IM发送者创建IM，添加IM发送者感兴趣接收的IMDN请求信息，然后发送IM。在某个时间点，IM接收者或中间人确定用户或应用程序已接收、未接收、显示或以其他方式处置IM。IM收件人确定其用户已阅读IM的机制超出了本文档的范围。此时，IM收件人或中间人会自动向IM发件人生成通知消息。此通知消息是即时消息处置通知（IMDN）。
+--------------+ +--------------+
| IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+
| |
| |
| 1. IM requesting IMDN |
|-------------------------------------->|
| |
| |
| 2. IMDN (disposition) |
|<--------------------------------------|
| |
| |
+--------------+ +--------------+
| IM Sender | | IM Recipient |
|IMDN Recipient| | IMDN Sender |
+--------------+ +--------------+
| |
| |
| 1. IM requesting IMDN |
|-------------------------------------->|
| |
| |
| 2. IMDN (disposition) |
|<--------------------------------------|
| |
| |
Basic IMDN Message Flow
基本IMDN消息流
Note the recipient of an IMDN, in some instances, may not be the IM Sender. This is specifically true for page-mode IMs where the Address of Record (AOR) of the IM Sender, which is present in the IM, resolves to a different location or user agent than that from which
注意：在某些情况下，IMDN的收件人可能不是IM发送者。这尤其适用于页面模式IMs，其中IM发送方的记录地址（AOR）解析为不同于源地址的位置或用户代理
the IM originated. This could happen, for example, if resolving the AOR results in forking the request to multiple user agents. For simplicity, the rest of this document assumes that the IM Sender and the IMDN Recipient are the same and therefore will refer to both as the IM Sender.
即时通讯的起源。例如，如果解析AOR导致将请求分叉到多个用户代理，则可能会发生这种情况。为简单起见，本文档的其余部分假设IM发送者和IMDN接收者是相同的，因此将两者都称为IM发送者。
There are three broad categories of disposition states. They are delivery, processing, and display.
有三大类处置状态。它们是交付、处理和显示。
The delivery notification type indicates whether or not the IM has been delivered to the IM Recipient. The delivery notification type can have the following states:
传递通知类型指示IM是否已传递给IM收件人。传递通知类型可以具有以下状态：
o "delivered" to indicate successful delivery.
o “已交付”表示已成功交付。
o "failed" to indicate failure in delivery.
o “失败”表示交付失败。
o "forbidden" to indicate denial for the IM Sender to receive the requested IMDN. The IM Recipient can send the "forbidden" state, but usually it is an intermediary that sends the message, if one configures it to do so. For example, it is possible the administrator has disallowed IMDNs.
o “禁止”表示拒绝IM发送方接收请求的IMDN。IM收件人可以发送“禁止”状态，但通常是中间人发送消息，如果将其配置为这样做的话。例如，管理员可能不允许IMDNs。
o "error" to indicate an error in determining the fate of an IM.
o “错误”表示确定IM命运的错误。
The processing notification type indicates that an intermediary has processed an IM. The processing notification type can have the following states:
处理通知类型表示中介已处理IM。处理通知类型可以具有以下状态：
o "processed" to indicate that the intermediary has performed its task on the IM. This is a general state of the IM.
o “已处理”表示中介已在IM上执行其任务。这是IM的一般状态。
o "stored" to indicate that the intermediary stored the IM for later delivery.
o “存储”表示中间人存储IM以供以后交付。
o "forbidden" to indicate denial for the IM Sender to receive the requested IMDN. The "forbidden" state is sent by an intermediary that is configured to do so. For example, the administrator has disallowed IMDNs.
o “禁止”表示拒绝IM发送方接收请求的IMDN。“禁止”状态由配置为这样做的中介发送。例如，管理员不允许IMDNs。
o "error" to indicate an error in determining the fate of an IM.
o “错误”表示确定IM命运的错误。
The display notification type indicates whether or not the IM Recipient rendered the IM to the user. The display notification type can have the following states:
显示通知类型指示IM收件人是否将IM呈现给用户。显示通知类型可以具有以下状态：
o "displayed" to indicate that the IM has been rendered to the user.
o “已显示”表示IM已呈现给用户。
o "forbidden" to indicate denial, by the IM Recipient, for the IM Sender to receive the requested IMDN.
o “禁止”表示IM接收方拒绝IM发送方接收请求的IMDN。
o "error" to indicate an error in determining the fate of an IM.
o “错误”表示确定IM命运的错误。
In addition to text, some IMs may contain audio, video, and still images. Therefore, the state "displayed" includes the start of rendering the audio or video file to the user.
除文本外，某些IMs还可能包含音频、视频和静态图像。因此，“显示”状态包括开始向用户呈现音频或视频文件。
Since there is no positive acknowledgement from the user, one cannot determine if the user actually read the IM. Thus, one cannot use the protocol described here as a service to prove someone actually read the IM.
由于没有来自用户的肯定确认，因此无法确定用户是否实际读取IM。因此，不能将这里描述的协议作为服务来证明有人确实阅读了IM。
This specification extends the CPIM data format specified in RFC 3862 [RFC3862]. A new namespace is created as well as a number of new CPIM header fields.
本规范扩展了RFC 3862[RFC3862]中规定的CPIM数据格式。将创建一个新名称空间以及许多新的CPIM头字段。
Per CPIM [RFC3862], this specification defines a new namespace for the CPIM extension header fields defined in the following sections. The namespace is:
根据CPIM[RFC3862]，本规范为以下部分中定义的CPIM扩展标头字段定义了一个新的命名空间。名称空间是：
urn:ietf:params:imdn
urn:ietf:params:imdn
As per CPIM [RFC3862] requirements, the new header fields defined in the following sections are prepended, in CPIM messages, by a prefix assigned to the URN through the NS header field of the CPIM message. The remainder of this specification always assumes an NS header field like this one:
根据CPIM[RFC3862]的要求，在CPIM消息中，以下章节中定义的新标头字段由通过CPIM消息的NS标头字段分配给URN的前缀预先添加。本规范的其余部分始终假定NS标头字段如下所示：
NS: imdn <urn:ietf:params:imdn>.
NS:imdn<urn:ietf:params:imdn>。
Of course, clients are free to use any prefix while servers and intermediaries must accept any legal namespace prefix specification.
当然，客户端可以自由使用任何前缀，而服务器和中介机构必须接受任何合法的名称空间前缀规范。
The IM Sender MUST include the Disposition-Notification header field to indicate the desire to receive IMDNs from the IM Recipient for that specific IM. Section 10 defines the syntax.
IM发送方必须包含处置通知标头字段，以指示希望从IM接收方接收该特定IM的IMDN。第10节定义了语法。
The IM Sender MUST include the Message-ID header field in the IM for which he wishes to receive an IMDN. The Message-ID contains a globally unique message identifier that the IM Sender can use to correlate received IMDNs. Because the Message-ID is used by the sender to correlate IMDNs with their respective IMs, the Message-ID MUST be selected so that:
IM发送者必须在其希望接收IMDN的IM中包含消息ID标头字段。消息ID包含一个全局唯一的消息标识符，IM发送方可以使用该标识符关联收到的IMDN。由于发送方使用消息ID将IMDN与其各自的IMs关联，因此必须选择消息ID，以便：
o There is a minimal chance of any two Message-IDs accidentally colliding during the time period within which an IMDN might be received.
o 在接收IMDN的时间段内，任何两个消息ID发生意外冲突的可能性最小。
o It is prohibitive for an attacker who has seen one or more valid Message-IDs to generate additional valid Message-IDs.
o 禁止看到一个或多个有效消息ID的攻击者生成其他有效消息ID。
The first requirement is a correctness requirement to ensure correct matching by the sender. The second requirement prevents off-path attackers from forging IMDNs. In order to meet both of these requirements, it is RECOMMENDED that Message-IDs be generated using a cryptographically secure, pseudo-random number generator and contain at least 64 bits of randomness, thus reducing the chance of a successful guessing attack to n/2^64, where n is the number of outstanding valid messages.
第一个要求是确保发送方正确匹配的正确性要求。第二个要求是防止非路径攻击者伪造IMDNs。为了满足这两个要求，建议使用加密安全的伪随机数生成器生成消息ID，并至少包含64位随机性，从而将猜测攻击成功的几率降低到n/2^64，其中n是未完成的有效消息数。
When the IM Sender receives an IMDN, it can compare its value with the value of the <message-id> element present in the IMDN payload. IMDNs also carry this header field. Note that since the IMDN is itself an IM, the Message-ID of the IMDN will be different than the Message-ID of the original IM. Section 10 defines the syntax.
当IM发送方收到IMDN时，它可以将其值与IMDN有效负载中存在的<message id>元素的值进行比较。IMDNs也带有这个头字段。注意，由于IMDN本身就是一个IM，因此IMDN的消息ID将不同于原始IM的消息ID。第10节定义了语法。
An intermediary MAY insert an Original-To header field into the IM. The value of the Original-To field MUST be the address of the IM Receiver. The IM Recipient uses this header to indicate the original IM address in the IMDNs. The IM Recipient does this by populating the <original-recipient-uri> element in the IMDN. The intermediary MUST insert this header if the intermediary changes the CPIM To header field value. The header field MUST NOT appear more than once in an IM. The intermediary MUST NOT change this header field value if it is already present. Section 10 defines the syntax.
中间人可以在IM中插入原始收件人标头字段。“原始收件人”字段的值必须是IM接收器的地址。IM收件人使用此标头指示IMDNs中的原始IM地址。IM收件人通过在IMDN中填充<original Recipient uri>元素来实现这一点。如果中介将CPIM更改为标头字段值，则中介必须插入此标头。标题字段在IM中不得出现多次。如果已存在此标头字段值，则中间层不得更改此标头字段值。第10节定义了语法。
An intermediary MAY insert an IMDN-Record-Route header field to the IM. This enables the intermediary to receive and process the IMDN on its way back to the IM Sender. The value of the IMDN-Record-Route header field MUST be the address of the intermediary. Multiple IMDN-Record-Route header fields can appear in an IM. Section 10 defines the syntax.
中介可以向IM插入IMDN记录路由头字段。这使中介能够在返回IM发送方的过程中接收和处理IMDN。IMDN记录路由头字段的值必须是中介的地址。一个IM中可以出现多个IMDN记录路由头字段。第10节定义了语法。
The IMDN-Route header field provides routing information by including one or more addresses to which to route the IMDN. An intermediary that needs the IMDN to flow back through the same intermediary MUST add the IMDN-Record-Route header. When the IM Recipient creates the corresponding IMDN, the IM Recipient copies the IMDN-Record-Route headers into corresponding IMDN-Route header fields. Section 10 defines the syntax.
IMDN路由头字段通过包括一个或多个将IMDN路由到的地址来提供路由信息。需要IMDN通过同一个中介返回的中介必须添加IMDN记录路由头。当IM收件人创建相应的IMDN时，IM收件人将IMDN记录路由头复制到相应的IMDN路由头字段中。第10节定义了语法。
An IM is constructed using the CPIM message format defined in RFC 3862 [RFC3862].
IM使用RFC 3862[RFC3862]中定义的CPIM消息格式构建。
If the IM Sender requests the reception of IMDNs, the IM Sender MUST include a Message-ID header field. This header field enables the IM Sender to match any IMDNs with their corresponding IMs. See Section 6.3 for Message-ID uniqueness requirements.
如果IM发送方请求接收IMDNs，则IM发送方必须包含消息ID标头字段。此标头字段使IM发送方能够将任何IMDN与其对应的IMs进行匹配。有关消息ID唯一性要求，请参见第6.3节。
Some devices are not able to retain state over long periods. For example, mobile devices may have memory or battery limits. Such limits mean these devices may not be able to, or may choose not to, keep sent messages for the purposes of correlating IMDNs with sent IMs. To make some use of IMDN in this case, we add a time stamp to the IM to indicate when the user sent the message. The IMDN returns this time stamp to enable the user to correlate the IM with the IMDN at the human level. We use the DateTime CPIM header field for this purpose. Thus, if the IM Sender would like an IMDN, the IM Sender MUST include the DateTime CPIM header field.
有些设备无法长时间保持状态。例如，移动设备可能具有内存或电池限制。此类限制意味着这些设备可能无法或可能选择不保留发送的消息，以便将IMDNs与发送的IMs关联起来。为了在这种情况下使用IMDN，我们在IM中添加了一个时间戳，以指示用户何时发送消息。IMDN返回此时间戳，使用户能够在人员级别将IM与IMDN关联起来。为此，我们使用DateTime CPIM头字段。因此，如果IM发送者想要IMDN，IM发送者必须包含DateTime CPIM头字段。
The Disposition-Notification conveys the type of disposition notification requested by the IM Sender. There are three types of disposition notification: delivery, processing, and display. The delivery notification is further subdivided into failure and success delivery notifications. An IM Sender requests failure delivery notification by including a Disposition-Notification header field with value "negative-delivery". Similarly, a success notification is requested by including a Disposition-Notification header field with value "positive-delivery". The IM Sender can request both types of delivery notifications for the same IM.
处置通知传达IM发送方请求的处置通知类型。有三种类型的处置通知：传递、处理和显示。传递通知进一步细分为失败和成功传递通知。IM发送方通过包含值为“负传递”的处置通知标头字段来请求失败传递通知。类似地，通过包含值为“正向传递”的处置通知标头字段来请求成功通知。IM发送者可以为同一IM请求两种类型的传递通知。
The IM Sender can request a processing notification by including a Disposition-Notification header field with value "processing".
IM发送方可以通过包含值为“processing”的处置通知标头字段来请求处理通知。
The IM Sender can also request a display notification. The IM Sender MUST include a Disposition-Notification header field with the value "display" to request a display IMDN.
IM发送者也可以请求显示通知。IM发送方必须包含一个值为“display”的处置通知标题字段，以请求显示IMDN。
The absence of this header field or the presence of the header field with an empty value indicates that the IM Sender is not requesting any IMDNs. Disposition-Notification header field values are comma-separated. The IM Sender MAY request more than one type of IMDN for a single IM.
缺少此标头字段或标头字段的值为空表示IM发送方未请求任何IMDNs。处置通知标头字段值以逗号分隔。IM发送方可以为单个IM请求多种类型的IMDN。
Future extensions may define other disposition notifications not defined in this document.
未来的扩展可能会定义本文档中未定义的其他处置通知。
Section 10 describes the formal syntax for the Disposition-Notification header field. The following is an example CPIM body of an IM where the IM Sender requests positive and negative delivery notifications, but not display notification or processing notifications:
第10节描述了处置通知标题字段的正式语法。以下是IM的CPIM正文示例，其中IM发送者请求正面和负面传递通知，但不显示通知或处理通知：
From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain
Content-length: 12
From: Alice <im:alice@example.com>
To: Bob <im:bob@example.com>
NS: imdn <urn:ietf:params:imdn>
imdn.Message-ID: 34jk324j
DateTime: 2006-04-04T12:16:49-05:00
imdn.Disposition-Notification: positive-delivery, negative-delivery
Content-type: text/plain
Content-length: 12
Hello World
你好，世界
An IM Sender matches an IMDN to an IM by matching the Message-ID header field value in the IM with the <message-id> element value in the body of the IMDN. If the IM was delivered to multiple recipients, the IM Sender uses the <recipient-uri> element and the <original-recipient-uri> element in the XML body of the IMDN it received to determine if the IM was sent to multiple recipients and to identify the IM Recipient that sent the IMDN.
IM发送方通过将IM中的Message ID header字段值与IMDN正文中的<Message ID>元素值相匹配，将IMDN与IM进行匹配。如果IM已发送给多个收件人，则IM发送方使用其接收的IMDN的XML正文中的<recipient uri>元素和<original recipient uri>元素来确定IM是否已发送给多个收件人，并标识发送IMDN的IM收件人。
An IM Sender can determine an IMDN is a disposition notification by noting if the Content-Disposition in the IMDN is "notification". This does mean the IM Sender MUST understand the Content-Disposition MIME header in CPIM messages.
IM发送者可以通过注意IMDN中的内容处置是否为“通知”来确定IMDN是处置通知。这意味着IM发送者必须理解CPIM消息中的内容处置MIME头。
This specification does not mandate the IM Sender to keep state for a sent IM.
此规范不强制IM发送者保留已发送IM的状态。
Once an IM Sender sends an IM containing an IMDN request, it MAY preserve the IM context (principally the Message-ID), other user-identifiable information such as the IM subject or content, and the date and time it was sent. Without preservation of the IM context, the IM Sender will not be able to correlate the IMDN with the IM it sent. The IM Sender may find it impossible to preserve IM state if it has limited resources or does not have non-volatile memory and then loses power.
一旦IM发送方发送包含IMDN请求的IM，它可能会保留IM上下文（主要是消息ID）、其他用户可识别信息（如IM主题或内容）以及发送的日期和时间。如果不保留IM上下文，IM发送方将无法将IMDN与其发送的IM关联起来。如果IM发送方的资源有限或没有非易失性内存，则可能无法保持IM状态，然后断电。
There is, however, the concept of a "Sent Items" box in an application that stores sent IMs. This "Sent Items" box has the necessary information and may have a fancy user interface indicating the state of a sent IM. A unique Message-ID for this purpose proves to be useful. The length of time for items to remain in the "Sent Items" box is a user choice. The user is usually free to keep or delete items from the "Sent Items" box as she pleases or as the memory on the device reaches capacity.
然而，在存储发送的IMs的应用程序中存在“发送的项目”框的概念。此“已发送项目”框包含必要的信息，并且可能有一个奇特的用户界面，指示已发送IM的状态。事实证明，用于此目的的唯一消息ID非常有用。项目保留在“已发送项目”框中的时间长度由用户选择。用户通常可以随意保留或删除“已发送项目”框中的项目，或者在设备内存达到容量时。
Clearly, if an IM Sender loses its sent items state (for example, the user deletes items from the "Sent Items" box), the client may use a different display strategy in response to apparently unsolicited IMDNs.
显然，如果IM发送者丢失其已发送项目状态（例如，用户从“已发送项目”框中删除项目），客户端可能会使用不同的显示策略来响应明显未经请求的IMDN。
This specification also does not mandate an IM Sender to run any timers waiting for an IMDN. There are no time limits regarding when IMDNs may be received.
本规范也不要求IM发送方运行任何等待IMDN的计时器。关于何时可以接收IMDNs没有时间限制。
IMDNs may legitimately never be received, so the time between the sending of an IM and the generation and ultimate receipt of the IMDN may simply take a very long time. Some clients may choose to purge the state associated with the sent IM. This is the reason for adding the time stamp in the IM and having it returned in the IMDN. This gives the user some opportunity to remember what IM was sent. For example, if the IMDN indicates that the IM the user sent at 2 p.m. last Thursday was delivered, the user has a chance to remember that they sent an IM at 2 p.m. last Thursday.
IMDNs可能永远不会被合法地接收，因此从IM的发送到IMDN的生成和最终接收之间的时间可能仅仅需要很长的时间。某些客户端可能会选择清除与已发送IM关联的状态。这就是在IM中添加时间戳并在IMDN中返回时间戳的原因。这让用户有机会记住IM发送的内容。例如，如果IMDN指示用户在上周四下午2点发送的IM已送达，则用户有机会记住他们在上周四下午2点发送的IM。
An IM Sender may send an IM to multiple recipients in one Transport Protocol Message (typically using a URI-List server [RFC5365]) and request IMDNs. An IM Sender that requested IMDNs MUST be prepared to receive multiple aggregated or non-aggregated IMDNs. See Section 8.3 for details.
IM发送者可以在一个传输协议消息中向多个接收者发送IM（通常使用URI列表服务器[RFC5365]），并请求IMDNs。请求IMDNs的IM发送方必须准备好接收多个聚合或非聚合IMDNs。详见第8.3节。
IM Recipients examine the contents of the Disposition-Notification header field of the CPIM message to determine if the recipient needs to generate an IMDN for that IM. Disposition-Notification header fields of CPIM messages can include one or more values. IM Recipients may need to generate zero, one, or more IMDNs for that IM, for example, a delivery notification as well as a display notification. In this case, the IM Recipient MUST be able to construct multiple IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN per disposition type. That is, it must not generate a delivery notification indicating "delivered" followed by a delivery notification indicating "failed" for the same IM. If the IM Sender requested only failure notifications and the IM was successfully delivered, then no IMDNs will be generated. If the IM Recipient does not understand a value of the Disposition-Notification header field, the IM Recipient ignores that value.
IM收件人检查CPIM邮件的处置通知标头字段的内容，以确定收件人是否需要为该IM生成IMDN。CPIM消息的处置通知标头字段可以包括一个或多个值。IM收件人可能需要为该IM生成零个、一个或多个IMDN，例如，传递通知以及显示通知。在这种情况下，IM收件人必须能够为每个IM构造多个IMDN。IM收件人不得为每个处置类型构造多个IMDN。也就是说，它不能为同一IM生成指示“已交付”的交付通知，然后生成指示“失败”的交付通知。如果IM发送方仅请求失败通知，并且IM已成功传递，则不会生成IMDNs。如果IM收件人不理解处置通知标题字段的值，IM收件人将忽略该值。
The IM Recipient MUST NOT generate "processing" notifications.
IM收件人不得生成“处理”通知。
A Disposition-Notification header field MUST NOT appear in an IMDN since it is forbidden to request an IMDN for an IMDN. An IM Sender MUST ignore a delivery notification request in an IMDN if present. The IM Sender MUST NOT send an IMDN for an IMDN.
处置通知标头字段不得出现在IMDN中，因为禁止为IMDN请求IMDN。IM发件人必须忽略IMDN中的传递通知请求（如果存在）。IM发送方不得为IMDN发送IMDN。
An IMDN MUST contain a Message-ID header field. The same rules of uniqueness for the Message-ID header field that appears in an IM apply to an IMDN. The Message-ID header field in the IMDN is different and unrelated to the one in the IM.
IMDN必须包含消息ID标头字段。IM中出现的消息ID标头字段的唯一性规则同样适用于IMDN。IMDN中的Message ID header字段与IM中的不同且不相关。
An IM may contain an IMDN-Record-Route header field (see Section 8 for details). If IMDN-Record-Route header fields appear in the IM, the IM Recipient constructing the IMDN MUST copy the contents of the IMDN-Record-Route header fields into IMDN-Route header fields in the IMDN and maintain their order. The IMDN is then sent to the URI in the top IMDN-Route header field. IMDN-Record-Route header fields do not make sense in an IMDN and therefore MUST NOT be placed in an IMDN. IMDN Recipients MUST ignore it if present.
IM可能包含IMDN记录路由头字段（有关详细信息，请参阅第8节）。如果IMDN记录路由头字段出现在IM中，则构建IMDN的IM收件人必须将IMDN记录路由头字段的内容复制到IMDN中的IMDN路由头字段中，并保持其顺序。然后将IMDN发送到顶部IMDN路由头字段中的URI。IMDN记录路由头字段在IMDN中没有意义，因此不能放在IMDN中。IMDN收件人必须忽略它（如果存在）。
If there is no IMDN-Record-Route header field, the IM Recipient MUST send the IMDN to the URI in the From header field.
如果没有IMDN记录路由头字段，IM收件人必须将IMDN发送到From头字段中的URI。
As stated in CPIM [RFC3862], CPIM messages may need to support MIME headers other than Content-type. IM Recipients MUST insert a Content-Disposition header field set to the value "notification". This indicates to the IM Sender that the message is an IMDN to an IM it has earlier sent.
如CPIM[RFC3862]中所述，CPIM消息可能需要支持内容类型以外的MIME头。IM收件人必须插入设置为值“notification”的内容处置标题字段。这向IM发送者表明该消息是其先前发送的IM的IMDN。
The IM Recipient constructs a delivery notification in a similar fashion as an IM, using a CPIM body [RFC3862] that carries a Disposition Notification XML document formatted according to the rules specified in Section 11. The MIME type of the Disposition Notification XML document is "message/imdn+xml".
IM接收人使用CPIM正文[RFC3862]以与IM类似的方式构造传递通知，该正文包含按照第11节中指定的规则格式化的处置通知XML文档。处置通知XML文档的MIME类型为“message/imdn+XML”。
Section 10 defines the schema for an IMDN.
第10节定义了IMDN的模式。
The following is an example CPIM body of an IMDN:
以下是IMDN的CPIM主体示例：
From: Bob <im:bob@example.com> To: Alice <im:alice@example.com> NS: imdn <urn:ietf:params:imdn> imdn.Message-ID: d834jied93rf Content-type: message/imdn+xml Content-Disposition: notification Content-length: ...
发件人：Bob<im:bob@example.com>致：Alice<im:alice@example.com>NS:imdn<urn:ietf:params:imdn>imdn.Message-ID:d834jied93rf内容类型：Message/imdn+xml内容处置：通知内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
</status>
</delivery-notification>
</imdn>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
</status>
</delivery-notification>
</imdn>
The IM Recipient constructs a display notification in a similar fashion as the delivery notification. See Section 7.2.1.1 for details.
IM收件人以与传递通知类似的方式构造显示通知。详见第7.2.1.1节。
Section 10 defines the schema for an IMDN.
第10节定义了IMDN的模式。
The following is an example:
以下是一个例子：
From: Bob <im:bob@example.com> To: Alice <im:alice@example.com> NS: imdn <urn:ietf:params:imdn> imdn.Message-ID: dfjkleriou432333 Content-type: message/imdn+xml Content-Disposition: notification Content-length: ...
发件人：Bob<im:bob@example.com>致：Alice<im:alice@example.com>NS:imdn<urn:ietf:params:imdn>imdn.Message-ID:dfjkleriou432333内容类型：Message/imdn+xml内容处置：通知内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>
There are situations where the IM Recipient cannot determine if or when the IM has been displayed. The IM Recipient in this case generates a display notification with a <status> value of "error" to indicate an internal error by the server. Note that the IM Recipient may choose to ignore any IMDN requests and not send any IMDNs. An IM
在某些情况下，IM收件人无法确定IM是否或何时显示。在这种情况下，IM收件人生成一个显示通知，其<status>值为“error”，以指示服务器的内部错误。请注意，IM收件人可以选择忽略任何IMDN请求，而不发送任何IMDN。即时通讯
Recipient may not wish to let a sender know whether or not a particular message has been displayed to her. This could be a per-message, per-sender, or programmed policy choice.
收件人可能不希望让发件人知道是否向其显示了特定的邮件。这可以是每封邮件、每发件人或编程策略选择。
In this context, intermediaries are application servers (including URI-List and store-and-forward servers) and gateways. A gateway is a server that translates between different IM systems that use different protocols.
在此上下文中，中介是应用程序服务器（包括URI列表和存储转发服务器）和网关。网关是在使用不同协议的不同IM系统之间进行转换的服务器。
A URI-List server may change the IM Recipient address from its own to the address of the final recipient of that IM for every copy it makes that it sends to the list members (see [RFC5365] for details). In this case, if the IM Sender is requesting an IMDN, the intermediary SHOULD add an Original-To header field to the IM, populating it with the address that was in the CPIM To header field before it was changed. That is, the intermediary populates the Original-To header field with the intermediary address. Of course, one may configure an intermediary to restrict it from rewriting or populating the Original-To field. An intermediary MUST NOT add an Original-To header field if one already exists. An intermediary MAY have an administrative configuration to not reveal the original Request-URI, and as such, MUST NOT add an Original-To header.
URI列表服务器可以将发送给列表成员的每个副本的IM收件人地址从其自己的更改为该IM的最终收件人的地址（有关详细信息，请参阅[RFC5365]）。在这种情况下，如果IM发送者正在请求IMDN，则中间人应向IM中添加一个“原始到标头”字段，并用更改前CPIM到标头字段中的地址填充该字段。也就是说，中介用中介地址填充原始的To头字段。当然，可以配置一个中介来限制它重写或填充原始to字段。中间人不得将原始字段添加到标头字段（如果已存在）。中介可能具有不显示原始请求URI的管理配置，因此，不得将原始URI添加到头中。
An IM reply for a page-mode IM is not linked in any way to the initial IM and can end up at a different user agent from where the initial IM originated, depending on how the recipient URI gets resolved. Therefore, IM replies may traverse different intermediaries. An IMDN, on the other hand, needs to traverse the same intermediaries as the IM itself since those intermediaries may be required to report negative delivery notifications if the IM was not delivered successfully. Some of those intermediaries are, for example, store-and-forward servers that may report that an IM has been processed and later report that the IM has failed to be delivered.
页面模式IM的IM回复不会以任何方式链接到初始IM，并且最终可能会位于初始IM发源地的不同用户代理，具体取决于收件人URI的解析方式。因此，IM回复可能会穿越不同的中介机构。另一方面，IMDN需要遍历与IM本身相同的中介，因为如果IM未成功交付，这些中介可能需要报告负面交付通知。例如，其中一些中介是存储转发服务器，它们可能会报告IM已被处理，然后报告IM未能交付。
For the reasons stated above, an intermediary MAY choose to remain on the path of IMDNs for a specific IM. It can do so by adding a CPIM IMDN-Record-Route header field as the top IMDN-Record-Route header field. The value of this field MUST be the intermediary's own address. An intermediary that does not support this extension will obviously not add the IMDN-Record-Route header field. This allows IMDNs to traverse directly from the IM Recipient to the IM Sender even if the IM traversed an intermediary not supporting this extension.
出于上述原因，中介可以选择保持在特定IM的IMDNs路径上。它可以通过添加一个CPIM IMDN记录路由头字段作为顶部IMDN记录路由头字段来实现。此字段的值必须是中间人自己的地址。不支持此扩展的中介显然不会添加IMDN记录路由头字段。这允许IMDNs直接从IM接收方遍历到IM发送方，即使IM遍历的中介不支持此扩展。
An intermediary receiving an IMDN checks the top IMDN-Route header field. If that header field carries the intermediary address, the intermediary removes that value and forwards the IMDN to the address indicated in the new top IMDN-Route header field. If no additional IMDN-Route header fields are present, the IMDN is forwarded to the address in the CPIM To header field.
接收IMDN的中介机构检查顶部IMDN路由头字段。如果该头字段包含中间地址，则中间删除该值并将IMDN转发到新的顶部IMDN路由头字段中指示的地址。如果不存在其他IMDN路由标头字段，IMDN将转发到CPIM to标头字段中的地址。
An intermediary MUST remove any information about the final recipients of a list if the list membership is not disclosed. The intermediary does that by removing the <recipient-uri> element and/or <original-recipient-uri> element from the body of the IMDN before forwarding it to the IM Sender.
如果未披露名单成员身份，中介机构必须删除有关名单最终接收人的任何信息。中介体通过在将IMDN转发给IM发送方之前从IMDN主体中移除<recipient uri>元素和/或<original recipient uri>元素来实现这一点。
Intermediaries are the only entities that construct processing notifications. They do so only if the IM Sender has requested a "processing" notification by including a Disposition-Notification header field with value "processing".
中介是唯一构造处理通知的实体。只有当IM发送方通过包含值为“processing”的处置通知标头字段请求“processing”通知时，才会执行此操作。
The intermediary can create and send "processing" notifications indicating that an IM has been processed or stored. The intermediary MUST NOT send more than one IMDN for the same disposition type -- i.e., it must not send a "processing" notification indicating that an IM is being "processed" followed by another IMDN indicating that the same IM is "stored".
中介可以创建并发送“处理”通知，指示IM已被处理或存储。对于同一处置类型，中介机构不得发送多个IMDN，即，中介机构不得发送“处理”通知，指示正在“处理”某个IM，然后发送另一个IMDN，指示“存储”同一IM。
An intermediary constructs a "processing" notification in a similar fashion as the IM Recipient constructs a delivery notification. See Section 7.2.1.1 for details.
中间人构造“处理”通知的方式与IM收件人构造传递通知的方式类似。详见第7.2.1.1节。
The following is an example:
以下是一个例子：
Content-type: Message/CPIM
内容类型：消息/CPIM
From: Bob <im:bob@example.com> To: Alice <im:alice@example.com> Content-type: message/imdn+xml Content-Disposition: notification Content-length: ...
发件人：Bob<im:bob@example.com>致：Alice<im:alice@example.com>内容类型：消息/imdn+xml内容处置：通知内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<processing-notification>
<status>
<processed/>
</status>
</processing-notification>
</imdn>
<processing-notification>
<status>
<processed/>
</status>
</processing-notification>
</imdn>
There are situations where the intermediary cannot know the fate of an IM. The intermediary in this case generates a processing notification with a <status> value of "error" to indicate so.
在某些情况下，中介机构无法知道IM的命运。在这种情况下，中介体生成一个处理通知，其<status>值为“error”，以表示存在错误。
Intermediaries MAY construct negative delivery notifications. They do so only if the IM Sender has requested a "negative-delivery" notification by including a Disposition-Notification header field with value "negative-delivery" AND an error was returned for that IM.
中介机构可以构建负面传递通知。只有当IM发送方通过包含值为“负传递”的处置通知标题字段请求“负传递”通知，并且该IM返回错误时，才会执行此操作。
The intermediary can create and send "negative-delivery" notifications indicating that an IM has failed to be delivered. The intermediary MUST NOT send more than one IMDN for the same disposition type -- i.e., it must not send a "failed" notification indicating that an IM has failed followed by another IMDN indicating that an IMDN is "forbidden".
中介可以创建并发送“负面传递”通知，指示IM未能传递。对于同一处置类型，中介机构不得发送多个IMDN，也就是说，中介机构不得发送“失败”通知，指示IM已失败，然后再发送另一个IMDN，指示IMDN被“禁止”。
An intermediary constructs a "negative-delivery" notification much like the IM Recipient. See Section 7.2.1.1 for details.
中间人构造“负面传递”通知，与IM收件人非常相似。详见第7.2.1.1节。
As previously described, URI-List servers are intermediaries.
如前所述，URI列表服务器是中介。
A URI-List server may choose (using local policy) to aggregate IMDNs or it may send individual IMDNs instead. When a URI-List server receives an IM and decides to aggregate IMDNs, it can wait for a configurable period of time or until all recipients have sent the IMDN, whichever comes first, before it sends an aggregated IMDN. Note that some IMDNs, for example "displayed" notifications, may never come due to user settings. How long to wait before sending an aggregated IMDN and before a URI-List server removes state for that IM is an administrator configuration and implementation issue.
URI列表服务器可以选择（使用本地策略）聚合IMDN，也可以发送单个IMDN。当URI列表服务器收到IM并决定聚合IMDN时，它可以等待一段可配置的时间，或者等待所有收件人发送IMDN（以先到者为准），然后再发送聚合的IMDN。请注意，由于用户设置的原因，某些IMDN（例如“显示的”通知）可能永远不会出现。在发送聚合IMDN之前以及在URI列表服务器删除该IM的状态之前等待多长时间是管理员配置和实现问题。
A URI-List server MAY choose to send multiple aggregated IMDNs. A timer can be started, and when it fires, the URI-List server can aggregate whatever IMDNs it has so far for that IM, send the aggregated IMDN, and restart the timer for the next batch. This is needed for scenarios where the IM Sender has requested more than one
URI列表服务器可以选择发送多个聚合IMDN。计时器可以启动，当它启动时，URI列表服务器可以聚合到目前为止该IM的所有IMDN，发送聚合的IMDN，并为下一批重新启动计时器。对于IM发送方请求了多个IP地址的情况，需要这样做
IMDN for a specific IM -- for example, delivery notifications as well as display notifications -- or when the URI-List server is short on resources and chooses to prioritise forwarding IMs over IMDNs.
特定IM的IMDN（例如，传递通知和显示通知），或者当URI列表服务器资源不足并选择将转发IMs优先于IMDN时。
A second timer can be running, and when it fires, the state of the IM is deleted. In this case, the URI-List server consumes any IMDNs that might arrive after that time.
第二个计时器可以运行，当它启动时，IM的状态被删除。在本例中，URI列表服务器使用在此时间之后可能到达的任何IMDN。
Please note the references to timers in the above paragraphs are not normative and are only present to help describe one way one might implement aggregation.
请注意，上述段落中对计时器的引用并不规范，仅用于帮助描述实现聚合的一种方法。
A URI-List server MAY aggregate IMDNs for the case where the list membership information is not disclosed. There may be scenarios where the URI-List server starts sending aggregated IMDNs and switches to individual ones or visa versa. A timer firing often may in fact have that effect.
URI列表服务器可以针对未公开列表成员信息的情况聚合IMDNs。可能存在这样的情况：URI列表服务器开始发送聚合的IMDN并切换到单个IMDN，或者反之亦然。事实上，定时器经常触发可能会产生这种效果。
The aggregated IMDN is constructed using the multipart/mixed MIME type and including as individual payloads all the IMDNS that were received as message/imdn+xml.
聚合IMDN是使用多部分/混合MIME类型构建的，包括作为message/IMDN+xml接收的所有IMDN作为单独的有效负载。
Below is an example of aggregated IMDNs.
下面是聚合IMDNs的示例。
From: Bob <im:bob@example.com> To: Alice <im:alice@example.com> NS: imdn <urn:ietf:params:imdn> imdn.Message-ID: d834jied93rf Content-type: multipart/mixed; boundary="imdn-boundary" Content-Disposition: notification Content-length: ...
发件人：Bob<im:bob@example.com>致：Alice<im:alice@example.com>NS:imdn<urn:ietf:params:imdn>imdn.Message-ID:d834jied93rf内容类型：多部分/混合；boundary=“imdn boundary”内容处置：通知内容长度：。。。
--imdn-boundary Content-type: message/imdn+xml
--imdn边界内容类型：消息/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
</status>
</delivery-notification>
</imdn>
</status>
</delivery-notification>
</imdn>
--imdn-boundary Content-type: message/imdn+xml
--imdn边界内容类型：消息/imdn+xml
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>
--imdn-boundary
--imdn边界
Messages are typically carried in a transport protocol like SIP [RFC3261]. If the payload carried by the transport protocol does not contain any parts of type Message/CPIM, then the message is an IM. If the payload contains any parts of type Message/CPIM, and none of those parts contains a payload that is of type "message/imdn+xml", the message is an IM. It is not valid to attempt to carry both an IM and an IMDN in a multipart payload in a single transport protocol message.
消息通常在传输协议（如SIP[RFC3261]）中传输。如果传输协议携带的有效载荷不包含Message/CPIM类型的任何部分，则该消息为IM。如果有效负载包含Message/CPIM类型的任何部分，而这些部分都不包含“Message/imdn+xml”类型的有效负载，则该消息为IM。试图在单个传输协议消息中的多部分有效负载中同时携带IM和IMDN是无效的。
A message is identified as a delivery notification by examining its contents. The message is a delivery notification if the Content-type header field present has a value of "message/imdn+xml", the Content-Disposition header field has a value of "notification", and the <delivery-notification> element appears in that XML body.
通过检查邮件的内容，将邮件标识为传递通知。如果存在的内容类型标头字段的值为“message/imdn+xml”，内容处置标头字段的值为“notification”，并且<delivery notification>元素出现在该xml正文中，则该消息为传递通知。
A message is identified as a processing notification or display notification in a similar fashion as a delivery notification. The difference is that, for a processing notification, the <processing-notification> element appears in the XML body. For a display notification, the <display-notification> element appears in the XML body.
消息以与传递通知类似的方式标识为处理通知或显示通知。区别在于，对于处理通知，<processing notification>元素出现在XML正文中。对于显示通知，XML正文中会出现<display notification>元素。
The following syntax specification uses the message header field syntax as described in Section 3 of RFC 3862 [RFC3862].
以下语法规范使用RFC 3862[RFC3862]第3节所述的消息头字段语法。
Header field syntax is described without a namespace qualification. Following the rules in RFC 3862 [RFC3862], header field names and other text are case sensitive and MUST be used as given, using exactly the indicated upper-case and lower-case letters.
标题字段语法是在没有名称空间限定的情况下描述的。按照RFC 3862[RFC3862]中的规则，标题字段名称和其他文本区分大小写，必须按给定的大小写使用，并精确使用所示的大写和小写字母。
Disposition-Notification =
"Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))]
Disposition-Notification =
"Disposition-Notification" ": "
[(notify-req *(COMMA notify-req))]
notify-req =
("negative-delivery" / "positive-delivery" /
"processing" / "display" / Token) *(SEMI disp-notify-params)
notify-req =
("negative-delivery" / "positive-delivery" /
"processing" / "display" / Token) *(SEMI disp-notify-params)
disp-notify-params = Ext-param
disp-notify-params = Ext-param
Message-ID = "Message-ID" ": " Token
Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
SEMI = *SP ";" *SP ; semicolon
SEMI = *SP ";" *SP ; semicolon
COMMA = *SP "," *SP ; comma
COMMA = *SP "," *SP ; comma
An IMDN payload is an XML document [XML] that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. The IMDN payload MUST be based on XML 1.0 and MUST be encoded using UTF-8.
IMDN有效负载是一个XML文档[XML]，它必须格式良好，并且必须根据模式（包括扩展模式）有效，可供验证程序使用，并且适用于XML文档。IMDN有效负载必须基于XML 1.0，并且必须使用UTF-8进行编码。
The schema allows qualified extension elements in several positions other than the "urn:ietf:params:xml:ns:imdn" namespace. To maintain forwards compatibility (i.e., newer instance documents can be used by existing consumers), the new specifications MUST NOT extend the allowable content of this specification. The backwards compatibility
该模式允许在“urn:ietf:params:xml:ns:imdn”命名空间以外的多个位置使用限定的扩展元素。为了保持转发兼容性（即，现有使用者可以使用更新的实例文档），新规范不得扩展本规范允许的内容。向后兼容性
(i.e., existing instance documents can also be used by updated, new consumers) MAY break if there are conflicts with the existing qualified names of extension elements and possible future specifications. The IETF MAY specify new extension elements within the "sub-namespace" of "urn:ietf:params:xml:ns:" for this message/ imdn+xml MIME type.
（即，现有实例文档也可由更新的新使用者使用）如果与扩展元素的现有限定名称和未来可能的规范存在冲突，则可能会中断。IETF可以在“urn:IETF:params:xml:ns:”的“子命名空间”中为此消息/imdn+xml MIME类型指定新的扩展元素。
Possible future specifications can add new element definitions with the combine="interleave" pattern. When multiple elements of this new type are then allowed, the new definition MUST contain the <zeroOrMore> cardinality rule. If the new specification does allow only a single new element, the <optional> cardinality rule MUST be used. These cardinality requirements maintain the backwards compatibility of existing instance documents with newer consumers. Also, the new specification MUST then redefine either the "anyIMDN" extension or the individual extension points that reference it, so that new element definitions do not match with this redefined and more limited wildcard pattern.
未来可能的规范可以使用combine=“interleave”模式添加新元素定义。当允许此新类型的多个元素时，新定义必须包含<zeroOrMore>基数规则。如果新规范只允许一个新元素，则必须使用<optional>基数规则。这些基本要求维护现有实例文档与新使用者的向后兼容性。此外，新规范必须重新定义“anyIMDN”扩展或引用它的各个扩展点，以便新元素定义与重新定义的、更有限的通配符模式不匹配。
The namespace identifier for elements defined by this specification is a URN [URN], using the namespace identifier 'ietf' defined by [URN_NS] and extended by [IANA]. This urn is: urn:ietf:params:xml:ns:imdn.
本规范定义的元素的名称空间标识符为URN[URN]，使用由[URN_NS]定义并由[IANA]扩展的名称空间标识符“ietf”。这个urn是：urn:ietf:params:xml:ns:imdn。
This namespace declaration indicates the namespace on which the IMDN is based.
此命名空间声明指示IMDN所基于的命名空间。
The root element is <imdn>. The <imdn> element has sub-elements, namely <message-id>, <datetime>, <recipient-uri>, <original-recipient-uri>, <subject>, and one of <delivery-notification>, <processing-notification>, or <display-notification>. A <status> also appears as a sub-element of <delivery-notification>, <processing-notification>, and <display-notification>. The elements are described in detail in the following sections.
根元素是<imdn>。<imdn>元素具有子元素，即<message id>、<datetime>、<recipient uri>、<original recipient uri>、<subject>，以及<delivery notification>、<processing notification>或<display notification>中的一个。<status>还显示为<delivery notification>、<processing notification>和<display notification>的子元素。以下各节将详细介绍这些要素。
<imdn> can be extended in the future to include new disposition notification types or other elements, as described in Section 11.1.9.
如第11.1.9节所述，<imdn>可以在将来扩展，以包括新的处置通知类型或其他元素。
The <message-id> element is mandatory according to the XML schema and carries the message ID that appeared in the Message-ID header field of the IM.
根据XML模式，<message id>元素是必需的，它携带出现在IM消息id头字段中的消息id。
The <datetime> element is mandatory and carries the date and time the IM was sent (not the IMDN). This information is obtained from the DateTime header field of the IM.
<datetime>元素是必需的，它包含发送IM的日期和时间（而不是IMDN）。此信息从IM的DateTime标头字段中获取。
The <recipient-uri> element is optional and carries the URI of the final recipient. This information is obtained from the CPIM To header field of the IM.
<recipient uri>元素是可选的，包含最终收件人的uri。该信息从IM的CPIM To header字段中获取。
The <original-recipient-uri> element is optional and carries the URI of the original recipient. It MUST be present if the IM carried the Original-To header field. This information is obtained from the Original-To header field of the IM.
<original recipient uri>元素是可选的，它包含原始收件人的uri。如果IM携带原始至标题字段，则必须存在该字段。该信息从IM的原始To头字段中获取。
The <subject> element is optional. If present, it MUST carry the text and language attributes that were in the Subject header field, if any. This allows for a human-level correlation between an IM and an IMDN. If there are more than one Subject header fields in an IM, selecting any one of them to place in the IMDN payload <subject> element will suffice. The sender then needs to compare Subject header fields until a match or not match is determined.
<subject>元素是可选的。如果存在，它必须携带主题标题字段中的文本和语言属性（如果有）。这允许IM和IMDN之间存在人的级别关联。如果IM中有多个Subject头字段，则选择其中任何一个来放置在IMDN payload<Subject>元素中就足够了。然后，发送方需要比较主题标题字段，直到确定匹配与否。
11.1.6. The <delivery-notification>, <processing-notification>, and
<display-notification> Elements
11.1.6. The <delivery-notification>, <processing-notification>, and
<display-notification> Elements
The appearance of one of the <delivery-notification>, <processing-notification>, and <display-notification> elements is mandatory and carries the disposition type that the IM Sender requested and is being reported. It carries the sub-element <status>.
<delivery notification>、<processing notification>和<display notification>元素之一的外观是强制性的，并且带有IM发送者请求并正在报告的处置类型。它携带子元素<status>。
The <status> element is mandatory and carries the result of the disposition request. For notification type <delivery-notification>, it can carry one of the sub-elements <delivered>, <failed>, <forbidden>, or <error>. For notification type <display-notification>, it can carry one of the sub-elements <displayed>, <forbidden>, or <error>. For notification type <processing-notification>, it can carry one of the sub-elements <processed>,
<status>元素是必需的，包含处置请求的结果。对于通知类型<delivery notification>，它可以携带一个子元素<delivered>、<failed>、<forbidden>或<error>。对于通知类型<display notification>，它可以携带子元素<displayed>、<forbidden>或<error>之一。对于通知类型<processing notification>，它可以携带一个子元素<processing>，
<stored>, <forbidden>, or <error>. <forbidden> means the disposition was denied. <error> means internal server error. The <status> element can also be extended to carry any other status extension.
<stored>、<forbidden>或<error><禁止>表示处置被拒绝<错误>表示内部服务器错误。<status>元素还可以扩展以携带任何其他状态扩展。
The MIME type for the IMDN payload is "message/imdn+xml". The IMDN MUST identify the payload as MIME type "message/imdn+xml" in the Content-type header field.
IMDN负载的MIME类型为“message/IMDN+xml”。IMDN必须在内容类型头字段中将负载标识为MIME类型“message/IMDN+xml”。
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:imdn">
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
ns="urn:ietf:params:xml:ns:imdn">
<start>
<element name="imdn">
<element name="message-id">
<data type="token"/>
</element>
<element name="datetime">
<data type="string"/>
</element>
<optional>
<element name="recipient-uri">
<data type="anyURI"/>
</element>
<element name="original-recipient-uri">
<data type="anyURI"/>
</element>
<optional>
<element name="subject">
<data type="string"/>
</element>
</optional>
</optional>
<choice>
<ref name="deliveryNotification"/>
<ref name="displayNotification"/>
<ref name="processingNotification"/>
<empty/>
</choice>
<ref name="imdnExtension"/>
</element>
<start>
<element name="imdn">
<element name="message-id">
<data type="token"/>
</element>
<element name="datetime">
<data type="string"/>
</element>
<optional>
<element name="recipient-uri">
<data type="anyURI"/>
</element>
<element name="original-recipient-uri">
<data type="anyURI"/>
</element>
<optional>
<element name="subject">
<data type="string"/>
</element>
</optional>
</optional>
<choice>
<ref name="deliveryNotification"/>
<ref name="displayNotification"/>
<ref name="processingNotification"/>
<empty/>
</choice>
<ref name="imdnExtension"/>
</element>
</start>
</start>
<define name="deliveryNotification">
<element name="delivery-notification">
<element name="status">
<choice>
<element name="delivered">
<empty/>
</element>
<element name="failed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="deliveryExtension"/>
</element>
</element>
</define>
<define name="deliveryNotification">
<element name="delivery-notification">
<element name="status">
<choice>
<element name="delivered">
<empty/>
</element>
<element name="failed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="deliveryExtension"/>
</element>
</element>
</define>
<define name="displayNotification">
<element name="display-notification">
<element name="status">
<choice>
<element name="displayed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="displayExtension"/>
</element>
</element>
</define>
<define name="displayNotification">
<element name="display-notification">
<element name="status">
<choice>
<element name="displayed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="displayExtension"/>
</element>
</element>
</define>
<define name="processingNotification">
<element name="processing-notification">
<element name="status">
<choice>
<element name="processed">
<empty/>
</element>
<element name="stored">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="processingExtension"/>
</element>
</element>
<define name="processingNotification">
<element name="processing-notification">
<element name="status">
<choice>
<element name="processed">
<empty/>
</element>
<element name="stored">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="processingExtension"/>
</element>
</element>
</define>
</define>
<define name="commonDispositionStatus">
<choice>
<element name="forbidden">
<empty/>
</element>
<element name="error">
<empty/>
</element>
</choice>
</define>
<define name="commonDispositionStatus">
<choice>
<element name="forbidden">
<empty/>
</element>
<element name="error">
<empty/>
</element>
</choice>
</define>
<!-- <imdn> extension point for the extension schemas to add
new definitions with the combine="interleave" pattern.
Extension schemas should add proper cardinalities. For
example, the <zeroOrMore> cardinality should be used if
the extension is to allow multiple elements, and the
<optional> cardinality should be used if the extension
is to allow a single optional element. -->
<!-- <imdn> extension point for the extension schemas to add
new definitions with the combine="interleave" pattern.
Extension schemas should add proper cardinalities. For
example, the <zeroOrMore> cardinality should be used if
the extension is to allow multiple elements, and the
<optional> cardinality should be used if the extension
is to allow a single optional element. -->
<define name="imdnExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<define name="imdnExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- delivery-notification <status> extension point -->
<define name="deliveryExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- delivery-notification <status> extension point -->
<define name="deliveryExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- display-notification <status> extension point -->
<define name="displayExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- display-notification <status> extension point -->
<define name="displayExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- processing-notification <status> extension point -->
<define name="processingExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- processing-notification <status> extension point -->
<define name="processingExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- wildcard definition for complex elements (of mixed type)
unqualified or qualified in the imdn namespace.
Extension schemas MUST redefine this or the
individual, previous definitions that use this definition.
In other words, the extension schema MUST reduce the
allowable content in order to maintain deterministic
and unambiguous schemas with the interleave pattern. -->
<define name="anyIMDN">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:imdn"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="anyExtension"/>
</element>
</define>
<!-- wildcard definition for complex elements (of mixed type)
unqualified or qualified in the imdn namespace.
Extension schemas MUST redefine this or the
individual, previous definitions that use this definition.
In other words, the extension schema MUST reduce the
allowable content in order to maintain deterministic
and unambiguous schemas with the interleave pattern. -->
<define name="anyIMDN">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:imdn"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="anyExtension"/>
</element>
</define>
<!-- the rest of the "anyIMDN" wildcard definition -->
<define name="anyExtension">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="any"/>
</choice>
</zeroOrMore>
</define>
<!-- the rest of the "anyIMDN" wildcard definition -->
<define name="anyExtension">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="any"/>
</choice>
</zeroOrMore>
</define>
<!-- wildcard type for complex elements (of mixed type)
without any namespace or content restrictions -->
<define name="any">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="any"/>
</choice>
</zeroOrMore>
<!-- wildcard type for complex elements (of mixed type)
without any namespace or content restrictions -->
<define name="any">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="any"/>
</choice>
</zeroOrMore>
</element>
</define>
</element>
</define>
</grammar>
</grammar>
The IM Sender constructs a SIP MESSAGE request using RFC 3428 [RFC3428]. The Content-type header field indicates the MIME type of the request payload. When using this extension, the Content-type header field MUST be of MIME type "message/cpim" [RFC3862] for both IMs and IMDNs. The IM Sender constructs the payload according to Section 7.
IM发送方使用RFC 3428[RFC3428]构造SIP消息请求。Content type标头字段指示请求负载的MIME类型。使用此扩展时，IMs和IMDNs的内容类型标头字段必须为MIME类型“message/cpim”[RFC3862]。IM发送器根据第7节构造有效负载。
The IM Sender constructs a SIP MESSAGE request to multiple recipients in a similar manner as a SIP MESSAGE request to a single recipient. "Multiple-Recipient MESSAGE Requests in SIP" [RFC5365] describes the differences.
IM发送方以与对单个接收者的SIP消息请求类似的方式构造对多个接收者的SIP消息请求。“SIP中的多个收件人消息请求”[RFC5365]描述了这些差异。
IM Senders can remain anonymous. For example, the sender can set the SIP From header field of the SIP message to an anonymous URI. As there is no return address, anonymous IM Senders SHOULD NOT request disposition notifications. An IM Recipient MAY ignore such a request if the IM Sender is anonymous.
IM发送者可以保持匿名。例如，发送方可以将SIP消息的SIP From头字段设置为匿名URI。由于没有返回地址，匿名IM发件人不应请求处置通知。如果IM发送者是匿名的，IM接收者可以忽略这样的请求。
An endpoint receiving a SIP MESSAGE request constructs a SIP response according to RFC 3428 [RFC3428]. Of course, an endpoint will send a SIP response to the MESSAGE request regardless of the type of message (IM or IMDN) it has received or the disposition type for which it has been asked.
接收SIP消息请求的端点根据RFC 3428[RFC3428]构造SIP响应。当然，端点将向消息请求发送SIP响应，而不管它接收到的消息类型（IM或IMDN）或请求的处置类型。
A SIP MESSAGE request is identified as an IM by examining its contents according to Section 9.
通过根据第9节检查SIP消息请求的内容，将其标识为IM。
If an IM Recipient received a SIP MESSAGE request that is an IM requesting a positive-delivery notification, and that IM Recipient has constructed and sent a SIP 2xx class response, it MAY generate a positive-delivery notification after making sure that the IM has been
如果IM接收方接收到SIP消息请求，该请求是请求正向传递通知的IM，并且该IM接收方已构建并发送SIP 2xx类响应，则在确保IM已被发送后，它可能会生成正向传递通知
delivered to the user or application. A gateway, for example, can generate a 2xx response before the final recipient received the IM. The IM Recipient constructs a positive-delivery notification according to Section 7.2.1.1. The IM Recipient places the message as the payload in a SIP MESSAGE request.
交付给用户或应用程序。例如，网关可以在最终收件人收到IM之前生成2xx响应。IM接收人根据第7.2.1.1节构建积极的交付通知。IM接收方将消息作为有效负载放入SIP消息请求中。
If an IM Recipient received a SIP MESSAGE request that is an IM requesting a negative-delivery, and that IM Recipient has constructed and sent a 2xx class response, it SHOULD generate a negative-delivery notification if it learnt that the final recipient or application did not receive the IM (a gateway, for example, can generate a 2xx response before it has an error response from downstream or before any internal timers fire waiting for a response). The negative-delivery notification is constructed according to Section 7.2.1.1. The message is then placed as the payload in a SIP MESSAGE request.
如果IM接收方接收到SIP消息请求，该请求是请求负面传递的IM，并且该IM接收方已经构建并发送了2xx类响应，则如果它得知最终接收方或应用程序没有接收到该IM，则应生成负面传递通知（例如，网关可以在收到下游的错误响应之前或在任何内部计时器触发等待响应之前生成2xx响应）。负面传递通知根据第7.2.1.1节进行构造。然后将消息作为有效负载放置在SIP消息请求中。
If an IM Recipient received a SIP MESSAGE request that is an IM requesting a negative-delivery notification, and the IM Recipient has constructed and sent a non-2xx final response, it MUST NOT generate a negative-delivery notification.
如果IM收件人收到SIP消息请求，该请求是请求负面传递通知的IM，并且IM收件人已构建并发送非2xx最终响应，则不得生成负面传递通知。
If an IM Recipient received a SIP MESSAGE request that is an IM requesting a display notification, and that IM Recipient has constructed and sent a SIP 2xx class response, it MAY generate a display notification after making sure that the IM has been presented to the user or application. It is outside the scope of this document to discuss how a determination can be made whether the IM has been read. Note that the decision whether or not to send a display notification can be left to the user. An application may allow a user to configure such a choice. The IM Recipient constructs the display notification according to Section 7.2.1.2. The IM Recipient places the message as the payload in a SIP MESSAGE request.
如果IM接收者接收到作为IM请求显示通知的SIP消息请求，并且该IM接收者已构造并发送SIP 2xx类响应，则其可在确保IM已呈现给用户或应用程序之后生成显示通知。讨论如何确定是否已阅读IM不在本文件范围内。请注意，是否发送显示通知的决定可以留给用户。应用程序可以允许用户配置这样的选择。IM收件人根据第7.2.1.2节构造显示通知。IM接收方将消息作为有效负载放入SIP消息请求中。
For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP To header field using the address that appeared in the SIP From header field in the IM.
对于IMDNs，IM接收方使用IM中SIP From头字段中出现的地址填充SIP请求URI和SIP To头字段。
A SIP MESSAGE request is identified as a delivery notification by examining its contents according to Section 9.
通过根据第9节检查SIP消息请求的内容，将SIP消息请求标识为传递通知。
A SIP MESSAGE request is identified as a display notification by examining its contents according to Section 9.
通过根据第9节检查SIP消息请求的内容，将其标识为显示通知。
In this context, intermediaries include application servers (including URI-List and store-and-forward servers) and gateways. SIP Proxies MUST NOT generate IMDNs but MUST forward them like any other SIP request.
在此上下文中，中介包括应用程序服务器（包括URI列表和存储转发服务器）和网关。SIP代理不能生成IMDN，但必须像任何其他SIP请求一样转发IMDN。
Intermediaries forward a SIP MESSAGE request to multiple recipients according to [RFC5365].
中介机构根据[RFC5365]向多个收件人转发SIP消息请求。
If an intermediary receives an IM, the intermediary examines the body. If the body is of type "message/cpim", the intermediary then looks for a Disposition-Notification CPIM header field in the message. If the Disposition-Notification CPIM header field has either the value "positive-delivery" or "negative-delivery", and, in processing the IM, the intermediary generates a SIP 2xx class response to the MESSAGE request, then the intermediary performs the following actions.
如果中间人收到IM，中间人将检查身体。如果正文类型为“message/cpim”，则中介体将在消息中查找处置通知cpim头字段。如果处置通知CPIM标头字段的值为“正向传递”或“反向传递”，并且在处理IM时，中介体生成对消息请求的SIP 2xx类响应，则中介体执行以下操作。
If the Disposition-Notification header field contains a value of "positive-delivery", the intermediary MUST NOT generate a delivery notification if it receives a SIP 2xx class response for the sent IM. Just because a downstream entity received a MESSAGE request does not mean the message was relayed to its ultimate destination or was delivered. Thus, the intermediary cannot say delivery occurred just because it received a 2xx response.
如果处置通知标头字段包含“正向传递”的值，则如果中介接收到发送IM的SIP 2xx类响应，则不得生成传递通知。下游实体接收到消息请求并不意味着消息被中继到其最终目的地或已交付。因此，中介机构不能仅仅因为收到2xx响应就说发生了交付。
If the Disposition-Notification header field contains a value of "negative-delivery", the intermediary SHOULD generate a delivery notification if it receives a SIP 4xx, 5xx, or 6xx class final response for the sent IM. If it has received a SIP 2xx class response followed by a negative-delivery notification, the intermediary forwards that negative-delivery notification or aggregates it.
如果处置通知标头字段包含“负面传递”值，则如果中介接收到发送IM的SIP 4xx、5xx或6xx类最终响应，则应生成传递通知。如果中介接收到SIP 2xx类响应，随后是否定传递通知，则中介将转发或聚合该否定传递通知。
If the Disposition-Notification header field contains a value of "processing", the intermediary MAY generate a processing notification after it has forwarded or stored the IM. The rest of the procedures in Section 8.1 apply.
如果处置通知标题字段包含“处理”值，则中介可以在转发或存储IM后生成处理通知。第8.1节中的其余程序适用。
The procedure for generating such an IMDN is the same as that of an IM Recipient (Section 7.2.1.1).
生成此类IMDN的程序与IM收件人的程序相同（第7.2.1.1节）。
The <recipient-uri> element of the XML body is populated with the URI of the IM Recipient.
XML正文的<recipient uri>元素由IM收件人的uri填充。
If an intermediary receives a SIP MESSAGE request carrying a positive delivery notification or a display notification, it forwards it using the rules in Section 8.
如果中介接收到携带肯定传递通知或显示通知的SIP消息请求，则使用第8节中的规则将其转发。
The Message Session Relay Protocol (MSRP) [RFC4975] already provides a built-in mechanism to supply positive and negative delivery reports. These reports do not provide built-in display or processing notifications. However, these notifications in session-mode are not as useful as they are for page-mode. This is because the base use case for MSRP is that the recipient user agent immediately renders SEND requests sequentially, providing the session experience. This is unlike page-mode requests where a user has to actively initiate the display of the message. That is, they need to click on a button, open a message, and so on to read the message.
消息会话中继协议（MSRP）[RFC4975]已经提供了一种内置机制来提供正面和负面的传递报告。这些报告不提供内置的显示或处理通知。但是，会话模式下的这些通知不如页面模式下的通知有用。这是因为MSRP的基本用例是接收方用户代理立即按顺序呈现发送请求，从而提供会话体验。这与页面模式请求不同，在页面模式请求中，用户必须主动启动消息的显示。也就是说，他们需要点击一个按钮，打开一条消息，等等来阅读消息。
If new requirements arise in the future determining the need for IMDN in MSRP, new specifications can be drafted.
如果将来出现新的要求，确定MSRP中是否需要IMDN，则可以起草新的规范。
IMDNs provide a fine-grained view of the activity of the IM Recipient, and thus deserve particularly careful confidentiality protection so that only the intended recipient of the IMDN will receive the IMDN. In most cases, the intended recipient of the IMDN is the IM Sender.
IMDNs提供了IM接收者活动的细粒度视图，因此需要特别小心的保密保护，以便只有IMDN的预期接收者才会接收IMDN。在大多数情况下，IMDN的预期接收者是IM发送者。
Since the IM transport protocol carries the IMDN, all security considerations of the underlying IM protocol also apply to the IMDNs.
由于IM传输协议携带IMDN，基础IM协议的所有安全注意事项也适用于IMDN。
The threats in the IMDN system, over and beyond the threats inherent to IM, include the following:
除了IM固有的威胁外，IMDN系统中的威胁还包括：
o A malicious endpoint attempts to send messages to a user that would normally not wish to receive messages from that endpoint by convincing the IMDN system to "bounce" an IMDN from an unsuspecting endpoint to the user.
o 恶意端点试图通过说服IMDN系统将IMDN从不知情的端点“反弹”到用户，向通常不希望从该端点接收消息的用户发送消息。
o A malicious endpoint attempts to flood an IM Sender with IMDNs by convincing a URI-List server to send IMDNs to an unsuspecting IM Sender.
o 恶意端点试图通过说服URI列表服务器将IMDNs发送给不知情的IM发送者，从而向IM发送者发送IMDNs。
o A malicious intermediary or node attempts to flood a target node with IMDNs by inserting the target's address in the From field or IMDN-Record-Route field.
o 恶意中介或节点通过在“发件人”字段或“IMDN记录路由”字段中插入目标地址，试图向目标节点发送IMDN。
o A malicious node in the network attempts to modify an IMDN from an IM Recipient.
o 网络中的恶意节点试图修改来自IM收件人的IMDN。
o A malicious intermediary attempts to forward an IMDN from an IM Recipient to the IM Sender, where the IM Recipient would not normally forward the IMDN to that IM Sender if the IM Recipient knew the identity of the IM Sender.
o 恶意中介试图将IMDN从IM收件人转发给IM发件人，如果IM收件人知道IM发件人的身份，IM收件人通常不会将IMDN转发给该IM发件人。
o A malicious endpoint attempts to discover the Request-URI of an endpoint beyond an intermediary, where the endpoint would normally wish to keep its identity private from the malicious endpoint.
o 恶意端点尝试在中间层之外发现端点的请求URI，而在中间层中，端点通常希望保持其身份对恶意端点是私有的。
o A malicious node in the network attempts to eavesdrop on IMDN traffic to, for example, learn Request-URI or traffic pattern information.
o 网络中的恶意节点试图窃听IMDN流量，以获取请求URI或流量模式信息。
o A malicious node in the network attempts to stage a denial-of-service attack on an intermediary by requesting a large list expansion.
o 网络中的恶意节点试图通过请求大列表扩展对中间层发起拒绝服务攻击。
The protocol cannot protect against attacks that include the following:
该协议无法抵御包括以下内容的攻击：
o A malicious intermediary directly revealing the identity of a downstream endpoint that would not normally wish its identity revealed. Keeping such information private is an intermediary implementation issue.
o 一种恶意中介，直接泄露通常不希望泄露其身份的下游端点的身份。将此类信息保密是一个中间实施问题。
o A malicious IM Recipient alters the time of the IMDN. There is no protocol mechanism for ensuring that the IM Recipient does not lie about the time or purposely holds an IMDN for transmission to make it appear that the IM displayed to the user was read later than it actually was.
o 恶意IM收件人更改IMDN的时间。没有任何协议机制可确保IM接收者不会谎报时间或故意持有IMDN进行传输，以使显示给用户的IM看起来比实际读取晚。
o A deletion attack on an IMDN. This is a trade-off between privacy and security. The privacy considerations allow the IM Recipient to silently ignore an IMDN request. Any mechanism that would reliably indicate that a malicious node deleted an IM Recipient's IMDN would also serve the purpose of detecting an IM Recipient that chose not to issue an IMDN.
o 对IMDN的删除攻击。这是隐私和安全之间的权衡。隐私考虑允许IM收件人以静默方式忽略IMDN请求。任何能够可靠地表明恶意节点删除了IM收件人的IMDN的机制也可以用于检测选择不发布IMDN的IM收件人。
To combat eavesdropping, modification, and man-in-the-middle attacks, we require some level of authentication and integrity protections. That said, there are circumstances where strong integrity would be overkill. The presumption is that the IM Sender has, and sets the expectation for, the level of protection. The procedures for integrity protection are as follows.
为了打击窃听、修改和中间人攻击，我们需要一定程度的身份验证和完整性保护。这就是说，在某些情况下，强大的诚信是过火的。假定IM发送者拥有并设定了保护级别的期望。完整性保护程序如下所示。
o If the IM Recipient has a certificate, it MUST sign the IMDN. Signing the IMDN provides integrity protection. While an intermediary can replace the IMDN body, the IM Sender (the recipient of the IMDN) can validate the signature and note the IMDN does not come directly from the IM Receiver. This is not a problem if the IM Sender trusts the intermediary. Likewise, an IMDN in response to a signed IM without a signature indicates something bad might have happened.
o 如果IM收件人具有证书，则必须对IMDN进行签名。对IMDN进行签名可提供完整性保护。中间人可以替换IMDN主体，IM发送者（IMDN的接收者）可以验证签名，并注意IMDN不是直接来自IM接收者。如果IM发送者信任中间人，则这不是问题。类似地，响应没有签名的已签名IM的IMDN表示可能发生了不好的事情。
o If the IM is encrypted, the IM Recipient or intermediary MUST encrypt the IMDN body, as an attacker may attempt to discern the user's activity profile and identity from sniffing IMDNs on the network.
o 如果IM已加密，则IM收件人或中间人必须加密IMDN正文，因为攻击者可能试图通过在网络上嗅探IMDN来识别用户的活动配置文件和身份。
o The two above rules are cumulative.
o 以上两条规则是累积的。
The IM Recipient or intermediary MUST be capable of accessing the IM Sender's public certificate in order to verify the signature in the IM.
IM收件人或中间人必须能够访问IM发件人的公共证书，以便验证IM中的签名。
CPIM security considerations [RFC3862] apply here, as this is an extension of CPIM. In order to make the IMDN mechanism independent of the transport protocol, the Working Group made the design choice of putting routing information into the IMDN application-layer payload. One consequence of this choice is it eliminates the possibility of having end-to-end encryption.
CPIM安全注意事项[RFC3862]适用于此处，因为这是CPIM的扩展。为了使IMDN机制独立于传输协议，工作组做出了将路由信息放入IMDN应用层有效负载的设计选择。这种选择的一个结果是消除了端到端加密的可能性。
An attacker can mount a distributed denial-of-service attack on a node by sending lots of IMs to the node with IMDN requests. Note that this is the same problem as there is without IMDN; IMDN simply linearly increases the load on the node under attack. One can mitigate, but not eliminate, this threat by the endpoint immediately ignoring requests that are not authenticated.
攻击者可以通过向具有IMDN请求的节点发送大量IMs，在节点上发起分布式拒绝服务攻击。请注意，这与没有IMDN时的问题相同；IMDN只会线性增加受攻击节点上的负载。通过端点立即忽略未经身份验证的请求，可以减轻但不能消除这种威胁。
One way to address the potential for a malicious node to use the IMDN system to anonymize attacks is to log all IMDN requests on the IM Recipient user agent. This allows for tracking of attacks, if only after they occur. Note this also puts a burden on the IM Recipient user agent host. Limited user agents may not be able to preserve much of a log.
解决恶意节点使用IMDN系统匿名攻击的可能性的一种方法是在IM接收方用户代理上记录所有IMDN请求。这允许跟踪攻击，如果只是在攻击发生之后。注意，这也给IM收件人用户代理主机带来了负担。有限的用户代理可能无法保留大部分日志。
Likewise, an attacker can mount a denial-of-service attack on an intermediary by asking the intermediary to explode a large list.
类似地，攻击者可以通过请求中介爆开一个大列表，在中介上发起拒绝服务攻击。
The following security considerations apply when using IMDNs.
使用IMDNs时，以下安全注意事项适用。
IMs can be forged. To protect against that, an IM can be signed. An intermediary that receives a signed message and needs to modify any part of it that is included in the signature (like adding an Original-To header field to the CPIM header fields) MUST consume the IM and create a new copy of it that the intermediary signs itself.
IMs可以伪造。为了防止这种情况，可以签署IM。接收已签名消息并需要修改签名中包含的消息的任何部分（如向CPIM头字段添加原始到头字段）的中间层必须使用IM并创建中间层自己签名的新副本。
IMDNs may be forged as easily as ordinary IMs. Endpoints and intermediaries that wish to make automatic use of IMDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged IMDNs include the sending of a falsified IMDN when the indicated disposition of the IM has not actually occurred. For example, display notification could be forged to indicate that an IM has been displayed to the Recipient. Unsolicited IMDNs is also another form of forgery.
IMDNs可以像普通IMs一样容易伪造。希望自动使用IMDNs的端点和中介应采取适当的预防措施，以最大限度地减少拒绝服务攻击造成的潜在损害。与伪造的IMDN相关的安全威胁包括在指定的IM处置未实际发生时发送伪造的IMDN。例如，可以伪造显示通知，以表明已向收件人显示IM。未经请求的IMDNs也是另一种伪造形式。
There may be cases where an IM Recipient does not wish to reveal that she has received, or in fact read, the IM. In this situation, it is acceptable for the IM Recipient to silently ignore requests for an IMDN. It is strongly RECOMMENDED that the IM Recipient obtain the user's consent before sending an IMDN. Circumstances where the IM Recipient does not ask for the user's consent include IM systems that, for regulatory reasons, are required to issue an IMDN, such as in the health care field or financial community.
在某些情况下，即时通讯接收者不希望透露她已收到或实际上已阅读即时通讯。在这种情况下，IM收件人可以默默地忽略对IMDN的请求。强烈建议IM收件人在发送IMDN之前获得用户的同意。IM接收方未征求用户同意的情况包括出于监管原因需要发布IMDN的IM系统，如医疗领域或金融界。
An IM Recipient can obtain such consent by a prompt or dialog box on a per-IM basis, globally through the user's setting of a preference, or another, user-configurable mechanism. The user might also indicate globally that IMDNs are never to be sent or that a "forbidden" IMDN status is always sent in response to a request for an IMDN.
即时消息接收者可以通过提示或对话框，在每个即时消息的基础上，通过用户的首选项设置或其他用户可配置机制全局地获得此类同意。用户还可以全局指示永远不会发送IMDN，或者始终发送“禁止”IMDN状态以响应IMDN请求。
There are situations where a user sends an IM and requests IMDNs to a list whose member information is not disclosed. In this situation, the user will learn of the list members. Therefore, in this case, the URI-List server MUST remove any information about list members. If the number of members in the list is also not disclosed, the URI-List server MUST only deliver one aggregated IMDN. Alternatively, the URI-list server MAY reject the IM.
在某些情况下，用户发送IM并向其成员信息未被披露的列表请求IMDNs。在这种情况下，用户将了解列表成员。因此，在这种情况下，URI列表服务器必须删除关于列表成员的任何信息。如果列表中的成员数量也未披露，则URI列表服务器必须仅提供一个聚合IMDN。或者，URI列表服务器可以拒绝IM。
It is possible for a list server to not understand IMDN. IM Recipients may note the To header field is a list name and not the IM Recipient's name. In this case, the IM Recipient can take the appropriate action if it wishes to keep its identity private.
列表服务器可能不理解IMDN。IM收件人可能会注意到“收件人”标题字段是列表名，而不是IM收件人的名称。在这种情况下，如果IM收件人希望保持其身份的私密性，则可以采取适当的措施。
An unencrypted IMDN could reveal confidential information about an encrypted IM. The same level of security applied to an IM MUST be applied to its IMDNs. For example, if an IM is signed and encrypted, the IMDN must be signed and encrypted.
未加密的IMDN可能会泄露加密IM的机密信息。应用于IM的相同安全级别必须应用于其IMDNs。例如，如果IM经过签名和加密，则必须对IMDN进行签名和加密。
IMDNs cannot be relied on as a guarantee that an IM was or was not seen by the user. Even if IMDNs are not actively forged, they may be lost in transit. Moreover, the IM Recipient may bypass the IMDN issuing mechanism through policy or manipulation of their user agent Server.
IMDNs不能作为用户看到或不看到IM的保证。即使IMDNs不是主动伪造的，它们也可能在传输过程中丢失。此外，IM接收方可以通过策略或操纵其用户代理服务器绕过IMDN发布机制。
This document registers a new MIME type "message/imdn+xml", and registers a new XML namespace.
本文档注册了一个新的MIME类型“message/imdn+xml”，并注册了一个新的xml名称空间。
This specification follows the guidelines of RFC 3023 [RFC3023].
本规范遵循RFC 3023[RFC3023]的指南。
MIME media type: message
MIME媒体类型：消息
MIME subtype name: imdn+xml
MIME子类型名称：imdn+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023].
可选参数：与RFC 3023[RFC3023]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
编码注意事项：与RFC 3023[RFC3023]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 14 of this document.
安全注意事项：参见RFC 3023[RFC3023]第10节和本文件第14节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: This document
已发布规范：本文件
Applications which use this media type: This media type is used to support CPIM-based instant Messaging.
使用此媒体类型的应用程序：此媒体类型用于支持基于CPIM的即时消息。
Additional information: none
其他信息：无
Magic number: none
神奇数字：无
File extension: .cl or .xml
文件扩展名：.cl或.xml
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Hisham Khartabil (hisham.khartabil@gmail.com)
更多信息的个人和电子邮件地址：Hisham Khartabil（Hisham。khartabil@gmail.com)
Intended Usage: COMMON
预期用途：普通
Author/change controller: The IETF
作者/变更控制者：IETF
This section registers a new XML namespace and schema, as per guidelines in the IETF XML Registry [IANA].
本节根据IETF XML注册表[IANA]中的指南注册一个新的XML名称空间和模式。
URI: urn:ietf:params:xml:ns:imdn
URI: urn:ietf:params:xml:ns:imdn
XML: The schema for this namespace is in Section 11.1.9 above.
XML：该名称空间的模式见上文第11.1.9节。
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@gmail.com)
注册人联系人：IETF，简单工作组，Hisham Khartabil（Hisham。khartabil@gmail.com)
Per [RFC3553], please establish the following registry. New entries to the registry are Specification Required.
根据[RFC3553]，请建立以下注册表。需要注册表中的新条目。
Registry name: urn:ietf:params:imdn
Registry name: urn:ietf:params:imdn
Specification: RFC 5438. Additional values may be defined by a Standards Action [RFC5226] that updates or obsoletes RFC 5438.
规格：RFC 5438。附加值可由更新或淘汰RFC 5438的标准行动[RFC5226]定义。
Repository: RFC 5438
储存库：RFC 5438
Index value: Values subordinate to urn:ietf:params:imdn require RFC publication. The index value is the IMDN header name. The index value must follow the rules for a legal IMDN header name. In particular, the IMDN header name, and thus the index value to register, must be a string of octets taken from the restricted set of US-ASCII characters per Section 3.1 of [RFC3553]. The index value is case sensitive.
索引值：从属于urn:ietf:params:imdn的值需要RFC发布。索引值是IMDN头名称。索引值必须遵循合法IMDN头名称的规则。特别是，IMDN头名称，以及要注册的索引值，必须是根据[RFC3553]第3.1节从限制的US-ASCII字符集中提取的八位字节字符串。索引值区分大小写。
URN Formation: The URI for a header is formed from its name by
URN Formation：标头的URI由其名称通过
a) replacing any non-URN characters (as defined by RFC 2141 [URN]) with the corresponding '%hh' escape sequence (per RFC 3986 [RFC3986]) and
a) 将任何非URN字符（由RFC 2141[URN]定义）替换为相应的“%hh”转义序列（根据RFC 3986[RFC3986]），以及
b) prepending the resulting string with 'urn:ietf:params:imdn:'.
b) 在结果字符串前面加上“urn:ietf:params:imdn:”。
Thus, the URI corresponding to the CPIM message IMDN header 'Disposition-Notification:' would be 'urn:ietf:params:imdn:Disposition-Notification'.
因此，与CPIM消息IMDN头“Disposition Notification:”对应的URI将是“urn:ietf:params:IMDN:Disposition Notification”。
Initial values:
初始值：
+--------------------------+---------------------+
| Index Value | Reference |
+--------------------------+---------------------+
| Disposition-Notification | RFC5438 Section 6.2 |
| Message-ID | RFC5438 Section 6.3 |
| Original-To | RFC5438 Section 6.4 |
| IMDN-Record-Route | RFC5438 Section 6.5 |
| IMDN-Route | RFC5438 Section 6.6 |
+--------------------------+---------------------+
+--------------------------+---------------------+
| Index Value | Reference |
+--------------------------+---------------------+
| Disposition-Notification | RFC5438 Section 6.2 |
| Message-ID | RFC5438 Section 6.3 |
| Original-To | RFC5438 Section 6.4 |
| IMDN-Record-Route | RFC5438 Section 6.5 |
| IMDN-Route | RFC5438 Section 6.6 |
+--------------------------+---------------------+
This document registers one new Content-Disposition header field "disposition-types": notification, which has been recorded in the IANA registry for Mail Content Dispositions.
本文档注册了一个新的内容处置标题字段“处置类型”：通知，该字段已记录在IANA邮件内容处置注册表中。
Descriptions of this "disposition-types", including motivation and examples, are given in Section 7.2.1.1 and Section 9.
第7.2.1.1节和第9节给出了这种“处置类型”的描述，包括动机和示例。
Short descriptions suitable for the IANA registry are:
适用于IANA注册中心的简短说明如下：
notification: the payload of the message carrying this Content-Disposition header field value is an Instant Message Disposition Notification as requested in the corresponding Instant Message.
通知：携带此内容处置头字段值的消息的有效负载是相应即时消息中请求的即时消息处置通知。
Special thanks to Jari Urpalainen for the thorough review and suggestions for the RelaxNG schema.
特别感谢Jari Urpalainen对RelaxNG模式的全面审查和建议。
The authors would also like to thank Paul Kyzivat, Ben Campbell, Adam Roach, Gonzalo Camarillo, Frank Ellermann, Sean Olson, Eva Leppanen, Miguel Garcia, Eric McMurry, Jon Peterson, and Robert Sparks for their comments and support. In addition, we would like to thank the Gen-Art reviewer extraordinaire, Spencer Dawkins.
作者还要感谢Paul Kyzivat、Ben Campbell、Adam Roach、Gonzalo Camarillo、Frank Ellermann、Sean Olson、Eva Leppanen、Miguel Garcia、Eric McMurry、Jon Peterson和Robert Sparks的评论和支持。此外，我们还要感谢杰出的艺术评论家斯宾塞·道金斯。
[IANA] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[IANA]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3862]Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，2004年8月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[瓮]护城河，右，“瓮语法”，RFC 21411997年5月。
[XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, October 2000.
[XML]Bray，T.，“可扩展标记语言（XML）1.0（第二版）”，W3C CR-xml11-20011006，2000年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，2003年6月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798]Hansen，T.和G.Vaudreuil，“消息处置通知”，RFC 3798，2004年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]Campbell，B.，Mahy，R.，和C.Jennings，“消息会话中继协议（MSRP）”，RFC 49752007年9月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", RFC 5365, October 2008.
[RFC5365]Garcia Martin，M.和G.Camarillo，“会话启动协议（SIP）中的多收件人消息请求”，RFC 5365，2008年10月。
[URN_NS] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[URN_NS]Moats，R.，“IETF文档的URN名称空间”，RFC 26481999年8月。
Authors' Addresses
作者地址
Eric Burger Unaffiliated New Hampshire USA
美国新罕布什尔州非附属机构埃里克·伯格
Phone:
Fax: +1 603 457 5933
EMail: eburger@standardstrack.com
Phone:
Fax: +1 603 457 5933
EMail: eburger@standardstrack.com
Hisham Khartabil Ericsson Australia Melbourne Australia
澳大利亚墨尔本爱立信酒店
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com