Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7247 &yet
Category: Standards Track A. Houri
ISSN: 2070-1721 IBM
J. Hildebrand
Cisco Systems, Inc.
May 2014
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7247 &yet
Category: Standards Track A. Houri
ISSN: 2070-1721 IBM
J. Hildebrand
Cisco Systems, Inc.
May 2014
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：体系结构、地址和错误处理
Abstract
摘要
As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.
作为定义会话发起协议（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/rfc7247.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7247.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................3
2. Intended Audience ...............................................3
3. Terminology .....................................................4
4. Architectural Assumptions .......................................4
5. Interdomain Federation ..........................................6
6. Address Mapping .................................................7
6.1. Overview ...................................................7
6.2. Local Part Mapping .........................................9
6.3. Instance-Specific Mapping .................................11
6.4. SIP to XMPP ...............................................11
6.5. XMPP to SIP ...............................................12
7. Error Mapping ..................................................14
7.1. XMPP to SIP ...............................................15
7.2. SIP to XMPP ...............................................17
8. Security Considerations ........................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................22
Appendix A. Acknowledgements ......................................24
1. Introduction ....................................................3
2. Intended Audience ...............................................3
3. Terminology .....................................................4
4. Architectural Assumptions .......................................4
5. Interdomain Federation ..........................................6
6. Address Mapping .................................................7
6.1. Overview ...................................................7
6.2. Local Part Mapping .........................................9
6.3. Instance-Specific Mapping .................................11
6.4. SIP to XMPP ...............................................11
6.5. XMPP to SIP ...............................................12
7. Error Mapping ..................................................14
7.1. XMPP to SIP ...............................................15
7.2. SIP to XMPP ...............................................17
8. Security Considerations ........................................20
9. References .....................................................21
9.1. Normative References ......................................21
9.2. Informative References ....................................22
Appendix A. Acknowledgements ......................................24
The IETF has worked on two signaling technologies that can be used for multimedia session negotiation, instant messaging, presence, capabilities discovery, notifications, and other functions served by real-time communication applications:
IETF研究了两种信令技术，可用于多媒体会话协商、即时消息、状态、功能发现、通知和实时通信应用程序提供的其他功能：
o The Session Initiation Protocol [RFC3261], along with various SIP extensions developed within the SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group.
o 会话启动协议[RFC3261]，以及SIP中开发的各种SIP扩展，用于即时消息传递和状态利用扩展（SIMPLE）工作组。
o The Extensible Messaging and Presence Protocol [RFC6120], along with various XMPP extensions developed by the IETF as well as by the XMPP Standards Foundation (XSF).
o 可扩展消息和存在协议[RCF6120 ]，以及由IETF开发的各种XMPP扩展以及XMPP标准基金会（XSF）。
Because these technologies are widely deployed, it is important to clearly define mappings between them for the sake of interworking. This document provides the basis for a series of SIP-XMPP interworking specifications by defining architectural assumptions, address translation methods, and error condition mappings. Other documents in this series define mappings for presence, messaging, and media sessions.
由于这些技术被广泛部署，因此为了互通，必须明确定义它们之间的映射。本文档通过定义体系结构假设、地址转换方法和错误条件映射，为一系列SIP-XMPP互通规范提供了基础。本系列中的其他文档定义了状态、消息和媒体会话的映射。
The guidelines in this series are based on implementation and deployment experience, and they describe techniques that have worked well in the field with existing systems. In practice, interworking has been achieved through direct protocol mappings, not through mapping to an abstract model as described in, for example, [RFC3859] and [RFC3860]. Therefore, this series describes the direct mapping approach in enough detail for developers of new implementations to achieve practical interworking between SIP systems and XMPP systems.
本系列中的指导原则基于实现和部署经验，它们描述了在现有系统领域工作良好的技术。实际上，互通是通过直接协议映射实现的，而不是通过映射到抽象模型实现的，如[RFC3859]和[RFC3860]中所述。因此，本系列足够详细地描述了直接映射方法，以供新实现的开发人员实现SIP系统和XMPP系统之间的实际交互。
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 would like to enable communication from that existing system to systems based on the other technology (e.g., XMPP). With regard to this document, we assume that readers are familiar with the core specifications for both SIP and XMPP; with regard to the other documents in this series, we assume that readers are familiar with this document as well as with the relevant SIP and XMPP extensions.
本系列中的文档旨在供软件开发人员使用，这些软件开发人员拥有基于其中一种技术（如SIP）的现有系统，并且希望能够实现从该现有系统到基于其他技术（如XMPP）的系统的通信。关于本文档，我们假设读者熟悉SIP和XMPP的核心规范；关于本系列中的其他文档，我们假设读者熟悉本文档以及相关的SIP和XMPP扩展。
A number of terms used here are explained in [RFC3261] and [RFC6120].
[RFC3261]和[RFC6120]中解释了此处使用的许多术语。
Several examples use the "XML Notation" from the Internationalized Resource Identifier (IRI) specification [RFC3987] to represent Unicode characters outside the ASCII range (e.g., the string "ue" stands for the Unicode character [UNICODE] LATIN SMALL LETTER U WITH DIAERESIS, U+00FC).
一些示例使用国际化资源标识符（IRI）规范[RFC3987]中的“XML表示法”来表示ASCII范围之外的Unicode字符（例如，字符串“ue”代表Unicode字符[Unicode]拉丁小写字母U，带分音符，U+00FC）。
In architectural diagrams, SIP traffic is shown using arrows such as
"***>", whereas XMPP traffic is shown using arrows such as "...>".
In architectural diagrams, SIP traffic is shown using arrows such as
"***>", whereas XMPP traffic is shown using arrows such as "...>".
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]中的说明进行解释。
Protocol translation between SIP and XMPP could occur in a number of different entities, depending on the architecture of real-time communication deployments. For example, protocol translation could occur within a multiprotocol server (which uses protocol-specific connection managers to initiate traffic to and accept traffic from clients or other servers natively using SIP/SIMPLE, XMPP, etc.), within a multiprotocol client (which enables a user to establish connections natively with various servers using SIP/SIMPLE, XMPP, etc.), or within a gateway that acts as a dedicated protocol translator (which takes one protocol as input and provides another protocol as output).
SIP和XMPP之间的协议转换可能发生在许多不同的实体中，具体取决于实时通信部署的体系结构。例如，协议转换可能发生在多协议客户端内的多协议服务器（使用特定于协议的连接管理器启动到客户端或其他服务器的流量，并接受来自客户端或其他服务器的流量，这些服务器本机使用SIP/SIMPLE、XMPP等）（使用户能够使用SIP/SIMPLE、XMPP等与各种服务器建立本地连接），或在充当专用协议转换器（将一个协议作为输入，并提供另一个协议作为输出）的网关内建立连接。
This document assumes that the protocol translation will occur within a gateway, specifically:
本文档假设协议转换将在网关内进行，具体如下：
o When information needs to flow from an XMPP-based system to a SIP-based system, protocol translation will occur within an "XMPP-to-SIP gateway" that translates XMPP syntax and semantics on behalf of an "XMPP server" (together, these two logical functions comprise an "XMPP service").
o 当信息需要从基于XMPP的系统流向基于SIP的系统时，协议转换将在“XMPP到SIP网关”中进行，该网关代表“XMPP服务器”转换XMPP语法和语义（这两个逻辑功能一起构成“XMPP服务”）。
o When information needs to flow from a SIP-based system to an XMPP-based system, protocol translation will occur within a "SIP-to-XMPP gateway" that translates SIP syntax and semantics on behalf of a "SIP server" (together, these two logical functions comprise a "SIP service").
o 当信息需要从基于SIP的系统流向基于XMPP的系统时，协议转换将在“SIP到XMPP网关”中发生，该网关代表“SIP服务器”转换SIP语法和语义（这两个逻辑功能一起构成“SIP服务”）。
Naturally, these logical functions could occur in one and the same actual entity; we differentiate between them mainly for explanatory purposes (although, in practice, such gateways are indeed fairly common).
当然，这些逻辑功能可能发生在同一个实体中；我们区分它们主要是为了解释（尽管在实践中，这样的网关确实相当常见）。
Note: This assumption is not meant to discourage protocol translation within multiprotocol clients or servers; instead, this assumption is followed mainly to clarify the discussion and examples so that the protocol translation principles can be more easily understood and can be applied by client and server implementors with appropriate modifications to the examples and terminology.
注意：这一假设并不意味着阻止多协议客户端或服务器内的协议转换；相反，遵循此假设主要是为了澄清讨论和示例，以便协议翻译原则更容易理解，并且可以由客户机和服务器实现人员在对示例和术语进行适当修改后应用。
This document assumes that a gateway will translate directly from one protocol to the other. For the sake of the examples, we further assume that protocol translation will occur within a gateway in the source domain, so that information generated by the user of an XMPP system will be translated by a gateway within the trust domain of that XMPP system, and information generated by the user of a SIP system will be translated by a gateway within the trust domain of that SIP system. However, nothing in this document ought to be taken as recommending against protocol translation at the destination domain.
本文档假设网关将直接从一个协议转换到另一个协议。为了示例，我们进一步假设协议转换将发生在源域中的网关内，因此XMPP系统的用户生成的信息将被该XMPP系统的信任域中的网关转换，并且由SIP系统的用户生成的信息将由该SIP系统的信任域内的网关翻译。然而，本文件中的任何内容都不应被视为反对目标域的协议翻译。
An architectural diagram for a possible gateway deployment is shown below, where the entities have the following significance and the "#" character is used to show the boundary of a trust domain:
下面显示了可能的网关部署的体系结构图，其中实体具有以下意义，“#”字符用于显示信任域的边界：
o romeo@example.net -- a SIP user.
o romeo@example.net--SIP用户。
o example.net -- a SIP server with an associated gateway ("S2X GW") to XMPP.
o net——一个SIP服务器，带有到XMPP的关联网关（“S2X GW”）。
o juliet@example.com -- an XMPP user.
o juliet@example.com--一个XMPP用户。
o example.com -- an XMPP server with an associated gateway ("X2S GW") to SIP.
o example.com——一个XMPP服务器，它具有到SIP的关联网关（“X2S GW”）。
#########################################################
# #
# +-----+ #
# | S2X | #
# +-------------+ GW |<...........>+-------------+ #
# | SIP Server +-----+ | XMPP Server | #
# | example.net | +-----+ example.com | #
# +-------------+<***********>| X2S +-------------+ #
# * | GW | : #
# * +-----+ : #
# * : #
# romeo@example.net juliet@example.com #
# #
#########################################################
#########################################################
# #
# +-----+ #
# | S2X | #
# +-------------+ GW |<...........>+-------------+ #
# | SIP Server +-----+ | XMPP Server | #
# | example.net | +-----+ example.com | #
# +-------------+<***********>| X2S +-------------+ #
# * | GW | : #
# * +-----+ : #
# * : #
# romeo@example.net juliet@example.com #
# #
#########################################################
Legend:
XMPP = ... or :
SIP = *
Legend:
XMPP = ... or :
SIP = *
Figure 1: Possible Gateway Deployment Architecture
图1：可能的网关部署架构
Note that bidirectional communication between the SIP server and the XMPP server can be established over either SIP or XMPP. If the XMPP user initiates the interaction, then the XMPP server would invoke its XMPP-to-SIP gateway; thus, the communication would occur over SIP. If the SIP user initiates the interaction, then the SIP server would invoke its SIP-to-XMPP gateway; thus, the communication would occur over XMPP.
注意，SIP服务器和XMPP服务器之间的双向通信可以通过SIP或XMPP建立。如果XMPP用户发起交互，则XMPP服务器将调用其XMPP到SIP网关；因此，通信将通过SIP进行。如果SIP用户发起交互，则SIP服务器将调用其SIP到XMPP网关；因此，通信将通过XMPP进行。
The architectural assumptions underlying this document imply that communication between a SIP system and an XMPP system will take place using interdomain federation: the SIP server invokes its associated SIP-to-XMPP gateway, which communicates with the XMPP server using native XMPP server-to-server methods; similarly, the XMPP server invokes its associated XMPP-to-SIP gateway, which communicates with the SIP server using native SIP server-to-server methods.
本文档所依据的架构假设意味着SIP系统和XMPP系统之间的通信将使用域间联合进行：SIP服务器调用其关联的SIP到XMPP网关，该网关使用本机XMPP服务器到服务器方法与XMPP服务器通信；类似地，XMPP服务器调用其关联的XMPP-to-SIP网关，该网关使用本机SIP-server-to-server方法与SIP服务器通信。
When an XMPP server receives an XMPP stanza whose 'to' address specifies or includes a domain other than the domain of the XMPP server, it needs to determine whether the destination domain communicates via XMPP or SIP. To do so, it performs one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120]. If the response returns a hostname, the XMPP server can attempt XMPP communication. If not, it can determine the appropriate location for SIP communication at the target domain using the procedures specified in [RFC3263].
当XMPP服务器接收到一个XMPP节，该节的“to”地址指定或包含除XMPP服务器域以外的域时，它需要确定目标域是通过XMPP还是SIP进行通信。为此，它对[RFC6120]中指定的“_xmpp-server”记录执行一个或多个DNS SRV查找[RFC2782]。如果响应返回主机名，XMPP服务器可以尝试XMPP通信。如果没有，它可以使用[RFC3263]中指定的程序确定目标域上SIP通信的适当位置。
Similarly, when a SIP server receives a SIP message whose Request-URI or To header specifies or includes a domain other than the domain of the SIP server, it needs to determine whether the destination domain communicates via SIP or XMPP. To do so, it uses the procedures specified in [RFC3263]. If that response returns a hostname, the SIP server can attempt SIP communication. If not, it can perform one or more DNS SRV lookups [RFC2782] for "_xmpp-server" records as specified in [RFC6120].
类似地，当SIP服务器接收到其请求URI或To报头指定或包括SIP服务器域以外的域的SIP消息时，它需要确定目标域是否通过SIP或XMPP进行通信。为此，它使用[RFC3263]中指定的程序。如果该响应返回主机名，则SIP服务器可以尝试SIP通信。如果没有，它可以对[RFC6120]中指定的“_xmpp-server”记录执行一个或多个DNS SRV查找[RFC2782]。
In both cases, the server in question might have previously determined that the foreign domain communicates via SIP or XMPP, in which case it would not need to perform the relevant DNS lookups. The caching of such information is a matter of implementation and local service policy and is therefore out of scope for this document.
在这两种情况下，所讨论的服务器可能先前已确定外域通过SIP或XMPP进行通信，在这种情况下，它将不需要执行相关的DNS查找。缓存此类信息是实现和本地服务策略的问题，因此不在本文档的范围内。
Existing SIP and XMPP server implementations do not typically include the ability to communicate using the other technology (XMPP for SIP implementations, SIP for XMPP implementations). One common architectural pattern is to associate a gateway with the core server implementation (e.g., in XMPP such a gateway might be called a "connection manager"). How exactly such a gateway interacts with the core server to complete tasks such as address lookups and communication with systems that use the other technology is a matter of implementation (e.g., the gateway might be an add-on module that is trusted by the core server to act as a fallback delivery mechanism if the remote domain does not support the server's native communication technology).
现有的SIP和XMPP服务器实现通常不包括使用其他技术进行通信的能力（XMPP用于SIP实现，SIP用于XMPP实现）。一种常见的架构模式是将网关与核心服务器实现相关联（例如，在XMPP中，这样的网关可以称为“连接管理器”）。这样一个网关如何与核心服务器交互以完成地址查找和与使用其他技术的系统通信等任务是一个实现问题（例如，网关可能是核心服务器信任的附加模块，如果远程域不支持服务器的本机通信技术，它可以充当回退交付机制）。
Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from SIP to XMPP will need to support TCP as the underlying transport protocol. By contrast, as specified in [RFC3261], either TCP or UDP can be used as the underlying transport for SIP messages, and a given SIP deployment might support only UDP; therefore, a gateway from XMPP to SIP might need to communicate with a SIP server using either TCP or UDP.
因为[RFC6120]指定了XMPP到TCP的绑定，所以从SIP到XMPP的网关需要支持TCP作为底层传输协议。相反，如[RFC3261]中所述，TCP或UDP都可以用作SIP消息的底层传输，并且给定的SIP部署可能只支持UDP；因此，从XMPP到SIP的网关可能需要使用TCP或UDP与SIP服务器通信。
The basic SIP address format is a 'sip' or 'sips' URI as specified in [RFC3261]. When a SIP entity supports extensions for instant messaging it might be identified by an 'im' URI as specified in the Common Profile for Instant Messaging [RFC3860] (see [RFC3428]), and when a SIP entity supports extensions for presence it might be
基本SIP地址格式是[RFC3261]中指定的“SIP”或“sips”URI。当SIP实体支持即时消息扩展时，它可能由即时消息通用配置文件[RFC3860]（请参阅[RFC3428]）中指定的“im”URI标识，当SIP实体支持存在扩展时，它可能是
identified by a 'pres' URI as specified in the Common Profile for Presence [RFC3859] (see [RFC3856]). SIP entities typically also support the 'tel' URI scheme [RFC3966] and might support other URI schemes as well.
由公共配置文件[RFC3859]（参见[RFC3856]）中指定的“pres”URI标识。SIP实体通常还支持“tel”URI方案[RFC3966]，也可能支持其他URI方案。
The XMPP address format is specified in [RFC6122] (although note that XMPP URIs [RFC5122] are not used natively on the XMPP network); in addition, [RFC6121] encourages instant messaging and presence applications of XMPP to also support 'im' and 'pres' URIs as specified in [RFC3860] and [RFC3859], respectively, although such support might simply involve leaving resolution of such addresses up to an XMPP server.
XMPP地址格式在[RFC6122]中指定（尽管注意XMPP-uri[RFC5122]不是在XMPP网络上本机使用的）；此外，[RFC6121]鼓励XMPP的即时消息和状态应用程序也支持[RFC3860]和[RFC3859]中分别指定的“im”和“pres”URI，尽管这种支持可能只涉及将此类地址的解析留给XMPP服务器。
In this document we primarily describe mappings for addresses of the form <user@domain>; however, we also provide guidelines for mapping the addresses of specific user agent instances, which take the form of Globally Routable User Agent URIs (GRUUs) in SIP and "resourceparts" in XMPP. Mapping of protocol-specific identifiers (such as telephone numbers) is out of scope for this specification. In addition, we have ruled the mapping of domain names as out of scope for now, since that is a matter for the Domain Name System; specifically, the issue for interworking between SIP and XMPP relates to the translation of fully internationalized domain names (IDNs) into non-internationalized domain names (IDNs are not allowed in the SIP address format but are allowed in the XMPP address via Internationalized Domain Names in Applications; see [RFC6122] and [XMPP-ADDRESS-FORMAT]). Therefore, in the following sections we focus primarily on the local part of an address (these are called variously "usernames", "instant inboxes", "presentities", and "localparts" in the protocols at issue), secondarily on the instance-specific part of an address, and not at all on the domain-name part of an address.
在本文档中，我们主要描述表单地址的映射<user@domain>; 但是，我们还提供了映射特定用户代理实例地址的指南，这些实例在SIP中采用全局可路由用户代理URI（GROUS）的形式，在XMPP中采用“resourceparts”的形式。协议特定标识符（如电话号码）的映射超出本规范的范围。此外，我们已经将域名映射排除在范围之外，因为这是域名系统的问题；具体而言，SIP和XMPP之间的互通问题涉及将完全国际化域名（IDN）转换为非国际化域名（SIP地址格式中不允许IDN，但XMPP地址中允许IDN通过应用程序中的国际化域名；请参阅[RFC6122]和[XMPP-ADDRESS-FORMAT]）。因此，在以下章节中，我们主要关注地址的本地部分（在相关协议中，这些部分被称为各种“用户名”、“即时收件箱”、“存在实体”和“本地部分”），其次是地址的实例特定部分，而不是地址的域名部分。
The 'sip'/'sips', 'im'/'pres', and XMPP address schemes allow different sets of characters (although all three allow alphanumeric characters and disallow both spaces and control characters). In some cases, characters allowed in one scheme are disallowed in others; these characters need to be mapped appropriately in order to ensure interworking across systems.
“sip”/“sips”、“im”/“pres”和XMPP地址方案允许使用不同的字符集（尽管这三种方案都允许使用字母数字字符，并且不允许使用空格和控制字符）。在某些情况下，一个方案中允许的字符在其他方案中是不允许的；这些字符需要适当映射，以确保跨系统的互通。
The local part of a 'sip'/'sips' URI inherits from the "userinfo" rule in [RFC3986] with several changes; here we discuss the SIP "user" rule only (using ABNF as defined in [RFC5234]):
‘sip’/‘sips’URI的本地部分继承自[RFC3986]中的“userinfo”规则，并进行了一些更改；这里我们只讨论SIP“用户”规则（使用[RFC5234]中定义的ABNF）：
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
user = 1*( unreserved / escaped / user-unreserved )
user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
unreserved = alphanum / mark
mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"
Here we make the simplifying assumption that the local part of an 'im'/'pres' URI inherits from the "dot-atom-text" rule in [RFC5322] rather than the more complicated "local-part" rule:
在这里，我们做出简化假设，即'im'/'pres'URI的本地部分继承自[RFC5322]中的“点原子文本”规则，而不是更复杂的“本地部分”规则：
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"
dot-atom-text = 1*atext *("." 1*atext)
atext = ALPHA / DIGIT / ; Any character except
"!" / "#" / "$" / ; controls, SP, and
"%" / "&" / "'" / ; specials. Used for
"*" / "+" / "-" / ; atoms.
"/" / "=" / "?" /
"^" / "_" / "`" /
"{" / "|" / "}" /
"~"
The local part of an XMPP address allows any ASCII character except space, controls, and the " & ' / : < > @ characters.
XMPP地址的本地部分允许除空格、控件和“&”/：<>@字符以外的任何ASCII字符。
To summarize the foregoing information, the following table lists the allowed and disallowed characters in the local part of identifiers for each protocol (aside from the alphanumeric, space, and control characters), in order by hexadecimal character number (where each "A" row shows the allowed characters and each "D" row shows the disallowed characters).
为了总结上述信息，下表列出了每个协议标识符的本地部分中允许和不允许的字符（字母数字、空格和控制字符除外），按十六进制字符数排序（其中每个“A”行显示允许的字符，每个“D”行显示不允许的字符）。
+---+----------------------------------+
| SIP/SIPS CHARACTERS |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| IM/PRES CHARACTERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| XMPP CHARACTERS |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+
+---+----------------------------------+
| SIP/SIPS CHARACTERS |
+---+----------------------------------+
| A | ! $ &'()*+,-./ ; = ? _ ~ |
| D | "# % : < > @[\]^ `{|} |
+---+----------------------------------+
| IM/PRES CHARACTERS |
+---+----------------------------------+
| A | ! #$%&' *+ - / = ? ^_`{|}~ |
| D | " () , . :;< > @[\] |
+---+----------------------------------+
| XMPP CHARACTERS |
+---+----------------------------------+
| A | ! #$% ()*+,-. ; = ? [\]^_`{|}~ |
| D | " &' /: < > @ |
+---+----------------------------------+
Table 1: Allowed and Disallowed Characters
表1：允许和不允许的字符
When transforming the local part of an address from one address format to another, an application SHOULD proceed as follows:
将地址的本地部分从一种地址格式转换为另一种地址格式时，应用程序应按以下步骤进行：
1. Unescape any escaped characters in the source address (e.g., from SIP to XMPP unescape "%23" to "#" per [RFC3986], and from XMPP to SIP unescape "\27" to "'" per [XEP-0106]).
1. 取消源地址中的任何转义字符的转义（例如，根据[RFC3986]从SIP到XMPP Unescape“%23”到“#”，根据[XEP-0106]从XMPP到SIP Unescape“\27”到“”）。
2. Leave unmodified any characters that are allowed in the destination scheme.
2. 保留未修改的目标方案中允许的任何字符。
3. Escape any characters that are allowed in the source scheme but reserved in the destination scheme, as escaping is defined for the destination scheme. In particular:
3. 转义源方案中允许但在目标方案中保留的任何字符，因为转义是为目标方案定义的。特别地：
* Where the destination scheme is a URI (i.e., an 'im', 'pres', 'sip', or 'sips' URI), each reserved character MUST be percent-encoded to "%hexhex" as specified in Section 2.5 of [RFC3986] (e.g., when transforming from XMPP to SIP, encode "#" as "%23").
* 如果目标方案是URI（即“im”、“pres”、“sip”或“sips”URI），则每个保留字符必须按照[RFC3986]第2.5节中的规定百分比编码为“%hexhex”（例如，从XMPP转换为sip时，将“#”编码为“%23”）。
* Where the destination scheme is a native XMPP address, each reserved character MUST be encoded to "\hexhex" as specified in [XEP-0106] (e.g., when transforming from SIP to XMPP, encode "'" as "\27").
* 如果目标方案是本机XMPP地址，则必须按照[XEP-0106]中的规定将每个保留字符编码为“\hexhex”（例如，从SIP转换为XMPP时，将“'”编码为“\27”）。
The meaning of a resourcepart in XMPP (i.e., the portion of a Jabber ID (JID) after the slash character, such as "foo" in "user@example.com/foo") matches that of a Globally Routable User Agent URI (GRUU) in SIP [RFC5627]. In both cases, these constructs identify a particular device associated with the bare JID ("localpart@domainpart") of an XMPP entity or with the Address of Record (AOR) of a SIP entity. Therefore, it is reasonable to map the value of a "gr" URI parameter to an XMPP resourcepart and vice versa.
XMPP中resourcepart的含义（即，斜杠字符后面的Jabber ID（JID）部分，如中的“foo”user@example.com/foo”）匹配SIP[RFC5627]中全局可路由用户代理URI（GRUU）的URI。在这两种情况下，这些构造都标识与裸JID关联的特定设备（“localpart@domainpart）或具有SIP实体的记录地址（AOR）。因此，将“gr”URI参数的值映射到XMPP resourcepart是合理的，反之亦然。
The mapping described here does not apply to temporary GRUUs -- only to GRUUs associated with an Address of Record.
这里描述的映射不适用于临时GRUs——只适用于与记录地址关联的GRUs。
The "gr" URI parameter in SIP can contain only characters from the ASCII range (although characters outside the ASCII range can be percent-encoded in accordance with [RFC3986]), whereas an XMPP resourcepart can contain nearly any Unicode character [UNICODE]. Therefore, Unicode characters outside the ASCII range need to be mapped to characters in the ASCII range, as described below.
SIP中的“gr”URI参数只能包含ASCII范围内的字符（尽管ASCII范围外的字符可以按照[RFC3986]进行百分比编码），而XMPP resourcepart几乎可以包含任何Unicode字符[Unicode]。因此，ASCII范围之外的Unicode字符需要映射到ASCII范围内的字符，如下所述。
The following is a high-level algorithm for mapping a 'sip', 'sips', 'im', or 'pres' URI to an XMPP address:
以下是将“sip”、“sips”、“im”或“pres”URI映射到XMPP地址的高级算法：
1. Remove URI scheme.
1. 删除URI方案。
2. Split at the first '@' character into local part and hostname (mapping the latter is out of scope).
2. 在第一个“@”字符处拆分为本地部分和主机名（映射后者超出范围）。
3. Translate any percent-encoded strings ("%hexhex") to percent-decoded octets.
3. 将任何百分比编码字符串（“%hexhex”）转换为百分比解码八位字节。
4. Treat result as a UTF-8 string.
4. 将结果视为UTF-8字符串。
5. Translate "&" to "\26", "'" to "\27", and "/" to "\2f", respectively in order to properly handle the characters disallowed in XMPP addresses but allowed in 'sip'/'sips' URIs and 'im'/'pres' URIs as shown in Table 1 above (this is consistent with [XEP-0106]).
5. 将“&”分别翻译为“\26”、“'”翻译为“\27”和“/”翻译为“\2f”，以便正确处理XMPP地址中不允许的字符，但在“sip”/“sips”URI和“im”/“pres”URI中允许的字符，如上表1所示（这与[XEP-0106]一致）。
6. Apply Nodeprep profile of stringprep [RFC3454] or its replacement (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization (OPTIONAL).
6. 应用stringprep[RFC3454]的Nodeprep配置文件或其替代文件（参见[RFC6122]和[XMPP-ADDRESS-FORMAT]）进行规范化（可选）。
7. Recombine local part with mapped hostname to form a bare JID ("localpart@domainpart").
7. 将本地部件与映射的主机名重新组合以形成裸JID（“localpart@domainpart").
8. If the (SIP) address contained a "gr" URI parameter, append a slash character "/" and the "gr" value to the bare JID to form a full JID ("localpart@domainpart/resourcepart").
8. 如果（SIP）地址包含一个“gr”URI参数，则在裸JID中附加一个斜杠字符“/”和“gr”值以形成完整的JID（“localpart@domainpart/资源部分”）。
Several examples follow, illustrating steps 3, 5, and 8 described above.
下面是几个示例，说明了上述步骤3、5和8。
+----------------------------+--------------------------+
| SIP URI | XMPP Address |
+----------------------------+--------------------------+
| sip:f%C3%BC@sip.example | fü@sip.example |
+----------------------------+--------------------------+
| sip:o'malley@sip.example | o\27malley@sip.example |
+----------------------------+--------------------------+
| sip:foo@sip.example;gr=bar | foo@sip.example/bar |
+----------------------------+--------------------------+
+----------------------------+--------------------------+
| SIP URI | XMPP Address |
+----------------------------+--------------------------+
| sip:f%C3%BC@sip.example | fü@sip.example |
+----------------------------+--------------------------+
| sip:o'malley@sip.example | o\27malley@sip.example |
+----------------------------+--------------------------+
| sip:foo@sip.example;gr=bar | foo@sip.example/bar |
+----------------------------+--------------------------+
In the first example, the string "%C3%BC" is a percent-encoded representation of the UTF-8-encoded Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC), whereas the string "ü" is the same character shown for documentation purposes using the XML Notation defined in [RFC3987] (in XMPP, it would be sent directly as a UTF-8-encoded Unicode character and not percent-encoded as in a SIP URI to comply with the URI syntax defined in [RFC3986]).
在第一个示例中，字符串“%C3%BC”是UTF-8编码的Unicode字符拉丁小写字母U的百分比编码表示形式，带有分音符（U+00FC），而字符串“ü；”是使用[RFC3987]中定义的XML表示法为文档目的显示的相同字符（在XMPP中，它将直接作为UTF-8编码的Unicode字符发送，而不是按照[RFC3986]中定义的URI语法在SIP URI中进行百分比编码）。
The following is a high-level algorithm for mapping an XMPP address to a 'sip', 'sips', 'im', or 'pres' URI:
以下是将XMPP地址映射到“sip”、“sips”、“im”或“pres”URI的高级算法：
1. Split XMPP address into localpart (mapping described in remaining steps), domainpart (hostname; mapping is out of scope), and resourcepart (specifier for particular device or connection, for which an OPTIONAL mapping is described below).
1. 将XMPP地址拆分为localpart（其余步骤中描述的映射）、domainpart（主机名；映射超出范围）和resourcepart（特定设备或连接的说明符，下面介绍了可选映射）。
2. Apply Nodeprep profile of stringprep [RFC3454] or its replacement (see [RFC6122] and [XMPP-ADDRESS-FORMAT]) for canonicalization of the XMPP localpart (OPTIONAL).
2. 应用stringprep[RFC3454]的Nodeprep配置文件或其替代文件（参见[RFC6122]和[XMPP-ADDRESS-FORMAT]）以规范化XMPP localpart（可选）。
3. Translate "\26" to "&", "\27" to "'", and "\2f" to "/", respectively (this is consistent with [XEP-0106]).
3. 分别将“\26”翻译为“&”、“\27”翻译为“'”、“\2f”翻译为“/”（这与[XEP-0106]一致）。
4. Determine if the foreign domain supports 'im' and 'pres' URIs (discovered via [RFC2782] lookup as specified in [RFC6121]), else assume that the foreign domain supports 'sip'/'sips' URIs.
4. 确定外域是否支持“im”和“pres”URI（通过[RFC6121]中指定的[RFC2782]查找发现），否则假设外域支持“sip”/“sips”URI。
5. If converting into 'im' or 'pres' URI, for each byte, if the byte is in the set (),.;[\] or is a UTF-8 character outside the ASCII range, then percent-encode that byte to "%hexhex" format. If converting into 'sip' or 'sips' URI, for each byte, if the byte is in the set #%[\]^`{|} or is a UTF-8 character outside the ASCII range, then percent-encode that byte to "%hexhex" format.
5. 如果转换为'im'或'pres'URI，则对于每个字节，如果该字节在集合（）中，则为，。；[\]或是ASCII范围之外的UTF-8字符，然后将该字节百分比编码为“%hexhex”格式。如果转换为“sip”或“sips”URI，对于每个字节，如果字节在集合#%[\]^`{124;}中或是ASCII范围之外的UTF-8字符，则百分比将该字节编码为“%hexhex”格式。
6. Combine resulting local part with mapped hostname to form local@domain address.
6. 将生成的本地部件与映射的主机名组合在一起形成local@domain住址
7. Prepend with the string 'im:' (for XMPP <message/> stanzas) or 'pres:' (for XMPP <presence/> stanzas) if foreign domain supports these, else prepend with the string 'sip:' or 'sips:' according to local service policy.
7. 如果外域支持这些，则使用字符串“im:”（对于XMPP<message/>节）或“pres:”（对于XMPP<presence/>节）作为前缀，否则根据本地服务策略使用字符串“sip:”或“sips:”作为前缀。
8. If the XMPP address included a resourcepart and the destination URI scheme is 'sip' or 'sips', optionally append the slash character '/' and then append the resourcepart (making sure to percent-encode any UTF-8 characters outside the ASCII range) as the "gr" URI parameter.
8. 如果XMPP地址包含resourcepart，且目标URI方案为“sip”或“sips”，则可以选择附加斜杠字符“/”，然后附加resourcepart（确保对ASCII范围之外的任何UTF-8字符进行百分比编码）作为“gr”URI参数。
Several examples follow, illustrating steps 3, 5, and 8 described above.
下面是几个示例，说明了上述步骤3、5和8。
+---------------------------+---------------------------------+
| XMPP Address | SIP URI |
+---------------------------+---------------------------------+
| m\26m@xmpp.example | sip:m&m@xmpp.example |
| tschüss@xmpp.example | sip:tsch%C3%BCss@xmpp.example |
| baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux |
+---------------------------+---------------------------------+
+---------------------------+---------------------------------+
| XMPP Address | SIP URI |
+---------------------------+---------------------------------+
| m\26m@xmpp.example | sip:m&m@xmpp.example |
| tschüss@xmpp.example | sip:tsch%C3%BCss@xmpp.example |
| baz@xmpp.example/qux | sip:baz@xmpp.example;gr=qux |
+---------------------------+---------------------------------+
As above, in the first example the string "ü" is the Unicode character LATIN SMALL LETTER U WITH DIAERESIS (U+00FC) shown for documentation purposes using the XML Notation defined in [RFC3987] (in XMPP, it would be sent directly as a UTF-8-encoded Unicode character and not percent-encoded, whereas the string "%C3%BC" is a percent-encoded representation of the same character.
如上所述，在第一个示例中，字符串“ü；”是Unicode字符拉丁文小写字母U，带分音符（U+00FC），用于使用[RFC3987]中定义的XML表示法编制文档（在XMPP中，它将直接作为UTF-8编码的Unicode字符发送，而不是百分比编码的字符串“%C3%BC”是同一字符的百分比编码表示形式。
Various differences between XMPP error conditions and SIP response codes make it hard to provide a comprehensive and consistent mapping between the protocols:
XMPP错误条件和SIP响应代码之间的各种差异使得很难在协议之间提供全面一致的映射：
o Whereas the set of XMPP error conditions is fixed in the core XMPP specification (and supplemented where needed by application-specific extensions), the set of SIP response codes is more open to change, as evidenced by the IANA registry of SIP response codes.
o 尽管XMPP错误条件集在核心XMPP规范中是固定的（并在需要时由特定于应用程序的扩展进行补充），但SIP响应代码集更容易更改，SIP响应代码的IANA注册证明了这一点。
o XMPP has defined fewer error conditions related to stanza handling (22 are defined in [RFC6120]) than SIP has defined response codes related to message handling (at the date of this writing, 71 SIP response codes are registered with IANA as defined in [RFC3261] and numerous SIP extensions).
o XMPP定义的与节处理相关的错误条件（22个在[RFC6120]中定义）少于SIP定义的与消息处理相关的响应代码（在本文撰写之日，[RFC3261]和众多SIP扩展中定义的71个SIP响应代码在IANA中注册）。
o In many cases, the SIP response codes are more specific than the XMPP error conditions (e.g., from an XMPP perspective the SIP codes "413 Request Entity Too Large" and "414 Request-URI Too Long" are simply two different types of response to the same bad request, and the SIP codes "415 Unsupported Media Type" and "416 Unsupported URI Scheme" are two different responses to a request that is not acceptable).
o 在许多情况下，SIP响应代码比XMPP错误条件更具体（例如，从XMPP的角度来看，SIP代码“413请求实体太大”和“414请求URI太长”只是对相同错误请求的两种不同类型的响应，SIP代码“415不支持的媒体类型”和“416不支持的URI方案”是对不可接受的请求的两个不同响应）。
o SIP differentiates between responses about a particular endpoint or resource (the 4xx series) and responses about a user, i.e., all of a user's endpoints or resources (the 6xx series). There is no such distinction in XMPP, since the same error condition can be returned in relation to the "bare JID" (localpart@domainpart) of a user or the "full JID" (localpart@domainpart/resourcepart) of a particular endpoint or resource, depending on the 'to' address of the original request.
o SIP区分关于特定端点或资源（4xx系列）的响应和关于用户（即，用户的所有端点或资源（6xx系列））的响应。XMPP中没有这种区别，因为可以返回与“裸JID”相关的相同错误条件(localpart@domainpart)用户或“完整JID”(localpart@domainpart/resourcepart），具体取决于原始请求的“收件人”地址。
As a result of these and other factors, the mapping of error conditions and response codes is more of an art than a science. This document provides suggested mappings, but implementations are free to deviate from these mappings if needed. Also, because no XMPP error conditions are equivalent to the provisional (1xx) and successful (2xx) response codes in SIP, this document suggests mappings only for the SIP redirection (3xx), request failure (4xx), server failure (5xx), and global failure (6xx) response code families.
由于这些和其他因素，错误条件和响应代码的映射更像是一门艺术，而不是一门科学。本文档提供了建议的映射，但如果需要，实现可以自由地偏离这些映射。此外，由于没有XMPP错误条件等同于SIP中的临时（1xx）和成功（2xx）响应代码，因此本文档建议仅映射SIP重定向（3xx）、请求失败（4xx）、服务器失败（5xx）和全局失败（6xx）响应代码族。
Supplementary information about SIP response codes can be expressed
in the "Reason-Phrase" in the Status-Line header, and detailed
information about XMPP error conditions can be expressed in the
<text/> child of the <error/> element. Although the semantics of
Supplementary information about SIP response codes can be expressed
in the "Reason-Phrase" in the Status-Line header, and detailed
information about XMPP error conditions can be expressed in the
<text/> child of the <error/> element. Although the semantics of
these constructs are specified in a slightly different way, it is reasonable for a gateway to map these constructs to each other if they are found in a SIP response or XMPP error stanza.
这些构造是以稍微不同的方式指定的，如果在SIP响应或XMPP错误节中找到这些构造，网关将它们相互映射是合理的。
The mapping of specific XMPP error conditions to SIP response codes SHOULD be as described in the following table.
特定XMPP错误条件到SIP响应代码的映射应如下表所述。
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
+------------------------------+---------------------+
| <conflict/> | 400 |
+------------------------------+---------------------+
| <feature-not-implemented/> | 405 or 501 (1) |
+------------------------------+---------------------+
| <forbidden/> | 403 or 603 (2) |
+------------------------------+---------------------+
| <gone/> | 301 or 410 (3) |
+------------------------------+---------------------+
| <internal-server-error/> | 500 |
+------------------------------+---------------------+
| <item-not-found/> | 404 or 604 (2) |
+------------------------------+---------------------+
| <jid-malformed/> | 400 |
+------------------------------+---------------------+
| <not-acceptable/> | 406 or 606 (2) |
+------------------------------+---------------------+
| <not-allowed/> | 403 |
+------------------------------+---------------------+
| <not-authorized/> | 401 |
+------------------------------+---------------------+
| <policy-violation/> | 403 |
+------------------------------+---------------------+
| <recipient-unavailable/> | 480 or 600 (2) |
+------------------------------+---------------------+
| <redirect/> | 302 |
+------------------------------+---------------------+
| <registration-required/> | 407 |
+------------------------------+---------------------+
| <remote-server-not-found/> | 404 or 408 (4) |
+------------------------------+---------------------+
| <remote-server-timeout/> | 408 |
+------------------------------+---------------------+
+------------------------------+---------------------+
| XMPP Error Condition | SIP Response Code |
+------------------------------+---------------------+
| <bad-request/> | 400 |
+------------------------------+---------------------+
| <conflict/> | 400 |
+------------------------------+---------------------+
| <feature-not-implemented/> | 405 or 501 (1) |
+------------------------------+---------------------+
| <forbidden/> | 403 or 603 (2) |
+------------------------------+---------------------+
| <gone/> | 301 or 410 (3) |
+------------------------------+---------------------+
| <internal-server-error/> | 500 |
+------------------------------+---------------------+
| <item-not-found/> | 404 or 604 (2) |
+------------------------------+---------------------+
| <jid-malformed/> | 400 |
+------------------------------+---------------------+
| <not-acceptable/> | 406 or 606 (2) |
+------------------------------+---------------------+
| <not-allowed/> | 403 |
+------------------------------+---------------------+
| <not-authorized/> | 401 |
+------------------------------+---------------------+
| <policy-violation/> | 403 |
+------------------------------+---------------------+
| <recipient-unavailable/> | 480 or 600 (2) |
+------------------------------+---------------------+
| <redirect/> | 302 |
+------------------------------+---------------------+
| <registration-required/> | 407 |
+------------------------------+---------------------+
| <remote-server-not-found/> | 404 or 408 (4) |
+------------------------------+---------------------+
| <remote-server-timeout/> | 408 |
+------------------------------+---------------------+
+------------------------------+---------------------+
| <resource-constraint/> | 500 |
+------------------------------+---------------------+
| <service-unavailable/> | see note (5) below |
+------------------------------+---------------------+
| <subscription-required/> | 400 |
+------------------------------+---------------------+
| <undefined-condition/> | 400 |
+------------------------------+---------------------+
| <unexpected-request/> | 491 or 400 |
+------------------------------+---------------------+
+------------------------------+---------------------+
| <resource-constraint/> | 500 |
+------------------------------+---------------------+
| <service-unavailable/> | see note (5) below |
+------------------------------+---------------------+
| <subscription-required/> | 400 |
+------------------------------+---------------------+
| <undefined-condition/> | 400 |
+------------------------------+---------------------+
| <unexpected-request/> | 491 or 400 |
+------------------------------+---------------------+
Table 2: Mapping of XMPP Error Conditions to SIP Response Codes
表2:XMPP错误条件到SIP响应代码的映射
(1) If the error relates to a "full JID" (localpart@domainpart/ resourcepart), the SIP 405 response code is RECOMMENDED. If the error relates to a "bare JID" (localpart@domainpart), the SIP 501 response code is RECOMMENDED.
(1) 如果错误与“完整JID”相关(localpart@domainpart/resourcepart），建议使用SIP 405响应代码。如果错误与“裸JID”相关(localpart@domainpart)，建议使用SIP 501响应代码。
(2) If the error relates to a "full JID" (localpart@domainpart/ resourcepart), the SIP response code from the 4xx series is RECOMMENDED. If the error relates to a "bare JID" (localpart@domainpart), the SIP response code from the 6xx series is RECOMMENDED.
(2) 如果错误与“完整JID”相关(localpart@domainpart/resourcepart），建议使用4xx系列的SIP响应代码。如果错误与“裸JID”相关(localpart@domainpart)，建议使用6xx系列的SIP响应代码。
(3) If the <gone/> element includes XML character data specifying the new address, the error MUST be mapped to SIP 301; if not, it MUST be mapped to SIP 410.
(3) 如果<gone/>元素包含指定新地址的XML字符数据，则必须将错误映射到SIP 301；如果没有，则必须将其映射到SIP 410。
(4) The XMPP <remote-server-not-found/> error can mean that the remote server either (a) does not exist or (b) cannot be resolved. SIP has two different response codes here: 404 to cover (a) and 408 to cover (b).
(4) XMPP<remote server not found/>错误可能意味着远程服务器（a）不存在或（b）无法解析。SIP在这里有两个不同的响应代码：404覆盖（a）和408覆盖（b）。
(5) The XMPP <service-unavailable/> error condition is widely used to inform the requesting entity that the intended recipient does not support the relevant feature, to signal that a server cannot perform the requested service either generally or in relation to a particular user, and to avoid disclosing whether a given account exists at all. This is quite different from the semantics of the SIP 503 Service Unavailable response code, which is used to signal that communication with a server is impossible (e.g., even if the XMPP <service-unavailable/> error condition is returned in relation to a specific user, the SIP 503 response code will be interpreted as applying to all future requests to this server, not just requests for the specific user). Therefore, mapping the XMPP <service-unavailable/> error condition to the SIP 503 Service Unavailable response code is
(5) XMPP<service unavailable/>错误条件被广泛用于通知请求实体预期接收者不支持相关功能，表示服务器无法执行请求的服务，无论是一般的还是与特定用户相关的服务，并避免披露给定帐户是否存在。这与sip503服务不可用响应代码的语义大不相同，sip503服务不可用响应代码用于表示无法与服务器通信（例如，即使返回与特定用户相关的XMPP<service unavailable/>错误条件，SIP 503响应代码也将被解释为应用于将来对该服务器的所有请求，而不仅仅是对特定用户的请求）因此，将XMPP<service unavailable/>错误条件映射到SIP 503 service unavailable响应代码是不正确的
NOT RECOMMENDED. Although no precise mapping is available, the SIP 403 Forbidden and 405 Method Not Allowed response codes are closest in meaning to the XMPP <service-unavailable/> error condition.
不推荐。尽管没有精确的映射可用，但SIP 403禁止和405方法不允许响应代码在意义上与XMPP<service unavailable/>错误条件最接近。
The mapping of SIP response codes to XMPP error conditions SHOULD be as described in the following table. If a gateway encounters a SIP response code that is not listed below, it SHOULD map a 3xx-series code to <redirect/>, a 4xx-series code to <bad-request/>, a 5xx-series code to <internal-server-error>, and a 6xx-series code to <recipient-unavailable/>.
SIP响应代码到XMPP错误条件的映射应如下表所述。如果网关遇到以下未列出的SIP响应代码，则应将3xx系列代码映射到<redirect/>，将4xx系列代码映射到<bad request/>，将5xx系列代码映射到<internal server error>，将6xx系列代码映射到<recipient available/>。
+---------------------+---------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+---------------------------------+
| 3xx | <redirect/> |
+---------------------+---------------------------------+
| 300 | <redirect/> |
+---------------------+---------------------------------+
| 301 | <gone/> (1) |
+---------------------+---------------------------------+
| 302 | <redirect/> |
+---------------------+---------------------------------+
| 305 | <redirect/> |
+---------------------+---------------------------------+
| 380 | <not-acceptable/> |
+---------------------+---------------------------------+
| 4xx | <bad-request/> |
+---------------------+---------------------------------+
| 400 | <bad-request/> |
+---------------------+---------------------------------+
| 401 | <not-authorized/> |
+---------------------+---------------------------------+
| 402 | <bad-request/> (2) |
+---------------------+---------------------------------+
| 403 | <forbidden/> (3) |
+---------------------+---------------------------------+
| 404 | <item-not-found/> (4) |
+---------------------+---------------------------------+
| 405 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 406 | <not-acceptable/> |
+---------------------+---------------------------------+
| 407 | <registration-required/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| SIP Response Code | XMPP Error Condition |
+---------------------+---------------------------------+
| 3xx | <redirect/> |
+---------------------+---------------------------------+
| 300 | <redirect/> |
+---------------------+---------------------------------+
| 301 | <gone/> (1) |
+---------------------+---------------------------------+
| 302 | <redirect/> |
+---------------------+---------------------------------+
| 305 | <redirect/> |
+---------------------+---------------------------------+
| 380 | <not-acceptable/> |
+---------------------+---------------------------------+
| 4xx | <bad-request/> |
+---------------------+---------------------------------+
| 400 | <bad-request/> |
+---------------------+---------------------------------+
| 401 | <not-authorized/> |
+---------------------+---------------------------------+
| 402 | <bad-request/> (2) |
+---------------------+---------------------------------+
| 403 | <forbidden/> (3) |
+---------------------+---------------------------------+
| 404 | <item-not-found/> (4) |
+---------------------+---------------------------------+
| 405 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 406 | <not-acceptable/> |
+---------------------+---------------------------------+
| 407 | <registration-required/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 408 | <remote-server-timeout/> (5) |
+---------------------+---------------------------------+
| 410 | <gone/> (1) |
+---------------------+---------------------------------+
| 413 | <policy-violation/> |
+---------------------+---------------------------------+
| 414 | <policy-violation/> |
+---------------------+---------------------------------+
| 415 | <not-acceptable/> |
+---------------------+---------------------------------+
| 416 | <not-acceptable/> |
+---------------------+---------------------------------+
| 420 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 421 | <not-acceptable/> |
+---------------------+---------------------------------+
| 423 | <resource-constraint/> |
+---------------------+---------------------------------+
| 430 | <recipient-unavailable/> (6) |
+---------------------+---------------------------------+
| 439 | <feature-not-implemented/> (6) |
+---------------------+---------------------------------+
| 440 | <policy-violation/> (7) |
+---------------------+---------------------------------+
| 480 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 481 | <item-not-found/> |
+---------------------+---------------------------------+
| 482 | <not-acceptable/> |
+---------------------+---------------------------------+
| 483 | <not-acceptable/> |
+---------------------+---------------------------------+
| 484 | <item-not-found/> |
+---------------------+---------------------------------+
| 485 | <item-not-found/> |
+---------------------+---------------------------------+
| 486 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 487 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 488 | <not-acceptable/> |
+---------------------+---------------------------------+
| 489 | <policy-violation/> (8) |
+---------------------+---------------------------------+
| 491 | <unexpected-request/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 408 | <remote-server-timeout/> (5) |
+---------------------+---------------------------------+
| 410 | <gone/> (1) |
+---------------------+---------------------------------+
| 413 | <policy-violation/> |
+---------------------+---------------------------------+
| 414 | <policy-violation/> |
+---------------------+---------------------------------+
| 415 | <not-acceptable/> |
+---------------------+---------------------------------+
| 416 | <not-acceptable/> |
+---------------------+---------------------------------+
| 420 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 421 | <not-acceptable/> |
+---------------------+---------------------------------+
| 423 | <resource-constraint/> |
+---------------------+---------------------------------+
| 430 | <recipient-unavailable/> (6) |
+---------------------+---------------------------------+
| 439 | <feature-not-implemented/> (6) |
+---------------------+---------------------------------+
| 440 | <policy-violation/> (7) |
+---------------------+---------------------------------+
| 480 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 481 | <item-not-found/> |
+---------------------+---------------------------------+
| 482 | <not-acceptable/> |
+---------------------+---------------------------------+
| 483 | <not-acceptable/> |
+---------------------+---------------------------------+
| 484 | <item-not-found/> |
+---------------------+---------------------------------+
| 485 | <item-not-found/> |
+---------------------+---------------------------------+
| 486 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 487 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 488 | <not-acceptable/> |
+---------------------+---------------------------------+
| 489 | <policy-violation/> (8) |
+---------------------+---------------------------------+
| 491 | <unexpected-request/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 493 | <bad-request/> |
+---------------------+---------------------------------+
| 5xx | <internal-server-error/> |
+---------------------+---------------------------------+
| 500 | <internal-server-error/> |
+---------------------+---------------------------------+
| 501 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 502 | <remote-server-not-found/> |
+---------------------+---------------------------------+
| 503 | <internal-server-error/> (9) |
+---------------------+---------------------------------+
| 504 | <remote-server-timeout/> |
+---------------------+---------------------------------+
| 505 | <not-acceptable/> |
+---------------------+---------------------------------+
| 513 | <policy-violation/> |
+---------------------+---------------------------------+
| 6xx | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 600 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 603 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 604 | <item-not-found/> |
+---------------------+---------------------------------+
| 606 | <not-acceptable/> |
+---------------------+---------------------------------+
+---------------------+---------------------------------+
| 493 | <bad-request/> |
+---------------------+---------------------------------+
| 5xx | <internal-server-error/> |
+---------------------+---------------------------------+
| 500 | <internal-server-error/> |
+---------------------+---------------------------------+
| 501 | <feature-not-implemented/> |
+---------------------+---------------------------------+
| 502 | <remote-server-not-found/> |
+---------------------+---------------------------------+
| 503 | <internal-server-error/> (9) |
+---------------------+---------------------------------+
| 504 | <remote-server-timeout/> |
+---------------------+---------------------------------+
| 505 | <not-acceptable/> |
+---------------------+---------------------------------+
| 513 | <policy-violation/> |
+---------------------+---------------------------------+
| 6xx | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 600 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 603 | <recipient-unavailable/> |
+---------------------+---------------------------------+
| 604 | <item-not-found/> |
+---------------------+---------------------------------+
| 606 | <not-acceptable/> |
+---------------------+---------------------------------+
Table 3: Mapping of SIP Response Codes to XMPP Error Conditions
表3：SIP响应代码到XMPP错误条件的映射
(1) When mapping SIP 301 to XMPP <gone/>, the <gone/> element MUST include XML character data specifying the new address. When mapping SIP 410 to XMPP <gone/>, the <gone/> element MUST NOT include XML character data specifying a new address.
(1) 将SIP301映射到XMPP<gone/>时，<gone/>元素必须包含指定新地址的XML字符数据。将SIP 410映射到XMPP<Goe/>时，<Goe/>元素不得包含指定新地址的XML字符数据。
(2) The XMPP <payment-required/> error condition was removed in [RFC6120]. Therefore, a mapping to XMPP <bad-request/> is suggested instead.
(2) [RFC6120]中删除了XMPP<payment required/>错误条件。因此，建议改为映射到XMPP<bad request/>。
(3) Depending on the scenario, other possible translations for SIP 403 are <not-allowed/> and <policy-violation/>.
(3) 根据场景的不同，SIP 403的其他可能翻译为<not allowed/>和<policy invalition/>。
(4) Depending on the scenario, another possible translation for SIP 404 is <remote-server-not-found/>.
(4) 根据场景的不同，SIP 404的另一种可能的翻译是<remote server not found/>。
(5) Depending on the scenario, another possible translation for SIP 408 is <remote-server-not-found/>.
(5) 根据场景，SIP 408的另一种可能的翻译是<remote server not found/>。
(6) Codes 430 and 439 are defined in [RFC5626].
(6) [RFC5626]中定义了代码430和439。
(7) Code 440 is defined in [RFC5393].
(7) [RFC5393]中定义了代码440。
(8) Code 489 is defined in [RFC6665].
(8) [RFC6665]中定义了代码489。
(9) Regarding the semantic mismatch between XMPP <service-unavailable/> and SIP code 503, see note (5) in Section 7.1 of this document.
(9) 关于XMPP<service unavailable/>和SIP代码503之间的语义不匹配，请参见本文件第7.1节中的注释（5）。
Detailed security considerations for SIP and XMPP are given in [RFC3261] and [RFC6120], respectively.
[RFC3261]和[RFC6120]分别给出了SIP和XMPP的详细安全注意事项。
To protect information sent between SIP and XMPP systems, deployed gateways SHOULD use Transport Layer Security (TLS) [RFC5246] when communicating over TCP and Datagram Transport Layer Security (DTLS) [RFC6347] when communicating over UDP.
为了保护SIP和XMPP系统之间发送的信息，部署的网关在通过TCP通信时应使用传输层安全性（TLS）[RFC5246]，在通过UDP通信时应使用数据报传输层安全性（DTLS）[RFC6347]。
As specified in Section 26.4.4 of [RFC3261] and updated by [RFC5630], a To header or a Request-URI containing a Session Initiation Protocol Secure (SIPS) URI is used to indicate that all hops in a communication path need to be protected using TLS. Because XMPP lacks a way to signal that all hops need to be protected, if the To header or Request-URI of a SIP message is a SIPS URI then the SIP-to-XMPP gateway MUST NOT translate the SIP message into an XMPP stanza and MUST NOT route it to the destination XMPP server (there might be exceptions to such a policy, such as explicit agreement among two operators to enforce per-hop security, but currently they are quite rare).
如[RFC3261]第26.4.4节所述，并由[RFC5630]更新，To头或包含会话启动协议安全（SIPS）URI的请求URI用于指示需要使用TLS保护通信路径中的所有跃点。因为XMPP缺少一种方法来表示需要保护所有跃点，如果SIP消息的to头或请求URI是SIPS URI，则SIP到XMPP网关不得将SIP消息转换为XMPP节，也不得将其路由到目标XMPP服务器（这种政策可能会有例外，例如两个运营商之间明确约定实施每跳安全性，但目前这种情况非常罕见）。
A gateway between SIP and XMPP (in either direction) effectively acts as a SIP back-to-back user agent ("B2BUA"). The amplification vulnerability described in [RFC5393] can manifest itself with B2BUAs (see also [B2BUA-LOOP-DETECT]), and a gateway SHOULD implement the loop-detection methods defined in that specification to help mitigate the possibility of amplification attacks. Note that although it would be possible to signal the Max-Forwards and Max-Breadth SIP headers over XMPP using the Stanza Headers and Internet Metadata (SHIM) extension [XEP-0131], that extension is not widely implemented; therefore, defenses against excessive looping and amplification attacks when messages pass back and forth through SIP and XMPP networks are out of scope for this document. However, it
SIP和XMPP之间的网关（在任一方向上）有效地充当SIP背靠背用户代理（“B2BUA”）。[RFC5393]中描述的放大漏洞可以通过B2BUAs（另请参见[B2BUA-LOOP-DETECT]）表现出来，网关应实现该规范中定义的环路检测方法，以帮助降低放大攻击的可能性。注意，尽管可以使用节头和互联网元数据（SHIM）扩展[XEP-0131]通过XMPP向最大转发和最大宽度SIP头发送信号，但该扩展并未得到广泛实施；因此，当消息通过SIP和XMPP网络来回传递时，对过度循环和放大攻击的防御超出了本文档的范围。但是,
ought to be addressed in the future, and implementations are strongly encouraged to incorporate appropriate countermeasures wherever possible.
应在将来加以解决，并强烈鼓励实施工作尽可能纳入适当的对策。
The ability to use a wide range of Unicode characters [UNICODE] can lead to security issues, especially the possibility of user confusion over identifiers containing visually similar characters (also called "confusable characters" or "confusables"). The PRECIS framework specification [PRECIS] describes some of these security issues, and additional guidance can be found in [UTS39].
使用多种Unicode字符[Unicode]的能力可能会导致安全问题，特别是用户可能会对包含视觉相似字符（也称为“可混淆字符”或“可混淆字符”）的标识符产生混淆。PRECIS框架规范[PRECIS]描述了其中一些安全问题，更多指南可在[UTS39]中找到。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, December 2008.
[RFC5393]Sparks，R.，Lawrence，S.，Hawrylyshen，A.，和B.Campen，“解决会话启动协议（SIP）分叉代理中的放大漏洞”，RFC 5393，2008年12月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5630]Audet，F.“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, March 2011.
[RFC6122]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：地址格式”，RFC6122011年3月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.3", 2013, <http://www.unicode.org/versions/Unicode6.3.0/>.
[UNICODE]UNICODE联盟，“UNICODE标准，6.3版”，2013年<http://www.unicode.org/versions/Unicode6.3.0/>.
[B2BUA-LOOP-DETECT] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Work in Progress, February 2014.
[B2BUA-LOOP-DETECT]Kaplan，H.和V.Pascual，“会话启动协议（SIP）背对背用户代理（B2BUAs）的循环检测机制”，正在进行的工作，2014年2月。
[PRECIS] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, April 2014.
[PRECIS]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备和比较”，正在进行的工作，2014年4月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[RFC3428]Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]彼得森，J.，“存在的共同特征（CPP）”，RFC3859，2004年8月。
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[RFC3860]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC3860，2004年8月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122]Saint Andre，P.，“可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 5122，2008年2月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626]Jennings，C.，Mahy，R.，和F.Audet，“在会话启动协议（SIP）中管理客户端启动的连接”，RFC 5626，2009年10月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121]圣安德烈，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC61212011年3月。
[RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665]Roach，A.，“SIP特定事件通知”，RFC 66652012年7月。
[UTS39] The Unicode Consortium, "Unicode Technical Standard #39: Unicode Security Mechanisms", November 2013, <http://unicode.org/reports/tr39/>.
[UTS39]Unicode联盟，“Unicode技术标准#39：Unicode安全机制”，2013年11月<http://unicode.org/reports/tr39/>.
[XEP-0106] Hildebrand, J. and P. Saint-Andre, "JID Escaping", XSF XEP 0106, June 2007, <http://www.xmpp.org/extensions/xep-0106.html>.
[XEP-0106]Hildebrand，J.和P.Saint Andre，“JID逃逸”，XSF XEP 0106，2007年6月<http://www.xmpp.org/extensions/xep-0106.html>.
[XEP-0131] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and Internet Metadata", XSF XEP 0131, July 2006, <http://xmpp.org/extensions/xep-0131.html>.
[XEP-0131]Saint Andre，P.和J.Hildebrand，“节头和互联网元数据”，XSF XEP 01312006年7月<http://xmpp.org/extensions/xep-0131.html>.
[XMPP-ADDRESS-FORMAT] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", Work in Progress, March 2014.
[XMPP-ADDRESS-FORMAT]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：地址格式”，正在进行的工作，2014年3月。
The authors wish to thank the following individuals for their feedback: Mary Barnes, Dave Cridland, Dave Crocker, Mike De Vries, Fabio Forno, Adrian Georgescu, Philipp Hancke, Saul Ibarra Corretge, Markus Isomaki, Olle Johansson, Paul Kyzivat, Salvatore Loreto, Daniel-Constantin Mierla, Tory Patnoe, and Robert Sparks.
作者希望感谢以下个人的反馈：玛丽·巴恩斯、戴夫·克里德兰、戴夫·克罗克、迈克·德弗里斯、法比奥·福诺、阿德里安·乔治斯库、菲利普·汉克、索尔·伊巴拉·科雷奇、马库斯·伊索马基、奥利·约翰森、保罗·基齐瓦特、萨尔瓦托·洛雷托、丹尼尔·康斯坦丁·米尔拉、托利·帕特诺和罗伯特·斯帕克斯。
Dan Romascanu reviewed the document on behalf of the General Area Review Team.
Dan Romascanu代表一般区域审查小组审查了该文件。
During IESG review, Stephen Farrell, Ted Lemon, Pete Resnick, and Sean Turner caught several issues that needed to be addressed.
在IESG审查期间，斯蒂芬·法雷尔、特德·莱蒙、皮特·雷斯尼克和肖恩·特纳抓住了几个需要解决的问题。
The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group chairs and Gonzalo Camarillo as the sponsoring Area Director.
作者衷心感谢工作组主席Markus Isomaki和Yana Stamcheva以及赞助区域主任Gonzalo Camarillo的协助。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier versions of this document.
Peter Saint Andre希望感谢Cisco Systems，Inc.在编写本文件早期版本时雇用了他。
Authors' Addresses
作者地址
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
EMail: ietf@stpeter.im
EMail: ietf@stpeter.im
Avshalom Houri IBM Rorberg Building, Pekris 3 Rehovot 76123 Israel
以色列雷霍沃特佩克里斯3号Avshalom Houri IBM Rorberg大楼76123
EMail: avshalom@il.ibm.com
EMail: avshalom@il.ibm.com
Joe Hildebrand Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA
Joe Hildebrand Cisco Systems，Inc.美国科罗拉多州丹佛市温库普街1899号600室，邮编：80202
EMail: jhildebr@cisco.com
EMail: jhildebr@cisco.com