[要約] RFC 2779は、インターネット標準としてのプレゼンスおよびインスタントメッセージング（IM）プロトコルが満たすべき、詳細な技術要件を定義しています。セキュリティ、ユーザーのプライバシー保護、スケーラビリティ、および異なるサービス間での相互運用性に関する具体的な機能目標を整理しています。メッセージの傍受やなりすましを防止し、ユーザーが自身の状態情報を誰に公開するかを制御できる、安全で信頼性の高いIMインフラの構築を支援することを目的としています。
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.
Copyright（c）The Internet Society（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
アクセスルールクローズドフェッチャーインスタント受信トレイインスタントメッセージ通知オープンポーラープレゼンス情報プレゼンスサービス
The terms MUST and SHOULD are used in the following sense while specifying requirements:
規約は、要件を指定しながら、次の意味で使用する必要があります。
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.
このマストの使用は、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.
ドメイン：名前空間の一部。
ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER (all defined in [RFC 2778]).
エンティティ：プレゼンティ、サブスクライバー、フェッチャー、ポーラー、またはウォッチャー（すべて[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.
識別子：名刺などの公的使用を目的とした連絡先を示す手段。電話番号、メールアドレス、および典型的なホームページ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.
名前空間：エンティティの名前からそのエンティティの具体的な実装にマッピングするシステム。名前空間は、多くの異なるドメインで構成されている場合があります。
OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE SERVICE cannot communicate.
連絡先：一部のエンティティとプレゼンスサービスが通信できない状況。
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.
配信の成功：意図した受信者のインスタントメッセージがインスタント受信トレイに送信され、インスタント受信トレイが領収書を認めた状況。配信の成功は通常、受信トレイユーザーエージェントがプリンシパルによって選択された方法でメッセージを処理したことを意味します。ただし、配信の成功は、メッセージが実際にその校長によって見られたことを意味するものではありません。
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. このプロトコルは、インスタントメッセージサービスが利用可能かどうか、およびその逆とは無関係に、プレゼンスサービスを利用できるようにしなければなりません (MUST)。
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. プロトコルは、インスタント受信トレイが紹介と同じ識別子によって必然的に到達されると仮定してはなりません。具体的には、プロトコルは、一部のインスタント受信トレイに関連するプレゼンテーションがない可能性があり、その逆も同様であると仮定する必要があります。
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. また、プロトコルでは、表示の識別子と同じ識別子を介してインスタント受信トレイに到達できるようにしなければなりません (MUST)。
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. 特定のドメイン内のエンティティの管理と命名は、他のドメインでのアクションとは独立して動作できなければなりません (MUST)。
2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS within the NAMESPACE.
2.1.5. プロトコルは、名前空間内の任意の数のドメインを許可しなければなりません (MUST)。
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. ドメインが以前にお互いを認識していなかった場合、あるドメイン内のエンティティが別のドメインのエンティティと相互運用することが可能でなければなりません (MUST)。
The protocol MUST be capable of meeting its other functional and performance requirements even when
プロトコルは、他の機能的要件とパフォーマンス要件を満たすことができなければなりません (MUST)
-- (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
紹介をコントロールする元本は制御できなければなりません (MUST)
-- (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.
- （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
インスタント受信トレイを制御するプリンシパルは制御できなければなりません (MUST)
-- (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. アクセス制御は存在とは独立していなければなりません (MUST)。プレゼンスサービスは、プレゼンテーションが接触していない場合でも、アクセス制御の決定を行うことができなければなりません (MUST)。
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. プロトコルは、直接およびプロキシなどの仲介者の両方を介してサブスクリプションを作成することを許可しなければなりません (MUST)。
2.4.2. The protocol MUST allow the sending of a NOTIFICATION both directly and via intermediaries, such as PROXIES.
2.4.2. このプロトコルは、直接通知とプロキシなどの仲介者を介して送信することを許可しなければなりません (MUST)。
2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both directly and via intermediaries, such as PROXIES.
2.4.3. このプロトコルは、直接的なインスタントメッセージを直接およびプロキシなどの仲介者を介して送信することを許可しなければなりません (MUST)。
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. プロトコルのプロキシ施設と輸送慣行は、管理者が既存および一般的に展開されたファイアウォールを介してプロトコルアクティビティを有効にして無効にする方法を許可しなければなりません (MUST)。プロトコルは、そのようなファイアウォールによって効果的にフィルタリングする方法を指定しなければなりません (MUST)。
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. プロトコルは、受信したメッセージ（NOTIFICATIONまたはINSTANT MESSAGE）が破損や改ざんを受けていないことを確信できるようにする手段を提供しなければなりません (MUST)。
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. プロトコルは、受信したメッセージ（NOTIFICATIONまたはINSTANT MESSAGE）が攻撃者によって記録され再生されたものではないことを確信できるようにする手段を提供しなければなりません (MUST)。
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. プロトコルは、送信されたメッセージ（NOTIFICATIONまたはINSTANT MESSAGE）を、送信者が許可したENTITYのみが読めるようにする手段を提供しなければなりません (MUST)。
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. すべてのエンティティは、プレゼンス情報のために少なくとも共通のベース形式を作成および消費しなければなりません (MUST)。
3.1.2. The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported.
3.1.2. 共通のプレゼンスフォーマットには、プレゼンス情報が報告されているプレゼントを一意に識別する手段を含めなければなりません (MUST)。
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. 共通のプレゼンス形式には、電子メールアドレス、電話番号、郵便アドレスなど、プレゼンティのプリンシパル（該当する場合）の連絡先情報をカプセル化する手段を含めなければなりません (MUST)。
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. 共通形式に含まれていない追加情報を表すために、共通のプレゼンス形式を拡張する手段がなければなりません (MUST)。
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標準に基づいているべきです (SHOULD)。
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. フェッチャーは、プレゼンティが接触していない場合でも、プレゼンティの存在情報を取得できなければなりません (MUST)。
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. サブスクライバーは、プレゼンティが接触していない場合でも、プレゼンティの存在情報のサブスクリプションを要求できなければなりません (MUST)。
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. プレゼンスサービスには、プレゼンテーションのプレゼンス情報のサブスクリプションがあり、そのプレゼンス情報が変更された場合、プレゼンスサービスは、プレゼンティのアクセスルールで防止されない限り、各サブスクライバーに通知を提供しなければなりません (MUST)。
3.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.
3.2.4. プロトコルは、提示またはサブスクライバーが接触しなくなったときに検出するためのメカニズムを提供しなければなりません (MUST)。
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. プロトコルは、予期せぬ障害のためにプレゼンティまたはサブスクライバーが接触しなくなる可能性があるため、サービスにコミュニケーションがなくなることをサービスに優雅に伝えることに依存してはなりません (MUST NOT)。
3.3.1. The protocol MUST include mechanisms to allow PRESENCE INFORMATION to be cached.
3.3.1. プロトコルには、存在情報をキャッシュできるようにするメカニズムを含めなければなりません (MUST)。
3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE INFORMATION to be updated when the master copy changes.
3.3.2. プロトコルには、マスターコピーが変更されたときにキャッシュされた存在情報を更新できるようにするメカニズムを含めなければなりません (MUST)。
3.3.3 The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms.
3.3.3 プロトコルキャッシュ施設は、確立されたアクセスルールを回避したり、認証/暗号化メカニズムの選択を制限したりしてはなりません (MUST NOT)。
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 プレゼンティが存在情報を変更すると、その情報のサブスクライバーは、アクセスルールによって完全に妨げられている場合を除き、変更された情報を迅速に通知しなければなりません (MUST)。この要件は、各サブスクライバーの通知がインスタントメッセージがインスタント受信トレイに輸送されるのと同じくらい迅速に輸送される場合に満たされます。
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. インスタントメッセージを送信および受信するすべてのエンティティは、インスタントメッセージに対して少なくとも共通のベース形式を実装しなければなりません (MUST)。
4.1.2. The common base format for an INSTANT MESSAGE MUST identify the sender and intended recipient.
4.1.2. インスタントメッセージの共通のベース形式は、送信者と意図された受信者を識別しなければなりません (MUST)。
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. 一般的なメッセージ形式には、レシーバーが別のインスタントメッセージで送信者に返信するための返信アドレスを含めなければなりません (MUST)。
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. 一般的なメッセージ形式には、電話番号や電子メールアドレスなど、インスタントメッセージ以外のメディアのアドレスの標準フォームまたは連絡先手段を含めるべきです (SHOULD)。
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または暗号化されたコンテンツを許可しなければなりません (MUST)。
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. ワーキンググループは、インスタントインボックスアドレスの新しいフィールドや新しいスキームなど、メッセージ形式の拡張機能と登録メカニズムを定義しなければなりません (MUST)。
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. ワーキンググループは、一般的なメッセージ形式にメッセージの番号付けまたは識別のフィールドが含まれるかどうかを判断しなければなりません (MUST)。そのようなフィールドがある場合、ワーキンググループは、そのような識別子が一意である範囲と、そのような識別子を生成する許容可能な手段を定義しなければなりません (MUST)。
4.1.10. The common message format SHOULD be based on IETF-standard MIME [RFC 2045].
4.1.10. 一般的なメッセージ形式は、IETFスタンダードMIME [RFC 2045]に基づいているべきです (SHOULD)。
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. プロトコルは、送信者がINSTANT MESSAGEのSUCCESSFUL DELIVERY、または失敗の理由を知らされるようにするためのメカニズムを含まなければなりません (MUST)。ワーキンググループは、メッセージが非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. インスタントメッセージの輸送は、短いメッセージの快適な会話交換を可能にするために十分に迅速でなければなりません (MUST)。
4.4.1. The common presence format MUST define a minimum standard presence schema suitable for INSTANT MESSAGE SERVICES.
4.4.1. 共通のプレゼンス形式は、インスタントメッセージサービスに適した最小標準存在スキーマを定義しなければなりません (MUST)。
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. インスタントメッセージをサポートするシステムで使用する場合、共通のプレゼンス形式には、開いて閉じたステータス条件を表す手段を含めなければなりません (MUST)。
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はすべて、非管理者校長の名前です。
[RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC 2778] Day, M., Rosenberg, J. and H. Sagano、「存在とインスタントメッセージングのモデル」、RFC 2778、2000年2月。
[RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[RFC 2426] Dawson, F. and T. Howes、「VCard Mime Dime Directory Profile」、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] Freed, N. and N. Borenstein、「多目的インターネットメールエクステンション（MIME） - パート1：インターネットメッセージボディの形式」、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] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Mark Day SightPath, Inc. 135 Beaver Street Waltham, MA 02452 USA
Mark Day SightPath、Inc。135 Beaver Street Waltham、MA 02452 USA
EMail: mday@alum.mit.edu
(Formerly Mark_Day@lotus.com)
Sonu Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Sonu Aggarwal Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
EMail: sonuag@microsoft.com
Gordon Mohr
ゴードン・モール
EMail: gojomo@usa.net
(Formerly gojomo@activerse.com)
Jesse Vincent Into Networks, Inc. 150 Cambridgepark Drive Cambridge, MA 02140 USA
Jesse Vincent Into Networks、Inc。150 CambridgePark Drive Cambridge、MA 02140 USA
EMail: jesse@intonet.com
(Formerly 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メーリングリストで議論され、Jesse Vincentが組み立てたセキュリティの期待に基づいています。番号付けの元の形式は、この付録に保存されています（たとえば、B1とラベル付けされたいくつかの異なるアイテムがあります）。派生要件には、ドキュメントの本体と一致する新しい数字があります。この付録は、リストの議論からセクション8の要件までの接続を提供するために含まれていますが、セクション5〜8に示されている要件を超えた新しい要件を導入することを意図したものではありません。
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.
存在情報の場合、支配校長のプライバシーの利益が最重要です。「丁寧なブロック」（サブスクリプションが拒否されていることを否定すること、または誤った情報を提供することを否定する）が可能であることに同意しました。
8.1.1. Subscription
8.1.1. サブスクリプション
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。プレゼントの校長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]
ディスカッション：要件として立っています。アリスがすべてのサブスクリプションを認証することを要求することなく、プロトコルはアリスに認証の能力を提供する必要があることに注意してください。この警告は、とりわけパフォーマンスの懸念によって必要になり、以下に導かれた他の多くの要件に適用されます。[要件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]
ディスカッション：これは、そのまま実施するのはやや不合理です。たとえば、一部のトポロジでは、AがBにサブスクライブしていると推測するために誰かがトラフィック分析を行うのを防ぐことはできません。プロトコルが明白な方法でサブスクリプション情報を公開しないことを単に要求する必要があります。[要件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.
ディスカッション：上記の「匿名のサブスクリプション」には2つの意味があります。（i）Bは、Aによる認知度のないサブスクリプションを許可する場合があり、（ii）BはAの記載されているアイデンティティに気付かない場合があります。要件（i）は合理的です[要件8.1.3]が、（ii）はコア要件ではないようです。サブスクリプションの仮名で適切にシミュレートできます。
A4. A will accurately receive what B chooses to disclose to A regarding B's presence.
A4。Aは、Bの存在に関してAに開示するためにBが選択したものを正確に受け取ります。
Discussion: Stands as a requirement, with the "optional" caveat. [Requirement 8.1.4]
ディスカッション：「オプションの」警告を備えた要件として立っています。[要件8.1.4]
A5. B will inform A if B refuses A's subscription
A5。BはAのサブスクリプションを拒否した場合に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に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。Aは、いつでも何らかの理由で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]
ディスカッション：これは本質的に立っています。ただし、実装は、キャンセルリクエストを送信した後、BがBによって送信された通知がキャンセルリクエストを受け取ったタイミングウィンドウと闘う必要がある場合があります。したがって、要件は、Aがそれを受け取るのをやめるのではなく、プレゼンス情報を送信するためにBの停止に焦点を合わせる必要があります。[要件5.1.7]
A8. no third party, C, can cancel A's subscription to B.
A8。サードパーティCは、AのBへのサブスクリプションをキャンセルすることはできません
Discussion: Stands, although the administrative exception does apply. [Requirement 5.1.8]
ディスカッション：スタンド、しかし、管理の例外は適用されますが。[要件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]
ディスカッション：意図は合理的ですが、キャンセルのAに通知を提供することは望ましくないか不可能な多くのシナリオ（たとえば、過剰なサーバー、詰まったネットワーク、サーバークラッシュ）があります。したがって、サービスは通知を試みる必要がありますが、これは必要ありません。[要件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]
ディスカッション：これは本質的に立っています。ただし、Bは、事実の後にAのサブスクリプションを決定することもできます。[要件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のプレゼンス情報は、Aによって第三者、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]
議論：この「丁寧なブロック」機能は本質的に立っています。「拒否された」サブスクリプションを受け入れることは、ステータス通知にサービスを提供することに影響を与えないはずです。[要件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]
ディスカッション：管理者は、誰が購読されているかを判断できるはずですが、加入者のリストを継続的に通知する必要はありません。また、場合によっては、ユーザーエージェント（プロキシなど）がユーザーに代わって購読している場合があり、これらの場合、管理者はユーザーではなくこれらのエージェントのIDのみを決定できます。[要件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をAでインスタントメッセージを交換できます。
Discussion: This stands in principle, but C should be able to waive these capabilities if C desires. [Requirement 5.1.18]
議論：これは原則として立っていますが、Cが望む場合、Cはこれらの能力を放棄できるはずです。[要件5.1.18]
8.1.2. Publication
8.1.2. 出版
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.
議論：これは達成することはほぼ不可能であるため、要件から省略されています。
8.1.3. Publication for Notification
8.1.3. 通知のための公開
When information is published for notification, B expects:
通知のために情報が公開されると、Bは次のことを期待しています。
B1. only a person being sent a notification, A, can read the notification.
B1。通知を送られている人だけが通知を読むことができます。
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]
議論：これは、「確実に」は少し強い（ネットワークの停止など）。[要件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に相当する通知です。[要件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.
議論：これは要件として表れています。上記のB3の対応する要件に組み込まれています。
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]
ディスカッション：原則的に立っていますが、Bにはオプションである必要があります[要件5.2.4]
8.1.4. Receiving a Notification
8.1.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]
議論：原則として立っていますが、「真実」であることは要件ではありません。検証はアリスにとってオプションです。[要件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]
議論：原則として立っていますが、検証はAに対してオプションでなければなりません[要件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。Aは、ユーザーによって生成されたメッセージと、ユーザーに代わってエージェントによって合法的に生成されたメッセージの違いを示すことができます。
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。Aは、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。Aは、Bが実際に特定のメッセージの送信者であることを証明することができます。
Discussion: This is a duplication of expectation A4 above and is reflected in the corresponding requirement 5.3.3.
議論：これは上記の期待A4の重複であり、対応する要件5.3.3に反映されています。
8.2.1. Named Instant Messaging
8.2.1. インスタントメッセージングと名付けられました
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.
議論：A1でカバーされ、対応する要件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]
ディスカッション：原則として立っています。受信者は、インスタントメッセージを介して返信できる必要があります。[要件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。Aの知識と同意なしに（彼女の場所やIPアドレスなど）に関する情報を決定することはできません。
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]
ディスカッション：「Aに関する情報」はあまりにも一般的です。要件はIPアドレスに焦点を合わせる必要があります。さらに、「Aの知識と同意なしに」はやり過ぎです。[要件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]
ディスカッション：原則として立っていますが、これはすべてのIMコミュニケーションに義務付けられるべきではありません。[要件5.4.6]
C2. tamper with M
C2。mで改ざんします
Discussion: Stands, with the same caveat as above. [Requirement 5.4.7]
ディスカッション：上記と同じ注意を払って立っています。[要件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:
ユーザーボブが別のユーザーアリスからインスタントメッセージ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の信ity性を確認できる（時間的および送信者の身元の両方）
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]
議論：前述のように、一時的なチェックを直接要求することは合理的ではありません。ただし、プロトコルでは、署名のために既存の標準を使用してメッセージに署名する必要があります。[要件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.
議論：これは、上記のC1の対応する要件5.4.6でカバーされています。
E2. informed Bob of all CCs.
E2。すべてのCCSの情報に基づいたボブ。
Discussion: As noted earlier, references to cc:'s are omitted from the requirements.
議論：前述のように、CC： 'の言及は要件から省略されています。
8.2.2. Anonymous Instant Messaging
8.2.2. 匿名のインスタントメッセージング
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は匿名のIMSを許可しない場合があります
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の信ity性を確認できる（時間的および送信者の身元の両方）
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が破棄された場合、エラーがアリスに送信されるかどうかを制御できます。
8.2.3. Administrator Expectations
8.2.3. 管理者の期待
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がオンラインで送信されるメッセージを受け取ること。
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.
C1-C3の議論：これがプロトコルレベルで特別に処理する必要があることは明らかではありません。管理者は、他の手段を通じて上記の目的を達成する場合があります。たとえば、管理者は通常のメカニズムを介してユーザーにメッセージを送信する場合があります。したがって、これは要件から省略されています。
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。