Network Working Group M. Day
Request for Comments: 2779 Lotus
Category: Informational S. Aggarwal
Microsoft
G. Mohr
Activerse
J. Vincent
Into Networks
February 2000
Instant Messaging / Presence Protocol Requirements
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.
プレゼンスとインスタントメッセージングは最近、インターネットを介したコミュニケーションの新しいメディアとして浮上しています。プレゼンスは、発見、取得、および他のユーザーのプレゼンス情報（例えば「オンライン」または「オフライン」）の変化に加入するための手段です。インスタントメッセージングは、オンラインユーザーに直ちに配信されている小さな、簡単なメッセージを送信するための手段です。
Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.
プレゼンスとインスタントメッセージングのアプリケーションは、現在、さまざまなベンダーが開発した、独立した非標準および非相互運用可能なプロトコルを使用します。インスタントメッセージングとプレゼンスプロトコル（IMPP）ワーキンググループの目標は、インスタント・メッセージングおよび/または存在を独立して開発されたアプリケーションは、インターネットを介して相互運用できるように、標準的なプロトコルを定義することです。この文書では、IMPPを満たさなければならない要件の最小セットを定義します。
Table of Contents
目次
1. Terminology................................................... 3
2. Shared Requirements........................................... 4
2.1. Namespace and Administration............................... 5
2.2. Scalability................................................ 5
2.3. Access Control............................................. 6
2.4. Network Topology........................................... 6
2.5. Message Encryption and Authentication...................... 7
3. Additional Requirements for PRESENCE INFORMATION.............. 7
3.1. Common Presence Format..................................... 7
3.2. Presence Lookup and Notification........................... 8
3.3. Presence Caching and Replication........................... 8
3.4. Performance................................................ 9
4. Additional Requirements for INSTANT MESSAGES.................. 9
4.1. Common Message Format...................................... 9
4.2. Reliability................................................ 10
4.3. Performance................................................ 10
4.4. Presence Format............................................ 10
5. Security Considerations....................................... 11
5.1. Requirements related to SUBSCRIPTIONS...................... 11
5.2. Requirements related to NOTIFICATION....................... 12
5.3. Requirements related to receiving a NOTIFICATION........... 13
5.4. Requirements related to INSTANT MESSAGES................... 13
6. References.................................................... 14
7. Authors' Addresses............................................ 15
8. Appendix: Security Expectations and Deriving Requirements..... 16
8.1. Presence Information....................................... 16
8.1.1. Subscription............................................ 16
8.1.2. Publication............................................. 19
8.1.3. Publication for Notification............................ 19
8.1.4. Receiving a Notification................................ 20
8.2. Instant Messaging.......................................... 21
8.2.1. Named Instant Messaging................................. 21
8.2.2. Anonymous Instant Messaging............................. 23
8.2.3. Administrator Expectations.............................. 24
Full Copyright Statement......................................... 26
The following terms are defined in [RFC 2778] and are used with those definitions in this document:
以下の用語は、[RFC 2778]で定義されており、この文書に記載されているそれらの定義で使用されています。
ACCESS RULES CLOSED FETCHER INSTANT INBOX INSTANT MESSAGE NOTIFICATION OPEN POLLER PRESENCE INFORMATION PRESENCE SERVICE PRESENTITY PRINCIPAL PROXY SERVER STATUS SUBSCRIBER SUBSCRIPTION WATCHER
アクセスルールは、OPENポーラープレゼンス情報PRESENCE SERVICE PRESENTITYプリンシパルPROXYサーバのステータス加入者の加入WATCHERフェッINSTANT INBOXインスタントメッセージ通知をCLOSED
The terms MUST and SHOULD are used in the following sense while specifying requirements:
要件を指定しての用語は以下の意味で使用されなければなりません、そして、SHOULD：
MUST: A proposed solution will have to meet this requirement. SHOULD: A proposed solution may choose not to meet this requirement.
提案された解決策は、この要件を満たす必要があります：しなければなりません。提案された解決策はこの要件を満たしていないのを選ぶかもしれません：べきです。
Note that this usage of MUST and SHOULD differs from that of RFC 2119.
MUSTやSHOULDのこの用法は、RFC 2119のものとは異なることに注意してください。
Additionally, the following terms are used in this document and defined here:
また、以下の用語は、この文書で使用されており、ここで定義されました：
ADMINISTRATOR: A PRINCIPAL with authority over local computer and network resources, who manages local DOMAINS or FIREWALLS. For security and other purposes, an ADMINISTRATOR often needs or wants to impose restrictions on network usage based on traffic type, content, volume, or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over some or all of that PRINCIPAL's computer and network resources.
管理者：ローカルドメインまたはファイアウォールを管理し、ローカルコンピュータおよびネットワークリソースに対する権限を持つ校長。セキュリティおよびその他の目的のために、管理者は、しばしば必要とする、またはトラフィックタイプ、内容、ボリューム、またはエンドポイントに基づいてネットワークの利用に制限を課すことを望んでいます。プリンシパルの管理者はそのプリンシパルのコンピュータおよびネットワークリソースの一部またはすべての権限を持っています。
DOMAIN: A portion of a NAMESPACE.
DOMAIN：NAMESPACEの部分。
ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER (all defined in [RFC 2778]).
ENTITY：PRESENTITYの任意の加入者、フェッチャ、ポーラー、またはWATCHER（すべて[RFC 2778]で定義されます）。
FIREWALL: A point of administrative control over connectivity. Depending on the policies being enforced, parties may need to take unusual measures to establish communications through the FIREWALL.
ファイアウォール：接続に対する管理制御のポイント。施行されたポリシーによっては、当事者は、ファイアウォールを介して通信を確立する異例の措置をとる必要があるかもしれません。
IDENTIFIER: A means of indicating a point of contact, intended for public use such as on a business card. Telephone numbers, email addresses, and typical home page URLs are all examples of IDENTIFIERS in other systems. Numeric IP addresses like 10.0.0.26 are not, and neither are URLs containing numerous CGI parameters or long arbitrary identifiers.
IDENTIFIER：、ビジネスカード上などの公共の使用を目的と接触点を示す手段、。電話番号、電子メールアドレス、および一般的なホーム・ページのURLは、他のシステム内の識別子のすべての例です。 10.0.0.26のような数値のIPアドレスではありません、そして数多くのCGIパラメータまたは長い任意の識別子を含むURLませんどちらも。
INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT MESSAGE is sending it.
目的の受信者：インスタントメッセージの送信者がそれを送っている人に対する主な。
NAMESPACE: The system that maps from a name of an ENTITY to the concrete implementation of that ENTITY. A NAMESPACE may be composed of a number of distinct DOMAINS.
NAMESPACE：そのエンティティの具体的な実装にENTITYの名前からマッピングしシステム。名前空間は、異なるドメインの数で構成されてもよいです。
OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE SERVICE cannot communicate.
CONTACT OF OUT：いくつかのENTITYとプレゼンスサービスが通信できない状況。
SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually also implies that an INBOX USER AGENT has handled the message in a way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not imply that the message was actually seen by that PRINCIPAL.
正常に配信：インスタントメッセージが目的の受信者のためにINSTANT INBOXに送信された状況、およびインスタントINBOXは、そのレシートを認めました。配信の成功は、通常、INBOXユーザエージェントは、プリンシパルによって選択された方法でメッセージを処理したことを意味します。しかし、正常に配信は、メッセージが実際にそのプリンシパルによって見られたことを意味するものではありません。
This section describes non-security requirements that are common to both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6 describes requirements specific to a PRESENCE SERVICE, while Section 7 describes requirements specific to an INSTANT MESSAGE SERVICE. Section 8 describes security considerations. The reader should note that Section 11 is an appendix that provides historical context and aids in tracing the origins of requirements in Section 8. Section 11 is not, however, a statement of current IMPP requirements.
このセクションでは、PRESENCEサービスとインスタントメッセージサービスの両方に共通する非セキュリティ要件について説明します。第7節は、インスタントメッセージサービスに固有の要件を説明しながら、第6節では、PRESENCEサービスに固有の要件について説明します。第8章では、セキュリティの考慮事項について説明します。読者は、セクション11は、ある第8項11に要求の起源をトレースにおける電流IMPP要件のステートメントがない、しかし、歴史的文脈とエイズを提供付録であることに注意すべきです。
It is expected that Presence and Instant Messaging services will be particularly valuable to users over mobile IP wireless access devices. Indeed the number of devices connected to the Internet via wireless means is expected to grow substantially in the coming years. It is not reasonable to assume that separate protocols will be available for the wireless portions of the Internet. In addition, we note that wireless infrastructure is maturing rapidly; the work undertaken by this group should take into account the expected state of the maturity of the technology in the time-frame in which the
プレゼンスとインスタントメッセージングサービスは、モバイルIP無線アクセスデバイスを超えるユーザーに特に貴重であることが期待されます。実際、無線手段を介してインターネットに接続されたデバイスの数は、今後数年間で大幅に増加することが予想されます。別のプロトコルは、インターネットの無線部分のために利用可能になると仮定することは合理的ではありません。また、当社は、無線インフラが急速に成熟していることに注意してください。このグループによって行わ作品は考慮中の時間枠における技術の成熟度の予想される状態を取る必要があります
Presence and Instant Messaging protocols are expected to be deployed.
プレゼンスとインスタントメッセージングプロトコルが展開されると予想されます。
To this end, the protocols designed by this Working Group must be suitable for operation in a context typically associated with mobile wireless access devices, viz. high latency, low bandwidth and possibly intermittent connectivity (which lead to a desire to minimize round-trip delays), modest computing power, battery constraints, small displays, etc. In particular, the protocols must be designed to be reasonably efficient for small payloads.
このため、このワーキンググループによって設計されたプロトコルは、典型的には、移動無線アクセス・デバイス、すなわちに関連付けられたコンテキストでの操作に適していなければなりません。特に高遅延、低帯域幅およびおそらく断続的な接続（往復遅延を最小限にする要望をもたらした）、適度な処理能力、バッテリ制約、小型ディスプレイ等のプロトコルは、小さなペイロードのために合理的に効率的であるように設計されなければなりません。
2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available independent of whether an INSTANT MESSAGE SERVICE is available, and vice-versa.
2.1.1. プロトコルは、プレゼンスサービスは、インスタントメッセージサービスが利用可能かどうかとは無関係に利用可能にできるように、及びその逆なければなりません。
2.1.2. The protocols must not assume that an INSTANT INBOX is necessarily reached by the same IDENTIFIER as that of a PRESENTITY. Specifically, the protocols must assume that some INSTANT INBOXes may have no associated PRESENTITIES, and vice versa.
2.1.2. プロトコルはINSTANT INBOXは必ずしもPRESENTITYのと同じ識別子によって達成されると仮定してはなりません。具体的には、プロトコルは、いくつかのインスタント受信ボックスに関連付けられているプレゼンティティ、およびその逆を有していないことを想定しなければなりません。
2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.
2.1.3. プロトコルはまたINSTANT INBOXは、いくつかのPRESENTITYの識別子と同じ識別子を介して到達することを可能にしなければなりません。
2.1.4. The administration and naming of ENTITIES within a given DOMAIN MUST be able to operate independently of actions in any other DOMAIN.
2.1.4. 所与のドメイン内投与及びエンティティの名称は、独立して、任意の他のドメインのアクションの動作できなければなりません。
2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS within the NAMESPACE.
2.1.5. プロトコルは、名前空間内のドメインの任意の数を可能にしなければなりません。
2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate with ENTITIES in another DOMAIN, without the DOMAINS having previously been aware of each other.
2.2.1. あるドメイン内のエンティティは、ドメインが以前にお互いを認識されず、別のドメイン内のエンティティと相互運用することが可能でなければなりません。
The protocol MUST be capable of meeting its other functional and performance requirements even when
プロトコルは、場合でも、そのほかの機能と性能要件を満たすことができなければなりません
-- (2.2.2) there are millions of ENTITIES within a single DOMAIN.
- （2.2.2）単一ドメイン内のエンティティの数百万人があります。
-- (2.2.3) there are millions of DOMAINS within the single NAMESPACE.
- （2.2.3）単一の名前空間内のドメイン数百万があります。
-- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds of PRESENTITIES.
- （2.2.4）すべての単一の加入者はプレゼンの何百ものサブスクリプションを持っています。
-- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to a single PRESENTITY.
- （2.2.5）の別個の加入者の何百もの単一プレゼンティティサブスクリプションを持っています。
-- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to PRESENTITIES in hundreds of distinct DOMAINS.
- （2.2.6）毎に単一の加入者は、異なるドメインの数百にプレゼンにサブスクリプションを持っています。
These are protocol design goals; implementations may choose to place lower limits.
これらは、プロトコルの設計目標です。実装は、下限値を配置することもできます。
The PRINCIPAL controlling a PRESENTITY MUST be able to control
PRESENTITY制御主体は制御できなければなりません
-- (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE INFORMATION.
- ウォッチャーは、そのプレゼンティティのプレゼンス情報を観察することができます（2.3.1）。
-- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that PRESENTITY's PRESENCE INFORMATION.
- ウォッチャーは、そのプレゼンティティのプレゼンス情報へのサブスクリプションを持つことができます（2.3.2）。
-- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see for that PRESENTITY, regardless of whether the WATCHER gets it by fetching or NOTIFICATION.
- 特定のWatcherは関係なくWATCHERフェッチまたは通知することにより、それを取得するかどうか、そのPRESENTITYため（2.3.3）どのプレゼンス情報が表示されます。
-- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE INFORMATION of that PRESENTITY.
- 他のプリンシパルが、もしあれば、そのプレゼンティティのプレゼンス情報を更新することができる（2.3.4）。
The PRINCIPAL controlling an INSTANT INBOX MUST be able to control
INSTANT INBOXを制御主体は制御できなければなりません
-- (2.3.5) which other PRINCIPALS, if any, can send INSTANT MESSAGES to that INSTANT INBOX.
- 他の原理は、もしあれば、その時点の受信トレイにインスタントメッセージを送信することができる（2.3.5）。
-- (2.3.6) which other PRINCIPALS, if any, can read INSTANT MESSAGES from that INSTANT INBOX.
- 他のプリンシパルが、もしあれば、その時点の受信トレイからインスタントメッセージを読むことができる（2.3.6）。
2.3.7. Access control MUST be independent of presence: the PRESENCE SERVICE MUST be able to make access control decisions even when the PRESENTITY is OUT OF CONTACT.
2.3.7. アクセス制御は存在とは無関係でなければならない：プレゼンスサービスは、プレゼンティティが接触していない場合でも、アクセス制御の決定を行うことができなければなりません。
Note that intermediaries such as PROXIES may be necessitated between IP and non-IP networks, and by an end-user's desire to provide anonymity and hide their IP address.
そのようなプロキシとして仲介は、IPと非IPネットワークとの間、及び匿名性を提供し、それらのIPアドレスを隠すために、エンドユーザの希望によって必要とされてもよいことに留意されたいです。
2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both directly and via intermediaries, such as PROXIES.
2.4.1. プロトコルは、両方の直接およびそのようなプロキシとして仲介を介してサブスクリプションの作成を可能にしなければなりません。
2.4.2. The protocol MUST allow the sending of a NOTIFICATION both directly and via intermediaries, such as PROXIES.
2.4.2. プロトコルは、両方の直接およびそのようなプロキシとして仲介を介して通知を送信することを可能にしなければなりません。
2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both directly and via intermediaries, such as PROXIES.
2.4.3. プロトコルは、両方の直接およびそのようなプロキシとして仲介を介してインスタントメッセージの送信を可能にしなければなりません。
2.4.4. The protocol proxying facilities and transport practices MUST allow ADMINISTRATORS ways to enable and disable protocol activity through existing and commonly-deployed FIREWALLS. The protocol MUST specify how it can be effectively filtered by such FIREWALLS.
2.4.4. プロトコルプロキシ施設や交通機関の実践は、既存および一般的に展開ファイアウォールを介したプロトコルアクティビティを有効または無効にするには、管理者の方法を許容しなければなりません。プロトコルは、それが効果的に、ファイアウォールによってフィルタリングすることができる方法を指定しなければなりません。
2.5.1. The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been corrupted or tampered with.
2.5.1. プロトコルは、受信したメッセージ（通知やインスタントメッセージ）が破損または改ざんされていない信頼性を確保する手段を提供しなければなりません。
2.5.2. The protocol MUST provide means to ensure confidence that a received message (NOTIFICATION or INSTANT MESSAGE) has not been recorded and played back by an adversary.
2.5.2. プロトコルは、受信したメッセージ（通知やインスタントメッセージ）が記録され、敵が再生されていない信頼性を確保するための手段を提供しなければなりません。
2.5.3. The protocol MUST provide means to ensure that a sent message (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that the sender allows.
2.5.3. プロトコルは、送信されたメッセージ（通知やインスタントメッセージ）の送信者ができエンティティによってのみ読み取り可能であることを確認するための手段を提供しなければなりません。
2.5.4. The protocol MUST allow any client to use the means to ensure non-corruption, non-playback, and privacy, but the protocol MUST NOT require that all clients use these means at all times.
2.5.4. プロトコルは、任意のクライアントが非汚職、非再生、プライバシーを確保するための手段を使用できるようにする必要がありますが、プロトコルは、すべてのクライアントがすべての回でこれらの手段を使用することを要求してはなりません。
The requirements in section 6 are applicable only to PRESENCE INFORMATION and not to INSTANT MESSAGES. Additional constraints on PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear in Section 7.4.
セクション6での要件は唯一のプレゼンス情報にしていないインスタントメッセージに適用されます。インスタントメッセージをサポートするシステムにおけるプレゼンス情報に関する追加の制約は、セクション7.4で表示されます。
3.1.1. All ENTITIES MUST produce and consume at least a common base format for PRESENCE INFORMATION.
3.1.1. すべてのエンティティは、プレゼンス情報のために、少なくとも共通の基本フォーマットを生成し、消費しなければなりません。
3.1.2. The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported.
3.1.2. 共通のプレゼンス形式は一意プレゼンス情報報告さPRESENTITYを識別するための手段を含まなければなりません。
3.1.3. The common presence format MUST include a means to encapsulate contact information for the PRESENTITY's PRINCIPAL (if applicable), such as email address, telephone number, postal address, or the like.
3.1.3. 共通のプレゼンス形式は、電子メールアドレス、電話番号、住所などのプレゼンティティのプリンシパル（該当する場合）の連絡先情報をカプセル化するための手段を含まなければなりません。
3.1.4. There MUST be a means of extending the common presence format to represent additional information not included in the common format, without undermining or rendering invalid the fields of the common format.
3.1.4. 共通フォーマットの無効なフィールドを損なう又はレンダリングすることなく、共通のフォーマットに含まれていない付加的な情報を表現するための共通のプレゼンス形式を拡張する手段がなければなりません。
3.1.5. The working group must define the extension and registration mechanisms for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP.
3.1.5. ワーキンググループは、新しいステータス条件および他のプレゼンスマークアップのための新たな形態を含む、プレゼンス情報スキーマの拡張および登録メカニズムを定義しなければなりません。
3.1.6. The presence format SHOULD be based on IETF standards such as vCard [RFC 2426] if possible.
3.1.6. 可能であればプレゼンス形式は、vCardの[RFC 2426]のようなIETF規格に基づくべきです。
3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE INFORMATION even when the PRESENTITY is OUT OF CONTACT.
3.2.1. フェッチャは、プレゼンティティが接触していない場合でも、プレゼンティティのプレゼンス情報を取得できなければなりません。
3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF CONTACT.
3.2.2. 加入者は、プレゼンティティが接触していない場合でも、プレゼンティティのプレゼンス情報へのサブスクリプションを要求することができなければなりません。
3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, unless prevented by the PRESENTITY's ACCESS RULES.
3.2.3. PRESENCEサービスは、プレゼンティティのプレゼンス情報のサブスクリプション、およびそのプレゼンス情報の変更がある場合はPRESENTITYのアクセス規則によって阻止されない限り、プレゼンスサービスは、各加入者への通知を提供しなければなりません。
3.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.
3.2.4. プロトコルはPRESENTITYまたは加入者が非接触状態になったときを検出するためのメカニズムを提供しなければなりません。
3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER gracefully telling the service that it will no longer be in communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT due to unanticipated failures.
3.2.5. プロトコルは、優雅PRESENTITYまたは加入者が原因予期せぬ障害に接触していて行くかもしれないので、それはもはや、通信することになるサービスを伝えるPRESENTITYまたはサブスクライバに依存してはなりません。
3.3.1. The protocol MUST include mechanisms to allow PRESENCE INFORMATION to be cached.
3.3.1. プロトコルは、プレゼンス情報をキャッシュできるようにする機構を含まなければなりません。
3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE INFORMATION to be updated when the master copy changes.
3.3.2. プロトコルは、マスターコピーの変更、更新するキャッシュされたプレゼンス情報をできるようにするメカニズムを含まなければなりません。
3.3.3 The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms.
プロトコル・キャッシング・ファシリティが確立アクセスルールを回避または認証/暗号化メカニズムの選択を制限してはいけません3.3.3。
3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any SUBSCRIBER to that information MUST be notified of the changed information rapidly, except when such notification is entirely prevented by ACCESS RULES. This requirement is met if each SUBSCRIBER's NOTIFICATION is transported as rapidly as an INSTANT MESSAGE would be transported to an INSTANT INBOX.
3.4.1プレゼンティティがそのプレゼンス情報を変更し、その情報への加入者は、そのような通知は、完全にアクセス規則によって防止される場合を除き、急激に変化情報を通知しなければなりません。各加入者の通知はとして急速にインスタントメッセージをINSTANT INBOXに輸送されるように搬送された場合には、この要件が満たされています。
The requirements in section 4 are applicable only to INSTANT MESSAGES and not to PRESENCE INFORMATION, with the exception of Section 4.4. Section 4.4 describes constraints on PRESENCE INFORMATION that are relevant only to systems that support both INSTANT MESSAGES and PRESENCE INFORMATION.
セクション4における要件は、4.4節を除いて、唯一のインスタントメッセージになく、プレゼンス情報に適用可能です。 4.4節では唯一のインスタントメッセージやプレゼンス情報の両方をサポートしているシステムに関連するプレゼンス情報に制約を記述する。
4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST implement at least a common base format for INSTANT MESSAGES.
4.1.1. インスタントメッセージを送受信するすべてのエンティティは、インスタントメッセージの少なくとも共通の基本フォーマットを実装しなければなりません。
4.1.2. The common base format for an INSTANT MESSAGE MUST identify the sender and intended recipient.
4.1.2. インスタントメッセージのための共通のベースフォーマットは、送信者と意図した受信者を特定しなければなりません。
4.1.3. The common message format MUST include a return address for the receiver to reply to the sender with another INSTANT MESSAGE.
4.1.3. 受信機は、別のインスタントメッセージで送信者に返信するための一般的なメッセージフォーマットは、リターンアドレスを含まなければなりません。
4.1.4. The common message format SHOULD include standard forms of addresses or contact means for media other than INSTANT MESSAGES, such as telephone numbers or email addresses.
4.1.4. 一般的なメッセージフォーマットは、電話番号やメールアドレスなどのインスタントメッセージ以外のメディアのアドレスまたは接触手段の標準形を含むべきです。
4.1.5. The common message format MUST permit the encoding and identification of the message payload to allow for non-ASCII or encrypted content.
4.1.5. 一般的なメッセージフォーマットは、非ASCIIまたは暗号化されたコンテンツを可能にするために、メッセージ・ペイロードの符号化および識別を可能にしなければなりません。
4.1.6. The protocol must reflect best current practices related to internationalization.
4.1.6. プロトコルは、国際化に関連した現在のベストプラクティスを反映しなければなりません。
4.1.7. The protocol must reflect best current practices related to accessibility.
4.1.7. プロトコルは、アクセシビリティに関連する現在のベストプラクティスを反映しなければなりません。
4.1.8. The working group MUST define the extension and registration mechanisms for the message format, including new fields and new schemes for INSTANT INBOX ADDRESSES.
4.1.8. ワーキンググループはINSTANT INBOXアドレスの新しいフィールドと、新しいスキームを含む、メッセージフォーマットの拡張および登録メカニズムを定義しなければなりません。
4.1.9. The working group MUST determine whether the common message format includes fields for numbering or identifying messages. If there are such fields, the working group MUST define the scope within which such identifiers are unique and the acceptable means of generating such identifiers.
4.1.9. ワーキンググループは、共通のメッセージフォーマットは番号又はメッセージを識別するためのフィールドを含むかどうかを決定しなければなりません。そのようなフィールドがある場合、ワーキンググループは、このような識別子が一意であるその中の範囲およびそのような識別子を生成するのに許容される手段を定義しなければなりません。
4.1.10. The common message format SHOULD be based on IETF-standard MIME [RFC 2045].
4.1.10. 一般的なメッセージフォーマットは、IETF標準のMIME [RFC 2045]に基づくべきです。
4.2.1. The protocol MUST include mechanisms so that a sender can be informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons for failure. The working group must determine what mechanisms apply when final delivery status is unknown, such as when a message is relayed to non-IMPP systems.
4.2.1. 送信者は、インスタントメッセージまたは失敗の理由の配信成功を通知することができるように、プロトコルは、機構を含まなければなりません。ワーキンググループは、最終的な配達状態が不明である場合、そのようなメッセージは、非IMPPシステムに中継される場合など、適用どんなメカニズムを決定しなければなりません。
4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid to allow for comfortable conversational exchanges of short messages.
4.3.1. インスタントメッセージの輸送は、ショートメッセージの快適な会話のやり取りを可能にするのに十分に迅速でなければなりません。
4.4.1. The common presence format MUST define a minimum standard presence schema suitable for INSTANT MESSAGE SERVICES.
4.4.1. 共通のプレゼンス形式は、インスタントメッセージサービスに適した最小標準プレゼンススキーマを定義しなければなりません。
4.4.2. When used in a system supporting INSTANT MESSAGES, the common presence format MUST include a means to represent the STATUS conditions OPEN and CLOSED.
4.4.2. インスタントメッセージをサポートするシステムで使用される場合、共通のプレゼンス形式は、開閉ステータス状態を表すための手段を含まなければなりません。
4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to messaging or communication modes other than INSTANT MESSAGE SERVICES.
4.4.3. 開閉ステータス状態はまた、インスタントメッセージサービス以外のメッセージングまたは通信モードに適用されてもよいです。
Security considerations are addressed in section 2.3, Access Control, and section 2.5, Message authentication and encryption.
セキュリティの考慮事項は、セクション2.3、アクセスコントロール、およびセクション2.5、メッセージの認証と暗号化で対処されています。
This section describes further security-related requirements that the protocol must meet.
このセクションでは、プロトコルが満たす必要があり、さらに、セキュリティ関連の要件について説明します。
The security requirements were derived from a set of all-encompassing "security expectations" that were then evaluated for practicality and implementability and translated into requirements. In the appendix, we describe the expectations and the process used to transform them into requirements. In this section, we simply list the consolidated set of derived requirements.
セキュリティ要件は、その後、実用性と実現可能性の評価をし、要件に翻訳されたすべての包括的な「セキュリティの期待」のセットから導き出されました。付録では、我々は期待と要件にそれらを変換するために使用されるプロセスを説明します。このセクションでは、我々は単に派生要件の連結セットをリストします。
Note that in the requirements, ADMINISTRATORs may have privileges beyond those allowed to PRINCIPALs referred to in the requirements. (Unless otherwise noted, the individual expectations specifically refer to PRINCIPALs.) It is up to individual implementations to control administrative access and implement the security privileges of ADMINISTRATORs without compromising the requirements made on PRINCIPALs.
要件では、管理者が要件に言及プリンシパルに許可されたもの以外の権限を持っていることに注意してください。 （特に断りのない限り、個々の期待は、具体的プリンシパルを参照してください。）これは、アップ管理アクセスを制御し、校長に作られた要件を損なうことなく、管理者のセキュリティ権限を実装するために、個々の実装にあります。
Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR PRINCIPALS.
特に断りのない限り、A、B、Cは、すべての管理者以外のプリンシパルの名前です。
When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION:
AはBのプレゼンス情報へのサブスクリプションを確立すると：
5.1.1. The protocol MUST provide A means of identifying and authenticating that the PRESENTITY subscribed to is controlled by B.
5.1.1. プロトコルは、プレゼンティティがBによって制御されるために加入することを識別し、認証する手段を提供しなければなりません
5.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION to B obvious to a third party C.
5.1.2. そう選択した場合、プロトコルがAのサブスクリプションが第三者Cに明らかBに行うべきではありません
5.1.3. The protocol MUST provide B with means of allowing an unauthenticated subscription by A.
5.1.3. プロトコルは、Aによって認証されていないサブスクリプションを可能にする手段とBを提供しなければなりません
5.1.4. The protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A.
5.1.4. プロトコルは、BがAに開示することを選択したコンテンツの正確な受信を検証する手段を提供しなければなりません
5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may choose to accept A's SUBSCRIPTION, but fail to deliver any information to it (so-called "polite blocking"). See 5.1.15.
5.1.5. BがAのサブスクリプションを拒否した場合、BはAに通知しなければなりません。 Bは、（「丁寧ブロック」と呼ばれる）Aのサブスクリプションを受け入れることを選択したが、それに任意の情報を提供するために失敗する可能性があります。 5.1.15を参照してください。
5.1.6. The protocol MUST NOT let any third party C force A to subscribe to B's PRESENCE INFORMATION without A's consent.
5.1.6. プロトコルは、第三者C力AがAの同意なしにBのプレゼンス情報を購読するせてはなりません。
5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE INFORMATION at any time and for any reason. When A does so, the PRESENCE SERVICE stops informing A of changes to B's PRESENCE INFORMATION.
5.1.7. いつでも任意の理由でBのプレゼンス情報への彼女のサブスクリプションをキャンセルすることができなければなりません。 Aがそうすると、PRESENCEサービスは、Bのプレゼンス情報への変更の通知を停止します。
5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's SUBSCRIPTION to B.
5.1.8. プロトコルは、不正なパーティCがBにAのサブスクリプションをキャンセルさせてはなりません
5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD inform A of the cancellation.
5.1.9. BにAのサブスクリプションがキャンセルされた場合、サービスはキャンセルの通知する必要があります。
5.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION to B, at any time.
5.1.10. 任意の時点で、BとAのサブスクリプションのステータスを決定することができるべきです。
5.1.11. The protocol MUST provide B means of learning about A's SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION and afterwards.
5.1.11. プロトコルは、サブスクリプションを確立する時に、その後の両方、BとAのサブスクリプションについての学習のBの手段を提供しなければなりません。
5.1.12. The protocol MUST provide B means of identifying and authenticating the SUBSCRIBER's PRINCIPAL, A.
5.1.12. プロトコルは、A.を識別し、加入者のプリンシパルを認証するB手段を提供しなければなりません
5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL from subscribing.
5.1.13. Bは、サブスクライブから任意の特定の主体を防ぐことが可能でなければなりません。
5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS from subscribing.
5.1.14. Bは、サブスクライブからの匿名のプリンシパルを防ぐことが可能でなければなりません。
5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE to deny A's subscription while appearing to A as if the subscription has been granted (this is sometimes called "polite blocking"). The protocol MUST NOT mandate the PRESENCE SERVICE to service subscriptions that are treated in this manner.
5.1.15. Bは、サブスクリプションは、（これは時々「丁寧ブロック」と呼ばれている）が付与されているかのように登場しながら、Aのサブスクリプションを拒否するようにプレゼンスサービスを設定することが可能でなければなりません。プロトコルは、この方法で処理されているサービスのサブスクリプションにプレゼンスサービスを強制してはなりません。
5.1.17. The protocol MUST NOT require A to reveal A's IP address to B.
5.1.17. プロトコルはBにAのIPアドレスを明らかにAを要求することはできません
When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to another PRINCIPAL A:
プリンシパルBは別のプリンシパルAへの通知のためのプレゼンス情報を公開すると：
5.2.1. The protocol MUST provide means of ensuring that only the PRINCIPAL A being sent the NOTIFICATION by B can read the NOTIFICATION.
5.2.1. プロトコルは、AがBによる通知を送信されるのみプリンシパルが通知を読み取ることができることを保証する手段を提供しなければなりません。
5.2.3. It MUST be possible for B to prevent A from receiving notifications, even if A is ordinarily permitted to see such notifications. It MUST be possible for B to, at its choosing, notify different subscribers differently, through different notification mechanisms or through publishing different content. This is a variation on "polite blocking".
5.2.3. Aは、通常、そのような通知を表示することが許可されていてもBは、通知の受信からAを防止することが可能でなければなりません。 Bは、その選んで、さまざまな通知メカニズムを介して、または別のコンテンツを公開を通じて、異なった別の加入者に通知することが可能でなければなりません。これは、「丁寧ブロック」のバリエーションです。
5.2.4. The protocol MUST provide means of protecting B from another PRINCIPAL C "spoofing" notification messages about B.
5.2.4. プロトコルは、Bについて別のプリンシパルC「なりすまし」の通知メッセージからBを保護する手段を提供しなければなりません
5.2.5. The protocol MUST NOT require that A reveal A's IP address to B.
5.2.5. プロトコルは、AがBにAのIPアドレスを明らかにすることを要求してはなりません
5.2.6. The protocol MUST NOT require that B reveal B's IP address to A.
5.2.6. プロトコルは、BがAにBのIPアドレスを明らかにすることを要求してはなりません
When a PRINCIPAL A receives a notification message from another principal B, conveying PRESENCE INFORMATION,
プリンシパルAは、プレゼンス情報を搬送する、別の主要Bからの通知メッセージを受信すると、
5.3.1. The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B.
5.3.1. B.によって送信されたプロトコルは、プレゼンス情報が正確であることを検証する手段を提供しなければなりません
5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS from entities she has subscribed to.
5.3.2. プロトコルは、Aは彼女が加入しているエンティティからの通知のみ送信されることを保証しなければなりません。
5.3.3. The protocol MUST provide A means of verifying that the notification was sent by B.
5.3.3. プロトコルは、通知がBによって送信されたことを検証する手段を提供しなければなりません
When a user A sends an INSTANT MESSAGE M to another user B,
ユーザAは、別のユーザBへのインスタントメッセージMを送信するとき、
5.4.3. The protocol MUST provide B means of verifying that A sent the message.
5.4.3. プロトコルは、Aは、メッセージを送信したことを確認するB手段を提供しなければなりません。
5.4.4. B MUST be able to reply to the message via another instant message.
5.4.4. Bは、別のインスタントメッセージを介してメッセージに返信することができなければなりません。
5.4.5. The protocol MUST NOT always require A to reveal A's IP address, for A to send an instant message.
5.4.5. Aは、インスタントメッセージを送信するためのプロトコルは、常に、AのIPアドレスを明らかにすることを要求してはなりません。
5.4.6. The protocol MUST provide A means of ensuring that no other PRINCIPAL C can see the content of M.
5.4.6. プロトコルは、他の主Cは、Mの内容を見ることができないことを保証する手段を提供しなければなりません
5.4.7. The protocol MUST provide A means of ensuring that no other PRINCIPAL C can tamper with M, and B means to verify that no tampering has occurred.
5.4.7. プロトコルは、他の主Cは、Mを改ざんできないことを保証する手段を提供しなければなりません、そしてBには改ざんが発生していないことを確認することを意味します。
5.4.9. The protocol MUST allow A to sign the message, using existing standards for digital signatures.
5.4.9. プロトコルは、デジタル署名のために既存の規格を使用して、Aがメッセージに署名することを可能にしなければなりません。
[RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC 2778]の日、M.、ローゼンバーグ、J.とH.嵯峨野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[RFC 2426]ドーソン、F.とT.ハウズ、 "vCardのMIMEディレクトリプロフィール"、RFC 2426、1998年9月。
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC 2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME） - 第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Mark Day SightPath, Inc. 135 Beaver Street Waltham, MA 02452 USA
マーク・デイSightPath、Inc.の135ビーバーストリートウォルサム、MA 02452 USA
EMail: mday@alum.mit.edu (Formerly Mark_Day@lotus.com)
Eメール：mday@alum.mit.edu（旧Mark_Day@lotus.com）
Sonu Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Sonuアガルワルマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: sonuag@microsoft.com
メールアドレス：sonuag@microsoft.com
Gordon Mohr
ゴードン・モーア
EMail: gojomo@usa.net (Formerly gojomo@activerse.com)
Eメール：gojomo@usa.net（旧gojomo@activerse.com）
Jesse Vincent Into Networks, Inc. 150 Cambridgepark Drive Cambridge, MA 02140 USA
ジェシー・ヴィンセントの中へネットワークス株式会社150 Cambridgeparkドライブケンブリッジ、MA 02140 USA
EMail: jesse@intonet.com (Formerly jvincent@microsoft.com)
Eメール：jesse@intonet.com（旧jvincent@microsoft.com）
This appendix is based on the security expectations discussed on the impp mailing list and assembled by Jesse Vincent. The original form of numbering has been preserved in this appendix (so there are several different items labeled B1, for example). The derived requirements have new numbers that are consistent with the main body of the document. This appendix is included to provide a connection from discussions on the list to the requirements of Section 8, but it is not intended to introduce any new requirements beyond those presented in Sections 5 through 8.
この付録では、IMPPメーリングリストで議論セキュリティの予測に基づくものであり、ジェシー・ヴィンセントによって組み立てられています。ナンバリングの元の形式は、この付録に保存されている（そのため、例えば、B1標識いくつかの異なる項目が存在します）。派生要件は、文書の本体と一致している新しい番号を持っています。この付録では、第8項の要件にリスト上の議論からの接続を提供するために含まれていますが、8を通じてセクション5に提示されたものを越えた新たな要件を導入するものではありません。
In the case of PRESENCE INFORMATION, the controlling PRINCIPAL's privacy interests are paramount; we agreed that "polite blocking" (denying without saying that the subscription is denied, or providing false information) should be possible.
プレゼンス情報の場合、制御本人のプライバシーの利益が最も重要です。私たちは「丁寧なブロック」（サブスクリプションが拒否されたことを言わずに否定し、または虚偽の情報を提供する）が可能でなければならないことで合意しました。
When a user Alice subscribes to another person, Bob's presence info, Alice expects:
ユーザーアリスは別の人、ボブのプレゼンス情報をサブスクライブすると、アリスは想定しています。
A1. the PRESENTITY's PRINCIPAL, B, is identifiable and authenticated
A1。 PRESENTITYの主要な、Bは、識別可能で、認証され
Discussion: Stands as a requirement. Note that the protocol
should provide Alice the capability of authenticating, without
requiring that Alice authenticate every SUBSCRIPTION. This
caveat is made necessary by performance concerns, among others,
and applies to many of the other requirements derived below.
[Requirement 5.1.1]
A2. no third party will know that A has subscribed to B.
A2。何の第三者は、AがBに加入していることを知っているんだろう
Discussion: This is somewhat unreasonable to enforce as is. For
example, in some topologies, nothing can prevent someone doing
traffic analysis to deduce that A has subscribed to B. We should
merely require that the protocol not expose subscription
information in any obvious manner. [Requirement 5.1.2]
A3. A has the capability to subscribe to B's presence without B's knowledge, if B permits anonymous subscriptions.
A3。 Aは、Bは、匿名サブスクリプションを許可した場合、Bの知識がなくてもBのプレゼンスをサブスクライブする機能を備えています。
Discussion: An "anonymous subscription" above can have two
implications - (i) B may allow an unauthenticated subscription by
A, and (ii) B may be unaware of A's stated identity. Requirement
(i) is reasonable [Requirement 8.1.3], but (ii) doesn't appear to
be a core requirement -- it can be adequately simulated via a
subscription pseudonym.
A4. A will accurately receive what B chooses to disclose to A regarding B's presence.
A4。正確に関するBの存在に開示することを選択したものをB受け取ることになります。
Discussion: Stands as a requirement, with the "optional"
caveat. [Requirement 8.1.4]
A5. B will inform A if B refuses A's subscription
A5。 BがAのサブスクリプションを拒否した場合、BはAに通知します
Discussion: Stands as a requirement. [Requirement 5.1.5]
考察：要件としてスタンド。 [要件5.1.5]
A6. No third party, C can force A to subscribe to B's presence without A's consent.
A6。いかなる第三者には、CはAの同意なしにBのプレゼンスを購読することを強制することはできません。
Discussion: Stands as a requirement. [Requirement 5.1.6]
考察：要件としてスタンド。 [要件5.1.6]
A7. A can cancel her subscription to B's presence at any time and for any reason. When A does so, she will receive no further information about B's presence information.
A7。いつでも任意の理由でBの存在に彼女のサブスクリプションをキャンセルすることができます。 Aがそうするとき、彼女はBのプレゼンス情報についてのさらなる情報を受け取りません。
Discussion: This essentially stands. However, implementations
may have to contend with a timing window where A receives, after
sending her cancellation request, a notification sent by B before
B received the cancellation request. Therefore, the requirement
should focus on B's ceasing to send presence information, rather
than A's ceasing to receive it. [Requirement 5.1.7]
A8. no third party, C, can cancel A's subscription to B.
A8。何の第三者、Cは、BにAのサブスクリプションをキャンセルすることはできません
Discussion: Stands, although the administrative exception does
apply. [Requirement 5.1.8]
A9. A is notified if her subscription to B is cancelled for any reason.
A9。 Bへの彼女の契約が何らかの理由でキャンセルされた場合にはAが通知されます。
Discussion: Although the intent is reasonable, there are a number
of scenarios (e.g. overburdened server, clogged network, server
crash) where delivering a notification to A of the cancellation
is undesirable or impossible. Therefore, the service should make an attempt to inform, but this is not required. [Requirement
5.1.9]
Bob expects:
ボブは想定しています。
B1. B will be informed that A subscribed to B's presence information, as long as A has not subscribed anonymously.
B1。 Bは限りAが匿名で加入していないとして、Bのプレゼンス情報に加入することを通知されます。
Discussion: This essentially stands. However, B can also choose
to determine A's subscription after the fact. [Requirement
5.1.10]
B2. A is identifiable and authenticated.
B2。 Aは、識別と認証されています。
Discussion: This stands as a requirement. [Requirement 5.1.11]
ディスカッション：これは要件として立っています。 [要件5.1.11]
B3. B can prevent a particular user, D, from subscribing.
B3。 Bは加入から、特定のユーザ、Dを防止することができます。
Discussion: This stands as a requirement. [Requirement 5.1.12]
ディスカッション：これは要件として立っています。 [要件5.1.12]
B4. B can prevent anonymous users from subscribing.
B4。 Bは、サブスクライブから匿名ユーザーを防ぐことができます。
Discussion: This stands as a requirement. [Requirement 5.1.13]
ディスカッション：これは要件として立っています。 [要件5.1.13]
B5. B's presence information is not republished by A to a third party, E, who does not.
B5。 Bのプレゼンス情報はない第三者、E、にによって再発行されていません。
Discussion: This is practically impossible to enforce, so it is
omitted from the requirement set.
B6. B can deny A's subscription without letting A know that she's been blocked.
B6。 Bは、彼女がブロックされていますことを知っているをさせることなく、Aのサブスクリプションを拒否することができます。
Discussion: This "polite blocking" capability essentially stands;
accepting a "denied" subscription should bear no implication on
servicing it for status notifications. [Requirement 5.1.14]
B7. B can cancel A's subscription at will.
B7。 Bは意志でAのサブスクリプションをキャンセルすることができます。
Discussion: Stands as a requirement. [Requirement 5.1.15]
考察：要件としてスタンド。 [要件5.1.15]
Charlie, bob's network administrator expects:
チャーリー、ボブのネットワーク管理者は想定しています。
C1. C knows who is subscribed to B at all times.
C1。 Cはすべての回でBに加入している人を知っています。
Discussion: Administrators should be able to determine who is
subscribed, but needn't be continuously informed of the list of
subscribers. Also, in some cases user agents (e.g. proxies) may have subscribed on behalf of users, and in these cases the
administrator can only determine the identity of these agents,
not their users. [Requirement 5.1.16]
C2. C can manage all aspects of A's presence information.
C2。 CはAのプレゼンス情報のすべての側面を管理することができます。
Discussion: This stands as a requirement. [Requirement 5.1.17]
ディスカッション：これは要件として立っています。 [要件5.1.17]
C3. C can control who can access A's presence information and exchange instant messages with A.
C3。 Cは、AとAのプレゼンス情報を交換インスタントメッセージにアクセスできるユーザーを制御することができます
Discussion: This stands in principle, but C should be able to
waive these capabilities if C desires. [Requirement 5.1.18]
The publisher of status information, Bob, expects:
ステータス情報の発行者、ボブは、想定しています。
B1. That information about B is not provided to any entity without B's knowledge and consent.
B1。 Bについての情報は、Bの知識や同意なしに任意のエンティティに提供されていません。
Discussion: This is nearly impossible to accomplish, so it is
omitted from the requirements.
When information is published for notification, B expects:
情報を通知するために公開されると、Bは想定しています。
B1. only a person being sent a notification, A, can read the notification.
B1。通知が送信されている唯一の人、Aは、通知を読むことができます。
Discussion: Stands as a requirement. [Requirement 5.2.1]
考察：要件としてスタンド。 [要件5.2.1]
B2. A reliably receives all notifications intended for her.
B2。確実に彼女のために意図したすべての通知を受け取ります。
Discussion: This stands, although "Reliably" is a little strong
(e.g. network outages, etc.). [Requirement 5.2.2]
B3. B can prevent A from receiving notifications, even if A is ordinarily permitted to see such notifications. This is a variation on "polite blocking."
B3。 Bは、Aが、通常、そのような通知を表示することが許可された場合でも、通知の受信からAを防止することができます。これは上のバリエーションである「丁寧ブロック。」
Discussion: This stands as a requirement. Also incorporated into
this requirement is the notifications equivalent of the next
expectation, B4. [Requirement 5.2.3]
B4. B can provide two interested parties A and E with different status information at the same time. (B could represent the same event differently to different people.)
B4。 Bは同時に異なるステータス情報を持つ2つの利害関係者AとEを提供することができます。 （Bは別の人に異なっ同じイベントを表すことができます。）
Discussion: This stands as a requirement; it has been
incorporated into the corresponding requirement for B3 above.
B5. B expects that malicious C cannot spoof notification messages about B.
B5。 Bは、悪意のあるCはB.についてのパロディー通知メッセージをできないことを期待します
Discussion: Stands in principle, but it should be optional for B.
[Requirement 5.2.4]
When Alice receives a notification, the recipient, Alice, expects:
アリスは、通知を受信すると、受信者、アリスは、想定しています。
A1. That the notification information is accurate, truthful.
A1。通知情報が真実、正確であること。
Discussion: Stands in principle, although being "truthful" can't
be a requirement, and the verification is optional for Alice.
[Requirement 5.3.1]
A2. That information about subscriptions remains private; people do not learn that A's subscription to B's information exists by watching notifications occur.
A2。サブスクリプションについての情報は、専用のまま。人々は、Bの情報へのAのサブスクリプションは、通知が起こる見て存在していることを学習することはありません。
Discussion: This is omitted from the requirements, as traffic
analysis, even of encrypted traffic, can convey this information
in some situations.
A3. That she only receives notifications of things she's subscribed to.
A3。彼女は彼女だけが加入しています物事の通知を受けること。
Discussion: Stands as a requirement. [Requirement 5.3.2]
考察：要件としてスタンド。 [要件5.3.2]
A4. Notifications come from the apparent sender, B.
A4。通知はB.、見かけ上の送信者から来ます
Discussion: Stands in principle, although the verification should
be optional for A. [Requirement 5.3.3]
A5. A can tell the difference between a message generated by the user, and a message legitimately generated by the agent on behalf of the user.
A5。ユーザーによって生成されたメッセージ、および合法的にユーザーに代わってエージェントによって生成されたメッセージの違いを伝えることができます。
Discussion: This could be quite difficult to enforce and could
unduly restrict usage scenarios; this is omitted from the
requirements.
A6. That information given by agents on behalf of users can also be expected to be truthful, complete, and legitimately offered; the user permitted the agent to publish these notifications.
A6。ユーザーの代わりにエージェントによって与えられている情報は、真実、完全、かつ合法的に提供することが期待できます。ユーザーは、これらの通知を発行するために、エージェントを許可しました。
Discussion: This is difficult to enforce and is omitted from the
requirements.
A7. A can prove that a notification from B was delivered in a timely fashion and can prove exactly how long the message took to be delivered.
A7。 Bからの通知がタイムリーに配信されたメッセージが配信されるようにかかった正確にどのくらいの時間を証明できることを証明することができます。
Discussion: This is difficult to enforce and is omitted from the
requirements. For example, such proof may entail global time
synchronization mechanisms (since any system clocks have
associated unreliability), which is outside the scope of this
effort.
A8. A can prove that B was indeed the sender of a given message.
A8。 Bが与えられたメッセージの送信者が実際にあったことを証明することができます。
Discussion: This is a duplication of expectation A4 above and is
reflected in the corresponding requirement 5.3.3.
When a user Alice sends an instant message M to another user Bob:
ユーザーアリスは、他のユーザ、ボブにインスタントメッセージMを送信する場合：
Alice expects that she:
アリスは彼女ことを想定しています。
A1. will receive notification of non-delivery
A1。非配信の通知を受け取ります
Discussion: Stands as a requirement. [Requirement 5.4.1]
考察：要件としてスタンド。 [要件5.4.1]
Alice expects that Bob:
アリスはボブと予測します：
B1. will receive the message
B1。メッセージを受信します
Discussion: covered by A1 and is reflected in the corresponding
requirement 5.4.1.
B2. will receive the message quickly
B2。すぐにメッセージが表示されます
Discussion: Stands as a requirement, although this is also
covered elsewhere (in the non-security requirements), so this is
omitted from the security requirements.
B3. will receive the message only once
B3。一度だけメッセージが表示されます
Discussion: Stands as a requirement. [Requirement 5.4.2]
考察：要件としてスタンド。 [要件5.4.2]
B4. will be able to verify that Alice sent the message
B4。アリスがメッセージを送っていることを確認することができるようになります
Discussion: Stands as a requirement. [Requirement 5.4.3]
考察：要件としてスタンド。 [要件5.4.3]
B5. will not know whether there were BCCs
B5。 BCCがあったかどうかを知ることができません
Discussion: Emulating e-mail conventions and social protocols is
not a core goal of this effort, and therefore references to
standard mail fields are omitted from the requirements.
B6. will be able to reply to the message
B6。メッセージに返信することができるようになります
Discussion: Stands in principle; the recipient should be able to
reply via an instant message. [Requirement 5.4.4]
B7. will know if he was a bcc recipient
B7。彼はBCCの受信者だったかどうかを知るだろう
Discussion: Omitted, as noted above.
ディスカッション：上記のように、省略。
B8. will not be able to determine any information about A (such as her location or IP address) without A's knowledge and consent.
B8。 （そのような彼女の場所やIPアドレスなど）Aの知識や同意なしAに関する情報を決定することができません。
Discussion: "Any information about A" is too general; the
requirement should focus on IP address. Further, "without A's
knowledge and consent" may be overkill. [Requirement 5.4.5]
Alice expects that no other user Charlie will be able to:
アリスは、他のユーザチャーリーがすることはできなくなることを想定しています。
C1. see the content of M
C1。 Mの内容を見ます
Discussion: Stands in principle, although this should not be
mandated for all IM communication. [Requirement 5.4.6]
C2. tamper with M
C2。 Mを改ざん
Discussion: Stands, with the same caveat as above.
[Requirement 5.4.7]
C3. know that M was sent
C3。 Mが送信されたことを知っています
Discussion: It is impossible to prevent traffic analysis, and
this is therefore omitted from the requirements.
When a user Bob receives an instant message M from another user Alice:
ユーザBobは、他のユーザ、アリスからインスタントメッセージMを受信した場合：
Bob expects that Bob:
ボブは、ボブと予測します：
D1. will be able to read M
D1。 Mを読み取ることができます
Discussion: Stands as a requirement. [Requirement 5.4.8]
考察：要件としてスタンド。 [要件5.4.8]
D2. will be able to verify M's authenticity (both Temporal and the sender's identity)
D2。 （時間的および送信者の身元の両方）Mの真正性を検証することができるようになります
Discussion: As noted earlier, it is not reasonable to directly
require temporal checks. The protocol should, however, allow
signing messages using existing standards for signing.
[Requirement 5.4.9]
D3. will be able to verify M's integrity
D3。 Mの整合性を確認することができるようになります
Discussion: Stands as a requirement. [Requirement 5.4.10]
考察：要件としてスタンド。 [要件5.4.10]
D4. will be able to prevent A from sending him future messages
D4。彼の今後のメッセージを送るからAを防ぐことができるようになります
Discussion: Stands as a requirement. [Requirement 5.4.11]
考察：要件としてスタンド。 [要件5.4.11]
Bob expects that Alice:
ボブは、アリスと予測します：
E1. intended to send the message to Bob
E1。ボブにメッセージを送信するためのもの
Discussion: This is covered by the corresponding requirement
5.4.6 for C1 above.
E2. informed Bob of all CCs.
E2。すべてのCCのボブを通知しました。
Discussion: As noted earlier, references to cc:'s are omitted
from the requirements.
Discussion: Anonymous instant messaging, as in "hiding the
identity of the sender", is not deemed to be a core requirement
of the protocol and references to it are therefore omitted from
the requirements. Implementations may provide facilities for
anonymous messaging if they wish, in ways that are consistent
with the other requirements.
When a user Alice sends an anonymous instant message to another user Bob:
ユーザーアリスは、他のユーザのボブへの匿名のインスタントメッセージを送信する場合：
Alice expects that Bob:
アリスはボブと予測します：
B1. will receive the message
B1。メッセージを受信します
B2. will receive the message quickly
B2。すぐにメッセージが表示されます
B3. will receive the message only once
B3。一度だけメッセージが表示されます
AB4.1. cannot know Alice sent it
AB4.1。アリスはそれを送っ知ることができません
AB4.2. will know that the IM is anonymous, and not from a specific named user
AB4.2。 IMは、特定の名前のユーザーから匿名ではなく、ということを知っているだろう
AB4.3 may not allow anonymous IMs
AB4.3は、匿名のIMを許可しない場合があります
B5. will not know whether there were BCCs
B5。 BCCがあったかどうかを知ることができません
B6. will be able to reply to the message
B6。メッセージに返信することができるようになります
Alice expects that she:
アリスは彼女ことを想定しています。
C1. will receive notification of non-delivery
C1。非配信の通知を受け取ります
AC2. will receive an error if the IM was refused
AC2。 IMが拒否された場合は、エラーを受け取ることになります
Bob expects that he:
ボブは彼と予測します：
D1. will be able to read M
D1。 Mを読み取ることができます
D2. will be able to verify M's authenticity (both temporal and the sender's identity)
D2。 （時間的および送信者の身元の両方）Mの真正性を検証することができるようになります
D3. will be able to verify M's integrity
D3。 Mの整合性を確認することができるようになります
AD4. will know if an IM was sent anonymously
AD4。 IMを匿名で送信されたかどうかを知るだろう
AD5. will be able to automatically discard anonymous IM if desired
AD5。必要に応じて、自動的に匿名のIMを破棄することができるようになります
AD6. will be able to control whether an error is sent to Alice if M is discarded.
AD6。 Mが破棄される場合、エラーがアリスに送信するかどうかを制御することができるであろう。
Charlie, Alice's network administrator expects:
チャーリー、アリスのネットワーク管理者は想定しています。
C1. that C will be able to send A instant messages at any time.
C1。そのCはいつでもインスタントメッセージを送信することができるようになります。
C2. that A will receive any message he sends while A is online.
C2。そのAは、Aがオンラインの間、彼が送信するすべてのメッセージが表示されます。
C3. that A will not be able to refuse delivery of any instant messages sent by C.
C3。そのAはC.によって送信されたインスタントメッセージの配信を拒否することはできません
Discussion for C1-C3: It is not clear this needs to be specially
handled at the protocol level; Administrators may accomplish the
above objectives through other means. For example, an
administrator may send a message to a user through the normal
mechanisms. This is therefore omitted from the requirements.
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。