Network Working Group J. Peterson
Request for Comments: 3860 NeuStar
Category: Standards Track August 2004
Common Profile for Instant Messaging (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）インターネット協会（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サービスは、この動作は、独自のプロトコルの相互作用上にマッピングされる方法を指定する必要があります。戦略の選択は、（このメモで指定されている）と、それがどのように忠実に、特定のインスタントメッセージングサービスによって実現されるサービスの抽象的行動との間に明確な関係があることを提供し、ローカルの問題です。例えば、一つの戦略は、テキストキー/値のペアとしてインスタントメッセージを送信することが、別のコンパクトバイナリ表現を使用する場合があり、第三は、ネストされたコンテナを使用するかもしれません。
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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、及び「OPTIONAL」は、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]。その中で定義されているようなCLOSED、INSTANT INBOX、インスタントメッセージ、およびOPENなどの用語は同じ意味で使用されています。
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.,
アプリケーションがインスタントINBOXにメッセージを送信したいとき、それは、例えば、メッセージオペレーションを呼び出します
+-------+ +-------+
| | | |
| 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.
送信元、送信先、MaxForwardsとTRANSID：メッセージ操作は、以下の属性があります。 「ソース」と「宛先」（セクション3.2で説明したように）は、それぞれ、インスタントメッセージの発信者と受信者を識別し、INSTANT INBOX識別子から成ります。 MaxForwardsはセクション3.4.2で定義された詳細な使用と、ゲートウェイを介してループを回避するホップカウンタです。その初期値は、発信者によって設定されます。 TRANSIDは応答操作にメッセージ操作を相関させるために使用される一意の識別子です。ゲートウェイは、長さが40バイトにTransIDsを扱うことができるべきです。
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.
TRANSIDとステータス：応答操作は、以下の属性が含まれています。 TRANSIDは、特定のインスタントメッセージへの応答を相関させるために使用されます。ステータスメッセージの配信が成功したか失敗したかどうかを示します。有効なステータス値は、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"
URIスキーム：INSTANT INBOXを「イム」でURIインスタントメッセージングを使用して指定されています。 IM URIスキームの完全な構文は、付録Aに与えられている例は次のようになります。「イム：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.
ソースまたは宛先が構文的に有効なインスタントINBOXを参照していない場合は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、ステータスが「失敗」を有する応答操作が呼び出されます。
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.
インスタントメッセージの動的ルーティングは、リレーを介してメッセージのループをもたらすことができます。エイリアシングおよびグループリストの展開が合法的メッセージが1時間以上のリレーを通過する可能性がありますので、ループの検出は、必ずしも明確ではありません。
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のMaxForwards属性を有するインスタントメッセージ操作を受け付けた場合、それはメッセージを破棄し、障害オペレーションを呼び出します。
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でインスタントメッセージングのセキュリティモデルへのゲートウェイの導入はまた、いくつかの新たなリスクを紹介します。 （[4]は、このようなMSGFMTに記載のフォーマットなど）に支持されている一般的なインスタントメッセージフォーマット場合CPIMゲートウェイを介してインタフェースのみを提供することができることは、インスタント・メッセージング・ユーザエージェントとの間のエンドツーエンドのセキュリティ特性（特に機密性と完全性） 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).
エンドツーエンドのセキュリティが必要とされる場合、メッセージ動作は、暗号化（CMS EnvelopeData）および/またはS / MIME署名（CMSのSignedData）と、[8] MSGFMTを使用しなければならない、およびS / MIMEで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は最高の多くのプラットフォームの能力に合っていることが予想されるとして、AES [11]アルゴリズムは、優先されなければなりません。実装は、暗号化アルゴリズムとして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 URIは、インスタントメッセージングプロトコルに置かれたとき、彼らは、送信者および/または受信者のアイデンティティを伝えます。 S / MIME IM操作に使用されている証明書は、参照整合性のために、その対象のIM URIを含むのsubjectAltNameフィールドを含むべきです。そのような証明書はまた、特定のインスタントメッセージングプロトコルに固有のものを含む他の識別子を含んでいてもよいことに注意してください。さらに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スキームは、インターネットリソース、すなわちINSTANT INBOXを指定します。
The syntax of an IM URI is given in Appendix A.
IM URIの構文は、付録Aに記載されています
Dave Crocker edited earlier versions of this document.
デイブ・クロッカーはこのドキュメントの以前のバージョンを編集しました。
The following individuals made substantial textual contributions to this document:
以下の個人は、この文書にかなりのテキストの貢献をしました。
Athanassios Diacakis (thanos.diacakis@openwave.com)
Athanassios Diacakis（thanos.diacakis@openwave.com）
Florencio Mazzoldi (flo@networkprojects.com)
がflorencio Mazzoldi（flo@networkprojects.com）
Christian Huitema (huitema@microsoft.com)
クリスチャン・ハイテマ（huitema@microsoft.com）
Graham Klyne (gk@ninebynine.org)
グラハムKlyne（gk@ninebynine.org）
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
ジョナサン・ローゼンバーグ（jdrosen@dynamicsoft.com）
Robert Sparks (rsparks@dynamicsoft.com)
ロバート・スパークス（rsparks@dynamicsoft.com）
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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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]レズニック、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]アトキンス、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]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[6日目、M.、アガルワル、S.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、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.、RFC 3851、2004年7月 "/多目的インターネットメール拡張（S / MIME）バージョン3.1メッセージ仕様を固定します"。
[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]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、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.
、RFC 3565、2003年8月[11] Schaad、J.、 "AES（Advanced Encryption Standard）暗号化アルゴリズムと暗号メッセージ構文（CMS）での使用"。
Appendix A. IM URI IANA Registration Template
付録A. IM URI IANA登録テンプレート
This section provides the information to register the im: instant messaging URI.
インスタントメッセージングURI：このセクションでは、IMを登録するための情報を提供します。
A.1. URI Scheme Name
A.1。 URIスキーム名
im
で
A.2. URI Scheme Syntax
A.2。 URIスキームの構文
The syntax follows the existing mailto: URI syntax specified in RFC 2368. The ABNF is:
構文は、既存のmailtoを次の：ABNF RFC 2368.に指定されたURIの構文は次のとおりです。
IM-URI = "im:" [ to ] [ headers ] to = mailbox headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *uric hvalue = *uric
IM-URI = "イム：" "？" [ヘッダ] [へ]メールボックスヘッダ=へ=ヘッダ*（ "および" ヘッダ）ヘッダ=名 "=" 値名= *尿hvalue = *尿
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]符号化されたメールボックス名を表し、記号「尿」がURLに有効な任意の文字（RFC 2396で定義されている[10]）です。
A.3. Character Encoding Considerations
A.3。文字エンコーディングの考慮事項
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]。
A.4. Intended Usage
A.4。使用目的
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：URIは密接のmailtoの使用方法に従っています。これは、宛先アドレスとメッセージヘッダと、IM URIの呼び出しは、ユーザーのインスタントメッセージングアプリケーションが起動するようになります、ですフィルインURIに提供された情報によると。
A.5. Applications and/or Protocols which use this URI Scheme Name
A.5。この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のスキーム名を利用することが予想されます。
A.6. Security Considerations
A.6。セキュリティの考慮事項
See Section 4.
第4節を参照してください。
A.7. Relevant Publications
A.7。関連出版物
RFC 2779, RFC 2778
RFC 2779、RFC 2778
A.8. Person & Email Address to Contact for Further Information
A.8。詳細のために連絡する人とEメールアドレス
Jon Peterson [mailto:jon.peterson@neustar.biz]
ジョン・ピーターソン[mailtoの：jon.peterson@neustar.biz]
A.9. Author/Change Controller
A.9。著者/変更コントローラ
This scheme is registered under the IETF tree. As such, IETF maintains change control.
この方式は、IETFツリーの下に登録されています。そのため、IETFは、コントロールを変更維持しています。
A.10. Applications and/or Protocols which use this URI Scheme Name
A.10。このURIスキーム名を使用するアプリケーションおよび/またはプロトコル
Instant messaging service
インスタント・メッセージング・サービス
Appendix B. Issues of Interest
関心の付録B.問題
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway.
この付録では、簡単に相互運用ゲートウェイを設計する際に関心のある問題について説明します。
B.1. Address Mapping
B.1。アドレスマッピング
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]。
B.2. Source-Route Mapping
B.2。ソースルートマッピング
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:
先INSTANT INBOX「はPEPP：//example.com/フレッド」である場合、例えば、その後、必要に応じて文字変換を行った後、得られたマッピングがあります。
im:pepp=example.com/fred@relay-domain
イム：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.
経験は、エンドユーザーからこのマッピングを非表示にする非常に望ましいことを示している - 可能な場合は、基盤となるソフトウェアが自動的にマッピングを行う必要があります。
Appendix C. Acknowledgments
付録C.謝辞
The author would like to acknowledge John Ramsdell for his comments, suggestions and enthusiasm. Thanks to Derek Atkins for editorial fixes.
著者は彼のコメント、提案や熱意のためにジョンRamsdellを確認したいと思います。社説の修正のためのデレク・アトキンスに感謝します。
Author's Address
著者のアドレス
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
電話：+1 925/363から8720 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。