Network Working Group B. Campbell, Ed.
Request for Comments: 3428 J. Rosenberg
Category: Standards Track dynamicsoft
H. Schulzrinne
Columbia University
C. Huitema
D. Gurle
Microsoft Corporation
December 2002
Network Working Group B. Campbell, Ed.
Request for Comments: 3428 J. Rosenberg
Category: Standards Track dynamicsoft
H. Schulzrinne
Columbia University
C. Huitema
D. Gurle
Microsoft Corporation
December 2002
Session Initiation Protocol (SIP) Extension for Instant Messaging
用于即时消息传递的会话启动协议（SIP）扩展
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation.
即时消息（IM）是指用户之间近乎实时的消息传输。这些消息通常很短，但不要求很短。IMs通常以对话模式使用，也就是说，来回传递消息的速度足以让参与者维持交互式对话。
This document proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request.
本文档提出了消息方法，它是会话启动协议（SIP）的扩展，允许即时消息的传输。由于消息请求是SIP的扩展，它继承了该协议的所有请求路由和安全特性。消息请求以MIME正文部分的形式承载内容。消息请求本身并不启动SIP对话；在正常使用情况下，每条即时消息都是独立的，很像寻呼机消息。消息请求可以在由某个其他SIP请求发起的对话的上下文中发送。
Terminology
术语
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [6] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照BCP 14、RFC 2119[6]中的描述进行解释，并指出合规SIP实施的要求级别。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of Applicability . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. UAC Processing . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use of Instant Message URIs . . . . . . . . . . . . . . . . 6
6. Proxy Processing . . . . . . . . . . . . . . . . . . . . . . 6
7. UAS Processing . . . . . . . . . . . . . . . . . . . . . . . 7
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
9. Method Definition . . . . . . . . . . . . . . . . . . . . . 9
10. Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 13
11.1 Outbound authentication . . . . . . . . . . . . . . . . . . 13
11.2 SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.3 End-to-End Protection . . . . . . . . . . . . . . . . . . . 14
11.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 14
11.5 Using message/cpim bodies . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
15. Normative References . . . . . . . . . . . . . . . . . . . . 16
16. Informational References . . . . . . . . . . . . . . . . . . 16
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
18. Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of Applicability . . . . . . . . . . . . . . . . . . . 3
3. Overview of Operation . . . . . . . . . . . . . . . . . . . 4
4. UAC Processing . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use of Instant Message URIs . . . . . . . . . . . . . . . . 6
6. Proxy Processing . . . . . . . . . . . . . . . . . . . . . . 6
7. UAS Processing . . . . . . . . . . . . . . . . . . . . . . . 7
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 8
9. Method Definition . . . . . . . . . . . . . . . . . . . . . 9
10. Example Messages . . . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 13
11.1 Outbound authentication . . . . . . . . . . . . . . . . . . 13
11.2 SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.3 End-to-End Protection . . . . . . . . . . . . . . . . . . . 14
11.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . . 14
11.5 Using message/cpim bodies . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
15. Normative References . . . . . . . . . . . . . . . . . . . . 16
16. Informational References . . . . . . . . . . . . . . . . . . 16
17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
18. Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Instant Messaging (IM) is defined as the exchange of content between a set of participants in near real time. Generally, the content is short text messages, although that need not be the case. Generally, the messages that are exchanged are not stored, but this also need not be the case. IM differs from email in common usage in that instant messages are usually grouped together into brief live conversations, consisting of numerous small messages sent back and forth.
即时消息（IM）被定义为一组参与者之间近乎实时的内容交换。一般来说，内容是短文本消息，尽管情况并非如此。通常，不存储交换的消息，但也不需要这样。IM与电子邮件的不同之处在于，即时消息通常被组合成简短的实时对话，由大量来回发送的小消息组成。
Instant messaging as a service has been in existence within intranets and IP networks for quite some time. Early implementations include zephyr [11], the UNIX talk application, and IRC. More recently, IM
即时消息作为一种服务在内部网和IP网络中已经存在了相当长的一段时间。早期的实现包括zephyr[11]、UNIX talk应用程序和IRC。最近，我
has been used as a service coupled with presence and buddy lists; that is, when a friend comes online, a user can be made aware of this and have the option of sending the friend an instant message. The protocols for accomplishing this are all proprietary, which has seriously hampered interoperability.
已被用作与状态和好友列表相结合的服务；也就是说，当朋友在线时，用户可以知道这一点，并可以选择向朋友发送即时消息。实现这一点的协议都是专有的，这严重阻碍了互操作性。
The integration of instant messaging, presence, and session-oriented communications is very powerful. The Session Initiation Protocol (SIP) [1] provides mechanisms that are useful for presence applications, and for session-oriented communication applications, but not for instant messages.
即时消息、状态和面向会话的通信的集成功能非常强大。会话发起协议（SIP）[1]提供了对状态应用和面向会话的通信应用有用的机制，但不适用于即时消息。
This document proposes an extension method for SIP called the MESSAGE method. MESSAGE requests normally carry the instant message content in the request body.
本文档提出了一种SIP扩展方法，称为消息方法。消息请求通常在请求正文中包含即时消息内容。
RFC 2778 [3] and RFC 2779 [2] give a model and requirements for presence and instant messaging protocols. Implementations of the MESSAGE method SHALL support all the instant message requirements in RFC 2779 relevant to its scope of applicability.
RFC 2778[3]和RFC 2779[2]给出了状态和即时消息协议的模型和要求。消息方法的实现应支持RFC 2779中与其适用范围相关的所有即时消息要求。
This document describes the use of the MESSAGE method for sending instant messages using a metaphor similar to that of a two-way pager or SMS enabled handset. That is, there are no explicit association between messages. Each IM stands alone--any sense of a "conversation" only exists in the client user interface, or perhaps in the user's own imagination. We contrast this with a "session" model, where there is an explicit conversation with a clear beginning and end. In the SIP environment, an IM session would be a media session initiated with an INVITE transaction and terminated with a BYE transaction.
本文档描述了使用类似于双向寻呼机或支持SMS的手机的隐喻来发送即时消息的消息方法的使用。也就是说，消息之间没有明确的关联。每个IM都是独立的——任何“对话”的感觉都只存在于客户端用户界面中，或者可能存在于用户自己的想象中。我们将其与“会话”模型进行对比，在“会话”模型中，有明确的开始和结束的明确对话。在SIP环境中，IM会话是通过INVITE事务启动并通过BYE事务终止的媒体会话。
There is value in each model. Most modern IM clients offer both user experiences. The user can choose to send an IM to a contact, or he can choose to invite one or more contacts to join a conversation. The pager model makes sense when the user wishes to send a small number of short IMs to a single (or small number of) recipients. The session model makes sense for extended conversations, joining chat groups, if there is a need to associate a conversation with some other SIP initiated session, etc.
每个模型都有价值。大多数现代IM客户端都提供这两种用户体验。用户可以选择向联系人发送即时消息，也可以选择邀请一个或多个联系人加入对话。当用户希望向单个（或少量）接收者发送少量短消息时，寻呼机模型是有意义的。会话模型对于扩展会话、加入聊天组、需要将会话与其他SIP发起的会话相关联等都有意义。
This document addresses the pager model only. We recognize the value of the session model as well, but we do not define it here. Such a solution will require additional work beyond that of this document. The SIMPLE work group currently plans to address IM sessions in a separate document.
本文档仅针对寻呼机型号。我们也认识到会话模型的价值，但这里不定义它。这种解决方案将需要本文件以外的额外工作。简单工作组目前计划在一份单独的文件中处理IM会话。
There may be a temptation to simulate a session of IMs by initiating a dialog, then sending MESSAGE requests in the context of that dialog. This is not an adequate solution for IM sessions, in that this approach forces the MESSAGE requests to follow the same network path as any other SIP requests, even though the MESSAGE requests arguably carry media rather than signaling. IM applications are typically high volume, and we expect the IM volume in sessions to be even higher. This will likely cause congestion problems if sent over a transport without congestion control, and there is no clear mechanism in SIP to prevent some hop from forwarding a MESSAGE request over UDP.
通过启动一个对话框，然后在该对话框的上下文中发送消息请求，可能会有一种诱惑来模拟IMs会话。这不是IM会话的适当解决方案，因为这种方法强制消息请求遵循与任何其他SIP请求相同的网络路径，即使消息请求可能携带媒体而不是信令。IM应用程序通常是高容量的，我们预计会话中的IM容量会更高。如果在没有拥塞控制的情况下通过传输发送，这可能会导致拥塞问题，并且SIP中没有明确的机制来阻止某些跃点通过UDP转发消息请求。
Additionally, MESSAGE requests sent over an existing dialog must, by the nature of SIP, go to the same destination as any other request sent in that dialog. This prevents any separation between the IM endpoint and the signaling endpoint. This is not an acceptable limitation for the session-model of instant messaging.
此外，根据SIP的性质，通过现有对话框发送的消息请求必须与在该对话框中发送的任何其他请求到达相同的目的地。这防止了IM端点和信令端点之间的任何分离。对于即时消息的会话模型，这不是一个可接受的限制。
The authors recognize that there may be valid reasons to send MESSAGE requests in the context of a dialog. For example, one participant in a voice session may wish to send an IM to another participant, and associate that IM with the session. But implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE requests with one another.
作者认识到，在对话框的上下文中发送消息请求可能有正当的理由。例如，语音会话中的一个参与者可能希望向另一个参与者发送IM，并将该IM与会话关联。但是，实现不应该为了将消息请求彼此关联的主要目的而创建对话框。
Note that this statement does not prohibit using SIP to initiate a media session made up of IMs, just like any other session. Indeed, we expect the solution for IM sessions to use that metaphor. The reader should avoid confusing the concepts of a SIP dialog and a media session.
请注意，与任何其他会话一样，此语句并不禁止使用SIP启动由IMs组成的媒体会话。事实上，我们希望IM会话的解决方案使用这种比喻。读者应避免混淆SIP对话和媒体会话的概念。
When one user wishes to send an instant message to another, the sender formulates and issues a SIP request using the new MESSAGE method defined by this document. The Request-URI of this request will normally be the "address of record" for the recipient of the instant message, but it may be a device address in situations where the client has current information about the recipient's location. For example, the client could be coupled with a presence system that supplies an up to date device contact for a given address of record. The body of the request will contain the message to be delivered. This body can be of any MIME type, including message/cpim [7]. Since the message/cpim format is expected to be supported by other instant message protocols, endpoints using different IM protocols, but otherwise supporting message/cpim body types, should be able to
当一个用户希望向另一个用户发送即时消息时，发送方使用本文档定义的新消息方法制定并发出SIP请求。此请求的请求URI通常是即时消息接收者的“记录地址”，但在客户端具有关于接收者位置的当前信息的情况下，它可能是设备地址。例如，客户机可以与提供给定记录地址的最新设备联系人的存在系统耦合。请求主体将包含要传递的消息。此正文可以是任何MIME类型，包括message/cpim[7]。由于message/cpim格式预期会受到其他即时消息协议的支持，因此使用不同IM协议但支持message/cpim主体类型的端点应该能够
exchange messages without modification of the content by a gateway or other intermediary. This helps to enable end-to-end security between endpoints that use different IM protocols.
在网关或其他中介不修改内容的情况下交换消息。这有助于在使用不同IM协议的端点之间实现端到端安全性。
The request may traverse a set of SIP proxies, using a variety of transports, before reaching its destination. The destination for each hop is located using the address resolution rules detailed in the Common Profile for Instant Messaging (CPIM) [8] and SIP specifications. During traversal, each proxy may rewrite the request URI based on available routing information.
在到达目的地之前，请求可以使用各种传输方式遍历一组SIP代理。每个跃点的目的地使用即时消息传递（CPIM）[8]的通用配置文件和SIP规范中详述的地址解析规则定位。在遍历期间，每个代理可以基于可用的路由信息重写请求URI。
Provisional and final responses to the request will be returned to the sender as with any other SIP request. Normally, a 200 OK response will be generated by the user agent of the request's final recipient. Note that this indicates that the user agent accepted the message, not that the user has seen it.
与任何其他SIP请求一样，请求的临时和最终响应将返回给发送方。通常，请求的最终接收者的用户代理将生成200 OK响应。请注意，这表示用户代理接受了消息，而不是用户看到了消息。
MESSAGE requests do not establish dialogs.
消息请求不建立对话框。
Unless stated otherwise in this document, MESSAGE requests and associated responses are constructed according to the rules in section 8.1 of the SIP specification [1].
除非本文件另有规定，否则根据SIP规范[1]第8.1节中的规则构造消息请求和相关响应。
All UACs which support the MESSAGE method MUST be prepared to send MESSAGE requests with a body of type text/plain. They may send bodies of type message/cpim [7].
所有支持消息方法的UAC必须准备好发送文本/纯文本类型的消息请求。它们可以发送message/cpim[7]类型的正文。
MESSAGE requests do not initiate dialogs. User Agents MUST NOT insert Contact header fields into MESSAGE requests.
消息请求不会启动对话框。用户代理不得在邮件请求中插入联系人标头字段。
A UAC MAY associate a MESSAGE request with an existing dialog. If a MESSAGE request is sent within a dialog, it is "associated" with any media session or sessions associated with that dialog.
UAC可以将消息请求与现有对话框相关联。如果在对话框中发送消息请求，则该消息请求与任何媒体会话或与该对话框关联的会话“关联”。
If the UAC receives a 200 OK response to a MESSAGE request, it may assume the message has been delivered to the final destination. It MUST NOT assume that the recipient has actually read the instant message. If the UAC receives a 202 Accepted response, the message has been delivered to a gateway, store and forward server, or some other service that may eventually deliver the message. In this case, the UAC MUST NOT assume the message has been delivered to the final destination. If confirmation of delivery is required for a message that has been responded to with a 202 Accepted, that confirmation must be delivered via some other mechanism, which is beyond the scope of this specification.
如果UAC接收到对消息请求的200 OK响应，它可能会认为消息已发送到最终目的地。它不能假设收件人实际阅读了即时消息。如果UAC收到202接受的响应，则消息已被传递到网关、存储转发服务器或可能最终传递消息的某个其他服务。在这种情况下，UAC不得假设消息已送达最终目的地。如果对已被接受的202响应的消息需要传递确认，则该确认必须通过一些其他机制传递，这超出了本规范的范围。
Note that a downstream proxy could fork a MESSAGE request. If this occurs, the forking proxy will forward one final response upstream, even though it may receive multiple final responses. The UAC will have no way to detect whether or not a fork occurs. Therefore the UAC MUST NOT assume that a given final response represents the only UAS that receives the request. For example, multiple branches of a fork could have resulted in 2xx responses. Even though the UAC only sees one of those responses, the request has in fact been received by the second device as well.
请注意，下游代理可以派生消息请求。如果发生这种情况，分叉代理将向上游转发一个最终响应，即使它可能会收到多个最终响应。UAC将无法检测是否出现分叉。因此，UAC不得假设给定的最终响应代表接收请求的唯一UAS。例如，一个fork的多个分支可能会导致2xx响应。即使UAC只看到这些响应中的一个，请求实际上也已被第二个设备接收到。
The UAC MAY add an Expires header field to limit the validity of the message content. If the UAC adds an Expires header field with a non-zero value, it SHOULD also add a Date header field containing the time the message is sent.
UAC可以添加Expires标头字段来限制消息内容的有效性。如果UAC添加了一个带有非零值的Expires标头字段，它还应该添加一个包含消息发送时间的日期标头字段。
An instant inbox may be most generally referenced by an Instant Message URI [8] in the form of "im:user@domain". IM URIs are abstract, and will eventually be translated to concrete, protocol-dependent URI.
即时收件箱通常由即时消息URI[8]以“im:user@domain". IM URI是抽象的，最终将被转换为具体的、依赖于协议的URI。
If a UA is presented with an IM URI as the address for an instant message, it SHOULD resolve it to a SIP URI, and place the resulting URI in the Request-URI of the MESSAGE request before sending. If the UA is unable to resolve the IM URI, it MAY place the IM URI in the Request-URI, thus delegating the resolution to a downstream device such as proxy or gateway. Performing this translation as early as possible allows SIP proxies, which may be unaware of the im: namespace, to route the requests normally.
如果向UA提供IM URI作为即时消息的地址，则UA应将其解析为SIP URI，并在发送前将生成的URI放入消息请求的请求URI中。如果UA无法解析IM URI，它可以将IM URI放置在请求URI中，从而将解析委托给下游设备，例如代理或网关。尽早执行此转换允许SIP代理（可能不知道im:命名空间）正常路由请求。
MESSAGE requests also contain logical identifiers of the sender and intended recipient, in the form of the From and To header fields. These identifiers SHOULD contain SIP (or SIPS) URIs, but MAY include IM URIs if the SIP URIs are not known at the time of request construction.
消息请求还包含发件人和预期收件人的逻辑标识符，格式为“发件人”和“收件人”头字段。这些标识符应包含SIP（或SIPS）URI，但如果在请求构造时SIP URI未知，则可能包括IM URI。
Record-Route and Route header fields MUST NOT contain IM URIs. These header fields contain concrete SIP or SIPS URIs according to the rules of SIP [1].
记录路由和路由标头字段不得包含IM URI。根据SIP[1]的规则，这些头字段包含具体的SIP或SIPS URI。
Proxies route MESSAGE requests according to the rules of SIP [1]. Note that the MESSAGE request MAY fork; this allows for delivery of the message to several possible terminals where the user might be. A proxy forking a MESSAGE request follows the normal SIP rules for forking a non-INVITE request. In particular, even if the fork
代理根据SIP[1]的规则路由消息请求。注意，消息请求可能会分叉；这允许将消息传递到用户可能在的几个可能的终端。分叉消息请求的代理遵循分叉非INVITE请求的正常SIP规则。特别是，即使叉子
results in multiple successful deliveries, the forking proxy will only forward one final response upstream.
结果在多次成功交付时，分叉代理将只向上游转发一个最终响应。
A UAS that receives a MESSAGE request processes it following the rules of SIP [1].
接收消息请求的UAS按照SIP[1]的规则处理该消息。
A UAS receiving a MESSAGE request SHOULD respond with a final response immediately. Note, however, that the UAS is not obliged to display the message to the user either before or after responding with a 200 OK. That is, a 200 OK response does not necessarily mean the user has read the message.
收到消息请求的UAS应立即做出最终响应。但是，请注意，UAS没有义务在200 OK响应之前或之后向用户显示消息。也就是说，200 OK响应不一定意味着用户已经阅读了消息。
A 2xx response to a MESSAGE request MUST NOT contain a body. A UAS MUST NOT insert a Contact header field into a 2xx response.
对消息请求的2xx响应不得包含正文。UAS不得在2xx响应中插入联系人标题字段。
A UAS which is, in fact, a message relay, storing the message and forwarding it later on, or forwarding it into a non-SIP domain, SHOULD return a 202 (Accepted) [5] response indicating that the message was accepted, but end to end delivery has not been guaranteed.
事实上，UAS是一个消息中继，存储消息并在稍后转发，或将其转发到非SIP域，它应该返回一个202（已接受）[5]响应，指示消息已被接受，但端到端传递尚未得到保证。
A 4xx or 5xx response indicates that the message was not delivered successfully. A 6xx response means it was delivered successfully, but refused.
4xx或5xx响应表示消息未成功传递。6xx响应表示已成功交付，但被拒绝。
A UAS that supports the MESSAGE method MUST be prepared to receive and render bodies of type "text/plain", and may support reception and rendering of bodies of type "message/cpim" [7].
支持消息方法的UAS必须准备好接收和呈现“text/plain”类型的主体，并且可以支持接收和呈现“MESSAGE/cpim”类型的主体[7]。
A MESSAGE request is said to be expired if its expiration time has passed. The expiration time is determined by examining the Expires header field, if present. MESSAGE requests without an Expires header field do not expire. If the MESSAGE request containing an Expires header field also contains a Date header field, the UAS SHOULD interpret the Expires header field value as delta time from the Date header field value. If the request does not contain a Date header field, the UAS SHOULD interpret the Expires header value as delta time from the time the UAS received the request.
如果消息请求的过期时间已过，则称其已过期。过期时间通过检查Expires标头字段（如果存在）来确定。没有Expires标头字段的消息请求不会过期。如果包含Expires标头字段的消息请求也包含日期标头字段，则UAS应将Expires标头字段值解释为日期标头字段值的增量时间。如果请求不包含日期标头字段，UAS应将Expires标头值解释为自UAS收到请求之时起的增量时间。
If the MESSAGE expires before the UAS is able to present the message to the user, the UAS SHOULD handle the message based on local policy. This policy could mean: the message is deleted undisplayed,
如果消息在UAS能够向用户呈现消息之前过期，UAS应根据本地策略处理消息。此策略可能意味着：消息被删除而未显示，
the message is still displayed to the user, or some other policy may be invoked. If the message is displayed, the UAS SHOULD clearly indicate to the user that the message has expired.
该消息仍会显示给用户，或者可能会调用某些其他策略。如果显示该消息，UAS应清楚地向用户指示该消息已过期。
If the UAS is acting as a message relay, and is unable to deliver the message before expiration, it chooses an action based on local policy. This action could involve deleting the message undelivered, delivering it as is, logging the expired message, or any other local policy.
如果UAS充当消息中继，并且无法在到期前传递消息，则它将根据本地策略选择操作。此操作可能涉及删除未送达的邮件、按原样传递、记录过期邮件或任何其他本地策略。
Existing IM services have a history of very high volume usage. Additionally, MESSAGE requests differ from other sorts of SIP requests in that they carry media, in the form of IMs, as payload. Conventional SIP payloads carry signaling information about media, but not media itself. There is potential that when a SIP infrastructure is shared between call signaling and instant messaging, the IM traffic will interfere with call signaling traffic. Congestion control in general is an issue that should be addressed at the SIP specification level rather than for an individual method. But since the traffic patterns are likely to be different for MESSAGE than for most other methods, it makes sense to give MESSAGE special consideration.
现有IM服务的使用量非常高。此外，消息请求不同于其他类型的SIP请求，因为它们以IMs的形式携带媒体作为有效负载。传统的SIP有效负载承载有关媒体的信令信息，但不承载媒体本身。当SIP基础设施在呼叫信令和即时消息之间共享时，IM流量可能会干扰呼叫信令流量。一般来说，拥塞控制是一个应该在SIP规范级别解决的问题，而不是针对单个方法。但是，由于消息的通信模式可能与大多数其他方法不同，因此对消息进行特殊考虑是有意义的。
Whenever possible, MESSAGE requests SHOULD be sent over transports that implement end-to-end congestion control, such as TCP or SCTP. However, SIP does not provide a mechanism to prevent a downstream hop from sending a request over UDP. Even the requirement to use TCP for requests over a certain size can be overridden by the receiver. Therefore use of a congestion-controlled transport by the UAC is not sufficient.
只要可能，消息请求应该通过实现端到端拥塞控制的传输（如TCP或SCTP）发送。然而，SIP并没有提供一种机制来防止下游跃点通过UDP发送请求。即使对超过一定大小的请求使用TCP的要求也可以被接收方覆盖。因此，UAC使用拥塞控制传输是不够的。
The size of MESSAGE requests outside of a media session MUST NOT exceed 1300 bytes, unless the UAC has positive knowledge that the message will not traverse a congestion-unsafe link at any hop, or that the message size is at least 200 bytes less than the lowest MTU value found en route to the UAS. Larger payloads may be sent as part of a media session, or using some type of content-indirection.
媒体会话之外的消息请求大小不得超过1300字节，除非UAC明确知道消息不会在任何跃点通过拥塞不安全链路，或者消息大小至少比到UAS的路由中发现的最低MTU值小200字节。较大的有效载荷可以作为媒体会话的一部分发送，或者使用某种类型的内容间接发送。
At the time of this writing, there is no mechanism for a UAC to gain such knowledge outside of trivial network architectures, or networks that are wholly controlled by a single administrative domain. But if a mechanism for ensuring congestion-control at each hop is created in the future, MESSAGE clients can relax the size limit without requiring a change to this specification. The authors expect that such a mechanism or mechanism will be created in the near future.
在撰写本文时，UAC没有任何机制可以在琐碎的网络架构或完全由单个管理域控制的网络之外获得此类知识。但是，如果将来创建一种机制来确保每个跃点的拥塞控制，那么消息客户端就可以放宽大小限制，而无需更改此规范。作者们期望在不久的将来建立这样一种机制。
There have been discussions on making the 1300 byte limit based on the path MTU to the next hop SIP device. The SIP specification does exactly that, choosing the limit 200 bytes less than the path MTU, or 1300 bytes if the device does not know the path MTU. Transport decisions are made on a per-hop basis. However, the point of this limit is to make sure that no upstream proxy chooses to send a MESSAGE request with large content over UDP. Since, except in trivial circumstances, a MESSAGE client is very unlikely to know the MTU for upstream devices beyond the next hop, an MTU based limit is not very useful.
已经讨论过如何根据下一跳SIP设备的MTU路径设置1300字节的限制。SIP规范正是这样做的，选择比路径MTU小200字节的限制，或者如果设备不知道路径MTU，则选择1300字节的限制。传输决策是在每跳的基础上做出的。但是，此限制的要点是确保没有上游代理选择通过UDP发送包含大量内容的消息请求。因为，除了在一般情况下，消息客户端在下一跳之后不太可能知道上游设备的MTU，因此基于MTU的限制不是很有用。
A UAC MUST NOT initiate a new out-of-dialog MESSAGE transaction to a given URI if there is a previous out-of-dialog transaction pending for the same URI. Similarly, A UAC SHOULD NOT initiate overlapping MESSAGE transactions inside a dialog, and MUST NOT do so unless the route set for that dialog uses a congestion-controlled transport at every hop.
如果同一URI存在以前的对话外事务挂起，UAC不得向给定URI发起新的对话外消息事务。类似地，UAC不应在对话框内启动重叠的消息事务，并且不得这样做，除非为该对话框设置的路由在每个跃点使用拥塞控制传输。
The prohibition against overlapping MESSAGE request provides some degree of congestion-safe behavior. A request and its associated response must each cross the full path between the UAC and the UAS. The time required for this will increase as networks become congested. This provides an adaptive mechanism to slow the introduction of new MESSAGE requests to the same destination.
禁止重叠消息请求提供了某种程度的拥塞安全行为。请求及其相关响应必须分别穿过UAC和UAS之间的完整路径。当网络变得拥挤时，所需的时间将增加。这提供了一种自适应机制来减缓向同一目的地引入新消息请求的速度。
It has been suggested that provisional responses should not be allowed for pager-model MESSAGE requests. However, it is not possible to require special treatment for MESSAGE, since many proxy servers will not be aware of the MESSAGE method. Therefore MESSAGE requests will receive the same provisional response treatment as any other non-INVITE method, as described in the SIP specification.
有人建议，寻呼机模型消息请求不允许临时响应。但是，不可能要求对消息进行特殊处理，因为许多代理服务器不知道消息方法。因此，消息请求将收到与任何其他非INVITE方法相同的临时响应处理，如SIP规范中所述。
This specification defines a new SIP method, MESSAGE. The BNF for this method is:
本规范定义了一种新的SIP方法MESSAGE。此方法的BNF为：
MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
MESSAGEm = %x4D.45.53.53.41.47.45 ;MESSAGE in caps
As with all other methods, the MESSAGE method name is case sensitive.
与所有其他方法一样，消息方法名称区分大小写。
Tables 1 and 2 extend Tables 2 and 3 of SIP [1] by adding an additional column, defining the header fields that can be used in MESSAGE requests and responses.
表1和表2扩展了SIP[1]的表2和表3，增加了一列，定义了可用于消息请求和响应的头字段。
Header Field where proxy MESSAGE
__________________________________________
Accept R -
Accept 2xx -
Accept 415 m*
Accept-Encoding R -
Accept-Encoding 2xx -
Accept-Encoding 415 m*
Accept-Language R -
Accept-Language 2xx -
Accept-Language 415 m*
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date a o
Error-Info 300-699 a o
Expires o
From c r m
In-Reply-To R o
Max-Forwards R amr m
Organization ar o
Header Field where proxy MESSAGE
__________________________________________
Accept R -
Accept 2xx -
Accept 415 m*
Accept-Encoding R -
Accept-Encoding 2xx -
Accept-Encoding 415 m*
Accept-Language R -
Accept-Language 2xx -
Accept-Language 415 m*
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c r m
Call-Info ar o
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length ar t
Content-Type *
CSeq c r m
Date a o
Error-Info 300-699 a o
Expires o
From c r m
In-Reply-To R o
Max-Forwards R amr m
Organization ar o
Table 1: Summary of header fields, A--O
表1：标题字段摘要，A--O
Header Field where proxy MESSAGE
__________________________________________
Priority R ar o
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
Record-Route ar -
Reply-To o
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr o
Server r o
Subject R o
Timestamp o
To c(1) r m
Unsupported 420 o
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
Header Field where proxy MESSAGE
__________________________________________
Priority R ar o
Proxy-Authenticate 407 ar m
Proxy-Authenticate 401 ar o
Proxy-Authorization R dr o
Proxy-Require R ar o
Record-Route ar -
Reply-To o
Require ar c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R adr o
Server r o
Subject R o
Timestamp o
To c(1) r m
Unsupported 420 o
User-Agent o
Via R amr m
Via rc dr m
Warning r o
WWW-Authenticate 401 ar m
WWW-Authenticate 407 ar o
(1): copied with possible addition of tag
（1） ：复制并可能添加标记
Table 2: Summary of header fields, P--Z
表2：标题字段摘要，P--Z
A MESSAGE request MAY contain a body, using the standard MIME header fields to identify the content.
消息请求可能包含一个正文，使用标准MIME头字段来标识内容。
An example message flow is shown in Figure 1. The message flow shows an initial IM sent from User 1 to User 2, both users in the same domain, "domain", through a single proxy.
图1显示了一个示例消息流。消息流显示从用户1向用户2发送的初始IM，这两个用户通过单个代理在同一个域“域”中。
| F1 MESSAGE | |
|--------------------> | F2 MESSAGE |
| | ----------------------->|
| | |
| | F3 200 OK |
| | <-----------------------|
| F4 200 OK | |
|<-------------------- | |
| | |
| | |
| | |
User 1 Proxy User 2
| F1 MESSAGE | |
|--------------------> | F2 MESSAGE |
| | ----------------------->|
| | |
| | F3 200 OK |
| | <-----------------------|
| F4 200 OK | |
|<-------------------- | |
| | |
| | |
| | |
User 1 Proxy User 2
Figure 1: Example Message Flow
图1：示例消息流
Message F1 looks like:
消息F1看起来像：
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@domain.com;tag=49583
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
沃森，过来。
User1 forwards this message to the server for domain.com. The proxy receives this request, and recognizes that it is the server for domain.com. It looks up user2 in its database (built up through registrations), and finds a binding from sip:user2@domain.com to sip:user2@user2pc.domain.com. It forwards the request to user2. The resulting message, F2, looks like:
User1将此消息转发到domain.com的服务器。代理收到此请求，并识别它是domain.com的服务器。它在其数据库（通过注册建立）中查找user2，并从sip中找到绑定：user2@domain.com啜饮：user2@user2pc.domain.com. 它将请求转发给user2。结果消息F2如下所示：
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
MESSAGE sip:user2@domain.com SIP/2.0
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
Max-Forwards: 69
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.
沃森，过来。
The message is received by user2, displayed, and a response is generated, message F3, and sent to the proxy:
该消息由user2接收、显示，并生成响应消息F3，然后发送到代理：
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds;
received=192.0.2.1
Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
Note that most of the header fields are simply reflected in the response. The proxy receives this response, strips off the top Via, and forwards to the address in the next Via, user1pc.domain.com, the result being message F4:
请注意，大多数标题字段仅反映在响应中。代理收到此响应，剥离顶部的Via，并转发到下一个Via user1pc.domain.com中的地址，结果是消息F4:
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse;
received=1.2.3.4
From: sip:user1@domain.com;;tag=49394
To: sip:user2@domain.com;tag=ab8asdasd9
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Length: 0
In normal usage, most SIP requests are used to setup and modify communication sessions. The actual communication between participants happens in the media sessions, not in the SIP requests themselves. The MESSAGE method changes this assumption; MESSAGE requests normally carry the actual communication between participants as payload. This implies that MESSAGE requests have a greater need for security than most other SIP requests. In particular, UAs that support the MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms.
在正常使用中，大多数SIP请求用于设置和修改通信会话。参与者之间的实际通信发生在媒体会话中，而不是SIP请求本身。消息方法改变了这种假设；消息请求通常携带参与者之间的实际通信作为有效负载。这意味着消息请求比大多数其他SIP请求更需要安全性。特别是，支持消息请求的UAs必须实现端到端身份验证、主体完整性和主体机密性机制。
When local proxies are used for transmission of outbound messages, proxy authentication, as specified in RFC 3261, is RECOMMENDED. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network.
当使用本地代理传输出站消息时，建议使用RFC 3261中指定的代理身份验证。这有助于验证发起人的身份，并防止发起网络上的欺骗和垃圾邮件。
The SIPS URI mechanism [1] allows a UA to assert that every hop must occur over a secure connection. This provides some level of integrity and privacy protection. However, this requires the users to trust that each proxy in the request path is well-behaved, that is, they do not violate the rules for routing SIPS URIs. Also, any unencrypted bodies are fully exposed to the proxies.
SIPS URI机制[1]允许UA断言每个跃点必须在安全连接上发生。这提供了一定程度的完整性和隐私保护。但是，这要求用户相信请求路径中的每个代理都表现良好，也就是说，他们没有违反路由SIPS URI的规则。此外，任何未加密的实体都会完全暴露在代理之下。
Additionally, the possibility of a forking proxy allows a MESSAGE request to be delivered to additional endpoints without the knowledge of the UAC. If only hop-by-hop protection is used, the users must trust all proxies in the chain to not fork requests to unauthorized destinations.
此外，分叉代理的可能性允许在UAC不知情的情况下将消息请求传递到其他端点。如果仅使用逐跳保护，则用户必须信任链中的所有代理，以避免将请求转移到未经授权的目的地。
When the goal is to remedy the concerns stated above, the MESSAGE bodies MUST be secured with S/MIME. If bodies specified in future to be carried by the MESSAGE method have different means of providing end-to-end security, their specification MUST describe the usage. SIP MESSAGE endpoints MUST support encryption (CMS EnvelopeData) and S/MIME signatures (CMS SignedData).
当目标是解决上述问题时，必须使用S/MIME保护消息体。如果将来指定由消息方法承载的实体具有提供端到端安全性的不同方法，则它们的规范必须描述其用法。SIP消息端点必须支持加密（CMS信封数据）和S/MIME签名（CMS签名数据）。
The S/MIME algorithms are set by RFC 3369 [4]. The AES [10] algorithm should be preferred, as it is expected that AES best suits the capabilities of many platforms. However, an IETF specification for this is still incomplete as of the time of this writing.
S/MIME算法由RFC 3369[4]设置。AES[10]算法应该是首选，因为预计AES最适合许多平台的功能。然而，截至撰写本文之时，IETF对此的规范仍不完整。
To prevent the replay of old SIP requests, all signed MESSAGE requests and responses MUST contain a Date header field covered by the message signature. Any message with a date older than several minutes in the past, or which is more than several minutes in the future, SHOULD be answered with a 400 (Incorrect Date or Time) message, unless such messages arrive repeatedly from the same source, in which case they MAY be discarded without sending a response. Obviously, this replay attack prevention mechanism does not work for devices without clocks.
为了防止重播旧的SIP请求，所有已签名的消息请求和响应必须包含消息签名覆盖的日期头字段。任何过去的日期超过几分钟或将来超过几分钟的邮件，都应使用400（错误的日期或时间）邮件进行回复，除非此类邮件从同一来源重复到达，在这种情况下，可能会在不发送响应的情况下丢弃这些邮件。显然，这种重播攻击预防机制不适用于没有时钟的设备。
Note that there are situations where an stale Date header field is normal. For example, the MESSAGE request may have been stored in a store and forward server while the recipient was offline. When the recipient returns, that server might then forward the message. Final receipt of the message would then occur some time after it was originally sent.
请注意，在某些情况下，过时的日期标题字段是正常的。例如，邮件请求可能在收件人脱机时存储在存储转发服务器中。当收件人返回时，该服务器可能会转发邮件。消息最初发送后的一段时间将最终收到。
If a UAS receives a stale message that can be confirmed to have come from a known store and forward server (perhaps over a TLS connection), it makes sense for it to accept the message normally. Also, if one or more stale messages arrive shortly after an offline period, the UAS MAY accept the message, but SHOULD warn the user that there is a risk the message has been replayed.
如果UAS收到可以确认来自已知存储转发服务器（可能通过TLS连接）的过时消息，则它可以正常接受该消息。此外，如果一条或多条过时消息在脱机时间后不久到达，UAS可能会接受该消息，但应警告用户该消息有被重播的风险。
The message/cpim format [7] allows for the S/MIME protection of metadata in addition to the message payload itself. In many cases, this metadata is redundant with SIP header fields. Still, message/cpim adds value in that the protection of metadata can extend across protocol boundaries. For example, a signed message/cpim body can provide sender authentication using the message/cpim From header field, even if the message crosses a gateway to another CPIM compliant instant message service that does not understand SIP header fields.
消息/cpim格式[7]除了消息负载本身之外，还允许对元数据进行S/MIME保护。在许多情况下，此元数据与SIP头字段是冗余的。尽管如此，message/cpim还是增加了价值，因为元数据的保护可以跨越协议边界。例如，签名消息/cpim正文可以使用消息/cpim From标头字段提供发送方身份验证，即使消息通过网关到达另一个不理解SIP标头字段的符合cpim的即时消息服务。
This specification registers the MESSAGE method in the http://www.iana.org/assignments/sip-parameters/Method registry, according to the following information:
此规范在中注册消息方法http://www.iana.org/assignments/sip-parameters/Method 登记处，根据以下信息：
MESSAGE [RFC3428]
信息[RFC3428]
The following people made substantial contributions to this work:
以下人员对这项工作作出了重大贡献：
Bernard Aboba Microsoft Steve Donovan dynamicsoft Jonathan Lennox Columbia University Dave Oran Cisco Robert Sparks dynamicsoft Dean Willis dynamicsoft
Bernard Aboba微软Steve Donovan dynamicsoft Jonathan Lennox哥伦比亚大学Dave Oran Cisco Robert Sparks dynamicsoft主任Willis dynamicsoft
The authors would like to thank the following people for their support of the concept of SIP for IM, support for this work, and for their useful comments and insights:
作者要感谢以下人员对SIP for IM概念的支持、对这项工作的支持以及他们的有用评论和见解：
Jon Peterson NeuStar Sean Olson Microsoft Adam Roach dynamicsoft Billy Biggs University of Waterloo
乔恩彼得森纽斯塔尔肖恩奥尔森微软亚当RoaDaunkStand比利滑铁卢大学
Stuart Barkley UUNet Mauricio Arango SUN Richard Shockey NeuStar Jorgen Bjorker Hotsip Henry Sinnreich MCI Worldcom Ronald Akers Motorola Torrey Searle Indigo Software Rohan Mahy Cisco Christian Groves Ericsson Allison Mankin ISI Tan Ya-Ching Siemens
Stuart Barkley UUNet Mauricio Arango SUN Richard Shockey NeuStar Jorgen Bjorker Hotsip Henry Sinnreich MCI Worldcom Ronald Akers摩托罗拉Torrey Searle Indigo软件Rohan Mahy Cisco Christian Groves爱立信Allison Mankin ISI Tan Ya Ching西门子
15.Normative References
15.规范性引用文件
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[2] Day，M.，Aggarwal，S.和J.Vincent，“即时消息传递/存在协议要求”，RFC 27792000年2月。
[3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[3] Day，M.，Rosenberg，J.和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[4] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002.
[4] Housley，R.，“加密消息语法（CMS）”，RFC3369，2002年8月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[6] Bradner, S., "Keywords for Use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging Message Format", Work in Progress.
[7] Atkins，D.和G.Klyne，“常见状态和即时消息格式”，正在进行中。
[8] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Address Resolution for Instant Messaging and Presence", Work in Progress.
[8] Crocker，D.，Diacakis，A.，Mazzoldi，F.，Huitema，C.，Klyne，G.，Rose，M.，Rosenberg，J.，Sparks，R.，Sugano，H.和J.Peterson，“即时消息和状态的地址解析”，正在进行中。
[9] Rosenberg, J. and H. Schulzrinne, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
[9] Rosenberg，J.和H.Schulzrinne，“SIP呼叫方偏好和被呼叫方能力”，正在进行中。
[10] Schaad, J. and R. Housley, "Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS", Work in Progress.
[10] Schaad，J.和R.Housley，“在CMS中使用AES加密算法和RSA-OAEP密钥传输”，正在进行中。
[11] DellaFera, C., Eichin, M., French, R., Jedlinski, D., Kohl, J. and W. Sommerfeld, "The Zephyr notification service", in USENIX Winter Conference (Dallas, Texas), Feb. 1988.
[11] DellaFera，C.，Eichin，M.，French，R.，Jedlinski，D.，Kohl，J.和W.Sommerfeld，“西风通知服务”，USENIX冬季会议（德克萨斯州达拉斯），1988年2月。
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024
德克萨斯州普莱诺市坦尼森大道1200号本坎贝尔动力软件5100套房，邮编75024
EMail: bcampbell@dynamicsoft.com
EMail: bcampbell@dynamicsoft.com
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
亨宁·舒尔兹林内哥伦比亚大学M/S 0401 1214纽约州纽约市阿姆斯特丹大道10027-7003
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
David Gurle微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: dgurle@microsoft.com
EMail: dgurle@microsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。