Network Working Group M. Day
Request for Comments: 2779 Lotus
Category: Informational S. Aggarwal
Microsoft
G. Mohr
Activerse
J. Vincent
Into Networks
February 2000
Network Working Group M. Day
Request for Comments: 2779 Lotus
Category: Informational S. Aggarwal
Microsoft
G. Mohr
Activerse
J. Vincent
Into Networks
February 2000
Instant Messaging / Presence Protocol Requirements
即时消息/状态协议要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.
在线状态和即时消息最近已成为互联网上一种新的通信媒介。状态是一种查找、检索和订阅其他用户状态信息（如“在线”或“离线”）更改的方法。即时消息是一种发送小而简单的消息的方式，可立即发送给在线用户。
Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.
状态和即时消息应用程序目前使用由不同供应商开发的独立、非标准和不可互操作的协议。即时消息和状态协议（IMPP）工作组的目标是定义一个标准协议，以便独立开发的即时消息和/或状态应用程序可以在Internet上进行互操作。本文件规定了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
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.
注意，MUST和SHOULD的用法与RFC 2119的用法不同。
Additionally, the following terms are used in this document and defined here:
此外，本文件中使用了以下术语，并在此处进行了定义：
ADMINISTRATOR: A PRINCIPAL with authority over local computer and network resources, who manages local DOMAINS or FIREWALLS. For security and other purposes, an ADMINISTRATOR often needs or wants to impose restrictions on network usage based on traffic type, content, volume, or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over some or all of that PRINCIPAL's computer and network resources.
管理员：对本地计算机和网络资源具有权限的负责人，负责管理本地域或防火墙。出于安全和其他目的，管理员通常需要或希望根据流量类型、内容、容量或端点对网络使用施加限制。委托人的管理员有权管理该委托人的部分或全部计算机和网络资源。
DOMAIN: A portion of a NAMESPACE.
域：命名空间的一部分。
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
预计状态和即时消息服务对于通过移动IP无线接入设备的用户将特别有价值。事实上，通过无线方式连接到互联网的设备数量预计将在未来几年大幅增长。假设因特网的无线部分将有单独的协议是不合理的。此外，我们注意到无线基础设施正在迅速成熟；该工作组开展的工作应考虑到技术成熟度的预期状态，即
Presence and Instant Messaging protocols are expected to be deployed.
预计将部署状态和即时消息协议。
To this end, the protocols designed by this Working Group must be suitable for operation in a context typically associated with mobile wireless access devices, viz. high latency, low bandwidth and possibly intermittent connectivity (which lead to a desire to minimize round-trip delays), modest computing power, battery constraints, small displays, etc. In particular, the protocols must be designed to be reasonably efficient for small payloads.
为此，该工作组设计的协议必须适用于通常与移动无线接入设备相关联的上下文中的操作，即。高延迟、低带宽和可能的间歇性连接（这导致希望最小化往返延迟）、适度的计算能力、电池限制、小型显示器等。特别是，协议必须设计为对小型有效负载具有合理的效率。
2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available independent of whether an INSTANT MESSAGE SERVICE is available, and vice-versa.
2.1.1. 协议必须允许存在服务独立于即时消息服务是否可用，反之亦然。
2.1.2. The protocols must not assume that an INSTANT INBOX is necessarily reached by the same IDENTIFIER as that of a PRESENTITY. Specifically, the protocols must assume that some INSTANT INBOXes may have no associated PRESENTITIES, and vice versa.
2.1.2. 协议不得假设即时收件箱必须由与存在实体相同的标识符访问。具体地说，协议必须假设某些即时收件箱可能没有关联的存在实体，反之亦然。
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. 如果可能，存在格式应基于IETF标准，如vCard[RFC 2426]。
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. 协议必须为B提供允许A进行未经验证的订阅的方法。
5.1.4. The protocol MUST provide A means of verifying the accurate receipt of the content B chooses to disclose to A.
5.1.4. 协议必须提供一种方法来验证B选择披露给A的内容的准确接收。
5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may choose to accept A's SUBSCRIPTION, but fail to deliver any information to it (so-called "polite blocking"). See 5.1.15.
5.1.5. 如果B拒绝A的认购，B必须通知A。请注意，B可以选择接受A的订阅，但无法向其提供任何信息（所谓的“礼貌拦截”）。见5.1.15。
5.1.6. The protocol MUST NOT let any third party C force A to subscribe to B's PRESENCE INFORMATION without A's consent.
5.1.6. 协议不得允许任何第三方C在未经A同意的情况下强迫A订阅B的状态信息。
5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE INFORMATION at any time and for any reason. When A does so, the PRESENCE SERVICE stops informing A of changes to B's PRESENCE INFORMATION.
5.1.7. A必须能够随时以任何理由取消对B状态信息的订阅。当A这样做时，存在服务停止通知A对B的存在信息的更改。
5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's SUBSCRIPTION to B.
5.1.8. 协议不得允许未经授权的丙方取消A对B的订阅。
5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD inform A of the cancellation.
5.1.9. 如果A对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. 协议必须为B提供在建立订阅时和之后了解A对B的订阅的方法。
5.1.12. The protocol MUST provide B means of identifying and authenticating the SUBSCRIBER's PRINCIPAL, A.
5.1.12. 协议必须提供识别和认证用户主体的方法。
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的订阅，同时向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向B透露A的IP地址。
5.1.18 The protocol MUST NOT require B to reveal B's IP address to A.
5.1.18 协议不得要求B向A透露B的IP地址。
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. 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向B透露A的IP地址。
5.2.6. The protocol MUST NOT require that B reveal B's IP address to A.
5.2.6. 协议不能要求B向A透露B的IP地址。
When a PRINCIPAL A receives a notification message from another principal B, conveying PRESENCE INFORMATION,
当主体a接收到来自另一主体B的通知消息时，传送存在信息，
5.3.1. The protocol MUST provide A means of verifying that the presence information is accurate, as sent by B.
5.3.1. 协议必须提供一种方法来验证B发送的状态信息是否准确。
5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS from entities she has subscribed to.
5.3.2. 协议必须确保只从她订阅的实体发送通知。
5.3.3. The protocol MUST provide A means of verifying that the notification was sent by B.
5.3.3. 协议必须提供一种验证通知是否由B发送的方法。
When a user A sends an INSTANT MESSAGE M to another user B,
当用户a向另一用户B发送即时消息M时，
5.4.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是否发送消息的方法。
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. 协议必须允许用户使用现有的数字签名标准对消息进行签名。
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目录配置文件”，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，“多用途Internet邮件扩展（MIME）-第一部分：Internet邮件正文格式”，RFC 20451996年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
美国马萨诸塞州沃尔瑟姆市海狸街135号Mark Day SightPath，Inc.02452
EMail: mday@alum.mit.edu
(Formerly Mark_Day@lotus.com)
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美国
EMail: sonuag@microsoft.com
EMail: sonuag@microsoft.com
Gordon Mohr
戈登·莫尔
EMail: gojomo@usa.net
(Formerly gojomo@activerse.com)
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号，邮编：02140
EMail: jesse@intonet.com
(Formerly jvincent@microsoft.com)
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:
当用户Alice向另一个人订阅Bob的状态信息时，Alice期望：
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]
讨论：作为一项要求。请注意，协议应提供Alice身份验证功能，而无需Alice对每个订阅进行身份验证。除其他外，出于性能方面的考虑，此警告是必要的，并适用于以下衍生的许多其他需求。[要求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。如果B允许匿名订阅，A可以在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.
讨论：上述“匿名订阅”可能有两种含义—（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的认购，B将通知A
Discussion: Stands as a requirement. [Requirement 5.1.5]
讨论：作为一项要求。[要求5.1.5]
A6. No third party, C can force A to subscribe to B's presence without A's consent.
A6。未经A同意，C第三方不得强迫A订阅B的出席。
Discussion: Stands as a requirement. [Requirement 5.1.6]
讨论：作为一项要求。[要求5.1.6]
A7. A can cancel her subscription to B's presence at any time and for any reason. When A does so, she will receive no further information about B's presence information.
A7。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]
讨论：这基本上是正确的。然而，实现可能必须处理定时窗口，其中a在发送其取消请求之后，在B接收到取消请求之前接收由B发送的通知。因此，需求应该关注B停止发送状态信息，而不是A停止接收状态信息。[要求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。如果A因任何原因取消了对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]
尝试通知，但这不是必需的。[要求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订阅了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的订阅，而不让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:
Charlie，bob的网络管理员希望：
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]
已代表用户订阅，在这种情况下，管理员只能确定这些代理的身份，而不能确定其用户。[要求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:
状态信息的发布者Bob希望：
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。只有被发送通知的人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]
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可以同时向两个相关方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:
当Alice收到通知时，收件人Alice希望：
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]
讨论：原则上讲，尽管“真实”不是一项要求，但Alice可以选择验证。[要求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对B信息的订阅是否存在。
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]
讨论：原则上，尽管验证应为[要求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:
当用户Alice向另一用户Bob发送即时消息M时：
Alice expects that she:
Alice希望她：
A1. will receive notification of non-delivery
A1。将收到未交货通知
Discussion: Stands as a requirement. [Requirement 5.4.1]
讨论：作为一项要求。[要求5.4.1]
Alice expects that Bob:
Alice希望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。将能够验证Alice是否发送了消息
Discussion: Stands as a requirement. [Requirement 5.4.3]
讨论：作为一项要求。[要求5.4.3]
B5. will not know whether there were BCCs
B5。不知道是否有密件抄送
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。会知道他是否是密件抄送收件人
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的知情同意，将无法确定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:
Alice预计没有其他用户Charlie能够：
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。篡改
Discussion: Stands, with the same caveat as above. [Requirement 5.4.7]
讨论：看台，注意事项同上。[要求5.4.7]
C3. know that M was sent
C3。我知道我是被派来的
Discussion: It is impossible to prevent traffic analysis, and this is therefore omitted from the requirements.
讨论：不可能阻止流量分析，因此要求中省略了这一点。
When a user Bob receives an instant message M from another user Alice:
当用户Bob收到来自另一用户Alice的即时消息M时：
Bob expects that Bob:
Bob希望Bob：
D1. will be able to read M
D1。将能够阅读M
Discussion: Stands as a requirement. [Requirement 5.4.8]
讨论：作为一项要求。[要求5.4.8]
D2. will be able to verify M's authenticity (both Temporal and the sender's identity)
D2。将能够验证M的真实性（时间和发送者的身份）
Discussion: As noted earlier, it is not reasonable to directly require temporal checks. The protocol should, however, allow signing messages using existing standards for signing. [Requirement 5.4.9]
讨论：如前所述，直接要求临时检查是不合理的。但是，协议应允许使用现有的签名标准对消息进行签名。[要求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:
Bob希望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向另一用户Bob发送匿名即时消息时：
Alice expects that Bob:
Alice希望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。不知道是否有密件抄送
B6. will be able to reply to the message
B6。将能够回复该消息
Alice expects that she:
Alice希望她：
C1. will receive notification of non-delivery
C1。将收到未交货通知
AC2. will receive an error if the IM was refused
AC2。如果IM被拒绝，将收到错误
Bob expects that he:
Bob希望他：
D1. will be able to read M
D1。将能够阅读M
D2. will be able to verify M's authenticity (both temporal and the sender's identity)
D2。将能够验证M的真实性（时间和发送者的身份）
D3. will be able to verify M's integrity
D3。将能够验证M的完整性
AD4. will know if an IM was sent anonymously
AD4。将知道IM是否以匿名方式发送
AD5. will be able to automatically discard anonymous IM if desired
AD5。如果需要，将能够自动丢弃匿名IM
AD6. will be able to control whether an error is sent to Alice if M is discarded.
公元6年。如果M被丢弃，将能够控制是否向Alice发送错误。
8.2.3. Administrator Expectations
8.2.3. 管理员期望
Charlie, Alice's network administrator expects:
Alice的网络管理员Charlie希望：
C1. that C will be able to send A instant messages at any time.
C1。该C将能够在任何时候发送即时消息。
C2. that A will receive any message he sends while A is online.
C2。当A在线时，A将收到他发送的任何消息。
C3. that A will not be able to refuse delivery of any instant messages sent by C.
C3。A将无法拒绝C发送的任何即时消息。
Discussion for C1-C3: It is not clear this needs to be specially handled at the protocol level; Administrators may accomplish the above objectives through other means. For example, an administrator may send a message to a user through the normal mechanisms. This is therefore omitted from the requirements.
C1-C3讨论：不清楚这是否需要在协议级别进行专门处理；管理员可以通过其他方式实现上述目标。例如，管理员可以通过正常机制向用户发送消息。因此，要求中省略了这一点。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。