[要約] RFC 3860は、インスタントメッセージングのための共通プロファイル（CPIM）に関する要約です。その目的は、異なるインスタントメッセージングプロトコル間でのメッセージの相互運用性を確保することです。
Network Working Group J. Peterson
Request for Comments: 3860 NeuStar
Category: Standards Track August 2004
Common Profile for Instant Messaging (CPIM)
インスタントメッセージングの共通プロファイル（CPIM）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services.
このドキュメントが書かれた時点で、多数のインスタントメッセージングプロトコルが使用されており、これらのプロトコルに基づくサービス間の相互運用性はほとんど達成されていません。この仕様は、インスタントメッセージングサービス間のゲートウェイの作成を容易にするために、インスタントメッセージングの一般的なセマンティクスとデータ形式を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Abstract Instant Messaging Service . . . . . . . . . . . . . . 4
3.1. Overview of Instant Messaging Service . . . . . . . . . 4
3.2. Identification of INSTANT INBOXes . . . . . . . . . . . 5
3.2.1. Address Resolution . . . . . . . . . . . . . . . 5
3.3. Format of Instant Messages . . . . . . . . . . . . . . . 5
3.4. The Messaging Service . . . . . . . . . . . . . . . . . 5
3.4.1. The Message Operation . . . . . . . . . . . . . 5
3.4.2. Looping . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. The IM URI Scheme. . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
A. IM URI IANA Registration Template . . . . . . . . . . . . . . 10
A.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . 10
A.2. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . 10
A.3. Character Encoding Considerations . . . . . . . . . . . 10
A.4. Intended Usage . . . . . . . . . . . . . . . . . . . . . 10
A.5. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 10
A.6. Security Considerations . . . . . . . . . . . . . . . . 10
A.7. Relevant Publications . . . . . . . . . . . . . . . . . 11
A.8. Person & Email Address to Contact for Further
Information. . . . . . . . . . . . . . . . . . . . . . . 11
A.9. Author/Change Controller . . . . . . . . . . . . . . . . 11
A.10. Applications and/or Protocols which use this URI Scheme
Name . . . . . . . . . . . . . . . . . . . . . . . . . . 11
B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . . 11
B.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 11
B.2. Source-Route Mapping . . . . . . . . . . . . . . . . . . 11
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
Instant messaging is defined in RFC2778 [5]. At the time this document was written, numerous instant messaging protocols are in use, and little interoperability between services based on these protocols has been achieved. This specification defines semantics and data formats for common services of instant messaging to facilitate the creation of gateways between instant messaging services: a common profile for instant messaging (CPIM).
インスタントメッセージングはRFC2778 [5]で定義されています。このドキュメントが書かれた時点で、多数のインスタントメッセージングプロトコルが使用されており、これらのプロトコルに基づくサービス間の相互運用性はほとんど達成されていません。この仕様では、インスタントメッセージングサービスの作成を容易にするインスタントメッセージングの一般的なサービスのセマンティクスとデータ形式を定義します。インスタントメッセージングの共通プロファイル（CPIM）。
Service behavior is described abstractly in terms of operations invoked between the consumer and provider of a service. Accordingly, each IM service must specify how this behavior is mapped onto its own protocol interactions. The choice of strategy is a local matter, providing that there is a clear relation between the abstract behaviors of the service (as specified in this memo) and how it is faithfully realized by a particular instant messaging service. For example, one strategy might transmit an instant message as textual key/value pairs, another might use a compact binary representation, and a third might use nested containers.
サービスの動作は、サービスの消費者とプロバイダーの間で呼び出される運用の観点から抽象的に説明されています。したがって、各IMサービスは、この動作が独自のプロトコル相互作用にマッピングされる方法を指定する必要があります。戦略の選択はローカルな問題であり、サービスの抽象的な動作（このメモで指定されているように）と特定のインスタントメッセージングサービスによって忠実に実現される方法との間に明確な関係があることを規定しています。たとえば、1つの戦略は、インスタントメッセージをテキストキー/値のペアとして送信し、別の戦略はコンパクトなバイナリ表現を使用する場合があり、3分の1がネストされた容器を使用する場合があります。
The attributes for each operation are defined using an abstract syntax. Although the syntax specifies the range of possible data values, each IM service must specify how well-formed instances of the abstract representation are encoded as a concrete series of bits.
各操作の属性は、抽象的構文を使用して定義されます。構文は考えられるデータ値の範囲を指定していますが、各IMサービスは、抽象表現の適切に形成されたインスタンスがコンクリートシリーズのビットとしてエンコードされるかを指定する必要があります。
In order to provide a means for the preservation of end-to-end features (especially security) to pass through instant messaging interoperability gateways, this specification also provides recommendations for instant messaging document formats that could be employed by instant messaging protocols.
エンドツーエンド機能（特にセキュリティ）を保存するための手段を提供するために、インスタントメッセージングの相互運用性ゲートウェイを通過するために、この仕様は、インスタントメッセージングプロトコルで採用できるインスタントメッセージングドキュメント形式の推奨事項も提供します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]で説明されているように解釈され、準拠の実装の要件レベルを示します。
This memos makes use of the vocabulary defined in RFC 2778 [5]. Terms such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in the same meaning as defined therein.
このメモは、RFC 2778で定義されている語彙を利用しています[5]。閉じた、インスタント受信トレイ、インスタントメッセージ、オープンなどの用語は、そこに定義されているのと同じ意味で使用されます。
The term 'gateway' used in this document denotes a network element responsible for interworking between diverse instant messaging protocols. Although the instant messaging protocols themselves are diverse, under the model used in this document these protocols can carry a common payload that is relayed by the gateway. Whether these interworking intermediaries should be called 'gateways' or 'relays' is therefore somewhat debatable; for the purposes of this document, they are called 'CPIM gateways'.
このドキュメントで使用されている「ゲートウェイ」という用語は、多様なインスタントメッセージングプロトコル間のインターワーキングに関与するネットワーク要素を示しています。インスタントメッセージングプロトコル自体は多様ですが、このドキュメントで使用されるモデルでは、これらのプロトコルはゲートウェイによって中継される共通のペイロードを運ぶことができます。したがって、これらの仲介業者が「ゲートウェイ」と呼ばれるか「リレー」と呼ばれるべきかは、やや議論の余地があります。このドキュメントの目的のために、それらは「CPIMゲートウェイ」と呼ばれます。
The term 'instant messaging service' also derives from RFC 2778, but its meaning changes slightly due to the existence of gateways in the CPIM model. When a client sends an operation to an instant messaging service, that service might either be an endpoint or an intermediary such as a CPIM gateway - in fact, the client should not have to be aware which it is addressing, as responses from either will appear the same.
「インスタントメッセージングサービス」という用語は、RFC 2778にも由来しますが、CPIMモデルにゲートウェイが存在するため、その意味はわずかに変化します。クライアントがインスタントメッセージングサービスに操作を送信する場合、そのサービスはエンドポイントまたはCPIMゲートウェイなどの仲介者である可能性があります。同じ。
This document defines operations and attributes of an abstract instant messaging protocol. In order for a compliant protocol to interface with an instant messaging gateway, it must support all of the operations described in this document (i.e., the instant messaging protocol must have some message or capability that provides the function described by each of the given operations). Similarly, the attributes defined for these operations must correspond to information available in the instant messaging protocol in order for the protocol to interface with gateways defined by this specification. Note that these attributes provide only the minimum possible information that needs to be specified for interoperability
このドキュメントでは、抽象的なインスタントメッセージングプロトコルの操作と属性を定義します。準拠したプロトコルがインスタントメッセージングゲートウェイとインターフェイスするには、このドキュメントで説明されているすべての操作をサポートする必要があります（つまり、インスタントメッセージングプロトコルには、特定の操作によって説明されている関数を提供するメッセージまたは機能が必要です）。同様に、これらの操作に対して定義されている属性は、この仕様で定義されたゲートウェイとプロトコルがインターフェイスするために、インスタントメッセージングプロトコルで利用可能な情報に対応する必要があります。これらの属性は、相互運用性のために指定する必要がある最小可能な情報のみを提供することに注意してください
- the functions in an instant messaging protocol that correspond to the operations described in this document can contain additional information that will not be mapped by CPIM.
- このドキュメントで説明されている操作に対応するインスタントメッセージングプロトコルの関数には、CPIMによってマッピングされない追加情報を含めることができます。
When an application wants to send a message to an INSTANT INBOX, it invokes the message operation, e.g.,
アプリケーションがインスタント受信トレイにメッセージを送信したい場合、メッセージ操作を呼び出します。
+-------+ +-------+
| | | |
| appl. | -- message ------> | IM |
| | | svc. |
+-------+ +-------+
The message operation has the following attributes: source, destination, MaxForwards and TransID. 'source' and 'destination' identify the originator and recipient of an instant message, respectively, and consist of an INSTANT INBOX identifier (as described in Section 3.2). The MaxForwards is a hop counter to avoid loops through gateways, with usage detailed defined in Section 3.4.2; its initial value is set by the originator. The TransID is a unique identifier used to correlate message operations to response operations; gateways should be capable of handling TransIDs up to 40 bytes in length.
メッセージ操作には、次の属性があります：ソース、宛先、最大派、およびTransID。「ソース」と「宛先」は、それぞれインスタントメッセージのオリジネーターと受信者を識別し、インスタント受信トレイ識別子で構成されています（セクション3.2で説明されています）。MaxForwardは、ゲートウェイを介したループを避けるためのホップカウンターであり、セクション3.4.2で詳細な使用法が定義されています。その初期値は、オリジネーターによって設定されます。TransIDは、メッセージ操作を応答操作と相関させるために使用される一意の識別子です。ゲートウェイは、最大40バイトの長さまでトランスインドを処理できる必要があります。
The message operation also has some content, the instant message itself, which may be textual, or which may consist of other data. Content details are specified in Section 3.3.
メッセージ操作には、いくつかのコンテンツ、インスタントメッセージ自体もあります。これはテキストである可能性があり、他のデータで構成されている場合があります。コンテンツの詳細は、セクション3.3で指定されています。
Note that this specification assumes that instant messaging protocols provide reliable message delivery; there are no application-layer message delivery assurance provisions in this specification.
この仕様は、インスタントメッセージングプロトコルが信頼できるメッセージ配信を提供することを前提としていることに注意してください。この仕様には、アプリケーションレイヤーのメッセージ配信保証の規定はありません。
Upon receiving a message operation, the service immediately responds by invoking the response operation containing the same transaction-identifier, e.g.,
メッセージ操作を受信すると、同じトランザクション識別子を含む応答操作を呼び出すことにより、サービスはすぐに応答します。
+-------+ +-------+
| | | |
| appl. | <----- response -- | IM |
| | | svc. |
+-------+ +-------+
The response operation contains the following attributes: TransID and
status. The TransID is used to correlate the response to a
particular instant message. Status indicates whether the delivery of
the message succeeded or failed. Valid status values are described
in Section 3.4.1.
An INSTANT INBOX is specified using an instant messaging URI with the 'im:' URI scheme. The full syntax of the IM URI scheme is given in Appendix A. An example would be: "im:fred@example.com"
インスタント受信トレイは、「IM：」URIスキームを使用したインスタントメッセージングURIを使用して指定されています。IM URIスキームの完全な構文は、付録Aに記載されています。例は、「im：fred@example.com」です。
An IM service client determines the next hop to forward the IM to by resolving the domain name portion of the service destination. Compliant implementations SHOULD follow the guidelines for dereferencing URIs given in [2].
IMサービスクライアントは、サービス宛先のドメイン名部分を解決することにより、IMを転送する次のホップを決定します。準拠した実装は、[2]で与えられたURIを繰り返し参照するためのガイドラインに従う必要があります。
This specification defines an abstract interoperability mechanism for instant messaging protocols; the message content definition given here pertains to semantics rather than syntax. However, some important properties for interoperability can only be provided if a common end-to-end format for instant messaging is employed by the interoperating instant messaging protocols, especially with respect to security. In order to maintain end-to-end security properties, applications that send message operations to a CPIM gateway MUST implement the format defined in MSGFMT [4]. Applications MAY support other content formats.
この仕様は、インスタントメッセージングプロトコルの抽象的な相互運用性メカニズムを定義します。ここで与えられるメッセージコンテンツ定義は、構文ではなくセマンティクスに関係しています。ただし、相互運用性のいくつかの重要なプロパティは、インスタントメッセージングの一般的なエンドツーエンド形式が、特にセキュリティに関して、インスタントメッセージングプロトコルの相互運用のインスタントメッセージプロトコルによって採用されている場合にのみ提供できます。エンドツーエンドのセキュリティプロパティを維持するために、CPIMゲートウェイにメッセージ操作を送信するアプリケーションは、MSGFMT [4]で定義された形式を実装する必要があります。アプリケーションは、他のコンテンツ形式をサポートする場合があります。
CPIM gateways MUST be capable of relaying the content of a message operation between supported instant messaging protocols without needing to modify or inspect the content.
CPIMゲートウェイは、コンテンツを変更または検査する必要なく、サポートされているインスタントメッセージングプロトコル間のメッセージ操作のコンテンツを中継することができる必要があります。
When an application wants to send an INSTANT MESSAGE, it invokes the message operation.
アプリケーションがインスタントメッセージを送信したい場合、メッセージ操作を呼び出します。
When an instant messaging service receives the message operation, it performs the following preliminary checks:
インスタントメッセージングサービスがメッセージ操作を受信すると、次の予備チェックを実行します。
1. If the source or destination does not refer to a syntactically valid INSTANT INBOX, a response operation having status "failure" is invoked.
1. ソースまたは宛先が構文的に有効なインスタント受信トレイを参照していない場合、ステータス「失敗」を持つ応答操作が呼び出されます。
2. If the destination of the operation cannot be resolved by the recipient, and the recipient is not the final recipient, a response operation with the status "failure" is invoked.
2. 操作の宛先が受信者によって解決できず、受信者が最終的な受信者ではない場合、ステータス「故障」の応答操作が呼び出されます。
3. If access control does not permit the application to request this operation, a response operation having status "failure" is invoked.
3. Access Controlがアプリケーションにこの操作を要求できない場合、ステータス「失敗」を持つ応答操作が呼び出されます。
4. Provided these checks are successful:
4. これらのチェックが成功した場合：
If the instant messaging service is able to successfully deliver the message, a response operation having status "success" is invoked.
インスタントメッセージングサービスがメッセージを正常に配信できる場合、ステータス「成功」を持つ応答操作が呼び出されます。
If the service is unable to successfully deliver the message, a response operation having status "failure" is invoked.
サービスがメッセージを正常に配信できない場合、ステータス「失敗」を持つ応答操作が呼び出されます。
If the service must delegate responsibility for delivery (i.e., if it is acting as a gateway or proxying the operation), and if the delegation will not result in a future authoritative indication to the service, a response operation having status "indeterminant" is invoked.
サービスが配達の責任を委任する必要がある場合（つまり、ゲートウェイとして機能している場合、または操作のプロキシを展開している場合）、および代表団がサービスに対する将来の権威ある表示につながらない場合、ステータス「不確定」を持つ応答操作が呼び出されます。
If the service must delegate responsibility for delivery, and if the delegation will result in a future authoritative indication to the service, then a response operation is invoked immediately after the indication is received.
サービスが配達の責任を委任する必要があり、代表団がサービスに将来の権威ある表示をもたらす場合、兆候が受信された直後に応答操作が呼び出されます。
When the service invokes the response operation, the transID parameter is identical to the value found in the message operation invoked by the application.
サービスが応答操作を呼び出すと、TransIDパラメーターは、アプリケーションによって呼び出されたメッセージ操作で見つかった値と同一です。
The dynamic routing of instant messages can result in looping of a message through a relay. Detection of loops is not always obvious, since aliasing and group list expansions can legitimately cause a message to pass through a relay more than one time.
インスタントメッセージの動的なルーティングにより、リレーを介してメッセージがループする可能性があります。ループの検出は必ずしも明らかではありません。エイリアシングとグループリストの拡張により、メッセージがリレーを複数回通過する可能性があるためです。
This document assumes that instant messaging protocols that can be gatewayed by CPIM support some semantic equivalent to an integer value that indicates the maximum number of hops through which a message can pass. When that number of hops has been reached, the message is assumed to have looped.
このドキュメントでは、CPIMによってゲートウェイされる可能性のあるインスタントメッセージングプロトコルは、メッセージが渡すことができるホップの最大数を示す整数値に相当するセマンティックをサポートすることを前提としています。その数のホップに到達したとき、メッセージはループされていると想定されます。
When a CPIM gateway relays an instant message, it decrements the value of the MaxForwards attribute. This document does not mandate any particular initial setting for the MaxForwards element in instant messaging protocols, but it is recommended that the value be reasonably large (over one hundred).
CPIMゲートウェイがインスタントメッセージをリレーすると、MaxForwards属性の値が減少します。このドキュメントは、インスタントメッセージングプロトコルのMaxForwards要素の特定の初期設定を義務付けていませんが、値を合理的に大きくすることをお勧めします（100を超える）。
If a CPIM gateway receives an instant message operation that has a MaxForwards attribute of 0, it discards the message and invokes a failure operation.
CPIMゲートウェイが0の最大属性を持つインスタントメッセージ操作を受信した場合、メッセージを破棄し、障害操作を呼び出します。
Detailed security considerations for instant messaging protocols are given in RFC 2779 [6] (in particular, requirements are given in section 5.4 and some motivating discussion with 8.1).
インスタントメッセージングプロトコルの詳細なセキュリティに関する考慮事項は、RFC 2779 [6]に記載されています（特に、要件はセクション5.4に記載されており、8.1での動機付けの議論があります）。
CPIM defines an interoperability function that is employed by gateways between instant messaging protocols. CPIM gateways MUST be compliant with the minimum security requirements of the instant messaging protocols with which they interface.
CPIMは、インスタントメッセージングプロトコル間のゲートウェイによって使用される相互運用性関数を定義します。CPIMゲートウェイは、インターフェースがあるインスタントメッセージングプロトコルの最小セキュリティ要件に準拠する必要があります。
The introduction of gateways to the security model of instant messaging in RFC 2779 also introduces some new risks. End-to-end security properties (especially confidentiality and integrity) between instant messaging user agents that interface through a CPIM gateway can only be provided if a common instant message format (such as the format described in MSGFMT [4]) is supported by the protocols interfacing with the CPIM gateway.
RFC 2779でのインスタントメッセージングのセキュリティモデルへのゲートウェイの導入も、いくつかの新しいリスクをもたらします。CPIMゲートウェイを介してインターフェイスするインスタントメッセージングユーザーエージェント間のエンドツーエンドのセキュリティプロパティ（特に機密性と整合性）は、一般的なインスタントメッセージ形式（MSGFMT [4]で説明されている形式など）がによってサポートされている場合にのみ提供できます。CPIMゲートウェイとのインターフェースのプロトコル。
When end-to-end security is required, the message operation MUST use MSGFMT, and MUST secure the MSGFMT MIME body with S/MIME [8], with encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS SignedData).
エンドツーエンドのセキュリティが必要な場合、メッセージ操作はMSGFMTを使用する必要があり、暗号化（CMSエンベロヴナゲ）および/またはS/MIME署名（CMS SignedData）を使用して、S/MIME [8]でMSGFMT MIMEボディを保護する必要があります。
The S/MIME algorithms are set by CMS [9]. The AES [11] algorithm should be preferred, as it is expected that AES best suits the capabilities of many platforms. Implementations MAY use AES as an encryption algorithm, but are REQUIRED to support only the baseline algorithms mandated by S/MIME and CMS.
S/MIMEアルゴリズムはCMSによって設定されます[9]。AES [11]アルゴリズムは、AESが多くのプラットフォームの機能に最適な機能に最適であると予想されるため、推奨される必要があります。実装では、AESを暗号化アルゴリズムとして使用する場合がありますが、S/MIMEおよびCMSが義務付けているベースラインアルゴリズムのみをサポートする必要があります。
When IM URIs are placed in instant messaging protocols, they convey the identity of the sender and/or the recipient. Certificates that are used for S/MIME IM operations SHOULD, for the purposes of reference integrity, contain a subjectAltName field containing the IM URI of their subject. Note that such certificates may also contain other identifiers, including those specific to particular instant messaging protocols. In order to further facilitate interoperability of secure messaging through CPIM gateways, users and service providers are encouraged to employ trust anchors for certificates that are widely accepted rather than trust anchors specific to any particular instant messaging service or provider.
Im Urisがインスタントメッセージングプロトコルに配置されると、送信者および/または受信者の身元を伝えます。S/MIME IM操作に使用される証明書は、参照整合性の目的で、被験者のIM URIを含む対象のフィールドを含める必要があります。そのような証明書には、特定のインスタントメッセージングプロトコルに固有の証明書を含む他の識別子も含まれる場合があることに注意してください。CPIMゲートウェイを介した安全なメッセージの相互運用性をさらに促進するために、ユーザーとサービスプロバイダーは、特定のインスタントメッセージングサービスまたはプロバイダーに固有の信頼アンカーではなく、広く受け入れられている証明書に信頼アンカーを使用することをお勧めします。
In some cases, anonymous messaging may be desired. Such a capability is beyond the scope of this specification.
場合によっては、匿名のメッセージが望まれる場合があります。このような機能は、この仕様の範囲を超えています。
The IANA has assigned the "im" scheme.
IANAは「IM」スキームを割り当てました。
The Instant Messaging (IM) URI scheme designates an Internet resource, namely an INSTANT INBOX.
インスタントメッセージング（IM）URIスキームは、インターネットリソース、つまりインスタント受信トレイを指定します。
The syntax of an IM URI is given in Appendix A.
IM URIの構文は、付録Aに記載されています。
Dave Crocker edited earlier versions of this document.
Dave Crockerは、このドキュメントの以前のバージョンを編集しました。
The following individuals made substantial textual contributions to this document:
次の個人は、この文書に実質的なテキスト貢献をしました。
Athanassios Diacakis (thanos.diacakis@openwave.com)
athanassios diacakis（sanos.diacakis@openwave.com）
Florencio Mazzoldi (flo@networkprojects.com)
Florencio Mazzoldi（flo@networkprojects.com）
Christian Huitema (huitema@microsoft.com)
ChristianHuitema（huitema@microsoft.com）
Graham Klyne (gk@ninebynine.org)
Graham Klyne（gk@ninebynine.org）
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
Jonathan Rosenberg（jdrosen@dynamicsoft.com）
Robert Sparks (rsparks@dynamicsoft.com)
ロバートスパークス（rsparks@dynamicsoft.com）
Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
Hiroyasu sugano（suga@flab.fujitsu.co.jp）
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[2] ピーターソン、J。、「インスタントメッセージングと存在のアドレス解像度」、RFC 3861、2004年8月。
[3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April 2001.
[3] Resnick、P。、「インターネットメッセージフォーマット」、STD 11、RFC 2822、2001年4月。
[4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: Message Format", RFC 3862, August 2004.
[4] Atkins、D。およびG. Klyne、「共通の存在とインスタントメッセージング：メッセージ形式」、RFC 3862、2004年8月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[5] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[6] Day、M.、Aggarwal、S。、およびJ. Vincent、「インスタントメッセージング /プレゼンスプロトコル要件」、RFC 2779、2000年2月。
[7] Allocchio, C., "GSTN Address Element Extensions in Email Services", RFC 2846, June 2000.
[7] Allocchio、C。、「電子メールサービスのGSTNアドレス要素拡張機能」、RFC 2846、2000年6月。
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[8] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[9] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[10] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[11] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm and in Cryptographic Message Syntax (CMS)", RFC 3565, August 2003.
[11] Schaad、J。、「高度な暗号化標準（AES）暗号化アルゴリズムの使用および暗号化メッセージ構文（CMS）」、RFC 3565、2003年8月。
This section provides the information to register the im: instant messaging URI.
このセクションでは、IM：インスタントメッセージングURIを登録するための情報を提供します。
im
私は
The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is:
構文は、RFC 2368で指定された既存のMailto：URI構文に従います。ABNFは次のとおりです。
IM-URI = "im:" [ to ] [ headers ]
to = mailbox
headers = "?" header *( "&" header )
header = hname "=" hvalue
hname = *uric
hvalue = *uric
Here the symbol "mailbox" represents an encoded mailbox name as defined in RFC 2822 [3], and the symbol "uric" denotes any character that is valid in a URL (defined in RFC 2396 [10]).
ここで、シンボル「メールボックス」は、RFC 2822 [3]で定義されているエンコードされたメールボックス名を表し、シンボル「uRIC」はURLで有効な文字（RFC 2396 [10]で定義）を示します。
Representation of non-ASCII character sets in local-part strings is limited to the standard methods provided as extensions to RFC 2822 [3].
ローカルパート文字列の非ASCII文字セットの表現は、RFC 2822の拡張として提供される標準的な方法に限定されています[3]。
Use of the im: URI follows closely usage of the mailto: URI. That is, invocation of an IM URI will cause the user's instant messaging application to start, with destination address and message headers fill-in according to the information supplied in the URI.
IMの使用：uriは、mailto：uriの密接に使用されます。つまり、IM URIの呼び出しにより、ユーザーのインスタントメッセージングアプリケーションが開始され、URIで提供された情報に応じて宛先アドレスとメッセージヘッダーが入力されます。
It is anticipated that protocols compliant with RFC 2779, and meeting the interoperability requirements specified here, will make use of this URI scheme name.
プロトコルはRFC 2779に準拠し、ここで指定された相互運用性要件を満たすことで、このURIスキーム名を利用することが予想されます。
See Section 4.
セクション4を参照してください。
RFC 2779, RFC 2778
RFC 2779、RFC 2778
Jon Peterson [mailto:jon.peterson@neustar.biz]
Jon Peterson [Mailto：jon.peterson@neustar.biz]
This scheme is registered under the IETF tree. As such, IETF maintains change control.
このスキームは、IETFツリーの下に登録されています。そのため、IETFは変更制御を維持します。
Instant messaging service
インスタントメッセージングサービス
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway.
この付録では、相互操作ゲートウェイを設計する際に興味深い問題について簡単に説明します。
When mapping the service described in this memo, mappings that place special information into the im: address local-part MUST use the meta-syntax defined in RFC 2846 [7].
このメモに記載されているサービスをマッピングする場合、IMに特別な情報を配置するマッピング：アドレスローカルパートは、RFC 2846で定義されたメタシンタックスを使用する必要があります[7]。
The easiest mapping technique is a form of source-routing and usually is the least friendly to humans having to type the string. Source-routing also has a history of operational problems.
最も簡単なマッピング手法は、ソースルーティングの形式であり、通常、文字列を入力しなければならない人間にとって最も友好的ではありません。ソースルーティングには、運用上の問題の歴史もあります。
Use of source-routing for exchanges between different services is by a transformation that places the entire, original address string into the im: address local part and names the gateway in the domain part.
異なるサービス間の交換用のソースルーティングの使用は、元のアドレス文字列全体をIMに配置する変換によるものです。
For example, if the destination INSTANT INBOX is "pepp://example.com/ fred", then, after performing the necessary character conversions, the resulting mapping is:
たとえば、宛先インスタント受信トレイが「PEPP：//example.com/ Fred」の場合、必要な文字変換を実行した後、結果のマッピングは次のとおりです。
im:pepp=example.com/fred@relay-domain
where "relay-domain" is derived from local configuration information.
ここで、「リレードメイン」はローカル構成情報から派生しています。
Experience shows that it is vastly preferable to hide this mapping from end-users - if possible, the underlying software should perform the mapping automatically.
エクスペリエンスでは、このマッピングをエンドユーザーから非表示にすることが非常に好ましいことが示されています。可能であれば、基礎となるソフトウェアはマッピングを自動的に実行する必要があります。
The author would like to acknowledge John Ramsdell for his comments, suggestions and enthusiasm. Thanks to Derek Atkins for editorial fixes.
著者は、彼のコメント、提案、熱意についてジョン・ラムズデルに感謝したいと思います。編集の修正については、Derek Atkinsに感謝します。
Author's Address
著者の連絡先
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。