[要約] RFC 5438は、インスタントメッセージの配信状況通知（IMDN）に関する標準仕様です。その目的は、メッセージの配信状況を通知するためのプロトコルを提供することです。
Network Working Group E. Burger
Request for Comments: 5438 Unaffiliated
Category: Standards Track H. Khartabil
Ericsson Australia
February 2009
Instant Message Disposition Notification (IMDN)
インスタントメッセージ処分通知（IMDB）
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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）データ形式は、エンドポイントがIMDNを要求できるようにする新しいヘッダーフィールドで拡張されています。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メッセージ要求[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.
この仕様では、「配信」、「処理」、「ディスプレイ」の3つのカテゴリの処分タイプを定義します。特定の処分タイプは、より詳細な情報を提供します。たとえば、「配信」カテゴリには、配信の成功を示す「配信」と「失敗」を示すために「失敗」が含まれます。
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 メッセージ：メッセージ/CPIM形式を使用して生成されたIMまたはIMDN。
o IM Sender: An endpoint (user agent) generating and sending an IM. Also, the endpoint request IMDNs for an IM. Quite often, the IM Sender is the IMDN Recipient. However, that is not always the case, since the IMDN uses the From header in the CPIM message. That value is often the IM Sender's Address of Record (AOR). This address may in fact resolve to different user agents.
o IM送信者：IMを生成して送信するエンドポイント（ユーザーエージェント）。また、エンドポイントはIMのIMDNを要求します。多くの場合、IM送信者はIMDNの受信者です。ただし、IMDNはCPIMメッセージでFrom Headerを使用するため、常にそうではありません。その値は、多くの場合、IM送信者の記録アドレス（AOR）です。このアドレスは、実際にはさまざまなユーザーエージェントに解決する場合があります。
o IM Recipient: An endpoint (user agent) that receives IMs. The IM Recipient, as the node that presumably renders the IM to the user, generates and sends delivery IMDNs to IMs, if requested by the IM Sender and allowed by the IM Recipient.
o IM受信者：IMSを受信するエンドポイント（ユーザーエージェント）。IM受信者は、おそらくIMをユーザーにレンダリングするノードとして、IM送信者から要求され、IM受信者が許可する場合、IMDNを生成および送信します。
o Endpoint: An IM Sender or an IM Recipient.
o エンドポイント：IM送信者またはIMの受信者。
o Intermediary: An entity in the network, most often an application server (including URI-List and store-and-forward servers), that forwards an IM to its final destination. Intermediaries also can generate and send processing IMDNs to IMs, if requested by the IM Sender and allowed by policy.
o 中間：ネットワーク内のエンティティ、ほとんどの場合、アプリケーションサーバー（URIリストとストアアンドフォワードサーバーを含む）で、IMを最終目的地に転送します。また、IM送信者から要求され、ポリシーで許可されている場合、仲介者はIMDNを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 処分タイプ：この仕様では、「配信」、「処理」、「ディスプレイ」の3つのカテゴリの処分タイプを定義します。
o Transport Protocol Message: A SIP or other protocol message that contains an IM or IMDN.
o トランスポートプロトコルメッセージ：IMまたはIMDBを含む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を作成し、IMDNリクエスト情報を追加して、IM送信者が受信に関心があるという情報を追加し、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が発信した場所とは異なる場所またはユーザーエージェントに解決するページモードIMSに特に当てはまります。これは、たとえば、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 IM送信者が要求されたIMDNを受け取るための拒否を示す「禁止」。IMの受信者は「禁止」状態を送信できますが、通常、それを設定する場合、メッセージを送信するのは通常、仲介者です。たとえば、管理者がIMDNを禁止している可能性があります。
o "error" to indicate an error in determining the fate of an IM.
o IMの運命を決定する際のエラーを示す「エラー」。
The processing notification type indicates that an intermediary has processed an IM. The processing notification type can have the following states:
処理通知タイプは、仲介者がIMを処理したことを示しています。処理通知タイプには、次の状態を持つことができます。
o "processed" to indicate that the intermediary has performed its task on the IM. This is a general state of the IM.
o 仲介者がIMでそのタスクを実行したことを示すために「処理されました」。これはIMの一般的な状態です。
o "stored" to indicate that the intermediary stored the IM for later delivery.
o 仲介者が後の配達のためにIMを保存したことを示すために「保存された」。
o "forbidden" to indicate denial for the IM Sender to receive the requested IMDN. The "forbidden" state is sent by an intermediary that is configured to do so. For example, the administrator has disallowed IMDNs.
o IM送信者が要求されたIMDNを受け取るための拒否を示す「禁止」。「禁止」状態は、そうするように構成されている仲介者によって送信されます。たとえば、管理者はIMDNを禁止しています。
o "error" to indicate an error in determining the fate of an IM.
o IMの運命を決定する際のエラーを示す「エラー」。
The display notification type indicates whether or not the IM Recipient rendered the IM to the user. The display notification type can have the following states:
表示通知タイプは、IMの受信者がIMをユーザーにレンダリングしたかどうかを示します。表示通知タイプには、次の状態を持つことができます。
o "displayed" to indicate that the IM has been rendered to the user.
o IMがユーザーにレンダリングされたことを示すために「表示されました」。
o "forbidden" to indicate denial, by the IM Recipient, for the IM Sender to receive the requested IMDN.
o IMの受信者による否定を示す「禁止」は、IM送信者が要求されたIMDNを受け取るために。
o "error" to indicate an error in determining the fate of an IM.
o IMの運命を決定する際のエラーを示す「エラー」。
In addition to text, some IMs may contain audio, video, and still images. Therefore, the state "displayed" includes the start of rendering the audio or video file to the user.
テキストに加えて、一部のIMSにはオーディオ、ビデオ、静止画像が含まれている場合があります。したがって、「表示された」状態には、オーディオまたはビデオファイルをユーザーにレンダリングする開始が含まれます。
Since there is no positive acknowledgement from the user, one cannot determine if the user actually read the IM. Thus, one cannot use the protocol described here as a service to prove someone actually read the IM.
ユーザーからの肯定的な承認はないため、ユーザーが実際にIMを読むかどうかを判断することはできません。したがって、ここで説明したプロトコルを、誰かが実際にIMを読むことを証明するサービスとして使用することはできません。
This specification extends the CPIM data format specified in RFC 3862 [RFC3862]. A new namespace is created as well as a number of new CPIM header fields.
この仕様は、RFC 3862 [RFC3862]で指定されたCPIMデータ形式を拡張します。新しい名前空間と、多くの新しいCPIMヘッダーフィールドが作成されます。
Per CPIM [RFC3862], this specification defines a new namespace for the CPIM extension header fields defined in the following sections. The namespace is:
CPIM [RFC3862]ごとに、この仕様は、次のセクションで定義されているCPIM拡張ヘッダーフィールドの新しい名前空間を定義します。名前空間は次のとおりです。
urn:ietf:params:imdn
As per CPIM [RFC3862] requirements, the new header fields defined in the following sections are prepended, in CPIM messages, by a prefix assigned to the URN through the NS header field of the CPIM message. The remainder of this specification always assumes an NS header field like this one:
CPIM [RFC3862]要件に従って、次のセクションで定義されている新しいヘッダーフィールドは、CPIMメッセージで、CPIMメッセージのNSヘッダーフィールドを介してURNに割り当てられたプレフィックスによって準備されます。この仕様の残りの部分は、常に次のようなNSヘッダーフィールドを想定しています。
NS: imdn <urn:ietf:params:imdn>.
ns：imdb <urn：ietf：params：imdb>。
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のIMSIPEINTからIMDNを受け取るという欲求を示すために、気質 - 解釈ヘッダーフィールドを含める必要があります。セクション10では、構文を定義しています。
The IM Sender MUST include the Message-ID header field in the IM for which he wishes to receive an IMDN. The Message-ID contains a globally unique message identifier that the IM Sender can use to correlate received IMDNs. Because the Message-ID is used by the sender to correlate IMDNs with their respective IMs, the Message-ID MUST be selected so that:
IM送信者は、IMDNを受け取りたいIMにメッセージ-IDヘッダーフィールドを含める必要があります。メッセージIDには、IM送信者が受信したIMDNを相関させるために使用できるグローバルに一意のメッセージ識別子が含まれています。Message-IDは、送信者がIMDNをそれぞれのIMSと相関させるために使用するため、次のようにメッセージを選択する必要があります。
o There is a minimal chance of any two Message-IDs accidentally colliding during the time period within which an IMDN might be received.
o IMDNが受信される可能性のある期間中、任意の2つのメッセージIDが誤って衝突する可能性は最小限に抑えられます。
o It is prohibitive for an attacker who has seen one or more valid Message-IDs to generate additional valid Message-IDs.
o 1つまたは複数の有効なメッセージIDを見て、追加の有効なメッセージIDを生成する攻撃者にとっては禁止されています。
The first requirement is a correctness requirement to ensure correct matching by the sender. The second requirement prevents off-path attackers from forging IMDNs. In order to meet both of these requirements, it is RECOMMENDED that Message-IDs be generated using a cryptographically secure, pseudo-random number generator and contain at least 64 bits of randomness, thus reducing the chance of a successful guessing attack to n/2^64, where n is the number of outstanding valid messages.
最初の要件は、送信者による正しいマッチングを確保するための正確性要件です。2番目の要件では、パスオフパス攻撃者がIMDNSを偽造するのを防ぎます。これらの両方の要件を満たすために、メッセージ-IDを暗号化された擬似ランダム数ジェネレーターを使用して生成し、少なくとも64ビットのランダム性を含むことをお勧めします。^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に挿入する場合があります。元のフィールドの値は、IMレシーバーのアドレスでなければなりません。IMレシピエントは、このヘッダーを使用して、IMDNSの元のIMアドレスを示します。IMレシピエントは、IMDNの<Original-Recipient-uri>要素を登録することにより、これを行います。仲介者がCPIMをヘッダーフィールド値に変更した場合、中間はこのヘッダーを挿入する必要があります。ヘッダーフィールドは、IMに複数回表示してはなりません。仲介者は、すでに存在している場合、このヘッダーフィールド値を変更してはなりません。セクション10では、構文を定義しています。
An intermediary MAY insert an IMDN-Record-Route header field to the IM. This enables the intermediary to receive and process the IMDN on its way back to the IM Sender. The value of the IMDN-Record-Route header field MUST be the address of the intermediary. Multiple IMDN-Record-Route header fields can appear in an IM. Section 10 defines the syntax.
仲介者は、IMDN-Record-RouteヘッダーフィールドをIMに挿入する場合があります。これにより、仲介者はIMDNをIMDNに戻る途中で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を作成すると、IMレシピエントはIMDN-Record-Routeヘッダーを対応するIMDN-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送信者がIMDNの受信を要求する場合、IM送信者にはメッセージIDヘッダーフィールドを含める必要があります。このヘッダーフィールドにより、IM送信者は、IMDNを対応するIMSと一致させることができます。メッセージ-IDの一意性要件については、セクション6.3を参照してください。
Some devices are not able to retain state over long periods. For example, mobile devices may have memory or battery limits. Such limits mean these devices may not be able to, or may choose not to, keep sent messages for the purposes of correlating IMDNs with sent IMs. To make some use of IMDN in this case, we add a time stamp to the IM to indicate when the user sent the message. The IMDN returns this time stamp to enable the user to correlate the IM with the IMDN at the human level. We use the DateTime CPIM header field for this purpose. Thus, if the IM Sender would like an IMDN, the IM Sender MUST include the DateTime CPIM header field.
一部のデバイスは、長期にわたって状態を保持することができません。たとえば、モバイルデバイスにはメモリまたはバッテリーの制限がある場合があります。このような制限は、これらのデバイスがIMDNを送信されたIMSと相関させる目的で送信されたメッセージを保持できない、または選択しない場合があることを意味します。この場合にIMDNをある程度使用するために、ユーザーがメッセージを送信した時期を示すために、IMにタイムスタンプを追加します。IMDNはこのタイムスタンプを返し、ユーザーがIMを人間レベルでIMDNと相関させることができるようにします。この目的のために、DateTime CPIMヘッダーフィールドを使用します。したがって、IM送信者がIMDNを希望する場合、IM送信者にはDateTime CPIMヘッダーフィールドを含める必要があります。
The Disposition-Notification conveys the type of disposition notification requested by the IM Sender. There are three types of disposition notification: delivery, processing, and display. The delivery notification is further subdivided into failure and success delivery notifications. An IM Sender requests failure delivery notification by including a Disposition-Notification header field with value "negative-delivery". Similarly, a success notification is requested by including a Disposition-Notification header field with value "positive-delivery". The IM Sender can request both types of delivery notifications for the same IM.
気質 - 解釈は、IM送信者から要求された処分通知のタイプを伝えます。処分通知には、配信、処理、ディスプレイの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送信者がIMDNを要求していないことを示しています。気質 - 解釈ヘッダーフィールド値は、コンマセパートされています。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
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ヘッダーフィールド値をIMDNのボディの<メッセージID>要素値と一致させることにより、IMDNをIMに一致させます。IMが複数の受信者に配信された場合、IM送信者は、IMDNのXMLボディの<sipicateient-uri>要素と<original-recipient-uri>要素を使用して、IMが複数の受信者に送信されたかどうかを判断します。IMDNを送信したIM受信者を識別するため。
An IM Sender can determine an IMDN is a disposition notification by noting if the Content-Disposition in the IMDN is "notification". This does mean the IM Sender MUST understand the Content-Disposition MIME header in CPIM messages.
IM送信者は、IMDNがIMDNのコンテンツ偏見が「通知」であるかどうかに注意することにより、気質通知であると判断できます。これは、IM送信者がCPIMメッセージのコンテンツ偏位MIMEヘッダーを理解する必要があることを意味します。
This specification does not mandate the IM Sender to keep state for a sent IM.
この仕様では、送信者が送信されたIMの状態を維持するようにIM送信者を義務付けていません。
Once an IM Sender sends an IM containing an IMDN request, it MAY preserve the IM context (principally the Message-ID), other user-identifiable information such as the IM subject or content, and the date and time it was sent. Without preservation of the IM context, the IM Sender will not be able to correlate the IMDN with the IM it sent. The IM Sender may find it impossible to preserve IM state if it has limited resources or does not have non-volatile memory and then loses power.
IM送信者がIMDN要求を含むIMを送信すると、IMコンテキスト（主にメッセージID）、IMの主題やコンテンツなどの他のユーザー識別可能な情報、および送信された日時を保持する場合があります。IMコンテキストを保存しないと、IM送信者はIMDNを送信したIMと相関させることができません。IM送信者は、リソースが限られている場合、または不揮発性メモリがなく、その後パワーを失う場合、IM状態を保存することは不可能だと感じるかもしれません。
There is, however, the concept of a "Sent Items" box in an application that stores sent IMs. This "Sent Items" box has the necessary information and may have a fancy user interface indicating the state of a sent IM. A unique Message-ID for this purpose proves to be useful. The length of time for items to remain in the "Sent Items" box is a user choice. The user is usually free to keep or delete items from the "Sent Items" box as she pleases or as the memory on the device reaches capacity.
ただし、IMSを送信したアプリケーションに「送信されたアイテム」ボックスの概念があります。この「送信アイテム」ボックスには必要な情報があり、送信されたIMの状態を示す派手なユーザーインターフェイスがある場合があります。この目的のためのユニークなメッセージIDは、有用であることがわかります。アイテムが「送信されたアイテム」ボックスに残る時間の長さは、ユーザーの選択です。通常、ユーザーは、「Items」ボックスからアイテムを自由に保持または削除することができます。
Clearly, if an IM Sender loses its sent items state (for example, the user deletes items from the "Sent Items" box), the client may use a different display strategy in response to apparently unsolicited IMDNs.
明らかに、IM送信者が送信されたアイテム状態を失った場合（たとえば、ユーザーは「送信されたアイテム」ボックスからアイテムを削除します）、クライアントは、明らかに未承諾IMDNに応答して異なるディスプレイ戦略を使用できます。
This specification also does not mandate an IM Sender to run any timers waiting for an IMDN. There are no time limits regarding when IMDNs may be received.
この仕様では、IMDNを待っているタイマーを実行することをIM送信者に義務付けません。IMDNがいつ受信されるかに関して、時間制限はありません。
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に戻す理由です。これにより、ユーザーは送信されたものを覚えておく機会が与えられます。たとえば、IMDNが午後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送信者は、1つのトランスポートプロトコルメッセージ（通常はURI-Listサーバー[RFC5365]を使用）で複数の受信者にIMを送信し、IMDNを要求する場合があります。IMDNSを要求したIM送信者は、複数の集計または非凝集したIMDNを受信するために準備する必要があります。詳細については、セクション8.3を参照してください。
IM Recipients examine the contents of the Disposition-Notification header field of the CPIM message to determine if the recipient needs to generate an IMDN for that IM. Disposition-Notification header fields of CPIM messages can include one or more values. IM Recipients may need to generate zero, one, or more IMDNs for that IM, for example, a delivery notification as well as a display notification. In this case, the IM Recipient MUST be able to construct multiple IMDNs per IM. An IM Recipient MUST NOT construct more than one IMDN per disposition type. That is, it must not generate a delivery notification indicating "delivered" followed by a delivery notification indicating "failed" for the same IM. If the IM Sender requested only failure notifications and the IM was successfully delivered, then no IMDNs will be generated. If the IM Recipient does not understand a value of the Disposition-Notification header field, the IM Recipient ignores that value.
IMレシピエントは、CPIMメッセージの気質 - 解釈ヘッダーフィールドの内容を調べて、受信者がそのIMのIMDNを生成する必要があるかどうかを判断します。CPIMメッセージの処分 - 解釈ヘッダーフィールドには、1つ以上の値を含めることができます。IM受信者は、そのIMのゼロ、1つ、またはそれ以上のIMDNを生成する必要がある場合があります。たとえば、配信通知とディスプレイ通知などです。この場合、IMレシピエントはIMごとに複数のIMDNを構築できる必要があります。IM受信者は、処分タイプごとに複数のIMDNを構築してはなりません。つまり、「配信」を示す配信通知を生成してはならない後、同じIMの「失敗」を示す配信通知を示してはなりません。IM送信者が障害通知のみを要求し、IMが正常に配信された場合、IMDNは生成されません。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のMessage-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には、IMDN-Record-Routeヘッダーフィールドが含まれる場合があります（詳細については、セクション8を参照）。IMDN-Record-routeヘッダーフィールドがIMに表示される場合、IMDNを構築するIMレシピエントは、IMDN-Record-Routeヘッダーフィールドの内容をIMDNのIMDN-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 Headerフィールドの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の受信者は、コンテンツディスポジションヘッダーフィールドを値「通知」に設定する必要があります。これは、メッセージが以前に送信した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レシピエントは、セクション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: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<delivery-notification>
<status>
<delivered/>
</status>
</delivery-notification>
</imdn>
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: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<display-notification>
<status>
<displayed/>
</status>
</display-notification>
</imdn>
There are situations where the IM Recipient cannot determine if or when the IM has been displayed. The IM Recipient in this case generates a display notification with a <status> value of "error" to indicate an internal error by the server. Note that the IM Recipient may choose to ignore any IMDN requests and not send any IMDNs. An IM 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.
IMの受信者がIMが表示されたかどうか、またはいつ表示されたかを判断できない状況があります。この場合のIM受信者は、「エラー」の<ステータス>値を持つディスプレイ通知を生成して、サーバーによる内部エラーを示します。IM受信者は、IMDNリクエストを無視し、IMDNを送信しないことを選択する場合があることに注意してください。IMの受信者は、特定のメッセージが表示されているかどうかを送信者に知らせたくない場合があります。これは、精神ごと、センダーごと、またはプログラムされたポリシーの選択である可能性があります。
In this context, intermediaries are application servers (including URI-List and store-and-forward servers) and gateways. A gateway is a server that translates between different IM systems that use different protocols.
これに関連して、仲介業者はアプリケーションサーバー（URIリストとストアアンドフォワードサーバーを含む）およびゲートウェイです。ゲートウェイは、異なるプロトコルを使用する異なるIMシステム間で変換するサーバーです。
A URI-List server may change the IM Recipient address from its own to the address of the final recipient of that IM for every copy it makes that it sends to the list members (see [RFC5365] for details). In this case, if the IM Sender is requesting an IMDN, the intermediary SHOULD add an Original-To header field to the IM, populating it with the address that was in the CPIM To header field before it was changed. That is, the intermediary populates the Original-To header field with the intermediary address. Of course, one may configure an intermediary to restrict it from rewriting or populating the Original-To field. An intermediary MUST NOT add an Original-To header field if one already exists. An intermediary MAY have an administrative configuration to not reveal the original Request-URI, and as such, MUST NOT add an Original-To header.
URI-Listサーバーは、IM受信者アドレスを独自から、リストメンバーに送信するすべてのコピーに対して、そのIMの最終受信者のアドレスに変更する場合があります（詳細については[RFC5365]を参照）。この場合、IM送信者がIMDNを要求している場合、仲介者はIMに元のヘッダーフィールドを追加し、CPIMにあるアドレスが変更される前にヘッダーフィールドに浸透する必要があります。つまり、仲介者は、元のヘッダーフィールドに中間住所に浸透します。もちろん、元のフィールドへの書き換えまたは居住を制限するように仲介者を構成する場合があります。仲介者は、すでに存在する場合は元のヘッダーフィールドを追加してはなりません。仲介者は、元のリクエストURIを明らかにしないように管理構成を備えている可能性があるため、元のヘッダーを追加してはなりません。
An IM reply for a page-mode IM is not linked in any way to the initial IM and can end up at a different user agent from where the initial IM originated, depending on how the recipient URI gets resolved. Therefore, IM replies may traverse different intermediaries. An IMDN, on the other hand, needs to traverse the same intermediaries as the IM itself since those intermediaries may be required to report negative delivery notifications if the IM was not delivered successfully. Some of those intermediaries are, for example, store-and-forward servers that may report that an IM has been processed and later report that the IM has failed to be delivered.
ページモードIMのIM返信は、初期のIMにどのような方法でもリンクされておらず、受信者のURIがどのように解決されるかに応じて、最初のIMが発生した別のユーザーエージェントになります。したがって、IMは異なる仲介者を通過する可能性があります。一方、IMDNは、IMが正常に配信されなかった場合、それらの仲介者は負の配信通知を報告する必要があるため、IM自体と同じ仲介者を横断する必要があります。これらの仲介者の一部は、たとえば、IMが処理されたことを報告し、後にIMが配信されなかったことを報告する可能性のあるストアアンドフォワードサーバーです。
For the reasons stated above, an intermediary MAY choose to remain on the path of IMDNs for a specific IM. It can do so by adding a CPIM IMDN-Record-Route header field as the top IMDN-Record-Route header field. The value of this field MUST be the intermediary's own address. An intermediary that does not support this extension will obviously not add the IMDN-Record-Route header field. This allows IMDNs to traverse directly from the IM Recipient to the IM Sender even if the IM traversed an intermediary not supporting this extension.
上記の理由により、仲介者は特定のIMのIMDNSの経路にとどまることを選択する場合があります。CPIM IMDN-Record-RouteヘッダーフィールドをトップIMDN-Record-Routeヘッダーフィールドに追加することでそうすることができます。このフィールドの価値は、仲介者自身の住所でなければなりません。この拡張機能をサポートしない仲介者は、明らかにIMDN-Record-Routeヘッダーフィールドを追加しません。これにより、IMDNは、IMがこの拡張機能をサポートしていない仲介者を横断した場合でも、IMレシピエントからIM送信者に直接移動できます。
An intermediary receiving an IMDN checks the top IMDN-Route header field. If that header field carries the intermediary address, the intermediary removes that value and forwards the IMDN to the address indicated in the new top IMDN-Route header field. If no additional IMDN-Route header fields are present, the IMDN is forwarded to the address in the CPIM To header field.
IMDNを受け取った仲介者は、IMDNルートのトップヘッダーフィールドをチェックします。そのヘッダーフィールドに中間住所がある場合、仲介者はその値を削除し、IMDNを新しいTOP IMDN-Routeヘッダーフィールドに示されているアドレスに転送します。追加の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.
リストメンバーシップが開示されていない場合、仲介者はリストの最終受信者に関する情報を削除する必要があります。仲介者は、IMDNの本体から<受信者> uri>要素および/または<original-recipient-uri>要素を削除してから、それをIM送信者に転送することにより、それを行います。
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が「処理」されていることを示す「処理」通知を送信してはなりません。
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: ...
<?xml version="1.0" encoding="UTF-8"?>
<imdn xmlns="urn:ietf:params:xml:ns:imdn">
<message-id>34jk324j</message-id>
<datetime>2008-04-04T12:16:49-05:00</datetime>
<recipient-uri>im:bob@example.com</recipient-uri>
<original-recipient-uri
>im:bob@example.com</original-recipient-uri>
<processing-notification>
<status>
<processed/>
</status>
</processing-notification>
</imdn>
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送信者が、値「ネガティブ配信」を備えた処分notificationヘッダーフィールドを含めることにより「ネガティブ配信」通知を要求した場合にのみそうします。
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が失敗したことを示す「失敗した」通知を送信してはなりません。
An intermediary constructs a "negative-delivery" notification much like the IM Recipient. See Section 7.2.1.1 for details.
仲介者は、IMの受信者のように「ネガティブ配信」通知を構築します。詳細については、セクション7.2.1.1を参照してください。
As previously described, URI-List servers are intermediaries.
前述のように、URIリストサーバーは仲介者です。
A URI-List server may choose (using local policy) to aggregate IMDNs or it may send individual IMDNs instead. When a URI-List server receives an IM and decides to aggregate IMDNs, it can wait for a configurable period of time or until all recipients have sent the IMDN, whichever comes first, before it sends an aggregated IMDN. Note that some IMDNs, for example "displayed" notifications, may never come due to user settings. How long to wait before sending an aggregated IMDN and before a URI-List server removes state for that IM is an administrator configuration and implementation issue.
URIリストサーバーは、（ローカルポリシーを使用して）IMDNを集約するか、代わりに個々のIMDNを送信する場合があります。URI-ListサーバーがIMを受信し、IMDNを集約することを決定した場合、構成可能な期間を待つことができます。一部のIMDNは、たとえば「表示された」通知など、ユーザー設定のためには決して来ない場合があることに注意してください。集約されたIMDNを送信するまで、およびURIリストサーバーがそのために状態を削除するまでに待機する時間は、IMが管理者の構成と実装の問題です。
A URI-List server MAY choose to send multiple aggregated IMDNs. A timer can be started, and when it fires, the URI-List server can aggregate whatever IMDNs it has so far for that IM, send the aggregated IMDN, and restart the timer for the next batch. This is needed for scenarios where the IM Sender has requested more than one 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.
URIリストサーバーは、複数の集約されたIMDNを送信することを選択できます。タイマーを開始でき、URI-Listサーバーが発火すると、これまでのIMDNが何であれ、集約されたIMDNを送信し、次のバッチのタイマーを再起動できます。これは、IM送信者が特定のIMに複数のIMDNを要求したシナリオ（たとえば配信通知や表示通知）に必要な場合、またはURI-Listサーバーがリソースが不足している場合、IMSの転送の優先順位付けを選択する場合に必要です。IMDNS上。
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.
2番目のタイマーが実行される可能性があり、それが発火すると、IMの状態が削除されます。この場合、URI-Listサーバーは、その間に到着する可能性のあるIMDNを消費します。
Please note the references to timers in the above paragraphs are not normative and are only present to help describe one way one might implement aggregation.
上記の段落のタイマーへの参照は規範的ではなく、集約を実装する可能性のある1つの方法を説明するのに役立つためにのみ存在します。
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リストサーバーは、リストメンバーシップ情報が開示されていない場合にIMDNを集約できます。URI-Listサーバーが集約されたIMDNとスイッチを個々のものに送信し始めるシナリオがある場合があります。多くの場合、タイマーの発砲は実際にその効果があるかもしれません。
The aggregated IMDN is constructed using the multipart/mixed MIME type and including as individual payloads all the IMDNS that were received as message/imdn+xml.
集約されたIMDNは、マルチパート/混合MIMEタイプを使用して構築され、メッセージ/IMDN XMLとして受信されたすべてのIMDNを個々のペイロードとして含めます。
Below is an example of aggregated IMDNs.
以下は、集約されたIMDNの例です。
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: ...
--imdn-boundary Content-type: message/imdn+xml
-imdb結合コンテンツタイプ：メッセージ/in 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/>
</status>
</delivery-notification>
</imdn>
--imdn-boundary Content-type: message/imdn+xml
-imdb結合コンテンツタイプ：メッセージ/in 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>
--imdn-boundary
-imdn-boundary
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」の値を持っている場合、コンテンツ配置ヘッダーフィールドの値が「通知」の値を持ち、<配信-Notification>要素が表示され、その中に表示される場合、メッセージは配信通知です。XMLボディ。
A message is identified as a processing notification or display notification in a similar fashion as a delivery notification. The difference is that, for a processing notification, the <processing-notification> element appears in the XML body. For a display notification, the <display-notification> element appears in the XML body.
メッセージは、配信通知と同様の方法で、処理通知または表示通知として識別されます。違いは、処理通知の場合、<processing-notification>要素がXMLボディに表示されることです。ディスプレイ通知の場合、<display-notification>要素が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)
disp-notify-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
COMMA = *SP "," *SP ; comma
An IMDN payload is an XML document [XML] that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. The IMDN payload MUST be based on XML 1.0 and MUST be encoded using UTF-8.
IMDNペイロードは、XMLドキュメント[XML]であり、適切に形成されている必要があり、拡張スキーマを含むスキーマに従って有効でなければなりません。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.
スキーマは、「urn：ietf：params：xml：ns：imdn」名前空間以外のいくつかの位置で適格な拡張要素を許可します。フォワードの互換性（つまり、新しいインスタンスドキュメントを既存の消費者が使用できます）を維持するために、新しい仕様はこの仕様の許容コンテンツを拡張してはなりません。逆方向の互換性（つまり、既存のインスタンスドキュメントは、更新された新しい消費者でも使用できます）は、拡張要素の既存の適格名と将来の仕様の可能性と競合する場合に壊れる場合があります。IETFは、「urn：ietf：params：xml：ns： "の「サブネームスペース」内の新しい拡張要素を指定する場合があります。
Possible future specifications can add new element definitions with the combine="interleave" pattern. When multiple elements of this new type are then allowed, the new definition MUST contain the <zeroOrMore> cardinality rule. If the new specification does allow only a single new element, the <optional> cardinality rule MUST be used. These cardinality requirements maintain the backwards compatibility of existing instance documents with newer consumers. Also, the new specification MUST then redefine either the "anyIMDN" extension or the individual extension points that reference it, so that new element definitions do not match with this redefined and more limited wildcard pattern.
将来の仕様の可能性は、combine = "Interleave"パターンで新しい要素定義を追加できます。この新しいタイプの複数の要素が許可されている場合、新しい定義には<Zeroormore> Cardinalityルールが含まれている必要があります。新しい仕様で1つの新しい要素のみが許可されている場合、<optional> Cardinalityルールを使用する必要があります。これらのカーディナリティの要件は、既存のインスタンスドキュメントの新しい消費者との後方互換性を維持しています。また、新しい仕様では、「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は：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>、<dateTime>、<seciolient-uri>、<original-recipient-uri>、<axpument>、<delivery-notification>、<処理の1つ-notification>、または<display-notification>。<ステータス>は、<Defily-Notification>、<Processing-notification>、<display-notification>のサブ要素としても表示されます。要素については、次のセクションで詳しく説明します。
<imdn> can be extended in the future to include new disposition notification types or other elements, as described in Section 11.1.9.
<IMDN>は、セクション11.1.9で説明されているように、将来、新しい気質通知タイプまたはその他の要素を含めることができます。
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.
<message-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.
<DateTime>要素は必須であり、IMが送信された日付と時刻（IMDNではなく）を運びます。この情報は、IMのDateTimeヘッダーフィールドから取得されます。
The <recipient-uri> element is optional and carries the URI of the final recipient. This information is obtained from the CPIM To header field of the IM.
<受信者 - uri>要素はオプションであり、最終受信者のURIを運びます。この情報は、CPIMからIMのヘッダーフィールドまで取得されます。
The <original-recipient-uri> element is optional and carries the URI of the original recipient. It MUST be present if the IM carried the Original-To header field. This information is obtained from the Original-To header field of the IM.
<original-recipient-uri>要素はオプションであり、元の受信者のURIを運びます。IMが元のヘッダーフィールドを運んだ場合、存在する必要があります。この情報は、IMの元のヘッダーフィールドから取得されます。
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.
<thumber>要素はオプションです。存在する場合は、件名ヘッダーフィールドにあったテキストと言語の属性がある場合は、存在する必要があります。これにより、IMとIMDNの間の人間レベルの相関が可能になります。IMに複数のサブジェクトヘッダーフィールドがある場合、IMDN Payloadに配置するようにそれらのいずれかを選択してください<taxument>要素で十分です。その後、送信者は、マッチまたはマッチが決定されるまで、サブジェクトヘッダーフィールドを比較する必要があります。
11.1.6. The <delivery-notification>, <processing-notification>, and
<display-notification> Elements
The appearance of one of the <delivery-notification>, <processing-notification>, and <display-notification> elements is mandatory and carries the disposition type that the IM Sender requested and is being reported. It carries the sub-element <status>.
<配信-notification>、<process-notification>、および<display-notification>要素の1つの外観は必須であり、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>,
<status>要素は必須であり、処分要求の結果を伝えます。通知タイプ<配信-Notification>の場合、サブエレメントの1つを<配信>、<Failed>、<Forbidden>、または<Error>を運ぶことができます。通知タイプ<display-notification>の場合、サブエレメントの1つを<displased>、<forbidden>、または<エラー>を運ぶことができます。通知タイプ<Processing-notification>の場合、サブエレメントの1つを<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.
<Stored>、<Forbidden>、または<Error>。<禁止>は、性質が拒否されたことを意味します。<エラー>は、内部サーバーエラーを意味します。<status>要素を拡張して、他のステータス拡張機能を搭載することもできます。
The MIME type for the IMDN payload is "message/imdn+xml". The IMDN MUST identify the payload as MIME type "message/imdn+xml" in the Content-type header field.
IMDNペイロードのMIMEタイプは「メッセージ/IMDN XML」です。IMDNは、コンテンツタイプのヘッダーフィールドで、ペイロードを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">
<start>
<element name="imdn">
<element name="message-id">
<data type="token"/>
</element>
<element name="datetime">
<data type="string"/>
</element>
<optional>
<element name="recipient-uri">
<data type="anyURI"/>
</element>
<element name="original-recipient-uri">
<data type="anyURI"/>
</element>
<optional>
<element name="subject">
<data type="string"/>
</element>
</optional>
</optional>
<choice>
<ref name="deliveryNotification"/>
<ref name="displayNotification"/>
<ref name="processingNotification"/>
<empty/>
</choice>
<ref name="imdnExtension"/>
</element>
</start>
</start>
<define name="deliveryNotification">
<element name="delivery-notification">
<element name="status">
<choice>
<element name="delivered">
<empty/>
</element>
<element name="failed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="deliveryExtension"/>
</element>
</element>
</define>
<define name="displayNotification">
<element name="display-notification">
<element name="status">
<choice>
<element name="displayed">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="displayExtension"/>
</element>
</element>
</define>
<define name="processingNotification">
<element name="processing-notification">
<element name="status">
<choice>
<element name="processed">
<empty/>
</element>
<element name="stored">
<empty/>
</element>
<ref name="commonDispositionStatus"></ref>
</choice>
<ref name="processingExtension"/>
</element>
</element>
</define>
</define>
<define name="commonDispositionStatus">
<choice>
<element name="forbidden">
<empty/>
</element>
<element name="error">
<empty/>
</element>
</choice>
</define>
<!-- <imdn> extension point for the extension schemas to add
new definitions with the combine="interleave" pattern.
Extension schemas should add proper cardinalities. For
example, the <zeroOrMore> cardinality should be used if
the extension is to allow multiple elements, and the
<optional> cardinality should be used if the extension
is to allow a single optional element. -->
<define name="imdnExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- delivery-notification <status> extension point -->
<define name="deliveryExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- display-notification <status> extension point -->
<define name="displayExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- processing-notification <status> extension point -->
<define name="processingExtension">
<zeroOrMore>
<ref name="anyIMDN"/>
</zeroOrMore>
</define>
<!-- wildcard definition for complex elements (of mixed type)
unqualified or qualified in the imdn namespace.
Extension schemas MUST redefine this or the
individual, previous definitions that use this definition.
In other words, the extension schema MUST reduce the
allowable content in order to maintain deterministic
and unambiguous schemas with the interleave pattern. -->
<define name="anyIMDN">
<element>
<anyName>
<except>
<nsName ns="urn:ietf:params:xml:ns:imdn"/>
<nsName ns=""/>
</except>
</anyName>
<ref name="anyExtension"/>
</element>
</define>
<!-- the rest of the "anyIMDN" wildcard definition -->
<define name="anyExtension">
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<ref name="any"/>
</choice>
</zeroOrMore>
</define>
<!-- wildcard type for complex elements (of mixed type)
without any namespace or content restrictions -->
<define name="any">
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="any"/>
</choice>
</zeroOrMore>
</element>
</define>
</grammar>
</grammar>
The IM Sender constructs a SIP MESSAGE request using RFC 3428 [RFC3428]. The Content-type header field indicates the MIME type of the request payload. When using this extension, the Content-type header field MUST be of MIME type "message/cpim" [RFC3862] for both IMs and IMDNs. The IM Sender constructs the payload according to Section 7.
IM送信者は、RFC 3428 [RFC3428]を使用してSIPメッセージ要求を構築します。コンテンツタイプのヘッダーフィールドは、リクエストペイロードのMIMEタイプを示します。この拡張機能を使用する場合、コンテンツタイプのヘッダーフィールドは、IMSとIMDNの両方に対して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メッセージ要求を1人の受信者にSIPメッセージ要求と同様に構築します。「SIPでの多反心のメッセージ要求」[RFC5365]は、違いを説明しています。
IM Senders can remain anonymous. For example, the sender can set the SIP From header field of the SIP message to an anonymous URI. As there is no return address, anonymous IM Senders SHOULD NOT request disposition notifications. An IM Recipient MAY ignore such a request if the IM Sender is anonymous.
IM送信者は匿名のままでいることができます。たとえば、送信者は、SIPメッセージのヘッダーフィールドから匿名のURIに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メッセージ要求を受信するエンドポイントは、RFC 3428 [RFC3428]に従ってSIP応答を構築します。もちろん、エンドポイントは、受信したメッセージの種類（IMまたはIMDN）または尋ねられた処分タイプに関係なく、メッセージ要求にSIP応答を送信します。
A SIP MESSAGE request is identified as an IM by examining its contents according to Section 9.
SIPメッセージ要求は、セクション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の受信者が、肯定的な配信通知を要求するSIPメッセージリクエストを受け取った場合、IM受信者がSIP 2XXクラスの応答を構築して送信した場合、IMが確認されたことを確認した後に肯定的な配信通知を生成する可能性があります。ユーザーまたはアプリケーションに配信されます。たとえば、ゲートウェイは、最終受信者がIMを受信する前に2xx応答を生成できます。IMレシピエントは、セクション7.2.1.1に従って正配信通知を構築します。IMレシピエントは、メッセージをペイロードとしてSIPメッセージリクエストに配置します。
If an IM Recipient received a SIP MESSAGE request that is an IM requesting a negative-delivery, and that IM Recipient has constructed and sent a 2xx class response, it SHOULD generate a negative-delivery notification if it learnt that the final recipient or application did not receive the IM (a gateway, for example, can generate a 2xx response before it has an error response from downstream or before any internal timers fire waiting for a response). The negative-delivery notification is constructed according to Section 7.2.1.1. The message is then placed as the payload in a SIP MESSAGE request.
IMの受信者が、負の配信を要求するIMであるSIPメッセージリクエストを受け取った場合、IM受信者が2xxクラスの応答を構築して送信した場合、最終受信者またはアプリケーションが行ったことがわかった場合、ネガティブ配信通知を生成するはずです。IMを受信しません（たとえば、ゲートウェイは、下流からのエラー応答が発生したり、内部タイマーが応答を待っている前に2xx応答を生成できます）。負の配信通知は、セクション7.2.1.1に従って構築されます。メッセージは、SIPメッセージリクエストにペイロードとして配置されます。
If an IM Recipient received a SIP MESSAGE request that is an IM requesting a negative-delivery notification, and the IM Recipient has constructed and sent a non-2xx final response, it MUST NOT generate a negative-delivery notification.
IMの受信者が、負の配信通知を要求する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をリクエストしているIM受信者がSIP 2XXクラスの応答を構築して送信したSIPメッセージリクエストを受け取った場合、IMがユーザーに提示されたことを確認した後にディスプレイ通知を生成する可能性があります。またはアプリケーション。この文書の範囲外で、IMが読み取られたかどうかを決定する方法を議論することができます。ディスプレイ通知を送信するかどうかの決定は、ユーザーに任せることができることに注意してください。アプリケーションを使用すると、ユーザーがそのような選択を構成できる場合があります。IMレシピエントは、セクション7.2.1.2に従ってディスプレイ通知を構築します。IMレシピエントは、メッセージをペイロードとしてSIPメッセージリクエストに配置します。
For IMDNs, the IM Recipient populates the SIP Request-URI and the SIP To header field using the address that appeared in the SIP From header field in the IM.
IMDNSの場合、IMレシピエントは、IMのヘッダーフィールドからSIPに表示されたアドレスを使用して、SIPリクエスト-URIとSIPからヘッダーフィールドへのSIPに浸透します。
A SIP MESSAGE request is identified as a delivery notification by examining its contents according to Section 9.
SIPメッセージ要求は、セクション9に従ってその内容を調べることにより、配信通知として識別されます。
A SIP MESSAGE request is identified as a display notification by examining its contents according to Section 9.
SIPメッセージ要求は、セクション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リストとストアアンドフォワードサーバーを含む）とゲートウェイが含まれます。SIPプロキシはIMDNを生成してはなりませんが、他のSIPリクエストと同じように転送する必要があります。
Intermediaries forward a SIP MESSAGE request to multiple recipients according to [RFC5365].
仲介者は、[RFC5365]に従って複数の受信者にSIPメッセージ要求を転送します。
If an intermediary receives an IM, the intermediary examines the body. If the body is of type "message/cpim", the intermediary then looks for a Disposition-Notification CPIM header field in the message. If the Disposition-Notification CPIM header field has either the value "positive-delivery" or "negative-delivery", and, in processing the IM, the intermediary generates a SIP 2xx class response to the MESSAGE request, then the intermediary performs the following actions.
仲介者がIMを受け取った場合、仲介者は体を調べます。ボディが「メッセージ/CPIM」というタイプの場合、中間者はメッセージ内の気質 - 解釈CPIMヘッダーフィールドを探します。気質 - 解釈CPIMヘッダーフィールドに値「正配送」または「負の配信」のいずれかがあり、IMを処理する際に、中間はメッセージ要求に対するSIP 2XXクラスの応答を生成する場合、中間は次のことを実行します行動。
If the Disposition-Notification header field contains a value of "positive-delivery", the intermediary MUST NOT generate a delivery notification if it receives a SIP 2xx class response for the sent IM. Just because a downstream entity received a MESSAGE request does not mean the message was relayed to its ultimate destination or was delivered. Thus, the intermediary cannot say delivery occurred just because it received a 2xx response.
気質 - 解釈ヘッダーフィールドに「正配達」の値が含まれている場合、中間監督は送信されたIMのSIP 2XXクラス応答を受信した場合、配信通知を生成してはなりません。ダウンストリームエンティティがメッセージリクエストを受け取ったからといって、メッセージが最終的な目的地に中継されたり、配信されたりしたわけではありません。したがって、仲介者は、2xxの応答を受け取ったからといって、配達が発生したとは言えません。
If the Disposition-Notification header field contains a value of "negative-delivery", the intermediary SHOULD generate a delivery notification if it receives a SIP 4xx, 5xx, or 6xx class final response for the sent IM. If it has received a SIP 2xx class response followed by a negative-delivery notification, the intermediary forwards that negative-delivery notification or aggregates it.
気質 - 解釈ヘッダーフィールドに「ネガティブ配信」の値が含まれている場合、SIP 4XX、5XX、または送信IMの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:
IMに固有の脅威を超えて、IMDNシステムの脅威には、以下が含まれます。
o A malicious endpoint attempts to send messages to a user that would normally not wish to receive messages from that endpoint by convincing the IMDN system to "bounce" an IMDN from an unsuspecting endpoint to the user.
o 悪意のあるエンドポイントは、通常、IMDNシステムに疑いのないエンドポイントからユーザーにIMDNを「バウンス」するように説得することにより、そのエンドポイントからメッセージを受信することを望まないユーザーにメッセージを送信しようとします。
o A malicious endpoint attempts to flood an IM Sender with IMDNs by convincing a URI-List server to send IMDNs to an unsuspecting IM Sender.
o 悪意のあるエンドポイントは、URIリストサーバーにIMDNSを疑いを持たないIM送信者に送信するよう説得することにより、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 悪意のある仲介者またはノードは、FromフィールドまたはIMDN-Record-Routeフィールドにターゲットのアドレスを挿入することにより、ターゲットノードをIMDNSでフラッドしようとします。
o A malicious node in the network attempts to modify an IMDN from an IM Recipient.
o ネットワーク内の悪意のあるノードは、IMDNの受信者からIMDNを変更しようとします。
o A malicious intermediary attempts to forward an IMDN from an IM Recipient to the IM Sender, where the IM Recipient would not normally forward the IMDN to that IM Sender if the IM Recipient knew the identity of the IM Sender.
o 悪意のある仲介者は、IMDNをIMDNをIMDNからIM送信者に転送しようとします。IMの受信者がIMの受信者がIM送信者の身元を知っていれば、IMの受信者は通常IMDNをそのIM送信者に転送しません。
o A malicious endpoint attempts to discover the Request-URI of an endpoint beyond an intermediary, where the endpoint would normally wish to keep its identity private from the malicious endpoint.
o 悪意のあるエンドポイントは、エンドポイントが通常、悪意のあるエンドポイントからアイデンティティをプライベートに保ちたいと考えている仲介者を超えてエンドポイントのリクエストURIを発見しようとします。
o A malicious node in the network attempts to eavesdrop on IMDN traffic to, for example, learn Request-URI or traffic pattern information.
o ネットワーク内の悪意のあるノードは、たとえば、Request-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.
o IMDNに対する削除攻撃。これは、プライバシーとセキュリティのトレードオフです。プライバシーの考慮事項により、IMの受信者はIMDNリクエストを静かに無視することができます。悪意のあるノードがIM受信者のIMDNを削除したことを確実に示しているメカニズムは、IMDNを発行しないことを選択したIM受信者を検出する目的にも役立つことを示しています。
To combat eavesdropping, modification, and man-in-the-middle attacks, we require some level of authentication and integrity protections. That said, there are circumstances where strong integrity would be overkill. The presumption is that the IM Sender has, and sets the expectation for, the level of protection. The procedures for integrity protection are as follows.
盗聴、修正、および中間の攻撃と戦うには、ある程度の認証と整合性の保護が必要です。とはいえ、強い完全性が過剰になる状況があります。推定は、IM送信者が保護のレベルを持っていることを示し、そして設定するということです。整合性保護の手順は次のとおりです。
o If the IM Recipient has a certificate, it MUST sign the IMDN. Signing the IMDN provides integrity protection. While an intermediary can replace the IMDN body, the IM Sender (the recipient of the IMDN) can validate the signature and note the IMDN does not come directly from the IM Receiver. This is not a problem if the IM Sender trusts the intermediary. Likewise, an IMDN in response to a signed IM without a signature indicates something bad might have happened.
o IM受信者が証明書を持っている場合、IMDNに署名する必要があります。IMDNに署名すると、整合性保護が提供されます。仲介者はIMDNボディを置き換えることができますが、IM送信者（IMDNの受信者）は署名を検証し、IMDNがIMレシーバーから直接来ないことに注意することができます。IM送信者が仲介者を信頼している場合、これは問題ではありません。同様に、署名のない署名されたIMに応じたIMDNは、悪いことが起こった可能性があることを示しています。
o If the IM is encrypted, the IM Recipient or intermediary MUST encrypt the IMDN body, as an attacker may attempt to discern the user's activity profile and identity from sniffing IMDNs on the network.
o IMが暗号化されている場合、攻撃者がネットワーク上のIMDNを嗅ぐことからユーザーのアクティビティプロファイルとアイデンティティを識別しようとする場合があるため、IMの受信者または仲介者はIMDNボディを暗号化する必要があります。
o The two above rules are cumulative.
o 上記の2つのルールは累積的です。
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リクエストを使用して多くのIMSをノードに送信することにより、ノードに分散したサービス拒否攻撃を取り付けることができます。これは、IMDNなしと同じ問題であることに注意してください。IMDNは、攻撃下でノードの負荷を直線的に増加させるだけです。エンドポイントによるこの脅威は、認証されていないリクエストをすぐに無視することを緩和できますが、排除することはできません。
One way to address the potential for a malicious node to use the IMDN system to anonymize attacks is to log all IMDN requests on the IM Recipient user agent. This allows for tracking of attacks, if only after they occur. Note this also puts a burden on the IM Recipient user agent host. Limited user agents may not be able to preserve much of a log.
悪意のあるノードがIMDNシステムを使用して攻撃を匿名化する可能性に対処する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.
IMSは偽造できます。それを保護するために、IMに署名することができます。署名されたメッセージを受信し、署名に含まれる部分を変更する必要がある仲介者（CPIMヘッダーフィールドに元のヘッダーフィールドを追加するなど）は、IMを消費し、その中間の新しいコピーを作成する必要があります。それ自体に署名します。
IMDNs may be forged as easily as ordinary IMs. Endpoints and intermediaries that wish to make automatic use of IMDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged IMDNs include the sending of a falsified IMDN when the indicated disposition of the IM has not actually occurred. For example, display notification could be forged to indicate that an IM has been displayed to the Recipient. Unsolicited IMDNs is also another form of forgery.
IMDNは、普通のIMSと同じくらい簡単に偽造される場合があります。IMDNを自動的に使用したいエンドポイントと仲介者は、サービス拒否攻撃による潜在的な損害を最小限に抑えるために適切な予防措置を講じる必要があります。偽造されたIMDNに関連するセキュリティの脅威には、IMの指定された性質が実際に発生していない場合の偽造IMDNの送信が含まれます。たとえば、ディスプレイ通知は、IMが受信者に表示されたことを示すように偽造できます。未承諾IMDNSは、偽造の別の形式でもあります。
There may be cases where an IM Recipient does not wish to reveal that she has received, or in fact read, the IM. In this situation, it is acceptable for the IM Recipient to silently ignore requests for an IMDN. It is strongly RECOMMENDED that the IM Recipient obtain the user's consent before sending an IMDN. Circumstances where the IM Recipient does not ask for the user's consent include IM systems that, for regulatory reasons, are required to issue an IMDN, such as in the health care field or financial community.
IMの受信者が、IMを受け取った、または実際に読んだことを明らかにしたくない場合があります。この状況では、IMの受信者がIMDNのリクエストを静かに無視することは受け入れられます。IMDNを送信する前に、IMの受信者がユーザーの同意を得ることを強くお勧めします。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ごとにプロンプトまたはダイアログボックスによってそのような同意を得ることができます。また、ユーザーは、IMDNが送信されないこと、または「禁止されている」IMDNステータスがIMDNの要求に応じて常に送信されることをグローバルに示している場合があります。
There are situations where a user sends an IM and requests IMDNs to a list whose member information is not disclosed. In this situation, the user will learn of the list members. Therefore, in this case, the URI-List server MUST remove any information about list members. If the number of members in the list is also not disclosed, the URI-List server MUST only deliver one aggregated IMDN. Alternatively, the URI-list server MAY reject the IM.
ユーザーがIMを送信し、メンバー情報が開示されていないリストにIMDNを要求する状況があります。この状況では、ユーザーはリストメンバーについて学びます。したがって、この場合、URI-Listサーバーはリストメンバーに関する情報を削除する必要があります。リスト内のメンバーの数も開示されていない場合、URI-Listサーバーは1つの集約されたIMDNのみを配信する必要があります。あるいは、URI-Listサーバーは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 Headerフィールドがリスト名であり、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に適用される同じレベルのセキュリティをIMDNに適用する必要があります。たとえば、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.
IMDNは、IMがユーザーによって見られた、または見られなかったという保証として依存することはできません。IMDNが積極的に偽造されていなくても、輸送中に失われる可能性があります。さらに、IM受信者は、ユーザーエージェントサーバーのポリシーまたは操作を通じてIMDN発行メカニズムをバイパスする場合があります。
This document registers a new MIME type "message/imdn+xml", and registers a new XML namespace.
このドキュメントは、新しいMIMEタイプ「メッセージ/IMDN XML」を登録し、新しいXMLネームスペースを登録します。
This specification follows the guidelines of RFC 3023 [RFC3023].
この仕様は、RFC 3023 [RFC3023]のガイドラインに従います。
MIME media type: message
MIMEメディアタイプ：メッセージ
MIME subtype name: imdn+xml
MIMEサブタイプ名：IMDN XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [RFC3023].
オプションのパラメーター：RFC 3023 [RFC3023]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
考慮事項のエンコード：RFC 3023 [RFC3023]で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ。
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 14 of this document.
セキュリティ上の考慮事項：RFC 3023 [RFC3023]のセクション10およびこのドキュメントのセクション14を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: This document
公開された仕様：このドキュメント
Applications which use this media type: This media type is used to support CPIM-based instant Messaging.
このメディアタイプを使用するアプリケーション：このメディアタイプは、CPIMベースのインスタントメッセージングをサポートするために使用されます。
Additional information: none
追加情報：なし
Magic number: none File extension: .cl or .xml
マジック番号：なしファイル拡張子：.clまたは.xml
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Hisham Khartabil (hisham.khartabil@gmail.com)
詳細情報の個人および電子メールアドレス：Hisham Khartabil（hisham.khartabil@gmail.com）
Intended Usage: COMMON
意図された使用法：共通
Author/change controller: The IETF
著者/変更コントローラー：IETF
This section registers a new XML namespace and schema, as per guidelines in the IETF XML Registry [IANA].
このセクションでは、IETF XMLレジストリ[IANA]のガイドラインに従って、新しいXMLネームスペースとスキーマを登録します。
URI: urn:ietf:params:xml:ns:imdn
XML: The schema for this namespace is in Section 11.1.9 above.
XML：この名前空間のスキーマは、上記のセクション11.1.9にあります。
Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@gmail.com)
登録者の連絡先：IETF、シンプルワーキンググループ、Hisham Khartabil（hisham.khartabil@gmail.com）
Per [RFC3553], please establish the following registry. New entries to the registry are Specification Required.
[RFC3553]ごとに、次のレジストリを確立してください。レジストリへの新しいエントリが必要です。
Registry name: urn:ietf:params:imdn
Specification: RFC 5438. Additional values may be defined by a Standards Action [RFC5226] that updates or obsoletes RFC 5438.
仕様：RFC5438。追加の値は、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 b) prepending the resulting string with 'urn:ietf:params:imdn:'.
a) 非回行文字（RFC 2141 [URN]で定義されている）を対応する「％HH」エスケープシーケンス（RFC 3986 [RFC3986]ごと）に置き換えます。'。
Thus, the URI corresponding to the CPIM message IMDN header 'Disposition-Notification:' would be 'urn:ietf:params:imdn:Disposition-Notification'.
したがって、CPIMメッセージIMDNヘッダーに対応するURIは、「urn：ietf：params：imdn：diso-notification」になります。
Initial values:
初期値：
+--------------------------+---------------------+
| Index Value | Reference |
+--------------------------+---------------------+
| Disposition-Notification | RFC5438 Section 6.2 |
| Message-ID | RFC5438 Section 6.3 |
| Original-To | RFC5438 Section 6.4 |
| IMDN-Record-Route | RFC5438 Section 6.5 |
| IMDN-Route | RFC5438 Section 6.6 |
+--------------------------+---------------------+
This document registers one new Content-Disposition header field "disposition-types": notification, which has been recorded in the IANA registry for Mail Content Dispositions.
このドキュメントは、1つの新しいコンテンツディスポジションヘッダーフィールド「処分型」：通知を登録します。これは、メールコンテンツの処分のためにIANAレジストリに記録されています。
Descriptions of this "disposition-types", including motivation and examples, are given in Section 7.2.1.1 and Section 9.
モチベーションや例を含むこの「処分型」の説明は、セクション7.2.1.1およびセクション9に記載されています。
Short descriptions suitable for the IANA registry are:
IANAレジストリに適した短い説明は次のとおりです。
notification: the payload of the message carrying this Content-Disposition header field value is an Instant Message Disposition Notification as requested in the corresponding Instant Message.
通知：このコンテンツ配置ヘッダーフィールド値を伝えるメッセージのペイロードは、対応するインスタントメッセージで要求されているインスタントメッセージ処分通知です。
Special thanks to Jari Urpalainen for the thorough review and suggestions for the RelaxNG schema.
Relaxngスキーマの徹底的なレビューと提案をしてくれたJari 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.
著者はまた、ポール・キジバット、ベン・キャンベル、アダム・ローチ、ゴンザロ・カマリロ、フランク・エラーマン、ショーン・オルソン、エヴァ・レパネン、ミゲル・ガルシア、エリック・マクマリー、ジョン・ピーターソン、ロバート・スパークスにコメントとサポートに感謝します。さらに、Gen-Artレビュアーの並外れたSpencer Dawkinsに感謝したいと思います。
[IANA] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[IANA] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004.
[RFC3862] Klyne、G。およびD. Atkins、「共通の存在とインスタントメッセージング（CPIM）：メッセージ形式」、RFC 3862、2004年8月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[urn] Moats、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] Bray、T。、「拡張可能なマークアップ言語（XML）1.0（第2版）」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「即座のメッセージのためのセッション開始プロトコル（SIP）拡張」、RFC 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.、Hardie、T。、およびG. Klyne、「登録プロトコルパラメーターのIETF URNサブネームスペース」、BCP 73、RFC 3553、2003年6月。
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition Notification", RFC 3798, May 2004.
[RFC3798] Hansen、T。およびG. Vaudreuil、「メッセージ処分通知」、RFC 3798、2004年5月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「The Message Session Relay Protocol（MSRP）」、RFC 4975、2007年9月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、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] Garcia-Martin、M。and G. Camarillo、「セッション開始プロトコル（SIP）の多反心のメッセージ要求」、RFC 5365、2008年10月。
[URN_NS] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[urn_ns] Moats、R。、「IETFドキュメント用のURNネームスペース」、RFC 2648、1999年8月。
Authors' Addresses
著者の住所
Eric Burger Unaffiliated New Hampshire USA
エリック・バーガーは、新ハンプシャーUSAを結び付けていません
Phone:
Fax: +1 603 457 5933
EMail: eburger@standardstrack.com
Hisham Khartabil Ericsson Australia Melbourne Australia
Hisham Khartabil Ericsson Australia Melbourne Australia
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com