RFC2779 日本語訳
2779 Instant Messaging / Presence Protocol Requirements. M. Day, S.Aggarwal, G. Mohr, J. Vincent. February 2000. (Format: TXT=47420 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Day
Request for Comments: 2779 Lotus
Category: Informational S. Aggarwal
Microsoft
G. Mohr
Activerse
J. Vincent
Into Networks
February 2000
コメントを求めるワーキンググループM.日の要求をネットワークでつないでください: 2779年のロータスカテゴリ: ネットワーク2000年2月への情報のS.のマイクロソフトのG.モーア・Activerse J.Aggarwalヴィンセント
Instant Messaging / Presence Protocol Requirements
インスタントメッセージング/存在プロトコル要件
Status of this Memo
この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)インターネット協会(2000)。 All rights reserved。
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.
存在とInstant Messagingは最近、コミュニケーションの新しい媒体としてインターネットの上に現れました。 存在は、他のユーザの存在情報(例えば、「オンライン」か「オフライン」)における変化に見つけて、検索して、加入するための手段です。 インスタントメッセージングは、すぐにオンラインで配達される小さくて、簡単なメッセージにユーザを送るための手段です。
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.
存在とインスタントメッセージングのアプリケーションは現在、様々なベンダーによって開発された独立していて、標準的でなくて非共同利用できるプロトコルを使用します。 Instant MessagingとPresenceプロトコル(IMPP)作業部会の目標はインスタントメッセージング、そして/または、存在の独自に開発されたアプリケーションがインターネットの向こう側に共同利用できるように標準プロトコルを定義することです。 このドキュメントはIMPPが会わなければならないという要件の極小集合を定義します。
Day, et al. Informational [Page 1] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [1ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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
1. 用語… 3 2. 要件を共有します… 4 2.1. 名前空間と政権… 5 2.2. スケーラビリティ… 5 2.3. コントロールにアクセスしてください… 6 2.4. ネットワーク形態… 6 2.5. メッセージ暗号化と認証… 7 3. 存在情報のための追加要件… 7 3.1. 一般的な存在形式… 7 3.2. 存在ルックアップと通知… 8 3.3. 存在キャッシュと模写… 8 3.4. パフォーマンス… 9 4. インスタントメッセージのための追加要件… 9 4.1. 一般的なメッセージ・フォーマット… 9 4.2. 信頼性… 10 4.3. パフォーマンス… 10 4.4. 存在形式… 10 5. セキュリティ問題… 11 5.1. 要件はSUBSCRIPTIONSに関連しました… 11 5.2. 要件はNOTIFICATIONに関連しました… 12 5.3. 要件は受信にNOTIFICATIONに関連しました… 13 5.4. 要件はINSTANT MESSAGESに関連しました… 13 6. 参照… 14 7. 作者のアドレス… 15 8. 付録: セキュリティ期待と要件を引き出します… 16 8.1. 存在情報… 16 8.1.1. 購読… 16 8.1.2. 公表… 19 8.1.3. 通知のための公表… 19 8.1.4. 通知を受け取ります… 20 8.2. インスタントメッセージング… 21 8.2.1. インスタントメッセージングと命名されます… 21 8.2.2. 匿名のインスタントメッセージング… 23 8.2.3. 管理者期待… 24 完全な著作権宣言文… 26
Day, et al. Informational [Page 2] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [2ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
1. Terminology
1. 用語
The following terms are defined in [RFC 2778] and are used with those definitions in this document:
次の用語は、[RFC2778]で定義されて、それらの定義と共に本書では使用されます:
ACCESS RULES CLOSED FETCHER INSTANT INBOX INSTANT MESSAGE NOTIFICATION OPEN POLLER PRESENCE INFORMATION PRESENCE SERVICE PRESENTITY PRINCIPAL PROXY SERVER STATUS SUBSCRIBER SUBSCRIPTION WATCHER
アクセス規則は即時のオープンなFETCHER主要なプロキシサーバ状態加入者購読受信トレイインスタントメッセージ通知POLLER存在情報存在サービスPRESENTITYウォッチャーを閉じました。
The terms MUST and SHOULD are used in the following sense while specifying requirements:
用語はそうしなければなりません、そして、要件を指定している間、SHOULDは以下の意味で使用されます:
MUST: A proposed solution will have to meet this requirement. SHOULD: A proposed solution may choose not to meet this requirement.
必須: 提案されたソリューションはこの必要条件を満たさなければならないでしょう。 :であるべきです 提案されたソリューションは、この必要条件を満たさないのを選ぶかもしれません。
Note that this usage of MUST and SHOULD differs from that of RFC 2119.
それに注意してください、この用法、SHOULDはRFC2119のものと異なっていなければなりません。
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.
管理者: ローカルコンピュータとネットワーク資源の上に権威があるプリンシパル。(そのプリンシパルは、地方のDOMAINSかFIREWALLSを管理します)。 セキュリティと他の目的、ADMINISTRATORに関しては、しばしば、ネットワーク用法に制限を課す必要性か必需品がタイプ、内容、量、または終点をトラフィックに基礎づけました。 プリンシパルのADMINISTRATORはそのプリンシパルのコンピュータとネットワーク資源のいくつかかすべて上で権限があります。
DOMAIN: A portion of a NAMESPACE.
ドメイン: NAMESPACEの一部。
ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER (all defined in [RFC 2778]).
実体: PRESENTITY、SUBSCRIBER、FETCHER、POLLER、またはWATCHER([RFC2778]で定義されたすべて)のいずれも。
Day, et al. Informational [Page 3] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [3ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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.
ファイアウォール: 接続性の上の運営管理コントロールのポイント。 励行される方針によって、パーティーは、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.
識別子: 名刺などの公共の使用のために意図する連絡先を示す手段。 電話番号、Eメールアドレス、および典型的なホームページURLはすべて他のシステムのIDENTIFIERSに関する例です。数値IPが同類を扱う、10.0、.0、.26、なくて、また多数のCGIパラメタを含むURLであるかまたは任意の識別子を切望しません。
INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT MESSAGE is sending it.
受取人は意図しました: INSTANT MESSAGEの送付者がそれを送るプリンシパル。
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.
名前空間: それがENTITYという名前から具体的なそのENTITYの実装まで写像するシステム。 NAMESPACEは多くの異なったDOMAINSで構成されるかもしれません。
OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE SERVICE cannot communicate.
接触から: いくらかのENTITYとPRESENCE SERVICEが交信できない状況。
SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually also implies that an INBOX USER AGENT has handled the message in a way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not imply that the message was actually seen by that PRINCIPAL.
うまくいっている配送: INSTANT MESSAGEがINTENDED RECIPIENT、およびINSTANT INBOXのためにINSTANT INBOXに伝えられた状況は領収書を受け取ったことを知らせました。 また、通常、SUCCESSFUL DELIVERYは、INBOX USER AGENTがある意味でプリンシパルによって選ばれたメッセージを扱ったのを含意します。 しかしながら、SUCCESSFUL DELIVERYは、メッセージが実際にそのプリンシパルによって見られたのを含意しません。
2. Shared Requirements
2. 共有された要件
This section describes non-security requirements that are common to both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6 describes requirements specific to a PRESENCE SERVICE, while Section 7 describes requirements specific to an INSTANT MESSAGE SERVICE. Section 8 describes security considerations. The reader should note that Section 11 is an appendix that provides historical context and aids in tracing the origins of requirements in Section 8. Section 11 is not, however, a statement of current IMPP requirements.
このセクションはPRESENCE SERVICEとINSTANT MESSAGE SERVICEの両方に共通の非セキュリティ要件について説明します。 セクション6はPRESENCE SERVICEに特定の要件について説明しますが、セクション7はINSTANT MESSAGE SERVICEに特定の要件について説明します。 セクション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とInstant Messagingサービスが特にモバイルIPワイヤレス・アクセスデバイスの上のユーザにとって貴重になると予想されます。 本当に、ワイヤレスの手段でインターネットに接続されたデバイスの数が来たる年の間、実質的に成長すると予想されます。 別々のプロトコルがインターネットのワイヤレスの部分に利用可能になると仮定するのは妥当ではありません。 さらに、私たちは、ワイヤレスのインフラストラクチャが急速に成熟していることに注意します。 このグループによって引き受けられた仕事が中で時間枠で技術の円熟の期待している状態を考慮に入れるべきである、どれ
Day, et al. Informational [Page 4] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [4ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
Presence and Instant Messaging protocols are expected to be deployed.
存在とInstant Messagingプロトコルが配布されると予想されます。
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. Namespace and Administration
2.1. 名前空間と政権
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. プロトコルは、PRESENCE SERVICEがINSTANT MESSAGE SERVICEが利用可能であり、逆もまた同様です、の如何にかかわらず利用可能であることを許容しなければなりません。
2.1.2. The protocols must not assume that an INSTANT INBOX is necessarily reached by the same IDENTIFIER as that of a PRESENTITY. Specifically, the protocols must assume that some INSTANT INBOXes may have no associated PRESENTITIES, and vice versa.
2.1.2. プロトコルは、INSTANT INBOXが必ずPRESENTITYのものと同じIDENTIFIERによって達せられていると仮定してはいけません。 明確に、プロトコルは、いくつかのINSTANT INBOXesにはどんな関連PRESENTITIESもないかもしれないと仮定しなければなりません、そして、逆もまた同様です。
2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY.
2.1.3. また、プロトコルは、INSTANT INBOXにいくらかのPRESENTITYのIDENTIFIERと同じIDENTIFIERを通して達するのを許容しなければなりません。
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. そして、管理、命名して、いかなる他のDOMAINでの動作の如何にかかわらず与えられたDOMAIN MUSTの中のENTITIESでは、作動できてください。
2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS within the NAMESPACE.
2.1.5. プロトコルはNAMESPACEの中でDOMAINSの特殊活字の数字を考慮しなければなりません。
2.2. Scalability
2.2. スケーラビリティ
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. 1DOMAINのENTITIESが別のDOMAINのENTITIESと共に共同利用するのは、可能であるに違いありません、以前にDOMAINSなしで互いを意識していて。
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) 独身のDOMAINの中に何百万ENTITIESがあります。
-- (2.2.3) there are millions of DOMAINS within the single
NAMESPACE.
-- (2.2 .3) 独身のNAMESPACEの中に何百万DOMAINSがあります。
Day, et al. Informational [Page 5] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [5ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
-- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds
of PRESENTITIES.
-- (2.2 .4) あらゆるSUBSCRIBERには、SUBSCRIPTIONSが何百PRESENTITIESまであります。
-- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to
a single PRESENTITY.
-- (2.2に、異なったSUBSCRIBERSの.5の)数百が独身のPRESENTITYにSUBSCRIPTIONSを持っています。
-- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to
PRESENTITIES in hundreds of distinct DOMAINS.
-- (2.2 .6) あらゆるSUBSCRIBERが何百異なったDOMAINSにPRESENTITIESにSUBSCRIPTIONSを持っています。
These are protocol design goals; implementations may choose to place lower limits.
これらはプロトコルデザイン目標です。 実装は、下限を置くのを選ぶかもしれません。
2.3. Access Control
2.3. アクセス制御
The PRINCIPAL controlling a PRESENTITY MUST be able to control
プリンシパル、PRESENTITY MUSTを制御して、制御できてください。
-- (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE
INFORMATION.
-- (2.3 .1) どのWATCHERSがそのPRESENTITYのPRESENCE INFORMATIONを観測できますか?
-- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that
PRESENTITY's PRESENCE INFORMATION.
-- (2.3 .2) どのWATCHERSがそのPRESENTITYのPRESENCE INFORMATIONにSUBSCRIPTIONSを持つことができますか?
-- (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、)、PRESENCE INFORMATIONのa特定のWATCHERが望んでいるものはそのPRESENTITYに関して見られます、WATCHERがとって来るかNOTIFICATIONでそれを得るかどうかにかかわらず。
-- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE
INFORMATION of that PRESENTITY.
-- (2.3 .4) もしあればどの他のPRINCIPALSがそのPRESENTITYのPRESENCE INFORMATIONをアップデートできますか?
The PRINCIPAL controlling an INSTANT INBOX MUST be able to control
プリンシパル、INSTANT INBOX MUSTを制御して、制御できてください。
-- (2.3.5) which other PRINCIPALS, if any, can send INSTANT
MESSAGES to that INSTANT INBOX.
-- (2.3 .5) もしあれば他のPRINCIPALSがそのINSTANT INBOXへのINSTANT MESSAGESを送ることができる。
-- (2.3.6) which other PRINCIPALS, if any, can read INSTANT
MESSAGES from that INSTANT INBOX.
-- (2.3 .6) もしあれば他のPRINCIPALSがINSTANT MESSAGESをそのINSTANT INBOXから読み込むことができる。
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. アクセスコントロールは存在から独立しているに違いありません: PRESENCE SERVICE MUST、アクセスをいつPRESENTITYがOUT OF CONTACTでさえあるかというコントロール決定にすることができてください。
2.4. Network Topology
2.4. ネットワーク形態
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.
PROXIESなどの仲介者がIPと非IPネットワークの間と、そして、匿名を提供して、それらのIPアドレスを隠すエンドユーザの願望で必要とされるかもしれないことに注意してください。
Day, et al. Informational [Page 6] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [6ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both directly and via intermediaries, such as PROXIES.
2.4.1. プロトコルは直接とPROXIESなどの仲介者を通してSUBSCRIPTIONの作成を許容しなければなりません。
2.4.2. The protocol MUST allow the sending of a NOTIFICATION both directly and via intermediaries, such as PROXIES.
2.4.2. プロトコルは直接とPROXIESなどの仲介者を通してNOTIFICATIONの発信を許さなければなりません。
2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both directly and via intermediaries, such as PROXIES.
2.4.3. プロトコルは直接とPROXIESなどの仲介者を通してINSTANT MESSAGEの発信を許さなければなりません。
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. 施設と輸送練習をproxyingするプロトコルは存在するのによるプロトコル活動を可能にして、無効にするADMINISTRATORS方法と一般的に配布しているFIREWALLSを許容しなければなりません。 プロトコルはそのようなFIREWALLSがどう事実上それをフィルターにかけることができるかを指定しなければなりません。
2.5. Message Encryption and Authentication
2.5. メッセージ暗号化と認証
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)が崩壊もしませんし、いじられてもいないという信用を確実にする手段を提供しなければなりません。
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)が敵によって記録されて、再生されていないという信用を確実にする手段を提供しなければなりません。
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)が確実に単に送付者が許すENTITIESで読み込み可能になるようにする手段を提供しなければなりません。
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. どんなクライアントもプロトコルで非不正、非再生、およびプライバシーを確実にする手段を使用できなければなりませんが、プロトコルは、すべてのクライアントがいつもこれらの手段を使用するのを必要としてはいけません。
3. Additional Requirements for PRESENCE INFORMATION
3. 存在情報のための追加要件
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の要件はINSTANT MESSAGESではなく、PRESENCE INFORMATIONだけに適切です。 INSTANT MESSAGESをサポートするシステムのPRESENCE INFORMATIONにおける追加規制はセクション7.4に現れます。
3.1. Common Presence Format
3.1. 一般的な存在形式
3.1.1. All ENTITIES MUST produce and consume at least a common base format for PRESENCE INFORMATION.
3.1.1. すべてのENTITIES MUSTがPRESENCE INFORMATIONのための少なくとも一般的なベース形式を発生して、消費します。
3.1.2. The common presence format MUST include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported.
3.1.2. 一般的な存在形式は唯一、PRESENCE INFORMATIONが報告されるPRESENTITYを特定する手段を含まなければなりません。
Day, et al. Informational [Page 7] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [7ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年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. 一般的な存在形式はPRESENTITYのプリンシパルのために問い合わせ先をカプセル化する手段を含まなければなりません(適切であるなら)、Eメールアドレス、電話番号、郵便の宛先、または同様のものなどのように。
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. ワーキンググループは存在情報図式のために拡大と登録メカニズムを定義しなければなりません、OTHER PRESENCE MARKUPのための新しいSTATUS状態と新しいフォームを含んでいて。
3.1.6. The presence format SHOULD be based on IETF standards such as vCard [RFC 2426] if possible.
3.1.6. 存在形式SHOULDはvCardなどのIETF規格に基づいたこと[RFC2426]です。できれば。
3.2. Presence Lookup and Notification
3.2. 存在ルックアップと通知
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. FETCHER MUST、PRESENTITYがOUT OF CONTACTでさえあるときにはPRESENTITYのPRESENCE INFORMATIONをとって来ることができてください。
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. SUBSCRIBER MUST、PRESENTITYのPRESENCE INFORMATIONにSUBSCRIPTIONを要求できてください、PRESENTITYがOUT OF CONTACTでさえあるときに。
3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, unless prevented by the PRESENTITY's ACCESS RULES.
3.2.3. PRESENCE SERVICEにはPRESENTITYのPRESENCE INFORMATIONのためのSUBSCRIPTIONSがあって、そのPRESENCE INFORMATIONが変化するなら、PRESENCE SERVICE MUSTは各SUBSCRIBERにNOTIFICATIONを提供します、PRESENTITYのACCESS RULESによって防がれない場合。
3.2.4. The protocol MUST provide a mechanism for detecting when a PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT.
3.2.4. プロトコルはPRESENTITYかSUBSCRIBERがいつ行ったかを検出するためのメカニズムにOUT OF CONTACTを供給しなければなりません。
3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER gracefully telling the service that it will no longer be in communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT due to unanticipated failures.
3.2.5. プロトコルはそれがもうコミュニケーションにないと優雅にサービスに言うPRESENTITYかSUBSCRIBERによってはいけません、PRESENTITYかSUBSCRIBERがOUT OF CONTACT当然に思いがけない失敗になるかもしれないので。
3.3. Presence Caching and Replication
3.3. 存在キャッシュと模写
3.3.1. The protocol MUST include mechanisms to allow PRESENCE INFORMATION to be cached.
3.3.1. プロトコルは、PRESENCE INFORMATIONがキャッシュされるのを許容するためにメカニズムを含まなければなりません。
3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE INFORMATION to be updated when the master copy changes.
3.3.2. プロトコルは、マスターコピーが変化するとき、キャッシュされたPRESENCE INFORMATIONをアップデートするのを許容するためにメカニズムを含まなければなりません。
Day, et al. Informational [Page 8] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [8ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
3.3.3 The protocol caching facilities MUST NOT circumvent established ACCESS RULES or restrict choice of authentication/encryption mechanisms.
3.3.3 施設をキャッシュするプロトコルは、確立したACCESS RULESを回避してはいけませんし、また認証/暗号化メカニズムの選択を制限してはいけません。
3.4 Performance
3.4 パフォーマンス
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 PRESENTITYがPRESENCE INFORMATIONを変えるとき、変えられた情報について急速にその情報へのどんなSUBSCRIBERにも通知しなければなりません、そのような通知がACCESS RULESによって完全に防がれる時を除いて。 各SUBSCRIBERのNOTIFICATIONがINSTANT MESSAGEがINSTANT INBOXに輸送されるだろうというのと同じくらい急速に輸送されるなら、この必要条件は満たされます。
4. Additional Requirements for INSTANT MESSAGES
4. インスタントメッセージのための追加要件
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の要件はPRESENCE INFORMATIONではなく、INSTANT MESSAGESだけに適切です、セクション4.4を除いて。 セクション4.4はINSTANT MESSAGESとPRESENCE INFORMATIONの両方をサポートするシステムだけに関連しているPRESENCE INFORMATIONで規制について説明します。
4.1. Common Message Format
4.1. 一般的なメッセージ・フォーマット
4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST implement at least a common base format for INSTANT MESSAGES.
4.1.1. すべてのENTITIES送受信INSTANT MESSAGES MUSTは、INSTANT MESSAGESのために少なくとも一般的なベースが形式であると実装します。
4.1.2. The common base format for an INSTANT MESSAGE MUST identify the sender and intended recipient.
4.1.2. INSTANT MESSAGE 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. 受信機が別のINSTANT MESSAGEと共に送付者に答えるように、一般的なメッセージ・フォーマットは返送先を含まなければなりません。
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はアドレスの標準形式を含んでいるか、またはINSTANT MESSAGES以外のメディアのために手段に連絡します、電話番号やEメールアドレスのように。
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. プロトコルはアクセシビリティに関連される中で最も良い現在の実務を反映しなければなりません。
Day, et al. Informational [Page 9] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [9ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
4.1.8. The working group MUST define the extension and registration mechanisms for the message format, including new fields and new schemes for INSTANT INBOX ADDRESSES.
4.1.8. ワーキンググループはメッセージ・フォーマットのために拡大と登録メカニズムを定義しなければなりません、INSTANT INBOX ADDRESSESの新しい分野と新しい体系を含んでいて。
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. 一般的なメッセージはSHOULDをフォーマットします。IETF標準のMIME[RFC2045]に基づいてください。
4.2. Reliability
4.2. 信頼性
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について送付者に知らすことができるようにメカニズムを含まなければなりません。 ワーキンググループは、最終的な配送状態が未知であるときに、どんなメカニズムが適用されるかを決定しなければなりません、メッセージが非IMPPシステムにリレーされる時のように。
4.3 Performance
4.3 パフォーマンス
4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid to allow for comfortable conversational exchanges of short messages.
4.3.1. INSTANT MESSAGES MUSTの輸送は十分、そうです。短いメッセージの快適な会話の交換を考慮するのにおいて、急速です。
4.4 Presence Format
4.4 存在形式
4.4.1. The common presence format MUST define a minimum standard presence schema suitable for INSTANT MESSAGE SERVICES.
4.4.1. 一般的な存在形式はINSTANT MESSAGE SERVICESに適当な最低基準存在図式を定義しなければなりません。
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. INSTANT MESSAGESをサポートしながらシステムで使用されると、一般的な存在形式はSTATUS状態のオープンとCLOSEDを表す手段を含まなければなりません。
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. また、STATUS状態のオープンとCLOSEDはメッセージングかINSTANT MESSAGE SERVICES以外のコミュニケーションモードに適用されるかもしれません。
Day, et al. Informational [Page 10] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [10ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
5. Security Considerations
5. セキュリティ問題
Security considerations are addressed in section 2.3, Access Control, and section 2.5, Message authentication and encryption.
セキュリティ問題がセクション2.3、Access Control、およびセクション2.5で扱われて、Messageは認証と暗号化です。
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.
1セットについてオール次に、実用性とimplementabilityのために評価されて、要件に翻訳された「セキュリティ期待」を取り囲むのからセキュリティ要件を得ました。 付録では、私たちは期待について説明します、そして、プロセスは以前はよくそれらを要件に変えていました。 このセクションで、私たちは単に統合セットの派生している要件をリストアップします。
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.
要件では、ADMINISTRATORsが要件で言及されたPRINCIPALsに許容されたものを超えて特権を持っているかもしれないことに注意してください。 (別の方法で注意されない場合、個々の期待は明確にPRINCIPALsについて言及します。) PRINCIPALsで作られた要件に感染しないで管理アクセスを制御して、セキュリティがADMINISTRATORsの特権であると実装するのが個々の実装まで達しています。
Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR PRINCIPALS.
別の方法で注意されない場合、A、B、Cはすべて非ADMINISTRATOR PRINCIPALSという名前です。
5.1. Requirements related to SUBSCRIPTIONS
5.1. SUBSCRIPTIONSに関連する要件
When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION:
AがビーズPRESENCE INFORMATIONにSUBSCRIPTIONを設立すると:
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. プロトコルは特定のA手段を提供しなければなりません、そして、それをPRESENTITYが加入した認証するのは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がそう選ぶなら、プロトコルSHOULD NOTはAのSUBSCRIPTIONを第三者Cにとって、明白なBにします。
5.1.3. The protocol MUST provide B with means of allowing an unauthenticated subscription by A.
5.1.3. プロトコルはAで非認証された購読を許す手段をBに提供しなければなりません。
5.1.4. The protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A.
5.1.4. プロトコルはAに明らかにする内容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のSUBSCRIPTIONを拒否するかどうかをAに知らせなければなりません。 Bが、申し込みに応じるのを選ぶかもしれないことに注意しなさい、ただし、それ(いわゆる「礼儀正しいブロッキング」)に少しの情報も提供しないでください。 .15に5.1を見てください。
5.1.6. The protocol MUST NOT let any third party C force A to subscribe to B's PRESENCE INFORMATION without A's consent.
5.1.6. プロトコルで、どんな第三者CもAにAの同意なしでビーズPRESENCE INFORMATIONに強制的に加入させてはいけません。
Day, et al. Informational [Page 11] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [11ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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はいつでもであることにおいてどんな理由のでも彼女のSUBSCRIPTIONをビーズPRESENCE INFORMATIONに取り消すことができなければなりません。 Aがそうすると、PRESENCE SERVICEは、ビーズPRESENCE INFORMATIONへの変化のAを知らせるのを止めます。
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のSUBSCRIPTIONが取り消されるなら、サービスSHOULDはキャンセルの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 SHOULDはAのSUBSCRIPTIONの状態を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のSUBSCRIPTIONに関してBに知るB手段を提供しなければなりません、ともにその後SUBSCRIPTIONを設立する時点で。
5.1.12. The protocol MUST provide B means of identifying and authenticating the SUBSCRIBER's PRINCIPAL, A.
5.1.12. プロトコルはSUBSCRIBERのプリンシパル、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が、匿名のPRINCIPALSが申し込むのを防ぐのは、可能であるに違いありません。
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に見えている間、Aの購読を否定するためにPRESENCE SERVICEを構成するのは、可能であるに違いありません。 プロトコルはこの様に扱われるサービス購読にPRESENCE SERVICEを強制してはいけません。
5.1.16. B MUST be able to cancel A's subscription at will.
5.1.16. Bは自由自在に定期講読契約を取り消すことができなければなりません。
5.1.17. The protocol MUST NOT require A to reveal A's IP address to B.
5.1.17. プロトコルは、AのIPアドレスをBに明らかにするためにAを必要としてはいけません。
5.1.18 The protocol MUST NOT require B to reveal B's IP address to A.
5.1.18 プロトコルは、ビーズIPアドレスをAに明らかにするためにBを必要としてはいけません。
5.2. Requirements related to NOTIFICATION
5.2. NOTIFICATIONに関連する要件
When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to another PRINCIPAL A:
プリンシパルBがNOTIFICATIONのために別のプリンシパルA:にPRESENCE INFORMATIONを発行するとき
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. プロトコルはNOTIFICATIONがBによって送られるプリンシパルAだけがNOTIFICATIONを読むことができるのを確実にする手段を提供しなければなりません。
Day, et al. Informational [Page 12] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [12ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
5.2.2. A should receive all NOTIFICATIONS intended for her.
5.2.2. Aは彼女のために意図するすべてのNOTIFICATIONSを受けるべきです。
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. Bが、Aが通知を受け取るのを防ぐのは、可能であるに違いありません、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に明らかにするのを必要としてはいけません。
5.2.6. The protocol MUST NOT require that B reveal B's IP address to A.
5.2.6. プロトコルは、BがビーズIPアドレスをAに明らかにするのを必要としてはいけません。
5.3. Requirements related to receiving a NOTIFICATION
5.3. 要件は受信にNOTIFICATIONに関連しました。
When a PRINCIPAL A receives a notification message from another principal B, conveying PRESENCE INFORMATION,
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で送るように存在情報が正確であることを確かめるA手段を提供しなければなりません。
5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS from entities she has subscribed to.
5.3.2. プロトコルは、NOTIFICATIONSが彼女が加入した実体からAに送られるだけであるのを確実にしなければなりません。
5.3.3. The protocol MUST provide A means of verifying that the notification was sent by B.
5.3.3. プロトコルは通知がBによって送られたことを確かめるA手段を提供しなければなりません。
5.4. Requirements related to INSTANT MESSAGES
5.4. INSTANT MESSAGESに関連する要件
When a user A sends an INSTANT MESSAGE M to another user B,
ユーザAが別のユーザBにINSTANT MESSAGE Mを送るとき
5.4.1. A MUST receive confirmation of non-delivery.
5.4.1. Aは非配送の確認を受け取らなければなりません。
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のIPアドレスを明らかにして、Aがインスタントメッセージを送るように、プロトコルはいつもAを必要としなければならないというわけではありません。
Day, et al. Informational [Page 13] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [13ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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の内容を見ることができないのを確実にするA手段を提供しなければなりません。
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が、いじらないことが起こったことを確かめることを意味するのを確実にするA手段を提供しなければなりません。
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がメッセージを彼に送るのを防ぐことができなければなりません。
6. References
6. 参照
[RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] 日、M.とローゼンバーグとJ.とH.Sagano、「存在とインスタントメッセージングのためのモデル」、RFC2778、2000年2月。
[RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998.
[RFC2426] ドーソンとF.とT.ハウズ、「vCard MIMEディレクトリプロフィール」、RFC2426、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.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)--1つを分けてください」 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
Day, et al. Informational [Page 14] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [14ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
7. Authors' Addresses
7. 作者のアドレス
Mark Day SightPath, Inc. 135 Beaver Street Waltham, MA 02452 USA
マークDay SightPath Inc.135ビーバー通りMA02452ウォルサム(米国)
EMail: mday@alum.mit.edu (Formerly Mark_Day@lotus.com)
メール: mday@alum.mit.edu (以前 Mark_Day@lotus.com )
Sonu Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
ソヌーAggarwalマイクロソフト社1マイクロソフト、道のワシントン98052レッドモンド(米国)
EMail: sonuag@microsoft.com
メール: sonuag@microsoft.com
Gordon Mohr
ゴードン・モーア
EMail: gojomo@usa.net (Formerly gojomo@activerse.com)
メール: gojomo@usa.net (以前 gojomo@activerse.com )
Jesse Vincent Into Networks, Inc. 150 Cambridgepark Drive Cambridge, MA 02140 USA
ネットワークInc.150Cambridgepark Drive MA02140ケンブリッジ(米国)へのジェシー・ヴィンセント
EMail: jesse@intonet.com (Formerly jvincent@microsoft.com)
メール: jesse@intonet.com (以前 jvincent@microsoft.com )
Day, et al. Informational [Page 15] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [15ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
8. Appendix: Security Expectations and Deriving Requirements
8. 付録: セキュリティ期待と要件を引き出すこと。
This appendix is based on the security expectations discussed on the impp mailing list and assembled by Jesse Vincent. The original form of numbering has been preserved in this appendix (so there are several different items labeled B1, for example). The derived requirements have new numbers that are consistent with the main body of the document. This appendix is included to provide a connection from discussions on the list to the requirements of Section 8, but it is not intended to introduce any new requirements beyond those presented in Sections 5 through 8.
この付録はimppメーリングリストで議論して、ジェシー・ヴィンセントによって組み立てられたセキュリティ期待に基づいています。 付番の原型はこの付録に保存されました(したがって、例えばB1とラベルされた数個の異なった項目があります)。 派生している要件には、ドキュメントの本体と一致した新しい数があります。 この付録はリストにおける議論からセクション8の要件までの接続を提供するために含まれていますが、セクション5〜8に提示されたものを超えてどんな新しい要件も導入することを意図しません。
8.1. PRESENCE INFORMATION
8.1. 存在情報
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.
PRESENCE INFORMATIONの場合では、制御プリンシパルのプライバシー利益のためは最高のです。 私たちは、「礼儀正しいブロッキング」(購読が偽情報を否定されるか、または提供していると言わない、否定する)が可能であるべきであるのに同意しました。
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
A1PRESENTITYのプリンシパル(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]
議論: 要件の候補に立ちます。 アリスがあらゆるSUBSCRIPTIONを認証する必要でないプロトコルが認証の能力をアリスに提供するべきであることに注意してください。 この警告は、性能関心によって必要に特に作られて、以下で引き出された他の要件の多くに適用されます。 [要件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]
議論: これはそのままで実施するのにおいていくらか無理です。 例えば、いくらかのtopologiesでは、だれかが、何によってもAがB.に加入したと推論するためにトラヒック分析ができません。Weは、プロトコルがどんな明白な方法による購読情報も露出しないのを単に必要とするはずです。 [要件5.1.2]
Day, et al. Informational [Page 16] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [16ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
A3. A has the capability to subscribe to B's presence without B's knowledge, if B permits anonymous subscriptions.
A3。 Aには、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。 意志は正確に、Bがビーズの存在に関してAに明らかにするのを選ぶものを受けます。
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は、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の同意なしでビーズの存在にやむを得ず加入できます。
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はいつでもであることにおいてどんな理由のでもビーズの存在の彼女の購読を中止できます。 Aがそうする場合、彼女はこれ以上ビーズ存在情報の情報を受け取らないでしょう。
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]
議論: これは本質的には立ちます。 しかしながら、実現はAが受信されるタイミングウィンドウを競争しなければならないかもしれません、彼女の解約請求を送った後に、Bが解約請求を受ける前にBによって送られた通知。 したがって、要件はAが、それを受けるのをやめるよりむしろ存在情報を送るのをやめるビーズに焦点を合わせるべきです。 [要件5.1.7]
A8. no third party, C, can cancel A's subscription to B.
A8どんな第三者(C)も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
議論: 意図は妥当ですが、多くのシナリオ(例えば、サーバ、妨げられたネットワーク、サーバクラッシュに負担をかける)がキャンセルのAに通知を提供するのが望ましくないか、または不可能であるところにあります。 したがって、サービスはするべきです。
Day, et al. Informational [Page 17] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [17ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
an attempt to inform, but this is not required. [Requirement
5.1.9]
しかし、知らせる試み、これは必要ではありません。 [要件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。 Aが匿名で申し込まれていない限り、BはAがビーズ存在情報に加入したと知らされるでしょう。
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。 ビーズ存在情報は第三者への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。 Aに彼女が妨げられたのを知らせない、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は自由自在に定期講読契約を取り消すことができます。
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
議論: 管理者に、だれが申し込まれるかを決定できるべきですが、応募者名簿について絶え間なく知らされる必要はありません。 また、いくつかの場合ユーザエージェント(例えば、プロキシ)はそうするかもしれません。
Day, et al. Informational [Page 18] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [18ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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]
申し込まれて、これらがケースに入れるユーザ、およびコネを代表して管理者はこれらのエージェントのアイデンティティを決定できるだけです、彼らのユーザでない。 [要件5.1.16]
C2. C can manage all aspects of A's presence information.
C2。 CはAの存在情報の全面に対処できます。
Discussion: This stands as a requirement. [Requirement 5.1.17]
議論: これは要件の候補に立ちます。 [要件5.1.17]
C3. C can control who can access A's presence information and exchange instant messages with A.
C3。 Cは、だれがAと共にAの存在情報と交換インスタントメッセージにアクセスできるかを制御できます。
Discussion: This stands in principle, but C should be able to
waive these capabilities if C desires. [Requirement 5.1.18]
議論: これは原則として立ちますが、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のその情報はビーズ知識と同意なしでどんな実体にも提供されません。
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通知が送られる人(A)だけが通知を読むことができます。
Discussion: Stands as a requirement. [Requirement 5.2.1]
議論: 要件の候補に立ちます。 [要件5.2.1]
B2. A reliably receives all notifications intended for her.
B2。 Aは彼女のために意図するすべての通知を確かに受け取ります。
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]
Day, et al. Informational [Page 19] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [19ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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。 購読のその情報は個人的に残っています。 人々は、通知が現れるのを見ることによってビーズ情報の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.
議論: これは、実施するのがかなり難しいかもしれなく、用法シナリオを過度に制限するかもしれません。 これは要件から省略されます。
Day, et al. Informational [Page 20] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [20ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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. INSTANT MESSAGEs
8.2. インスタントメッセージ
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.
議論: 対応する要件5.4で.1にA1で覆っていて、反射しています。
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.
議論: 要件としてのスタンド、また、ほかの場所(非セキュリティ要件で)に覆われていますが、したがって、これはセキュリティ要件から省略されます。
Day, et al. Informational [Page 21] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [21ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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
B5BCCがあったかどうかを知らないでしょう。
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.
B8Aの知識と同意なしで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
C1Mの内容を見てください。
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
C2Mをいじってください。
Discussion: Stands, with the same caveat as above.
[Requirement 5.4.7]
議論: 同じ警告が上であることでのスタンド。 [要件5.4.7]
C3. know that M was sent
C3Mが送られたのを知ってください。
Discussion: It is impossible to prevent traffic analysis, and
this is therefore omitted from the requirements.
議論: トラヒック分析を防ぐのが不可能であり、したがって、これは要件から省略されます。
Day, et al. Informational [Page 22] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [22ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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
D1Mを読むことができるでしょう。
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)
D2Mの信憑性について確かめることができるでしょう。(Temporalと送付者のアイデンティティの両方)
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
D3Mの保全について確かめることができるでしょう。
Discussion: Stands as a requirement. [Requirement 5.4.10]
議論: 要件の候補に立ちます。 [要件5.4.10]
D4. will be able to prevent A from sending him future messages
D4Aが将来のメッセージを彼に送るのを防ぐことができるでしょう。
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はすべてのCCについてボブに知らせました。
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:
ユーザアリスが別のユーザボブに匿名のインスタントメッセージを送るとき:
Day, et al. Informational [Page 23] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [23ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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.2IMが匿名であることを知って、どんな特定の命名されたユーザからもそうしないでしょう。
AB4.3 may not allow anonymous IMs
AB4.3は匿名のIMsを許容しないかもしれません。
B5. will not know whether there were BCCs
B5BCCがあったかどうかを知らないでしょう。
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
AC2IMが拒否されたなら、誤りを受けるでしょう。
Bob expects that he:
ボブがそれを予想する、彼:
D1. will be able to read M
D1Mを読むことができるでしょう。
D2. will be able to verify M's authenticity (both temporal and the sender's identity)
D2Mの信憑性について確かめることができるでしょう。そして、(ともに時、送付者のアイデンティティ)
D3. will be able to verify M's integrity
D3Mの保全について確かめることができるでしょう。
AD4. will know if an IM was sent anonymously
AD4IMが匿名で送られたかどうかを知るでしょう。
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.
AD6Mが捨てられるなら誤りがアリスに送られるかどうかを制御できるでしょう。
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はいつでも、Aインスタントメッセージを送ることができるでしょう。
C2. that A will receive any message he sends while A is online.
C2Aがオンラインである間、そのAは彼が送るどんなメッセージも受け取るでしょう。
Day, et al. Informational [Page 24] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [24ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
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のための議論: これが、特に、プロトコルレベルで扱われる必要があるのは、明確ではありません。 管理者は他の手段で上の目的を達成するかもしれません。 例えば、管理者は正常なメカニズムを通してメッセージをユーザに送るかもしれません。したがって、これは要件から省略されます。
Day, et al. Informational [Page 25] RFC 2779 Instant Messaging/Presence Protocol February 2000
日、他 [25ページ]情報のRFC2779インスタントメッセージング/存在プロトコル2000年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Day, et al. Informational [Page 26]
日、他 情報[26ページ]
一覧
スポンサーリンク
