[要約] RFC 2779は、インスタントメッセージング/プレゼンスプロトコルの要件を定義しており、インスタントメッセージングとプレゼンス情報の効果的な通信を可能にするためのガイドラインを提供しています。目的は、異なるプラットフォーム間での相互運用性を確保し、セキュリティやプライバシーの要件を満たすための基準を設定することです。
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.
配信の成功：意図した受信者のインスタントメッセージがインスタント受信トレイに送信され、インスタント受信トレイが領収書を認めた状況。配信の成功は通常、受信トレイユーザーエージェントがプリンシパルによって選択された方法でメッセージを処理したことを意味します。ただし、配信の成功は、メッセージが実際にその校長によって見られたことを意味するものではありません。
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.
このセクションでは、プレゼンスサービスとインスタントメッセージサービスの両方に共通の非セキュリティ要件について説明します。セクション6では、プレゼンスサービスに固有の要件について説明し、セクション7ではインスタントメッセージサービスに固有の要件について説明します。セクション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 Presence and Instant Messaging protocols are expected to be deployed.
存在感とインスタントメッセージングサービスは、モバイルIPワイヤレスアクセスデバイスよりもユーザーにとって特に価値があると予想されます。実際、ワイヤレス平均を介してインターネットに接続されているデバイスの数は、今後数年間で大幅に成長すると予想されます。インターネットのワイヤレス部分で個別のプロトコルが利用可能になると仮定することは合理的ではありません。さらに、ワイヤレスインフラストラクチャは急速に成熟していることに注意してください。このグループが実施した作業では、存在とインスタントメッセージングプロトコルが展開されると予想される時間フレームで、テクノロジーの成熟度の予想される状態を考慮する必要があります。
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. プロトコルは、インスタント受信トレイが紹介と同じ識別子によって必然的に到達されると仮定してはなりません。具体的には、プロトコルは、一部のインスタント受信トレイに関連するプレゼンテーションがない可能性があり、その逆も同様であると仮定する必要があります。
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. また、プロトコルでは、表示の識別子と同じ識別子を介してインスタント受信トレイに到達できるようにする必要があります。
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
紹介をコントロールする元本は制御できる必要があります
-- (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
インスタント受信トレイを制御するプリンシパルは制御できる必要があります
-- (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. 共通の存在フォーマットには、存在情報が報告されているプレゼントを一意に識別する手段を含める必要があります。
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. プレゼンスサービスには、プレゼンテーションのプレゼンス情報のサブスクリプションがあり、そのプレゼンス情報が変更された場合、プレゼンスサービスは、プレゼンティのアクセスルールで防止されない限り、各サブスクライバーに通知を提供する必要があります。
3.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.
3.2.4. プロトコルは、提示またはサブスクライバーが接触しなくなったときに検出するためのメカニズムを提供する必要があります。
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. プロトコルは、予期せぬ障害のためにプレゼンティまたはサブスクライバーが接触しなくなる可能性があるため、サービスにコミュニケーションがなくなることをサービスに優雅に伝えることに依存してはなりません。
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 プレゼンティが存在情報を変更すると、その情報のサブスクライバーは、アクセスルールによって完全に妨げられている場合を除き、変更された情報を迅速に通知する必要があります。この要件は、各サブスクライバーの通知がインスタントメッセージがインスタント受信トレイに輸送されるのと同じくらい迅速に輸送される場合に満たされます。
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. ワーキンググループは、インスタントインボックスアドレスの新しいフィールドや新しいスキームなど、メッセージ形式の拡張機能と登録メカニズムを定義する必要があります。
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が選択した場合、プロトコルはAのbへのサブスクリプションをサードパーティCに明白にするべきではありません。
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は、BがAのサブスクリプションを拒否した場合に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. プロトコルは、Aの同意なしに、第三者Cに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. Aは、いつでも何らかの理由でBの存在情報へのサブスクリプションをキャンセルできる必要があります。Aがそうする場合、プレゼンスサービスは、Bの存在情報の変更を通知するのを停止します。
5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's SUBSCRIPTION to B.
5.1.8. プロトコルは、不正なパーティCをBのサブスクリプションをキャンセルさせてはなりません。
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. Aは、Aのbのサブスクリプションのステータスをいつでも決定できるはずです。
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. プロトコルは、サブスクリプションの確立時とその後の両方で、Aのbのサブスクリプションについて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のサブスクリプションを拒否しながら、bがaのサブスクリプションを拒否しているように設定することが可能である必要があります。これは、サブスクリプションが付与されているかのように表示されます（これは「丁寧なブロック」と呼ばれることもあります）。プロトコルは、この方法で扱われるサービスサブスクリプションにプレゼンスサービスを義務付けてはなりません。
5.1.16. B MUST be able to cancel A's subscription at will.
5.1.16. Bは、Aのサブスクリプションを自由にキャンセルできる必要があります。
5.1.17. The protocol MUST NOT require A to reveal A's IP address to B.
5.1.17. プロトコルは、AのIPアドレスをBに表示することを要求してはなりません
5.1.18 The protocol MUST NOT require B to reveal B's IP address to A.
5.1.18 プロトコルは、BのBのIPアドレスをAに表示するためにBを要求してはなりません。
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. プロトコルは、Bによって通知を送信されているプリンシパルAのみが通知を読み取ることができるようにする手段を提供する必要があります。
5.2.2. A should receive all NOTIFICATIONS intended for her.
5.2.2. Aは彼女のためのすべての通知を受け取る必要があります。
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のAのIPアドレスをBにBEにすることを要求してはなりません。
5.2.6. The protocol MUST NOT require that B reveal B's IP address to A.
5.2.6. プロトコルは、BがBのIPアドレスをAに明らかにすることを要求してはなりません。
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がインスタントメッセージmを別のユーザーbに送信する場合、
5.4.1. A MUST receive confirmation of non-delivery.
5.4.1. 非配信の確認を受け取る必要があります。
5.4.2. If M is delivered, B MUST receive the message only once.
5.4.2. mが配信された場合、Bは一度だけメッセージを受信する必要があります。
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アドレスを表示するために常にAを要求する必要はありません。
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.8. B must be able to read M.
5.4.8. BはMを読むことができなければなりません
5.4.9. The protocol MUST allow A to sign the message, using existing standards for digital signatures.
5.4.9. プロトコルでは、デジタル署名の既存の標準を使用して、Aがメッセージに署名できるようにする必要があります。
5.4.10. B MUST be able to prevent A from sending him messages
5.4.10. bはAが彼にメッセージを送信するのを防ぐことができなければなりません
[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。、および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。および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。および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の議論：これがプロトコルレベルで特別に処理する必要があることは明らかではありません。管理者は、他の手段を通じて上記の目的を達成する場合があります。たとえば、管理者は通常のメカニズムを介してユーザーにメッセージを送信する場合があります。したがって、これは要件から省略されています。
Full Copyright Statement
完全な著作権声明
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エディター機能の資金は現在、インターネット協会によって提供されています。