Network Working Group E. Burger
Request for Comments: 5438 Unaffiliated
Category: Standards Track H. Khartabil
Ericsson Australia
February 2009
Instant Message Disposition Notification (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ドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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
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）フォーマット、メッセージ/ CPIM [RFC3862]は、インスタントメッセージを生成するために使用されるメッセージフォーマットです。セッション開始プロトコル（SIP [RFC3261]）をSIPのMESSAGEリクエスト[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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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：メッセージ/ CPIMの形式を使用して生成されたインスタントメッセージ。
o IMDN: An Instant Message Disposition Notification generated using the Message/CPIM format that carries an IMDN XML document.
O IMDN：インスタントメッセージ気質通知IMDN XML文書を運ぶメッセージ/ CPIMフォーマットを使用して生成しました。
o Message: An IM or an IMDN generated using the Message/CPIM format.
Oメッセージ：IMまたはIMDNは、メッセージ/ CPIMフォーマットを使用して生成。
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メッセージ内からヘッダを使用するので、それは、必ずしもそうではありません。この値は、多くの場合、レコード（AOR）のIMの送信者のアドレスです。このアドレスは、実際には異なるユーザーエージェントに解決されることがあります。
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受信者：インスタントメッセージを受信エンドポイント（ユーザエージェント）。 IM受信者は、おそらくユーザーにIMをレンダリングノードとして、生成してIM送信者から要求されたとIM受信者によって許可された場合、IMSに送達IMDNsを送信します。
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仲介：ほとんどの場合、ネットワーク内のエンティティ、その最終目的地へのIMを転送し、（URI-Listおよびストアアンドフォワードサーバーなど）アプリケーションサーバ。仲介者はまた、生成し、IMの送信者から要求され、ポリシーで許可されていれば、IMSに処理IMDNsを送ることができます。
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タイプ「メッセージ/ 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) |
|<--------------------------------------|
| |
| |
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 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.
IMDNの受信者に注意し、いくつかの例では、IMの送信者ではないかもしれません。 IM内に存在するレコードのアドレスIM送信者の（AOR）は、IMが由来するものとは異なる場所またはユーザエージェントに解決ここでは、ページモードのIMに特に真実です。これは、例えば、複数のユーザエージェントへの要求をフォークでAOR結果を解決する場合、発生する可能性があります。簡単にするために、このドキュメントの残りの部分は、IMの送信者とIMDN受信者が同じであるため、IMの送信者としての両方を参照することを前提としています。
There are three broad categories of disposition states. They are delivery, processing, and display.
配置状態の3つの広範なカテゴリがあります。彼らは、配信、処理、および表示されています。
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要求IMDNを受け取るためにIMの送信者のために拒否を示すために、「禁止さ」。 IM受信者は、「禁止」状態を送信することができますが、通常は1つがそうするように、それを構成した場合、メッセージを送信仲介です。例えば、管理者がIMDNsを禁止している可能です。
o "error" to indicate an error in determining the fate of an IM.
IMの運命を決定する際に、エラーを示すために、O「エラー」。
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要求IMDNを受け取るためにIMの送信者のために拒否を示すために、「禁止さ」。 「禁止」状態がそうするように構成された仲介者によって送信されます。たとえば、管理者がIMDNsを禁止しています。
o "error" to indicate an error in determining the fate of an IM.
IMの運命を決定する際に、エラーを示すために、O「エラー」。
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の送信者が要求IMDNを受信するために、IM受信者によって、拒否を示すために、「禁止さ」。
o "error" to indicate an error in determining the fate of an IM.
IMの運命を決定する際に、エラーを示すために、O「エラー」。
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.
テキストに加えて、いくつかのIMは、オーディオ、ビデオ、および静止画が含まれていてもよいです。そのため、「表示」の状態は、ユーザーにオーディオまたはビデオファイルをレンダリングの開始を含んでいます。
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メッセージのNSヘッダフィールドを介してURNに割り当てられたプレフィックスにより、CPIMメッセージに、付加されています。本明細書の残りの部分は、常にこのような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受信者からIMDNsを受信したいという要望を示すために、処分、通知ヘッダフィールドを含まなければなりません。セクション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の送信者が受信IMDNsを関連付けるために使用できるグローバルにユニークなメッセージ識別子が含まれています。メッセージIDは、それぞれのIMとIMDNsを相関させるために、送信者によって使用されるため、メッセージ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任意の二つのメッセージIDが誤ってIMDNが受信されるかもしれない以内の期間に衝突の最小限のチャンスがあります。
o It is prohibitive for an attacker who has seen one or more valid Message-IDs to generate additional valid Message-IDs.
Oそれは追加の有効なメッセージIDを生成するために1つ以上の有効なメッセージ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ペイロードに存在する<メッセージ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にOriginal-Toヘッダーフィールドを挿入することができます。オリジナル-Toフィールドの値は、IM受信者のアドレスであるに違いありません。 IM受信者はIMDNsの元のIMアドレスを示すために、このヘッダーを使用しています。 IM受信者はIMDNで<オリジナル・受信者-uri>要素を取り込むことでこれを行います。中間フィールド値をToヘッダ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-Record-Routeヘッダーフィールドを挿入することができます。これは、バックIMの送信者へ向かう途中でIMDNを受信して処理するための仲介を可能にします。 IMDN-Record-Routeヘッダフィールドの値は、中間のアドレスでなければなりません。複数のIMDN-Record-Routeヘッダフィールドは、IMに表示されます。セクション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-Routeヘッダフィールドは、これにルートIMDNに1つ以上のアドレスを含めることにより、ルーティング情報を提供します。同じ介して逆流するIMDNを必要仲介はIMDN-Record-Routeヘッダを追加しなければなりません。 IM受信者がIMDN-Routeヘッダフィールドに対応するに対応IMDN、IM受信者コピーIMDN-のRecord-Routeヘッダを作成するとき。セクション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ヘッダフィールドを含まなければなりません。このヘッダーフィールドは、対応するIMSに任意IMDNsに一致するようにIM送信者を可能にします。メッセージ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を相関させる目的で送信されたメッセージを保持しないことを選択できることを意味します。この場合IMDNの一部に利用するために、我々は、ユーザーがメッセージを送ったことを示すためにIMにタイムスタンプを追加します。 IMDNは、人間のレベルでIMDNでIMを相関させるために、ユーザーを有効にするには、このタイムスタンプを返します。私たちは、この目的のためにDateTimeのCPIMヘッダフィールドを使用します。 IM送信者は、IMDNをご希望の場合したがって、IM送信者は日付と時刻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の送信者から要求された処分通知の種類を伝えます。配信、処理、および表示：処分通知の3つのタイプがあります。配信通知は、さらに失敗と成功配信通知に細分されます。 IM送信者は、値「負送達」との処分、通知ヘッダフィールドを含むことにより、障害の配信通知を要求します。同様に、成功の通知が値「正送達」と処分、通知ヘッダフィールドを含むことによって要求されます。 IMの送信者は、同じIMの配信通知の両方のタイプを要求することができます。
The IM Sender can request a processing notification by including a Disposition-Notification header field with value "processing".
IM送信者は、値「処理」と気質、通知ヘッダフィールドを含めることによって、処理通知を要求することができます。
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送信者は、表示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送信者要求正および負の送達通知が、しかし通知や処理通知を表示しないIMの例CPIM体です：
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
投稿者：アリス<イム：alice@example.com>へ：ボブ<イム：bob@example.com> NS：imdn <URN：IETF：のparams：imdn> imdn.Message-ID：34jk324j日時：2006-04-04T12 ：16：49から05：00 imdn.Disposition-通知正配信、負配信コンテンツタイプ：text / plainのコンテンツの長さ：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送信者は、IMDNの身体内の<メッセージID>要素値とIMでメッセージ-IDヘッダフィールド値を照合することによって、IMにIMDNと一致します。 IMは、複数の受信者に配信された場合は、IMの送信者は、それがIMが複数の受信者に送信されたかどうかを判断するために受信IMDNのXML本体で<受信者-uri>要素と<オリジナル・受信者-uri>要素を使用し、 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.
IMDNを決定することができIMの送信者は、IMDNのContent-Disposition「の場合は通知」である場合には注目の処分通知です。これは、IMの送信者は、CPIMメッセージのContent-処分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対象またはコンテンツ、それが送信された日時としてIMコンテキスト（主にメッセージID）、他のユーザが識別可能な情報を保存することができます。 IMコンテキストの保存せずに、IMの送信者は、それが送られたIMとIMDNを相関することができません。 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の送信者が送信済みアイテムの状態を失った場合、明らかに、クライアントが明らかに迷惑IMDNsに応じて異なる表示方法を使用すること（例えば、ユーザーが「送信済みアイテム」ボックスからアイテムを削除します）。
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.
また、この仕様はIMDNを待っているすべてのタイマーを実行するためにIMの送信者を強制しません。 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をIMユーザが2午後に送信したことを示す場合先週の木曜日配信されたが、利用者は、彼らは午後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の送信者は、要求のIMDNs（通常はURI-リストサーバ[RFC5365]を使用して）1トランスポートプロトコルのメッセージで複数の受信者にIMを送信することができます。 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受信者は、受信者がそのIMためIMDNを生成する必要があるかどうかを決定するためにCPIMメッセージの処分、通知ヘッダフィールドの内容を調べます。 CPIMメッセージの配置、通知ヘッダフィールドは、1つ以上の値を含むことができます。 IM受信者は、例えば、そのIMのために、ゼロ、1つ、またはそれ以上のIMDNsを生成するために、送達通知、ならびにディスプレイ通知を必要とするかもしれません。この場合、IM受信者は、IMごとに複数のIMDNsを構築することができなければなりません。 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ヘッダフィールドを含まなければなりません。 IMDNに適用IMに表示されるメッセージ-IDヘッダフィールドの一意の同じ規則。 IMDNにおけるメッセージ-IDヘッダフィールドは異なり、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（詳細はセクション8を参照）IMDN-Record-Routeヘッダフィールドを含んでいてもよいです。 IMDN-Record-RouteヘッダフィールドがIMに表示された場合は、IMDNを構築IM受信者はIMDNでIMDN-RouteヘッダーフィールドにIMDN-Record-Routeヘッダフィールドの内容をコピーし、その順序を維持しなければなりません。 IMDNは、トップIMDN-Routeヘッダフィールド内のURIに送信されます。 IMDN-Record-Routeヘッダフィールドは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-Record-Routeヘッダーフィールドが存在しない場合は、IM受信者は、FromヘッダーフィールドにURIにIMDNを送らなければなりません。
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受信者は、値「通知」に設定のContent-Dispositionヘッダーフィールドを挿入しなければなりません。これは、メッセージは、それが以前に送信したIMにIMDNであることをIMの送信者に通知します。
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受信者が気質通知XML文書のMIMEタイプは、セクション11で指定された規則に従ってフォーマット気質通知XML文書を運ぶCPIM体[RFC3862]を使用して、IMと同様の方法で配信通知を構成します」メッセージ/ imdn + XML」。
Section 10 defines the schema for an IMDN.
セクション10は、IMDBのスキーマを定義します。
The following is an example CPIM body of an IMDN:
以下は、IMDBの例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: ...
From：へ：<bob@example.comイム>：アリスボブ<イム：alice@example.com> NS：imdn <URN：IETF：のparams：imdn> imdn.Message-ID：d834jied93rfコンテンツ・タイプ：メッセージ/ 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" エンコード= "UTF-8"？> <imdnのxmlns = "URN：IETF：paramsは：XML：NS：imdn"> <メッセージID> 34jk324j </メッセージID> <日時> 2008-04-04T12：16：49から05：00 </日時> <受信者-URI> IM：bob@example.com </レシピエント-URI>
<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は、IMDBのスキーマを定義します。
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@example.com>へ：アリス<イム：alice@example.com> NS：imdn <URN：IETF：のparams：imdn> imdn.Message-ID：dfjkleriou432333コンテンツタイプ：メッセージ/ 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" エンコード= "UTF-8"？> <imdnのxmlns = "URN：IETF：paramsは：XML：NS：imdn"> <メッセージID> 34jk324j </メッセージID> <日時> 2008-04-04T12：16：49から05：00 </日時> <受信者-URI> IM：bob@example.com </レシピエント-URI> <元の受信者-URI> IM：bob@example.com < /元の受信者-URI> <表示通知> <状態> <表示/> </状態> </ディスプレイ通知> </ 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受信者がサーバーによって内部エラーを示すために「エラー」の<状態>の値で表示通知を生成します。 IM受信者が任意のIMDN要求を無視することを選択すると、任意のIMDNsを送信しないことに注意してください。 IM
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-Listおよびストア・アンド・フォワード・サーバを含む）サーバやゲートウェイです。ゲートウェイは、異なるプロトコルを使用する異なる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-リスト・サーバーは、（詳細については、[RFC5365]を参照）ごとに、それがリストのメンバーに送信することになり、コピーのためにそのIMの最終受信者のアドレスに、自身からIM受信者のアドレスを変更することがあります。 IMの送信者がIMDNを要求している場合は、この場合には、仲介者は、変更される前のToヘッダーフィールドCPIMにあったアドレスでそれを移入、オリジナル-TO IMにフィールドをヘッダを追加する必要があります。つまり、仲介者は、仲介アドレスとOriginal-Toヘッダーフィールドを取り込み、です。もちろん、一つは書き換えやオリジナル-Toフィールドを移入からそれを制限するための仲介を設定することができます。 1がすでに存在する場合、仲介者はOriginal-Toヘッダーフィールドを追加してはなりません。仲介者は、元のRequest-URIを明らかにしないために、管理者の構成を有してもよい、とのような、Original-Toヘッダーを追加してはなりません。
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の経路上に残ることを選択するかもしれません。これは、トップIMDN-Record-RouteヘッダフィールドとしてCPIM IMDN-Record-Routeヘッダフィールドを追加することによってこれを行うことができます。このフィールドの値は、仲介者自身のアドレスであるに違いありません。この拡張機能をサポートしていないの仲介は明らかにIMDN-Record-Routeヘッダーフィールドを追加しません。これは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-Routeヘッダフィールドをチェックします。そのヘッダフィールドは、中間アドレスを運ぶ場合、仲介者はその値を削除し、新たなトップIMDN-Routeヘッダフィールドで示されたアドレスにIMDNを転送します。追加IMDN-Routeヘッダフィールドが存在しない場合、IMDNフィールドをヘッダーにはCPIMのアドレスに転送されます。
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.
リストメンバーが開示されていない場合、仲介者は、リストの最終受信者に関するすべての情報を削除する必要があります。仲介者は、<受け手-uri>要素及び/又はIM送信者に転送する前にIMDNの本体から<元の受信者-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の送信者が値「処理」と処分-通知ヘッダフィールドを含めることによって、「処理」の通知を要求した場合にのみ行ってください。
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を同じIM「が格納されている」であることを示す別のIMDN続いて「処理」されていることを示す「処理」通知を送信してはなりません。
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@example.com>へ：アリス<イム：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" エンコード= "UTF-8"？> <imdnのxmlns = "URN：IETF：paramsは：XML：NS：imdn"> <メッセージID> 34jk324j </メッセージID> <日時> 2008-04-04T12：16：49から05：00 </日時> <受信者-URI> IM：bob@example.com </レシピエント-URI> <元の受信者-URI> IM：bob@example.com < /元・受信者-URI>
<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の運命を知ることができない状況があります。この場合、中間ので示す「エラー」の<状態>の値と、処理通知を生成します。
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リストサーバがIMDNsを集約するかではなく、個々のIMDNsを送ることができ（ローカルポリシーを使用して）選択することができます。 URIリストサーバがIMを受信し、IMDNsを集約することを決定したときは、設定可能な期間のためか、それが集約さIMDNを送信する前にすべての受信者は、どちらか早い方IMDNを、送信されるまで待つことができます。通知の「表示」は、例えば、いくつかのIMDNsは、ユーザー設定のために来ないかもしれないことに注意してください。どのくらいの集約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-リスト・サーバーは、複数の集約IMDNsを送信するために選ぶかもしれません。タイマーを開始することができ、それが発火するとき、URIリストサーバが、それは今のところそのIMのために持っているものは何でもIMDNs集約集約IMDNを送信し、次のバッチのためのタイマーを再起動することができます。これは、IMの送信者が複数のを要求したシナリオのために必要とされます
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.
特定のSIMのためのIMDB - 例えば、送達通知、並びに表示通知 - またはURIリストサーバがリソースに短く、IMDB上に転送インスタントメッセージを優先することを選択したとき。
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-リスト・サーバーはその時間後に到着する可能性のあるIMDNsを消費します。
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リストサーバは、個々のものまたはその逆に集約さIMDNsやスイッチの送信を開始するシナリオがあるかもしれません。多くの場合、発射タイマーは、実際にその効果を有することができます。
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タイプを使用して、個々のペイロードメッセージ/ imdn + XMLとして受信された全てIMDNSとして含んで構成されています。
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: ...
From：へ：<bob@example.comイム>：アリスボブ<イム：alice@example.com> NS：imdn <URN：IETF：のparams：imdn> imdn.Message-ID：d834jied93rfのコンテンツタイプ：混合/マルチパート;境界= "imdn境界の" Content-処分：通知コンテンツの長さ：...
--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" エンコード= "UTF-8"？> <imdnのxmlns = "URN：IETF：paramsは：XML：NS：imdn"> <メッセージID> 34jk324j </メッセージID> <日時> 2008-04-04T12：16：49から05：00 </日時> <受信者-URI> IM：bob@example.com </レシピエント-URI> <元の受信者-URI> IM：bob@example.com < /元の受信者-URI> <配信通知> <状態> <配信/>
</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" エンコード= "UTF-8"？> <imdnのxmlns = "URN：IETF：paramsは：XML：NS：imdn"> <メッセージID> 34jk324j </メッセージID> <日時> 2008-04-04T12：16：49から05：00 </日時> <受信者-URI> IM：bob@example.com </レシピエント-URI> <元の受信者-URI> IM：bob@example.com < /元の受信者-URI> <表示通知> <状態> <表示/> </状態> </ディスプレイ通知> </ 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]のようなトランスポートプロトコルで運ばれます。トランスポート・プロトコルによって運ばれるペイロードタイプメッセージ/ CPIMの任意の部分が含まれていない場合、メッセージはIMです。ペイロードタイプメッセージ/ CPIMの任意の部分を含み、それらの部分のいずれもタイプの「メッセージ/ 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.
メッセージは、その内容を調べることによって、配信通知として識別されます。メッセージは、コンテンツタイプヘッダフィールドの存在は、「メッセージ/ imdn + XML」の値を有する場合、コンテンツの廃棄ヘッダーフィールドは「通知」の値を有し、そして、<配達通知>要素に表示される配信通知でありますその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.
メッセージが配信通知と同様の方法で処理通知または表示通知として識別されます。違いは、処理通知のために、<処理通知>要素は、XML本体に表示されます、ということです。ディスプレイ通知の場合、<表示・通知>要素は、XML本体に表示されます。
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))]
notify-req = ("negative-delivery" / "positive-delivery" / "processing" / "display" / Token) *(SEMI disp-notify-params)
通知-REQ =（ "負配信" / "正配信" / "処理" / "表示" /トークン）*（SEMI DISP-通知-paramsは）
disp-notify-params = Ext-param
DISP-通知-paramsは= EXT-PARAM
Message-ID = "Message-ID" ": " Token
Original-To = "Original-To" ": " [ Formal-name ] "<" URI ">"
IMDN-Record-Route =
"IMDN-Record-Route" ": " [ Formal-name ] "<" URI ">"
IMDN-Route = "IMDN-Route" ": " [ Formal-name ] "<" URI ">"
SEMI = *SP ";" *SP ; semicolon
SEMI = * SP ";" * SP;セミコロン
COMMA = *SP "," *SP ; comma
PARAGRAPH = * SP "" * SP;サブセクション
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ペイロードは、十分に形成されなければならないとvalidaterと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 (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：のparams：XML：：NS imdn壷」以外のいくつかの位置で修飾された拡張要素を可能にします。前方の互換性を維持するために（すなわち、既存の消費者が使用することができ、新しいインスタンス文書）が、新たな仕様は、この仕様の許容量を拡張してはなりません。拡張要素と可能な将来の仕様の既存の修飾名との競合がある場合には後方互換性（すなわち、既存のインスタンス・ドキュメントが更新され、新しい消費者にも使用することができます）が破損する可能性があります。 IETFは、の「サブ名前空間」内の新しい拡張要素を指定するかもしれない「壷：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.
可能性のある将来の仕様は、組み合わせ=「インターリーブ」パターンを持つ新しい要素の定義を追加することができます。この新しいタイプの複数の要素は、その後、許可されている場合は、新しい定義は、<zeroOrMore>カーディナリティの規則を含まなければなりません。新しい仕様は、単一の新しい要素を許可しない場合は、<オプション>カーディナリティの規則を使用しなければなりません。これらのカーディナリティの要件は、新しい消費者との既存のインスタンス・ドキュメントの下位互換性を維持します。これは再定義し、より限定されたワイルドカードパターンを使用して新しい要素の定義が一致しないように、また、新しい仕様はその後、「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_NS]によって定義され、[IANA]によって拡張「IETF」名前空間識別子を使用して、URN [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>要素は、サブ要素、すなわち<メッセージID>、<日時>、<受け手-URI>、<元の受信者-URI>、<主題>、および<配達通知>の<処理を有しています-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に記載されているように、<IMDB>、新しい配置の通知タイプ、または他の要素を含むように、将来的に拡張することができます。
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.
<メッセージID>要素は、XMLスキーマに従って必須であり、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.
<日時>要素は必須で、IMが送信された日時（不IMDN）を運びます。この情報は、IMの日時ヘッダフィールドから得られます。
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.
<受信者-uri>要素はオプションであり、最終的な受信者のURIを搬送します。この情報は、IMのフィールドをヘッダーにはCPIMから得られます。
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.
<元の受信者-uri>要素はオプションであり、元の受信者のURIを搬送します。 IMはOriginal-Toヘッダーフィールドを実施した場合には存在しなければなりません。この情報は、IMのOriginal-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.
<主題>要素はオプションです。存在する場合、それがもしあれば、件名ヘッダフィールドにあったテキストと言語属性を運ばなければなりません。これは、IMとIMDN間の人間レベルの相関関係を可能にします。 IMに複数の件名ヘッダフィールドがある場合、IMDNペイロード<対象>に配置するためにそれらのいずれかを選択する要素は十分です。送信者は、次いで、一致か一致が判定されるまで、件名ヘッダフィールドを比較する必要があります。
11.1.6. The <delivery-notification>, <processing-notification>, and <display-notification> Elements
11.1.6. <配信通知>、<処理通知>、および<表示通知>要素
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>.
<配信通知>の一の外観、<処理通知>、および<表示通知>要素は必須で、IM送信者が要求され、報告されていることを配置タイプを運びます。これは、サブ要素<状態>を運びます。
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>,
<状態>要素は必須で、配置要求の結果を運びます。通知タイプ<配達通知>のために、それが<配信>サブ要素の一つ、<失敗>、<禁止>、または<エラー>を運ぶことができます。通知タイプ<表示通知>ためには、サブ要素<表示>の<禁止>、または<エラー>を運ぶことができます。通知タイプ<処理通知>のために、それは、サブ要素<処理>のいずれかを運ぶことができます
<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.
<禁止さ>、<保存>、または<エラー>。 <禁断の>は、処分が拒否されたことを意味します。 <エラー>は内部サーバーエラーを意味します。 <状態>要素はまた、任意の他のステータスの拡張子を運ぶために拡張することができます。
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タイプは、「メッセージ/ imdn + xml」です。 IMDNは、Content-Typeヘッダフィールド内のMIMEタイプ「メッセージ/ 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" エンコード= "UTF-8"？>は<文法の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 = "壷：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>
</スタート>
<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>
<定義名= "deliveryNotification"> <要素名= "配達通知"> <要素名= "ステータス"> <選択> < "送達" 要素名=> <空/> </要素> <要素名=」失敗した "> <空/> </要素> <REF名=" commonDispositionStatus "> </ ref>を</選択> <refの名前=" deliveryExtension "/> </要素> </要素> </定義>
<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>
<定義名= "displayNotification"> <要素名= "表示通知"> <要素名= "ステータス"> <選択> <要素名は= "表示"> <空/> </要素> <REF名=」 commonDispositionStatus "> </ ref>を</選択> <refの名前=" displayExtension "/> </要素> </要素> </定義>
<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>
<定義名= "processingNotification"> <要素名= "処理通知"> <要素名= "ステータス"> <選択> <要素名= "処理"> <空/> </要素> <要素名=」保存された "> <空/> </要素> <refの名前=" commonDispositionStatus "> </ ref>を</選択> <refの名前=" processingExtension "/> </要素> </要素>
</define>
</定義>
<define name="commonDispositionStatus"> <choice> <element name="forbidden"> <empty/> </element> <element name="error"> <empty/> </element> </choice> </define>
<名前を定義= "commonDispositionStatus"> <選択> <要素名= "禁断"> <空/> </要素> <要素名= "エラー"> <空/> </要素> </選択> </定義>
<!-- <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>拡張ポイントを兼ね備え=「インターリーブ」パターンで新しい定義を追加します。拡張スキーマは、適切なカーディナリティを追加する必要があります。例えば、拡張子が複数の要素を許可する場合、<zeroOrMore>カーディナリティを使用する必要があり、そして拡張は、単一の任意の要素を許可する場合、<オプション>基数は、使用されるべきです。 - >
<define name="imdnExtension"> <zeroOrMore> <ref name="anyIMDN"/> </zeroOrMore> </define>
<zeroOrMore> <refの名前= "anyIMDN" /> </ zeroOrMore> </定義> <名前= "imdnExtension" を定義>
<!-- delivery-notification <status> extension point --> <define name="deliveryExtension"> <zeroOrMore> <ref name="anyIMDN"/> </zeroOrMore> </define>
<！ - 配達通知<状態>拡張ポイント - > <名前を定義= "deliveryExtension"> <zeroOrMore> <refの名前= "anyIMDN" /> </ zeroOrMore> </定義>
<!-- display-notification <status> extension point --> <define name="displayExtension"> <zeroOrMore> <ref name="anyIMDN"/> </zeroOrMore> </define>
<！ - ディスプレイ通知<状態>拡張ポイント - > <名前を定義= "displayExtension"> <zeroOrMore> <refの名前= "anyIMDN" /> </ zeroOrMore> </定義>
<!-- processing-notification <status> extension point --> <define name="processingExtension"> <zeroOrMore> <ref name="anyIMDN"/> </zeroOrMore> </define>
<！ - 処理通知<状態>拡張ポイント - > <名前を定義= "processingExtension"> <zeroOrMore> <refの名前= "anyIMDN" /> </ zeroOrMore> </定義>
<!-- 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>
<！ - imdn名前空間で修飾されていないか、資格（混合型の）複雑な要素のためのワイルドカードの定義。拡張スキーマは、このまたはこの定義を使用して、個々の、以前の定義を再定義する必要があります。つまり、拡張スキーマは、インターリーブパターンで確定的で明確なスキーマを維持するために許容量を削減しなければなりません。 - > <定義名= "anyIMDN"> <要素> <anyName> <除く> <ますNSname NS = "URN：IETF：paramsは：XML：NS：imdn" /> <ますNSname NS = "" /> </以外> </ anyName> <REF名= "anyExtension" /> </要素> </定義>
<!-- the rest of the "anyIMDN" wildcard definition --> <define name="anyExtension"> <zeroOrMore> <choice> <attribute> <anyName/> </attribute> <ref name="any"/> </choice> </zeroOrMore> </define>
<名前を定義= "anyExtension"> <zeroOrMore> <選択> <属性> <anyName /> </属性> <refの名前= "あらゆる" /> <！ - - "anyIMDN" ワイルドカードの定義の残りの部分> </選択> </ 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>
<！ - 任意の名前空間またはコンテンツの制限なし（混合型の）複雑な要素のためのワイルドカード型 - > <定義名= "任意の"> <要素> <anyName /> <zeroOrMore> <選択> <属性> <anyName / > </属性> <テキスト/> <refの名前= "あらゆる" /> </選択> </ zeroOrMore>
</element> </define>
</要素> </定義>
</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タイプを示します。この拡張機能を使用する場合は、Content-Typeヘッダフィールドは、IMSとIMDNs両方のMIMEタイプ「メッセージ/ 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 MESSAGEリクエストと同様に複数の受信者にSIP MESSAGEリクエストを構築します。 [RFC5365]は違いを説明し、「複数受信者MESSAGEは、SIPに要求します」。
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送信者は匿名のまますることができます。例えば、送信者が匿名のURIに、SIPメッセージのヘッダフィールドからSIPを設定することができます。ノーリターンアドレスが存在しないため、匿名の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のMESSAGE要求を受信したエンドポイントは、RFC 3428 [RFC3428]に従ってSIP応答を構築します。もちろん、エンドポイントは、受信したメッセージのタイプ（IMまたはIMDN）、または、それは頼まされた処分の種類にかかわらず、MESSAGE要求に対するSIP応答を送信します。
A SIP MESSAGE request is identified as an IM by examining its contents according to Section 9.
SIPのMESSAGEリクエストは、セクション9に記載の内容を調べることによって、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 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受信者は、正の配信通知を要求するIMであるSIPメッセージの要求を受け、IM受信者が構築したこととSIPの2xxクラスの応答を送信した場合、それはIMがされていることを確認した後、正配信通知を生成してもよい（MAY）ユーザーやアプリケーションに配信。最終受信者がIMを受信する前に、ゲートウェイは、例えば、2xx応答を生成することができます。 IM受信者は、セクション7.2.1.1に係る正配信通知を構築します。 IM受信者は、SIP MESSAGE要求にペイロードとしてメッセージを配置します。
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受信者が負の配信を要求するIMであるSIPメッセージの要求を受け、IM受信者が構築したこととの2xxクラスの応答を送信した場合、それは最終的に受信者またはアプリケーションがやったことを知ったならば、それは負の配信通知を生成する必要がありますIM（それが下流または応答を待って、内部タイマ火災前からエラー応答を持つ前に、ゲートウェイは、例えば、2xx応答を生成することができる）を受信しません。負配信通知は、セクション7.2.1.1に従って構成されています。メッセージは、SIPのMESSAGEリクエストでペイロードとして配置されています。
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受信者が負配信通知を要求するIMであるSIPメッセージの要求を受け、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をユーザに提示されていることを確認した後、表示通知を生成してもよい（MAY）またはアプリケーション。それは決意がIMが読まれたかどうかを判断することができますどのように議論するために、このドキュメントの範囲外です。ディスプレイ通知を送信するか否かの決定は、利用者に委ねられることに注意してください。アプリケーションは、ユーザがそのような選択を設定することを可能にします。 IM受信者は、セクション7.2.1.2に係る表示通知を構築します。 IM受信者は、SIP MESSAGE要求にペイロードとしてメッセージを配置します。
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でFromヘッダーフィールドSIPに登場したアドレスを使用してフィールドをヘッダにはSIP要求URIとSIPに移入されます。
A SIP MESSAGE request is identified as a delivery notification by examining its contents according to Section 9.
SIPのMESSAGEリクエストは、セクション9に記載の内容を調べることによって、配信通知として識別されます。
A SIP MESSAGE request is identified as a display notification by examining its contents according to Section 9.
SIPのMESSAGEリクエストは、セクション9に記載の内容を調べることによって、表示通知として識別されます。
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-Listおよびストア・アンド・フォワード・サーバを含む）のサーバーとゲートウェイが含まれます。 SIPプロキシはIMDNsを発生させてはいけませんが、他のSIP要求のようにそれらを転送する必要があります。
Intermediaries forward a SIP MESSAGE request to multiple recipients according to [RFC5365].
仲介は、[RFC5365]によれば、複数の受信者へのSIP MESSAGEリクエストを転送します。
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を受信した場合、仲介者は体を調べます。本体は、タイプ「メッセージ/ 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クラスの応答を受信した場合、仲介は、配信通知を生成してはいけません。下流のエンティティはMESSAGE要求を受けたからといって、メッセージがその最終的な宛先に中継されたか、配信されたという意味ではありません。このように、仲介者は、それは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本体の<受信-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プロトコルのすべてのセキュリティの考慮もIMDNsに適用されます。
The threats in the IMDN system, over and beyond the threats inherent to IM, include the following:
オーバーIMDNシステム、内とIMに固有の脅威を超えた脅威は、次のものがあります。
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悪質なエンドポイントは、疑うことを知らないIMの送信者にIMDNsを送信するためにURI-リスト・サーバーを説得することでIMDNsとIMの送信者をあふれしようとします。
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-Record-Routeフィールドにターゲットのアドレスを挿入することにより、IMDNsでターゲットノードをあふれしようとします。
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をIM受信者は、IMの送信者の身元を知っていた場合はIM受信者は、通常、そのIMの送信者にIMDNを転送しないとIMの送信者、受信者へのIMからIMDNを転送しようとします。
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ネットワーク内の悪意のあるノードは、例えば、リクエストURIまたはトラフィックパターン情報を学習するIMDNトラフィックを盗聴しよう。
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受信者が時間について嘘や故意IMはそれが実際にあったより後に読み込まれたユーザーに表示することを見えるようにする伝送のためのIMDNを保持していないことを保証するためのプロトコルのメカニズムはありません。
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.
IMDNでの削除攻撃O。これは、プライバシーとセキュリティの間のトレードオフです。プライバシーの考慮事項は、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.
盗聴、修正、およびman-in-the-middle攻撃に対抗するために、我々は、認証と完全性保護のいくつかのレベルが必要です。それは、強い整合性が過剰になる事情がある、と述べました。推定は、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.
IM受信者が証明書を持っている場合は、O、それは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.
IMが暗号化されている場合、攻撃者がネットワーク上のIMDNsを盗聴からユーザの活動プロファイルおよびアイデンティティを識別することを試みることができるよう、O、IM受信者または仲介者は、IMDN本体を暗号化する必要があります。
o The two above rules are cumulative.
2つの以上の規則が累積され、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アプリケーション層のペイロードにルーティング情報を置くの設計上の選択をしました。この選択肢の1つの結果は、それがエンドツーエンドの暗号化を持つ可能性を排除しています。
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要求でノードへのIMの多くを送信することにより、ノード上の分散サービス拒否攻撃を仕掛けることができます。 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システムを使用するには、悪意のあるノードのための可能性に対処する1つの方法は、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.
インスタントメッセージを偽造することができます。それを防ぐために、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は、通常のIMと同じように簡単に偽造することができます。 IMDNsの自動使用をしたいエンドポイントおよび仲介は、サービス拒否攻撃からの潜在的な損傷を最小限にするために、適切な予防措置を取るべきです。鍛造IMDNsに関連するセキュリティの脅威は、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受信者は、彼女が受け取った、または実際にはIM、読み取ったことを明らかにしたくない場合があります。 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.
IM受信者は、グローバル好み、または別、ユーザ設定可能メカニズムの利用者の設定により、あたり-IMベースでプロンプトまたはダイアログボックスで、このような同意を得ることができます。また、ユーザーはIMDNsが送信または「禁止」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-リスト・サーバーは1つの集約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受信者はToヘッダーフィールドに注意して、リスト名ではなく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.
この文書は、「メッセージ/ imdn + xml」で新しいMIMEタイプを登録し、新しい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で指定され、application / xmlのcharsetパラメータと同じです[RFC3023]。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
符号化の考慮事項：RFC 3023で指定されたアプリケーション/ XMLの考察をコードするものと同じ[RFC3023]。
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 14 of this document.
セキュリティの考慮事項：RFC 3023 [RFC3023]とこのドキュメントのセクション14のセクション10を参照してください。
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のファイルタイプコード：「TEXT」
Personal and email address for further information: Hisham Khartabil (hisham.khartabil@gmail.com)
詳しくは、個人やメールアドレス：ヒシャムKhartabil（hisham.khartabil@gmail.com）
Intended Usage: COMMON
意図した使用法：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、SIMPLEワーキンググループ、ヒシャム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
レジストリ名：URN：IETF：のparams：IMDB
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形成：ヘッダの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）に対応する '％のHH' エスケープシーケンス（RFC 3986ごと[RFC3986]）と任意の非URN文字（RFC 2141 [URN]によって定義されるような）置換および
b) prepending the resulting string with 'urn:ietf:params:imdn:'.
B） '：IETF：paramsは：IMDB：URN' と結果の文字列を付加。
Thus, the URI corresponding to the CPIM message IMDN header 'Disposition-Notification:' would be 'urn:ietf:params:imdn:Disposition-Notification'.
したがって、URIはCPIMメッセージIMDNヘッダに対応する '処分-通知：' 'URN：IETF：paramsは：imdn：処分-通知' であろう。
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 |
+--------------------------+---------------------+
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レジストリに記録されている通知、：この文書は、1新しいコンテンツ-Dispositionヘッダーフィールド「処分・タイプ」を登録します。
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.
通知：このContent-Dispositionヘッダーフィールド値を運ぶメッセージのペイロードは、対応するインスタントメッセージで要求されるようにインスタントメッセージ気質通知です。
Special thanks to Jari Urpalainen for the thorough review and suggestions for the RelaxNG schema.
RelaxNGスキーマのための徹底した見直しと提案のためのヤリUrpalainenに感謝します。
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.
著者はまた、彼らのコメントやサポートのためにポール・Kyzivat、ベン・キャンベル、アダムローチ、ゴンサロ・カマリロ、フランクEllermann、ショーン・オルソン、エヴァLeppanen、ミゲル・ガルシア、エリック・マクマリー、ジョンピーターソン、ロバート・スパークスに感謝したいと思います。また、当社は、非凡なスペンサードーキンスのジェン・アート投稿者に感謝したいと思います。
[IANA] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[IANA]、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月をMealling。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "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.アトキンス、 "一般的なプレゼンスとインスタントメッセージング（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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[URN]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[XML] Bray, T., "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, October 2000.
[XML]ブレイ、T.、 "拡張マークアップ言語（XML）1.0（第二版）"、W3C CR 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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年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.、ハーディー、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]ハンセン、T.およびG.ボードルイ、 "メッセージ気質通知"、RFC 3798、2004年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975]キャンベル、B.、マーイ、R.、およびC.ジェニングス、 "メッセージセッションリレープロトコル（MSRP）"、RFC 4975、2007年9月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年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]ガルシア・マーチン、M.およびG.カマリロ、RFC 5365、2008年10月「セッション開始プロトコル（SIP）における複数の受信者のメッセージ要求」。
[URN_NS] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[URN_NS]堀、R.、 "IETFドキュメントのためのURN名前空間"、RFC 2648、1999年8月。
Authors' Addresses
著者のアドレス
Eric Burger Unaffiliated New Hampshire USA
エリックバーガー無所属ニューハンプシャー州USA
Phone: Fax: +1 603 457 5933 EMail: eburger@standardstrack.com
電話：ファックス：+1 603 457 5933 Eメール：eburger@standardstrack.com
Hisham Khartabil Ericsson Australia Melbourne Australia
ヒシャムKhartabilエリクソンオーストラリアメルボルンオーストラリア
Phone: +61 416 108 890 EMail: hisham.khartabil@gmail.com
電話：+61 416 108 890 Eメール：hisham.khartabil@gmail.com