Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7572 &yet
Category: Standards Track A. Houri
ISSN: 2070-1721 IBM
J. Hildebrand
Cisco Systems, Inc.
June 2015
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7572 &yet
Category: Standards Track A. Houri
ISSN: 2070-1721 IBM
J. Hildebrand
Cisco Systems, Inc.
June 2015
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：即时消息
Abstract
摘要
This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).
本文档定义了一个双向协议映射，用于在会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间交换单个即时消息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7572.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7572.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Internationalization Considerations . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Intended Audience . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. XMPP to SIP . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. SIP to XMPP . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Message Size . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Content Types . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Internationalization Considerations . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
In order to help ensure interworking between instant messaging (IM) systems that conform to the instant messaging / presence requirements [RFC2779], it is important to clearly define protocol mappings between such systems. Within the IETF, work has proceeded on two instant messaging technologies:
为了帮助确保符合即时消息/状态要求[RFC2779]的即时消息（IM）系统之间的互通，必须明确定义此类系统之间的协议映射。在IETF内，两种即时消息技术的工作正在进行：
o Various extensions to the Session Initiation Protocol ([RFC3261]) for instant messaging, in particular the MESSAGE method extension [RFC3428]; collectively the capabilities of SIP with these extensions are commonly called SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE).
o 用于即时消息传递的会话启动协议（[RFC3261]）的各种扩展，尤其是消息方法扩展[RFC3428]；具有这些扩展的SIP的功能统称为SIP，用于即时消息传递和状态利用扩展（简单）。
o The Extensible Messaging and Presence Protocol (XMPP), which consists of a formalization of the core XML streaming protocols developed originally by the Jabber open-source community; the relevant specifications are [RFC6120] for the XML streaming layer and [RFC6121] for basic presence and instant messaging extensions.
o 可扩展消息和状态协议（XMPP），它由最初由Jabber开源社区开发的核心XML流协议的形式化组成；相关规范为[RFC6120]用于XML流媒体层，以及[RFC6121]用于基本状态和即时消息扩展。
One approach to helping ensure interworking between these protocols is to map each protocol to the abstract semantics described in [RFC3860]; that is the approach taken by [SIMPLE-CPIM] and [RFC3922]. In contrast, the approach taken in this document is to directly map semantics from one protocol to another (i.e., from SIP / SIMPLE to XMPP and vice versa), since that is how existing systems solve the interworking problem.
帮助确保这些协议之间互通的一种方法是将每个协议映射到[RFC3860]中描述的抽象语义；这是[SIMPLE-CPIM]和[RFC3922]采取的方法。相反，本文档中采用的方法是直接将语义从一个协议映射到另一个协议（即从SIP/SIMPLE映射到XMPP，反之亦然），因为这是现有系统解决互通问题的方式。
Both XMPP systems and IM-capable SIP systems enable entities to exchange "instant messages". The term "instant message" usually refers to a message sent between two entities for delivery in close
XMPP系统和支持IM的SIP系统都支持实体交换“即时消息”。术语“即时消息”通常指在两个实体之间发送的用于近距离传递的消息
to real time (rather than a message that is stored and forwarded to the intended recipient upon request). This document specifies mappings only for single messages (sometimes called "pager-mode" messaging), since they form the lowest common denominator for IM. Separate documents cover "session-mode" instant messaging in the form of one-to-one chat sessions [RFC7573] and multi-party chat sessions [GROUPCHAT]. In particular, session-mode instant messaging supports several features that are not part of pager-mode instant messaging, such as a higher level of assurance regarding end-to-end message delivery. As with all of these documents, the architectural assumptions underlying such direct mappings are provided in [RFC7247], including mapping of addresses and error conditions.
实时发送（而不是根据请求存储并转发给预期收件人的消息）。本文档仅为单个消息（有时称为“寻呼机模式”消息）指定映射，因为它们构成IM的最低公分母。单独的文档包括一对一聊天会话[RFC7573]和多方聊天会话[GROUPCHAT]形式的“会话模式”即时消息。特别是，会话模式即时消息支持一些不属于寻呼机模式即时消息的功能，例如关于端到端消息传递的更高级别的保证。与所有这些文档一样，[RFC7247]中提供了此类直接映射的基础架构假设，包括地址映射和错误条件。
The documents in this series are intended for use by software developers who have an existing system based on one of these technologies (e.g., SIP) and who would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). We assume that readers are familiar with the core specifications for both SIP [RFC3261] and XMPP [RFC6120], with the base document for this series [RFC7247], and with the following IM-related specifications:
本系列中的文档旨在供软件开发人员使用，这些软件开发人员拥有基于其中一种技术（如SIP）的现有系统，并且希望能够实现从该现有系统到基于其他技术（如XMPP）的系统的通信。我们假设读者熟悉SIP[RFC3261]和XMPP[RFC6120]的核心规范、本系列的基础文档[RFC7247]以及以下IM相关规范：
o "Session Initiation Protocol (SIP) Extension for Instant Messaging" [RFC3428]
o “即时消息会话启动协议（SIP）扩展”[RFC3428]
o "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence" [RFC6121]
o “可扩展消息和状态协议（XMPP）：即时消息和状态”[RFC6121]
Note well that not all protocol-compliant messages are shown (such as SIP 100 TRYING messages), in order to focus the reader on the essential aspects of the protocol flows.
请注意，并非所有符合协议的消息都被显示（例如SIP 100 TRYING消息），以便使读者关注协议流的基本方面。
A number of terms used here are explained in [RFC3261], [RFC3428], [RFC6120], and [RFC6121].
[RFC3261]、[RFC3428]、[RFC6120]和[RFC6121]中解释了此处使用的许多术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
As described in [RFC6121], a single instant message is an XML <message/> stanza of type "normal" sent over an XML stream (since "normal" is the default for the 'type' attribute of the <message/> stanza, the attribute is often omitted).
如[RFC6121]中所述，单个即时消息是通过XML流发送的类型为“normal”的XML<message/>节（由于“normal”是<message/>节的“type”属性的默认值，因此该属性通常被忽略）。
When the XMPP user Juliet with a Jabber Identifier (JID) of <juliet@example.com> wants to send an instant message to Romeo, she interacts with her XMPP client, which generates an XMPP <message/> stanza. The syntax of the <message/> stanza, including required and optional elements and attributes, is defined in [RFC6121] (for single instant messages, Section 5.1 of [RFC6121] recommends that the value of the 'to' address be a "bare JID" of the form "localpart@domainpart"). The following is an example of such a stanza:
当XMPP用户Juliet的Jabber标识符（JID）为<juliet@example.com>想要向罗密欧发送即时消息，她与她的XMPP客户端交互，该客户端生成一个XMPP<message/>节。[RFC6121]中定义了<message/>节的语法，包括必需的和可选的元素和属性。（对于单个即时消息，[RFC6121]第5.1节建议“to”地址的值为表单的“裸JID”localpart@domainpart"). 以下是这一节的一个例子：
Example 1: XMPP User Sends Message
示例1:XMPP用户发送消息
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='romeo@example.net'>
| <body>Art thou not Romeo, and a Montague?</body>
| </message>
| <message from='juliet@example.com/yn0cl4bnw0yr3vym'
| to='romeo@example.net'>
| <body>Art thou not Romeo, and a Montague?</body>
| </message>
Upon receiving such a message stanza, the XMPP server needs to determine the identity of the domainpart in the 'to' address, which it does by following the procedures explained in Section 5 of [RFC7247]. If the domain is a SIP domain, the XMPP server will hand off the message stanza to an XMPP-to-SIP gateway or connection manager that natively communicates with IM-aware SIP servers.
在接收到这样一个消息节时，XMPP服务器需要确定“to”地址中domainpart的标识，这是通过遵循[RFC7247]第5节中解释的过程来完成的。如果域是SIP域，XMPP服务器将把消息节传递给XMPP-to-SIP网关或连接管理器，该网关或连接管理器本机与IM感知SIP服务器通信。
The XMPP-to-SIP gateway is then responsible for translating the XMPP message stanza into a SIP MESSAGE request from the XMPP user to the SIP user:
然后，XMPP到SIP网关负责将XMPP消息节转换为从XMPP用户到SIP用户的SIP消息请求：
Example 2: XMPP User Sends Message (SIP Transformation)
示例2:XMPP用户发送消息（SIP转换）
| MESSAGE sip:romeo@example.net SIP/2.0
| Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
| Max-Forwards: 70
| To: sip:romeo@example.net
| From: <sip:juliet@example.com;gr=yn0cl4bnw0yr3vym>;tag=12345
| Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 35
|
| Art thou not Romeo, and a Montague?
| MESSAGE sip:romeo@example.net SIP/2.0
| Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
| Max-Forwards: 70
| To: sip:romeo@example.net
| From: <sip:juliet@example.com;gr=yn0cl4bnw0yr3vym>;tag=12345
| Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 35
|
| Art thou not Romeo, and a Montague?
The destination SIP server is responsible for delivering the message to the intended recipient, and the recipient is responsible for generating a response (e.g., 200 OK).
目的地SIP服务器负责将消息传递给预期接收者，接收者负责生成响应（例如，200 OK）。
Example 3: SIP User Agent Indicates Receipt of Message
示例3:SIP用户代理表示收到消息
| SIP/2.0 200 OK
| Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
| From: sip:juliet@example.com;tag=12345
| To: sip:romeo@example.net;tag=vwxyz
| Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
| CSeq: 1 MESSAGE
| Content-Length: 0
| SIP/2.0 200 OK
| Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bK776sgdkse
| From: sip:juliet@example.com;tag=12345
| To: sip:romeo@example.net;tag=vwxyz
| Call-ID: D9AA95FD-2BD5-46E2-AF0F-6CFAA96BDDFA
| CSeq: 1 MESSAGE
| Content-Length: 0
As described in [RFC3428], a downstream proxy could fork a MESSAGE request, but it would return only one 200 OK to the gateway.
如[RFC3428]中所述，下游代理可以转发消息请求，但它只会向网关返回一个200 OK。
Note: This document does not specify handling of the 200 OK by the XMPP-to-SIP gateway (e.g., to enable message acknowledgements). See [RFC7573] for a mapping of message acknowledgements in the context of one-to-one chat sessions.
注意：本文档未指定XMPP到SIP网关对200 OK的处理（例如，启用消息确认）。有关一对一聊天会话上下文中的消息确认映射，请参见[RFC7573]。
The mapping of XMPP syntax to SIP syntax MUST be as shown in the following table.
XMPP语法到SIP语法的映射必须如下表所示。
Table 1: Message Syntax Mapping from XMPP to SIP
表1：从XMPP到SIP的消息语法映射
+-----------------------------+--------------------------+
| XMPP Element or Attribute | SIP Header or Contents |
+-----------------------------+--------------------------+
| <body/> | body of MESSAGE |
| <subject/> | Subject |
| <thread/> | Call-ID |
| from | From (1) |
| id | transaction identifier |
| to | To or Request-URI |
| type | (no mapping) (2) |
| xml:lang | Content-Language |
+-----------------------------+--------------------------+
+-----------------------------+--------------------------+
| XMPP Element or Attribute | SIP Header or Contents |
+-----------------------------+--------------------------+
| <body/> | body of MESSAGE |
| <subject/> | Subject |
| <thread/> | Call-ID |
| from | From (1) |
| id | transaction identifier |
| to | To or Request-URI |
| type | (no mapping) (2) |
| xml:lang | Content-Language |
+-----------------------------+--------------------------+
1. As shown in the foregoing example and described in [RFC7247], the XMPP-to-SIP gateway MUST map the bare JID ("localpart@domainpart") of the XMPP sender to the SIP From header and include the resourcepart of the "full JID" ("localpart@domainpart/resourcepart") as the Globally Routable User Agent URI (GRUU) portion [RFC5627] of the SIP URI.
1. 如上述示例所示并在[RFC7247]中所述，XMPP到SIP网关必须映射裸JID（“localpart@domainpart），并包括“完整JID”的resourcepart（“”）localpart@domainpart/resourcepart”）作为SIP URI的全局可路由用户代理URI（GRUU）部分[RFC5627]。
2. Because there is no SIP header field that matches the meaning of the XMPP message 'type' values ("normal", "chat", "groupchat", "headline", "error"), no general mapping is possible here.
2. 因为没有与XMPP消息“type”值（“normal”、“chat”、“groupchat”、“headline”、“error”）的含义匹配的SIP头字段，所以这里不可能进行一般映射。
As described in [RFC3428], a single instant message is a SIP MESSAGE request sent from a SIP user agent to an intended recipient who is most generally referenced by an Instant Messaging (IM) URI [RFC3861] of the form <im:user@domain> but who might be referenced by a SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>.
如[RFC3428]中所述，单个即时消息是从SIP用户代理发送给预期接收者的SIP消息请求，该接收者通常由形式为<IM:user@domain>但SIP或SIPS URI形式为<SIP:user@domain>或<sips:user@domain>.
When a SIP user Romeo with a SIP URI of <sip:romeo@example.net> wants to send an instant message to Juliet, he interacts with his SIP user agent, which generates a SIP MESSAGE request. The syntax of the MESSAGE request is defined in [RFC3428]. The following is an example of such a request:
当SIP用户Romeo的SIP URI<SIP:romeo@example.net>想要向Juliet发送即时消息，他与他的SIP用户代理交互，后者生成SIP消息请求。[RFC3428]中定义了消息请求的语法。以下是此类请求的示例：
Example 4: SIP User Sends Message
示例4：SIP用户发送消息
| MESSAGE sip:juliet@example.com SIP/2.0
| Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
| Max-Forwards: 70
| To: sip:juliet@example.com
| From: sip:romeo@example.net;tag=vwxyz
| Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 44
|
| Neither, fair saint, if either thee dislike.
| MESSAGE sip:juliet@example.com SIP/2.0
| Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
| Max-Forwards: 70
| To: sip:juliet@example.com
| From: sip:romeo@example.net;tag=vwxyz
| Call-ID: 9E97FB43-85F4-4A00-8751-1124FD4C7B2E
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 44
|
| Neither, fair saint, if either thee dislike.
Section 5 of [RFC3428] stipulates that a SIP user agent presented with an im: URI should resolve it to a sip: or sips: URI. Therefore, we assume that the Request-URI of a request received by an IM-capable SIP-to-XMPP gateway will contain a sip: or sips: URI. Upon receiving the MESSAGE, the SIP server needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures explained in Section 5 of [RFC7247]. If the domain is an XMPP domain, the SIP server will hand off the MESSAGE to an associated SIP-to-XMPP gateway or connection manager that natively communicates with XMPP servers.
[RFC3428]第5节规定，提供im:URI的SIP用户代理应将其解析为SIP:或sips:URI。因此，我们假设由支持IM的SIP到XMPP网关接收的请求的请求URI将包含SIP:或sips:URI。收到消息后，SIP服务器需要确定请求URI或to头的域部分的标识，这是通过遵循[RFC7247]第5节中解释的过程来完成的。如果域是XMPP域，SIP服务器将把消息传递给与XMPP服务器本机通信的关联SIP-to-XMPP网关或连接管理器。
The SIP-to-XMPP gateway is then responsible for translating the request into an XMPP message stanza from the SIP user to the XMPP user and returning a SIP 200 OK message to the sender:
然后，SIP到XMPP网关负责将请求转换为从SIP用户到XMPP用户的XMPP消息节，并将SIP 200 OK消息返回给发送方：
Example 5: SIP User Sends Message (XMPP Transformation)
示例5:SIP用户发送消息（XMPP转换）
| <message from='romeo@example.net/dr4hcr0st3lup4c'
| to='juliet@example.com'>
| <body>Neither, fair saint, if either thee dislike.</body>
| </message>
| <message from='romeo@example.net/dr4hcr0st3lup4c'
| to='juliet@example.com'>
| <body>Neither, fair saint, if either thee dislike.</body>
| </message>
Note that the stanza-handling rules specified in [RFC6121] allow the receiving XMPP server to deliver a message stanza whose 'to' address is a bare JID ("localpart@domainpart") to multiple connected devices. This is similar to the "forking" of messages in SIP.
请注意，[RFC6121]中指定的节处理规则允许接收XMPP服务器传递一个“to”地址为裸JID的消息节（“localpart@domainpart）连接到多个连接的设备。这类似于SIP中的消息“分叉”。
The mapping of SIP syntax to XMPP syntax MUST be as shown in the following table.
SIP语法到XMPP语法的映射必须如下表所示。
Table 2: Message Syntax Mapping from SIP to XMPP
表2：从SIP到XMPP的消息语法映射
+--------------------------+-----------------------------+
| SIP Header or Contents | XMPP Element or Attribute |
+--------------------------+-----------------------------+
| Call-ID | <thread/> |
| Content-Language | xml:lang |
| CSeq | (no mapping) |
| From | from (1) |
| Subject | <subject/> |
| Request-URI or To | to |
| body of MESSAGE | <body/> |
| transaction identifier | id |
+--------------------------+-----------------------------+
+--------------------------+-----------------------------+
| SIP Header or Contents | XMPP Element or Attribute |
+--------------------------+-----------------------------+
| Call-ID | <thread/> |
| Content-Language | xml:lang |
| CSeq | (no mapping) |
| From | from (1) |
| Subject | <subject/> |
| Request-URI or To | to |
| body of MESSAGE | <body/> |
| transaction identifier | id |
+--------------------------+-----------------------------+
1. As shown in the foregoing example and described in [RFC7247], if the IM-capable SIP-to-XMPP gateway has information about the GRUU [RFC5627] of the particular endpoint that sent the SIP message, then it MUST map the sender's address to a full JID ("localpart@domainpart/resourcepart") in the 'from' attribute of the XMPP stanza and include the GRUU as the resourcepart.
1. 如上述示例所示并在[RFC7247]中所述，如果支持IM的SIP-to-XMPP网关具有关于发送SIP消息的特定端点的GRUU[RFC5627]的信息，则它必须将发送者的地址映射到完整的JID（“localpart@domainpart/资源部分）在XMPP节的“from”属性中，并将GRUU包含为resourcepart。
When transforming SIP pager-mode messages, an IM-capable SIP-to-XMPP gateway MUST specify no XMPP 'type' attribute or, equivalently, a 'type' attribute whose value is "normal" [RFC6121].
转换SIP寻呼机模式消息时，支持IM的SIP到XMPP网关必须不指定XMPP“type”属性，或者等效地指定值为“normal”的“type”属性[RFC6121]。
See Section 7 of this document about the handling of SIP message bodies that contain content types other than plain text.
请参阅本文档第7节，了解如何处理包含非纯文本内容类型的SIP消息体。
[RFC3428] specifies that (outside of a media session) the size of a MESSAGE request is not allowed to exceed 1300 bytes. Although, in practice, XMPP instant messages do not often exceed that size, neither [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP stanzas. However, XMPP server deployments usually do limit the size of stanzas in order to help prevent denial-of-service attacks, and [RFC6120] states that if a server sets a maximum stanza size, then the limit is not allowed to be less than 10,000 bytes. Because of this mismatch, an XMPP-to-SIP gateway SHOULD return a <policy-violation/> stanza error if an XMPP user attempts to send an XMPP message stanza that would result in a SIP MESSAGE greater than 1300 bytes. Although such a gateway might decide to "upgrade" from page mode to session mode using the Message Session Relay Protocol (MSRP) -- thus treating the instant message as part of a chat session as described in [RFC7573] -- such behavior is application-specific and this document provides no guidelines for how to complete such an upgrade.
[RFC3428]指定（在媒体会话之外）消息请求的大小不允许超过1300字节。尽管在实践中，XMPP即时消息通常不会超过该大小，[RFC6120]和[RFC6121]都没有对XMPP节的大小设置上限。但是，XMPP服务器部署通常会限制节的大小，以帮助防止拒绝服务攻击，[RFC6120]指出，如果服务器设置了最大节大小，则限制不允许小于10000字节。由于这种不匹配，如果XMPP用户试图发送导致SIP消息大于1300字节的XMPP消息节，则XMPP到SIP网关应返回<policy violation/>节错误。尽管这样的网关可能会决定使用消息会话中继协议（MSRP）从页面模式“升级”到会话模式，从而将即时消息视为[RFC7573]中所述的聊天会话的一部分，但此类行为是特定于应用程序的，本文档没有提供如何完成此类升级的指南。
SIP requests of type "MESSAGE" are allowed to contain essentially any content type. The recommended procedures for SIP-to-XMPP gateways to use in handling these content types are as follows.
类型为“MESSAGE”的SIP请求基本上可以包含任何内容类型。SIP到XMPP网关在处理这些内容类型时使用的推荐过程如下所示。
An IM-aware SIP-to-XMPP gateway MUST process SIP messages that contain message bodies of type "text/plain" and MUST encapsulate such message bodies as the XML character data of the XMPP <body/> element.
支持IM的SIP到XMPP网关必须处理包含“text/plain”类型消息体的SIP消息，并且必须将此类消息体封装为XMPP<body/>元素的XML字符数据。
An IM-aware SIP-to-XMPP gateway SHOULD process SIP messages that contain message bodies of type "text/html"; if so, a gateway MUST transform the "text/html" content into XHTML content that conforms to the XHTML-IM Integration Set specified in [XEP-0071].
支持IM的SIP-to-XMPP网关应处理包含“text/html”类型消息体的SIP消息；如果是这样，网关必须将“text/html”内容转换为符合[XEP-0071]中指定的XHTML-IM集成集的XHTML内容。
Although an IM-aware SIP-to-XMPP gateway MAY process SIP messages that contain message bodies of types other than "text/plain" and "text/html", the handling of such content types is a matter of implementation.
尽管IM-aware SIP-to-XMPP网关可以处理包含除“text/plain”和“text/html”以外类型的消息体的SIP消息，但是处理此类内容类型是一个实现问题。
Both XMPP and SIP support the UTF-8 encoding [RFC3629] of Unicode characters [UNICODE] within messages, along with tagging of the language for a particular message (in XMPP via the 'xml:lang' attribute and in SIP via the Content-Language header). Gateways MUST map these language tagging mechanisms if they are present in the original message. Several examples follow, using the "XML Notation" [RFC3987] for Unicode characters outside the ASCII range.
XMPP和SIP都支持消息中Unicode字符[Unicode]的UTF-8编码[RFC3629]，以及特定消息的语言标记（在XMPP中通过'xml:lang'属性，在SIP中通过Content language标头）。网关必须映射这些语言标记机制（如果它们存在于原始消息中）。下面有几个例子，对ASCII范围之外的Unicode字符使用“XML表示法”[RFC3987]。
Example 6: SIP User Sends Message
示例6:SIP用户发送消息
| MESSAGE sip:juliet@example.com SIP/2.0
| Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
| Max-Forwards: 70
| To: sip:juliet@example.com
| From: sip:romeo@example.net;tag=vwxyz
| Call-ID: 5A37A65D-304B-470A-B718-3F3E6770ACAF
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 45
| Content-Language: cs
|
| Nic z ob쎩ho, m쎡 d쒛vo spanil쎡,
| nenavid쎭얡-li jedno nebo druh쎩.
| MESSAGE sip:juliet@example.com SIP/2.0
| Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKeskdgs677
| Max-Forwards: 70
| To: sip:juliet@example.com
| From: sip:romeo@example.net;tag=vwxyz
| Call-ID: 5A37A65D-304B-470A-B718-3F3E6770ACAF
| CSeq: 1 MESSAGE
| Content-Type: text/plain
| Content-Length: 45
| Content-Language: cs
|
| Nic z ob쎩ho, m쎡 d쒛vo spanil쎡,
| nenavid쎭얡-li jedno nebo druh쎩.
Example 7: SIP User Sends Message (XMPP Transformation)
示例7:SIP用户发送消息（XMPP转换）
| <message from='romeo@example.net'
| to='juliet@example.com'
| xml:lang='cs'>
| <body>
| Nic z ob쎩ho, m쎡 d쒛vo spanil쎡,
| nenavid쎭얡-li jedno nebo druh쎩.
| </body>
| </message>
| <message from='romeo@example.net'
| to='juliet@example.com'
| xml:lang='cs'>
| <body>
| Nic z ob쎩ho, m쎡 d쒛vo spanil쎡,
| nenavid쎭얡-li jedno nebo druh쎩.
| </body>
| </message>
Detailed security considerations are given in the following documents:
以下文件中给出了详细的安全注意事项：
o For instant messaging protocols in general, see [RFC2779]
o 有关即时消息协议的一般信息，请参见[RFC2779]
o For SIP-based instant messaging, see [RFC3428] and also [RFC3261]
o 有关基于SIP的即时消息，请参见[RFC3428]和[RFC3261]
o For XMPP-based instant messaging, see [RFC6121] and also [RFC6120]
o 有关基于XMPP的即时消息，请参见[RFC6121]和[RFC6120]
o For SIP-XMPP interworking in general, see [RFC7247]
o 有关SIP-XMPP互通的一般信息，请参见[RFC7247]
This document specifies methods for exchanging "pager-mode" instant messages through a gateway that translates between SIP and XMPP, and [RFC7573] specifies such methods for "session-mode" instant messaging between MSRP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the textual chat protocols for which it translates (i.e., SIP or MSRP and XMPP).
本文件规定了通过在SIP和XMPP之间转换的网关交换“寻呼机模式”即时消息的方法，[RFC7573]规定了MSRP和XMPP之间“会话模式”即时消息的此类方法。这样的网关必须符合其翻译的文本聊天协议（即SIP或MSRP和XMPP）的最低安全要求。
The addition of gateways to the security model of instant messaging specified in [RFC2779] introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between instant messaging clients that interface through a gateway can be provided only if common formats are supported. Specification of those common formats is out of scope for this document. For instant messages, it is possible to use the methods described in [RFC3862] and [RFC3923], but those methods are not widely implemented. A more widely implemented, albeit nonstandardized, method for interoperable end-to-end encryption would be Off-the-Record Messaging [OTR].
[RFC2779]中规定的即时消息安全模型中增加网关会带来一些新的风险。特别是，只有在支持通用格式的情况下，才能提供通过网关进行交互的即时消息客户端之间的端到端安全属性（特别是机密性和完整性）。这些通用格式的规范超出了本文档的范围。对于即时消息，可以使用[RFC3862]和[RFC3923]中所述的方法，但这些方法并未广泛实施。一种实现更广泛（尽管不是标准化的）可互操作的端到端加密方法是非记录消息传递[OTR]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, DOI 10.17487/RFC3428, December 2002, <http://www.rfc-editor.org/info/rfc3428>.
[RFC3428]Campbell，B.，Ed.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 3428，DOI 10.17487/RFC3428，2002年12月<http://www.rfc-editor.org/info/rfc3428>.
[RFC3861] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, DOI 10.17487/RFC3861, August 2004, <http://www.rfc-editor.org/info/rfc3861>.
[RFC3861]Peterson，J.，“即时消息和状态的地址解析”，RFC 3861，DOI 10.17487/RFC3861，2004年8月<http://www.rfc-editor.org/info/rfc3861>.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，DOI 10.17487/RFC5627，2009年10月<http://www.rfc-editor.org/info/rfc5627>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <http://www.rfc-editor.org/info/rfc6121>.
[RFC6121]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 6121DOI 10.17487/RFC6121，2011年3月<http://www.rfc-editor.org/info/rfc6121>.
[RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling", RFC 7247, DOI 10.17487/RFC7247, May 2014, <http://www.rfc-editor.org/info/rfc7247>.
[RFC7247]Saint Andre，P.，Houri，A.，和J.Hildebrand，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：体系结构、地址和错误处理”，RFC 7247，DOI 10.17487/RFC7247，2014年5月<http://www.rfc-editor.org/info/rfc7247>.
[XEP-0071] Saint-Andre, P., "XHTML-IM", XSF XEP 0071, November 2012.
[XEP-0071]圣安德烈，P.，“XHTML-IM”，XSF XEP 0071，2012年11月。
[GROUPCHAT] Saint-Andre, P., Corretge, S., and S. Loreto, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat", Work in Progress, draft-ietf-stox-groupchat-11, March 2015.
[GROUPCHAT]Saint Andre，P.，Corretge，S.，和S.Loreto，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：GROUPCHAT”，正在进行的工作，草稿-ietf-stox-GROUPCHAT-11，2015年3月。
[OTR] Goldberg, I., "Off-the-Record Messaging", <https://otr.cypherpunks.ca/>.
[OTR]戈德伯格，I.，“非公开信息”<https://otr.cypherpunks.ca/>.
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, DOI 10.17487/RFC2779, February 2000, <http://www.rfc-editor.org/info/rfc2779>.
[RFC2779]Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息传递/存在协议要求”，RFC 2779，DOI 10.17487/RFC27792000年2月<http://www.rfc-editor.org/info/rfc2779>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, <http://www.rfc-editor.org/info/rfc3860>.
[RFC3860]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC 3860，DOI 10.17487/RFC3860，2004年8月<http://www.rfc-editor.org/info/rfc3860>.
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <http://www.rfc-editor.org/info/rfc3862>.
[RFC3862]Klyne，G.和D.Atkins，“常见状态和即时消息（CPIM）：消息格式”，RFC 3862，DOI 10.17487/RFC3862，2004年8月<http://www.rfc-editor.org/info/rfc3862>.
[RFC3922] Saint-Andre, P., "Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)", RFC 3922, DOI 10.17487/RFC3922, October 2004, <http://www.rfc-editor.org/info/rfc3922>.
[RFC3922]Saint Andre，P.，“将可扩展消息和状态协议（XMPP）映射到公共状态和即时消息（CPIM）”，RFC 3922，DOI 10.17487/RFC3922，2004年10月<http://www.rfc-editor.org/info/rfc3922>.
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, DOI 10.17487/RFC3923, October 2004, <http://www.rfc-editor.org/info/rfc3923>.
[RFC3923]Saint Andre，P.，“可扩展消息和状态协议（XMPP）的端到端签名和对象加密”，RFC 3923，DOI 10.17487/RFC3923，2004年10月<http://www.rfc-editor.org/info/rfc3923>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，DOI 10.17487/RFC3987，2005年1月<http://www.rfc-editor.org/info/rfc3987>.
[RFC7573] Saint-Andre, P. and S. Loreto, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions", RFC 7573, DOI 10.17487/RFC7573, June 2015, <http://www.rfc-editor.org/info/rfc7573>.
[RFC7573]Saint Andre，P.和S.Loreto，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：一对一文本聊天会话”，RFC 7573，DOI 10.17487/RFC7573，2015年6月<http://www.rfc-editor.org/info/rfc7573>.
[SIMPLE-CPIM] Campbell, B. and J. Rosenberg, "CPIM Mapping of SIMPLE Presence and Instant Messaging", Work in Progress, draft-ietf-simple-cpim-mapping-01, June 2002.
[SIMPLE-CPIM]Campbell，B.和J.Rosenberg，“简单状态和即时消息的CPIM映射”，正在进行的工作，草稿-ietf-SIMPLE-CPIM-Mapping-01，2002年6月。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
Acknowledgements
致谢
The authors wish to thank the following individuals for their feedback: Mary Barnes, Dave Cridland, Dave Crocker, Adrian Georgescu, Christer Holmberg, Saul Ibarra Corretge, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, and Tory Patnoe.
作者希望感谢以下个人的反馈：玛丽·巴恩斯、戴夫·克里德兰、戴夫·克罗克、阿德里安·乔治斯库、克里斯特·霍姆伯格、索尔·伊瓦拉·科雷奇、奥利·约翰森、保罗·基齐瓦特、萨尔瓦托·洛雷托、丹尼尔·康斯坦丁·米尔拉和托利·帕特诺。
Special thanks to Ben Campbell for his detailed and insightful reviews.
特别感谢Ben Campbell的详细和深刻的评论。
Francis Dupont reviewed the document on behalf of the General Area Review Team.
弗朗西斯·杜邦（Francis Dupont）代表一般区域审查小组审查了该文件。
Spencer Dawkins, Stephen Farrell, and Barry Leiba provided helpful input during IESG review.
斯宾塞·道金斯（Spencer Dawkins）、斯蒂芬·法雷尔（Stephen Farrell）和巴里·莱巴（Barry Leiba）在IESG审查期间提供了有用的意见。
The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors.
作者衷心感谢工作组主席Markus Isomaki和Yana Stamcheva以及赞助区域主任Gonzalo Camarillo和Alissa Cooper的协助。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint Andre希望感谢Cisco Systems，Inc.在编写本文件早期草稿期间聘用了他。
Authors' Addresses
作者地址
Peter Saint-Andre
&yet
EMail: peter@andyet.com
URI: https://andyet.com/
Peter Saint-Andre
&yet
EMail: peter@andyet.com
URI: https://andyet.com/
Avshalom Houri IBM Rorberg Building, Pekris 3 Rehovot 76123 Israel EMail: avshalom@il.ibm.com
Avshalom Houri IBM Rorberg大厦，Pekris 3 Rehovot 76123以色列电子邮件：avshalom@il.ibm.com
Joe Hildebrand Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 United States EMail: jhildebr@cisco.com
Joe Hildebrand Cisco Systems，Inc.美国丹佛Wynkoop街1899号600室邮编：80202电子邮件：jhildebr@cisco.com