RFC3860 日本語訳
3860 Common Profile for Instant Messaging (CPIM). J. Peterson. August 2004. (Format: TXT=26486 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Peterson Request for Comments: 3860 NeuStar Category: Standards Track August 2004
コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3860年のNeuStarカテゴリ: 標準化過程2004年8月
Common Profile for Instant Messaging (CPIM)
インスタントメッセージングのための一般的なプロフィール(CPIM)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 抽象的なインスタントメッセージングサービス. . . . . . . . . . . . . . 4 3.1。 インスタントメッセージングサービス. . . . . . . . . 4 3.2の概観。 即時の受信トレイ. . . . . . . . . . . 5 3.2.1の識別。 解決. . . . . . . . . . . . . . . 5 3.3を記述してください。 インスタントメッセージ. . . . . . . . . . . . . . . 5 3.4の形式。 メッセージサービス. . . . . . . . . . . . . . . . . 5 3.4.1。 メッセージ操作. . . . . . . . . . . . . 5 3.4.2。 ループ. . . . . . . . . . . . . . . . . . . . 6 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 5。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 5.1。 不-URI計画。 . . . . . . . . . . . . . . . . . . . 8 6. 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 8 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1。 引用規格. . . . . . . . . . . . . . . . . . 9 7.2。 有益な参照. . . . . . . . . . . . . . . . . 9
Peterson Standards Track [Page 1] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[1ページ]。
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
A.不-URI IANA登録テンプレート. . . . . . . . . . . . . . 10A.1。 URI計画名. . . . . . . . . . . . . . . . . . . . 10のA.2。 URI計画構文. . . . . . . . . . . . . . . . . . . 10A.3。 問題. . . . . . . . . . . 10A.4をコード化するキャラクター。 意図している用法. . . . . . . . . . . . . . . . . . . . . 10A.5。 このURI Scheme Name. . . . . . . . . . . . . . . . . . . . . . . . . . 10A.6を使用するアプリケーション、そして/または、プロトコル。 セキュリティ問題. . . . . . . . . . . . . . . . 10A.7。 関連刊行物. . . . . . . . . . . . . . . . . 11A.8。 詳細のために連絡する人とEメールアドレス。 . . . . . . . . . . . . . . . . . . . . . . 11 A.9。 コントローラ.11A.10を書くか、または変えてください。 Interest. . . . . . . . . . . . . . . . . . . . . . 11B.1のこのURI Scheme Name. . . . . . . . . . . . . . . . . . . . . . . . . . 11B.Issuesを使用するアプリケーション、そして/または、プロトコル。 マッピング. . . . . . . . . . . . . . . . . . . . 11B.2を記述してください。 送信元経路マッピング. . . . . . . . . . . . . . . . . . 11C.承認. . . . . . . . . . . . . . . . . . . . . . . 12作者のアドレスの.12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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サービスはこの振舞いがどうそれ自身のプロトコル相互作用に写像されるかを指定しなければなりません。 戦略の選択は地域にかかわる事柄です、サービス(このメモで指定されるように)とそれが特定のインスタントメッセージングサービスで忠実にどう実感されるかに関する抽象的な振舞いの明確な関係があれば。 例えば、原文のキー/値の組、別のものがコンパクトな2進法表示を使用するかもしれなくて、3分の1が入れ子にされた容器を使用するかもしれないとき、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サービスは抽象的表現のよく形成された例が具体的なシリーズのビットとしてどうコード化されるかを指定しなければなりません。
Peterson Standards Track [Page 2] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[2ページ]。
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.
また、終わりから終わりへの機能の保存(特にセキュリティ)がインスタントメッセージング相互運用性ゲートウェイを通り抜ける手段を提供するために、この仕様はインスタントメッセージングプロトコルで使うことができたインスタントメッセージングドキュメント・フォーマットのための推薦を提供します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTは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.
このメモはRFC2778[5]で定義されたボキャブラリーを利用します。 CLOSEDや、INSTANT INBOXや、INSTANT MESSAGEや、オープンなどの諸条件はそこに定義されるのと同じ意味で使用されます。
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.
また、'インスタントメッセージングサービス'という用語がRFC2778に由来していますが、わずかに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
このドキュメントは抽象的なインスタントメッセージングプロトコルの操作と属性を定義します。 インスタントメッセージングゲートウェイに連結する対応するプロトコルにおいて整然とします、それは本書では説明された操作のすべてを支持しなければなりません(メッセージング・プロトコルにそれぞれの与えられた操作で説明された機能を提供する何らかのメッセージか能力がなければならないとすぐにすなわち、)。 同様に、プロトコルがこの仕様で定義されるゲートウェイに連結するように、これらの操作のために定義された属性はインスタントメッセージングプロトコルで利用可能な情報に対応しなければなりません。 これらの属性が相互運用性に指定される必要がある最小の可能な情報だけを提供することに注意してください。
Peterson Standards Track [Page 3] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[3ページ]。
- 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によって写像されない追加情報を含むことができます。
3. Abstract Instant Messaging Service
3. 抽象的なインスタントメッセージングサービス
3.1. Overview of Instant Messaging Service
3.1. インスタントメッセージングサービスの概観
When an application wants to send a message to an INSTANT INBOX, it invokes the message operation, e.g.,
アプリケーションがメッセージをINSTANT INBOXに送りたがっているとき、それは例えばメッセージ操作を呼び出します。
+-------+ +-------+ | | | | | appl. | -- message ------> | IM | | | | svc. | +-------+ +-------+
+-------+ +-------+ | | | | | appl。 | -- メッセージ------>| 不-| | | | 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。 'ソース'と'目的地'は、それぞれインスタントメッセージの創始者と受取人を特定して、INSTANT INBOX識別子から成ります(セクション3.2で説明されるように)。 MaxForwardsは用法が詳細な状態でセクション3.4.2で定義されたゲートウェイを通して輪を避けるホップカウンタです。 初期の値は創始者によって設定されます。 TransIDは応答操作にメッセージ操作を関連させるのに使用されるユニークな識別子です。 ゲートウェイは取り扱いTransIDsが長さ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. | +-------+ +-------+
+-------+ +-------+ | | | | | appl。 | <、-、-、-、-- 応答--| 不-| | | | svc。 | +-------+ +-------+
Peterson Standards Track [Page 4] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[4ページ]。
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で説明されます。
3.2. Identification of INSTANT INBOXes
3.2. 即時の受信トレイの識別
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"
INSTANT INBOXがインスタントメッセージングURIを使用することで指定される、'、不-、: 'URI計画。 Appendix A.でIM URI計画の完全な構文を与えます。Anの例は以下の通りでしょう。 「不-、: fred@example.com 、」
3.2.1. Address Resolution
3.2.1. アドレス解決
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を送ると決心しています。 言いなりになっている実現SHOULDは[2]で与えられたURIに「反-参照をつけ」るためのガイドラインに従います。
3.3. Format of Instant Messages
3.3. インスタントメッセージの形式
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ゲートウェイは支持されたインスタントメッセージングプロトコルの間のメッセージ操作の内容をリレーできなければなりません。
3.4. The Messaging Service
3.4. メッセージサービス
3.4.1. The Message Operation
3.4.1. メッセージ操作
When an application wants to send an INSTANT MESSAGE, it invokes the message operation.
アプリケーションがINSTANT MESSAGEを送りたがっているとき、それはメッセージ操作を呼び出します。
Peterson Standards Track [Page 5] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[5ページ]。
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. 情報筋か目的地がシンタクス上有効なINSTANT INBOXについて言及しないなら、状態「失敗」を持っている応答操作は呼び出されます。
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. アクセス管理が、アプリケーションがこの操作を要求することを許可しないなら、状態「失敗」を持っている応答操作は呼び出されます。
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.
サービスが配送への責任を代表として派遣しなければならなくて(すなわち、ゲートウェイとして機能するか、または操作をproxyingしているなら)、代表団がサービスへの今後の正式の指示をもたらさないなら、状態"「不-決定的」"を持っている応答操作は呼び出されます。
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パラメタはアプリケーションで呼び出されたメッセージ操作で見つけられた値と同じです。
3.4.2. Looping
3.4.2. ループ
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.
インスタントメッセージのダイナミックルーティングはリレーによるメッセージのループをもたらすことができます。 輪の検出はいつも明白であるというわけではありません、エイリアシングとグループリスト拡大が合法的に十二分にあるときリレーを通り抜けるメッセージを引き起こす場合があるので。
Peterson Standards Track [Page 6] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[6ページ]。
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によってgatewayedされることができるインスタントメッセージングプロトコルがメッセージが終わることができるホップの最大数を示す整数値と何らかの意味同等物を支持すると仮定します。 その数のホップに達したとき、メッセージが輪にしたと思われます。
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属性を持っているインスタントメッセージ操作を受けるなら、それは、メッセージを捨てて、失敗操作を呼び出します。
4. Security Considerations
4. セキュリティ問題
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).
RFC2779[6]でインスタントメッセージングプロトコルのための詳細なセキュリティ問題を与えます(特に、8.1との議論を動機づけながら、セクション5.4といくつかで要件を与えます)。
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.
また、RFC2779でのインスタントメッセージングの機密保護モデルへのゲートウェイの導入はいくつかの新しい危険を導入します。 一般的なインスタントメッセージ形式である場合にだけCPIMゲートウェイを通して連結するインスタントメッセージングユーザエージェントの間の終わりから終わりへのセキュリティ資産(特に秘密性と保全)を提供できます。(CPIMゲートウェイに連結して、形式がMSGFMT[4])で説明したようにプロトコルはそのようなものを支持します。
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を使用しなければならなくて、S/MIME[8]でMSGFMT MIMEボディーを安全にしなければなりません、暗号化(CMS EnvelopeData)、そして/または、S/MIME署名(CMS SignedData)で。
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によって強制された基線アルゴリズムだけを支持するREQUIREDとCMSです。
Peterson Standards Track [Page 7] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[7ページ]。
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操作SHOULD、参照保全の目的に使用される証明書はそれらの対象のIM URIを含むsubjectAltName分野を含んでいます。 また、そのような証明書が特定のインスタントメッセージングプロトコルに特定のものを含む他の識別子を含むかもしれないことに注意してください。 CPIMゲートウェイを通してさらに安全なメッセージングの相互運用性を容易にするために、ユーザとサービスプロバイダーがどんな特定のインスタントメッセージングサービスやプロバイダーにも特定であると広く信用アンカーよりむしろ受け入れられる証明書のために信用アンカーを雇うよう奨励されます。
In some cases, anonymous messaging may be desired. Such a capability is beyond the scope of this specification.
いくつかの場合、匿名のメッセージングは望まれるかもしれません。 そのような能力はこの仕様の範囲を超えています。
5. IANA Considerations
5. IANA問題
The IANA has assigned the "im" scheme.
IANAが割り当てた、「不-、」 計画してください。
5.1. The IM URI Scheme
5.1. 不-URI計画
The Instant Messaging (IM) URI scheme designates an Internet resource, namely an INSTANT INBOX.
Instant Messaging(IM)URI計画はインターネット資料、すなわち、INSTANT INBOXを指定します。
The syntax of an IM URI is given in Appendix A.
Appendix AでIM URIの構文を与えます。
6. Contributors
6. 貢献者
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( 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)
菅野寛裕( suga@flab.fujitsu.co.jp )
Peterson Standards Track [Page 8] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[8ページ]。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[2] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[2] ピーターソン、J.、「インスタントメッセージングと存在のためのアドレス解決」、RFC3861、2004年8月。
[3] Resnick, P., "Internet Message Format", STD 11, RFC 2822, April
2001.
[3] レズニック、P.、「インターネットメッセージ・フォーマット」、STD11、RFC2822、2001年4月。
[4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging:
Message Format", RFC 3862, August 2004.
[4] アトキンス、D.、およびG.Klyne、「一般的な存在とインスタントメッセージング:」 「メッセージ・フォーマット」、RFC3862、2004年8月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
2000年2月の[5] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging /
Presence Protocol Requirements", RFC 2779, February 2000.
[6] 日、M.とAggarwal、S.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。
[7] Allocchio, C., "GSTN Address Element Extensions in Email
Services", RFC 2846, June 2000.
[7]Allocchio、C.、「メールサービスにおけるGSTNアドレス要素拡張子」、RFC2846、2000年6月。
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[8]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[9]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、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、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
7.2. Informative References
7.2. 有益な参照
[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.、「暗号化アルゴリズムと暗号のメッセージ構文(cm)におけるエー・イー・エス(AES)の使用」、RFC3565(2003年8月)。
Peterson Standards Track [Page 9] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[9ページ]。
Appendix A. IM URI IANA Registration Template
付録A.不-URI IANA登録テンプレート
This section provides the information to register the im: instant messaging URI.
このセクションが登録するために情報を提供する、不-、: インスタントメッセージングURI。
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に続きます: URI構文はRFC2368で指定しました。 ABNFは以下の通りです。
IM-URI = "im:" [ to ] [ headers ] to = mailbox headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *uric hvalue = *uric
不-URI=、「不-、:、」 []、“?"*(“&"ヘッダー)ヘッダー=hname「=」hvalue hname=*尿の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]).
ここで、RFC2822[3]、およびシンボルで「尿」で定義されて、「メールボックス」がコード化されたメールボックス名を表すシンボルはURLで有効な状態でそうするどんなキャラクタも指示します。(RFC2396[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文字の組の表現は拡大としてRFC2822[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.
使用、不-、: URIは密接にmailtoの使用法に従います: ユリ。 ユーザのインスタントメッセージングアプリケーションはすなわち、IM URIの実施で始まるでしょう、URIで提供された情報に従った送付先アドレスとメッセージヘッダー代理と共に。
A.5. Applications and/or Protocols which use this URI Scheme Name
A.5。 このURI Scheme Nameを使用するアプリケーション、そして/または、プロトコル
It is anticipated that protocols compliant with RFC 2779, and meeting the interoperability requirements specified here, will make use of this URI scheme name.
RFC2779に伴う対応することのプロトコルと、ここで指定された相互運用性必要条件を満たすとこのURI計画名が利用されると予期されます。
A.6. Security Considerations
A.6。 セキュリティ問題
See Section 4.
セクション4を見てください。
Peterson Standards Track [Page 10] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[10ページ]。
A.7. Relevant Publications
A.7。 関連刊行物
RFC 2779, RFC 2778
RFC2779、RFC2778
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 Scheme Nameを使用するアプリケーション、そして/または、プロトコル
Instant messaging service
インスタントメッセージングサービス
Appendix B. Issues of Interest
興味深い付録B.問題
This appendix briefly discusses issues that may be of interest when designing an interoperation gateway.
この付録は簡潔にinteroperationゲートウェイを設計するとき興味深いかもしれない問題について議論します。
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].
サービスを写像するとこのメモ、特別な情報を置くマッピングが中でいつまで説明されたか、不-、: アドレスの地方の一部がRFC2846[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.
ソースルーティングの異なったサービスの間の交換の使用がそれが全体の、そして、オリジナルのアドレスストリングを置く変化である、不-、: そのドメインのゲートウェイが分ける地方の部分と名前を記述してください。
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/ fred」であるなら、結果として起こるマッピングは以下の通りです。
im:pepp=example.com/fred@relay-domain
不-、: peppは example.com/fred@relay-domain と等しいです。
where "relay-domain" is derived from local configuration information.
「リレードメイン」がローカルの設定情報から得られるところ。
Peterson Standards Track [Page 11] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[11ページ]。
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一致、カリフォルニア94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz
Peterson Standards Track [Page 12] RFC 3860 CPIM August 2004
ピーターソンStandardsはCPIM2004年8月にRFC3860を追跡します[12ページ]。
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Peterson Standards Track [Page 13]
ピーターソン標準化過程[13ページ]
一覧
スポンサーリンク
