Internet Engineering Task Force (IETF) L. Stout, Ed.
Request for Comments: 7395 &yet
Category: Standards Track J. Moffitt
ISSN: 2070-1721 Mozilla
E. Cestari
cstar industries
October 2014
Internet Engineering Task Force (IETF) L. Stout, Ed.
Request for Comments: 7395 &yet
Category: Standards Track J. Moffitt
ISSN: 2070-1721 Mozilla
E. Cestari
cstar industries
October 2014
An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
WebSocket的可扩展消息和状态协议（XMPP）子策略
Abstract
摘要
This document defines a binding for the Extensible Messaging and Presence Protocol (XMPP) over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP.
本文档定义了WebSocket传输层上可扩展消息和状态协议（XMPP）的绑定。XMPP的WebSocket绑定提供了比当前XMPP的HTTP绑定更高的性能。
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/rfc7395.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7395.
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 ....................................................2
2. Terminology .....................................................3
3. XMPP Subprotocol ................................................3
3.1. Handshake ..................................................3
3.2. WebSocket Messages .........................................4
3.3. XMPP Framing ...............................................5
3.3.1. Framed XML Stream ...................................5
3.3.2. Framed Stream Namespace .............................5
3.3.3. Stream Frames .......................................5
3.4. Stream Initiation ..........................................6
3.5. Stream Errors ..............................................7
3.6. Closing the Connection .....................................7
3.6.1. see-other-uri .......................................8
3.7. Stream Restarts ............................................9
3.8. Pings and Keepalives .......................................9
3.9. Use of TLS .................................................9
3.10. Stream Management ........................................10
4. Discovering the WebSocket Connection Method ....................10
5. IANA Considerations ............................................11
5.1. WebSocket Subprotocol Name ................................11
5.2. URN Sub-namespace .........................................11
6. Security Considerations ........................................12
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Appendix A. XML Schema ............................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................18
1. Introduction ....................................................2
2. Terminology .....................................................3
3. XMPP Subprotocol ................................................3
3.1. Handshake ..................................................3
3.2. WebSocket Messages .........................................4
3.3. XMPP Framing ...............................................5
3.3.1. Framed XML Stream ...................................5
3.3.2. Framed Stream Namespace .............................5
3.3.3. Stream Frames .......................................5
3.4. Stream Initiation ..........................................6
3.5. Stream Errors ..............................................7
3.6. Closing the Connection .....................................7
3.6.1. see-other-uri .......................................8
3.7. Stream Restarts ............................................9
3.8. Pings and Keepalives .......................................9
3.9. Use of TLS .................................................9
3.10. Stream Management ........................................10
4. Discovering the WebSocket Connection Method ....................10
5. IANA Considerations ............................................11
5.1. WebSocket Subprotocol Name ................................11
5.2. URN Sub-namespace .........................................11
6. Security Considerations ........................................12
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Appendix A. XML Schema ............................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................18
To date, applications using the Extensible Messaging and Presence Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made use of Bidirectional-streams Over Synchronous HTTP (BOSH) (see [XEP-0124] and [XEP-0206]), an XMPP binding to HTTP. BOSH is based on the HTTP "long polling" technique, and it suffers from high transport overhead compared to XMPP's native binding to TCP. In addition, there are a number of other known issues with long polling [RFC6202] that have an impact on BOSH-based systems.
迄今为止，在Web上使用可扩展消息和状态协议（XMPP）（参见[RFC6120]和[RFC6121]）的应用程序已经通过同步HTTP（BOSH）（参见[XEP-0124]和[XEP-0206]）使用了双向流，这是一种绑定到HTTP的XMPP。BOSH基于HTTP“长轮询”技术，与XMPP与TCP的本机绑定相比，它具有较高的传输开销。此外，长轮询[RFC6202]还存在许多其他已知问题，这些问题会对基于BOSH的系统产生影响。
In most circumstances, it would be much better to avoid tunneling XMPP over HTTP long-polled connections and instead use XMPP directly. However, the APIs and sandbox that browsers have provided do not allow this. The WebSocket protocol [RFC6455] exists to solve these
在大多数情况下，最好避免通过HTTP长轮询连接对XMPP进行隧道传输，而是直接使用XMPP。但是，浏览器提供的API和沙盒不允许这样做。WebSocket协议[RFC6455]的存在就是为了解决这些问题
kinds of problems and is a bidirectional protocol that provides a simple message-based framing layer, allowing for more robust and efficient communication in web applications.
它是一种双向协议，提供了一个简单的基于消息的帧层，允许在web应用程序中进行更健壮和高效的通信。
The WebSocket protocol enables two-way communication between a client and a server, effectively emulating TCP at the application layer and, therefore, overcoming many of the problems with existing long-polling techniques for bidirectional HTTP. This document defines a WebSocket subprotocol for XMPP.
WebSocket协议支持客户端和服务器之间的双向通信，在应用层有效地模拟TCP，因此克服了现有双向HTTP长轮询技术的许多问题。本文档定义了XMPP的WebSocket子目录。
The WebSocket binding for XMPP is designed for use by browser-based applications (e.g., XMPP clients written in JavaScript). Typically, these applications are used to access the same information and communication opportunities (e.g., the same XMPP "roster" of contacts) as clients that connect to an XMPP server over the TCP binding defined in [RFC6120]. Although the only essential difference is the underlying transport binding, relevant implications (e.g., framing methods and discovery processes) are highlighted in this specification.
XMPP的WebSocket绑定设计用于基于浏览器的应用程序（例如，用JavaScript编写的XMPP客户端）。通常，这些应用程序用于访问与通过[RFC6120]中定义的TCP绑定连接到XMPP服务器的客户端相同的信息和通信机会（例如，相同的XMPP联系人“名册”）。尽管唯一的本质区别是底层传输绑定，但本规范强调了相关含义（例如，成帧方法和发现过程）。
The basic unit of framing in the WebSocket protocol is called a "message". In XMPP, the basic unit is the stanza, which is a subset of the first-level children of each document in an XMPP stream (see Section 9 of [RFC6120]). XMPP also has a concept of messages, which are stanzas with a top-level element of <message/>. In this document, the word "message" will mean a WebSocket message, not an XMPP message stanza (unless otherwise noted).
WebSocket协议中帧的基本单元称为“消息”。在XMPP中，基本单位是节，它是XMPP流中每个文档的第一级子文档的子集（参见[RFC6120]第9节）。XMPP还有消息的概念，消息是带有顶级元素<message/>的节。在本文档中，“消息”一词将表示WebSocket消息，而不是XMPP消息节（除非另有说明）。
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]中的说明进行解释。
The XMPP subprotocol is used to transport XMPP over a WebSocket connection. The client and server agree to this protocol during the WebSocket handshake (see Section 1.3 of [RFC6455]).
XMPP子策略用于通过WebSocket连接传输XMPP。在WebSocket握手期间，客户端和服务器同意此协议（参见[RFC6455]第1.3节）。
During the WebSocket handshake, the client MUST include the value 'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol' header. The reply from the server MUST also contain 'xmpp' in its own 'Sec-WebSocket-Protocol' header in order for an XMPP subprotocol connection to be established.
在WebSocket握手期间，客户端必须在“Sec WebSocket协议”头的协议列表中包含值“xmpp”。服务器的回复还必须在其自己的“Sec WebSocket Protocol”头中包含“xmpp”，以便建立xmpp子目录连接。
If a client receives a handshake response that does not include 'xmpp' in the 'Sec-WebSocket-Protocol' header, then an XMPP subprotocol WebSocket connection was not established and the client MUST close the WebSocket connection.
如果客户端收到的握手响应在“Sec WebSocket Protocol”标题中不包含“xmpp”，则未建立xmpp子目录WebSocket连接，客户端必须关闭WebSocket连接。
Once the handshake has successfully completed, WebSocket messages sent or received MUST conform to the protocol defined in the rest of this document.
握手成功完成后，发送或接收的WebSocket消息必须符合本文档其余部分中定义的协议。
The following is an example of a WebSocket handshake, followed by opening an XMPP stream:
以下是WebSocket握手的示例，随后打开XMPP流：
C: GET /xmpp-websocket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
...
Sec-WebSocket-Protocol: xmpp
Sec-WebSocket-Version: 13
C: GET /xmpp-websocket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
...
Sec-WebSocket-Protocol: xmpp
Sec-WebSocket-Version: 13
S: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
...
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: xmpp
S: HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
...
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: xmpp
[WebSocket connection established]
[已建立WebSocket连接]
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
Data frame messages in the XMPP subprotocol MUST be of the text type and contain UTF-8 encoded data.
XMPP子目录中的数据帧消息必须是文本类型，并且包含UTF-8编码的数据。
The framing method for the binding of XMPP to WebSocket differs from the framing method for the TCP binding as defined in [RFC6120]; in particular, the WebSocket binding adopts the message framing provided by WebSocket to delineate the stream open and close headers, stanzas, and other top-level stream elements.
XMPP绑定到WebSocket的框架方法不同于[RFC6120]中定义的TCP绑定的框架方法；特别是，WebSocket绑定采用WebSocket提供的消息框架来描述流打开和关闭头、节和其他顶级流元素。
The start of a framed XML stream is marked by the use of an opening "stream header", which is an <open/> element with the appropriate attributes and namespace declarations (see Section 3.3.2). The attributes of the <open/> element are the same as those of the <stream/> element defined for the 'http://etherx.jabber.org/streams' namespace [RFC6120] and with the same semantics and restrictions.
框架XML流的开始是通过使用开头的“streamheader”来标记的，这是一个<open/>元素，具有适当的属性和名称空间声明（参见第3.3.2节）。<open/>元素的属性与为http://etherx.jabber.org/streams'命名空间[RFC6120]和具有相同的语义和限制。
The end of a framed XML stream is denoted by the closing "stream header", which is a <close/> element with its associated attributes and namespace declarations (see Section 3.3.2).
框架XML流的结尾由结束的“stream header”表示，它是一个<close/>元素及其相关属性和名称空间声明（参见第3.3.2节）。
The introduction of the <open/> and <close/> elements is motivated by the parsable XML document framing restriction in Section 3.3.3. As a consequence, note that a framed XML stream does not provide a wrapping <stream:stream/> [RFC6120] element encompassing the entirety of the XML stream.
<open/>和<close/>元素的引入受到第3.3.3节中可解析XML文档框架限制的推动。因此，请注意，框架XML流不提供包含整个XML流的包装<stream:stream/>[RFC6120]元素。
The XML stream headers (the <open/> and <close/> elements) MUST be qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing' (the "framed stream namespace"). If this rule is violated, the entity that receives the offending stream header MUST close the stream with an error, which MUST be <invalid-namespace> (see Section 4.9.3.10 of [RFC6120]).
XML流头（<open/>和<close/>元素）必须由名称空间“urn:ietf:params:XML:ns:xmpp framing”（框架流名称空间）限定。如果违反此规则，则接收违规流标头的实体必须关闭带有错误的流，该错误必须是<invalid namespace>（请参阅[RFC6120]第4.9.3.10节）。
The individual frames of a framed XML stream have a one-to-one correspondence with WebSocket messages and MUST be parsable as standalone XML documents, complete with all relevant namespace and language declarations. The inclusion of XML declarations, however, is NOT RECOMMENDED, as WebSocket messages are already mandated to be UTF-8 encoded. Including declarations in each message would only increase the framing overhead of each message.
框架XML流的各个框架与WebSocket消息有一对一的对应关系，并且必须作为独立的XML文档进行分析，包括所有相关的名称空间和语言声明。但是，不建议包含XML声明，因为WebSocket消息已经被强制使用UTF-8编码。在每条消息中包含声明只会增加每条消息的帧开销。
The first character of each frame MUST be a '<' character.
每帧的第一个字符必须是“<”字符。
Every XMPP stanza or other XML element (including the stream open and close headers) sent directly over the XML stream MUST be sent in its own frame.
直接通过XML流发送的每个XMPP节或其他XML元素（包括流打开和关闭头）都必须在自己的框架中发送。
Example of a WebSocket message that contains an independently parsable XML document:
包含独立可解析XML文档的WebSocket消息示例：
<message xmlns="jabber:client" xml:lang="en">
<body>Every WebSocket message is parsable by itself.</body>
</message>
<message xmlns="jabber:client" xml:lang="en">
<body>Every WebSocket message is parsable by itself.</body>
</message>
Note that for stream features and errors, there is no parent context element providing the "stream" namespace prefix as in [RFC6120], and thus the stream prefix MUST be declared or use an unprefixed form:
请注意，对于流功能和错误，没有父上下文元素提供[RFC6120]中的“流”命名空间前缀，因此必须声明流前缀或使用不固定的形式：
<stream:features xmlns:stream="http://etherx.jabber.org/streams">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
</stream:features>
<stream:features xmlns:stream="http://etherx.jabber.org/streams">
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
</stream:features>
-- OR --
--或--
<error xmlns="http://etherx.jabber.org/streams">
<host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</error>
<error xmlns="http://etherx.jabber.org/streams">
<host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</error>
The first message sent after the WebSocket opening handshake MUST be from the initiating entity and MUST be an <open/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-framing' namespace and with the same attributes mandated for the <stream> opening tag as described in Section 4.7 of [RFC6120].
WebSocket打开握手后发送的第一条消息必须来自发起实体，并且必须是由“urn:ietf:params:xml:ns:xmpp framing”名称空间限定的<open/>元素，并且具有[RFC6120]第4.7节中所述的<stream>打开标记的相同属性。
The receiving entity MUST respond with either an <open/> element (whose attributes match those described in Section 4.7 of [RFC6120]) or a <close/> element (see Section 3.6.1).
接收实体必须使用<open/>元素（其属性与[RFC6120]第4.7节中描述的属性匹配）或<close/>元素（见第3.6.1节）进行响应。
An example of a successful stream initiation exchange:
成功的流启动交换示例：
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
S: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
from="example.com"
id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
xml:lang="en"
version="1.0" />
Clients MUST NOT multiplex XMPP streams over the same WebSocket.
客户端不能在同一WebSocket上多路复用XMPP流。
Stream-level errors in XMPP are fatal. Should such an error occur, the server MUST send the stream error as a complete element in a message to the client.
XMPP中的流级错误是致命的。如果发生这种错误，服务器必须将流错误作为消息中的完整元素发送给客户端。
If the error occurs during the opening of a stream, the server MUST send the initial open element response, followed by the stream-level error in a second WebSocket message frame. The server MUST then close the connection as specified in Section 3.6.
如果错误发生在打开流的过程中，服务器必须发送初始打开元素响应，然后在第二个WebSocket消息帧中发送流级错误。然后，服务器必须按照第3.6节的规定关闭连接。
The closing process for the XMPP subprotocol mirrors that of the XMPP TCP binding as defined in Section 4.4 of [RFC6120], except that a <close/> element is used instead of the ending </stream:stream> tag.
XMPP子目录的关闭过程与[RFC6120]第4.4节中定义的XMPP TCP绑定的关闭过程相同，只是使用了<close/>元素而不是结尾的<stream:stream>标记。
Either the server or the client may close the connection at any time. Before closing the connection, the closing party is expected to first close the XMPP stream (if one has been opened) by sending a message with the <close/> element, qualified by the "urn:ietf:params:xml:ns:xmpp-framing" namespace. The stream is considered closed when a corresponding <close/> element is received from the other party, and the XMPP session is ended.
服务器或客户端可以随时关闭连接。在关闭连接之前，希望关闭方首先通过发送带有<close/>元素的消息来关闭XMPP流（如果已打开），该元素由“urn:ietf:params:xml:ns:XMPP framing”命名空间限定。当从另一方接收到相应的<close/>元素并且XMPP会话结束时，流被认为是关闭的。
To then close the WebSocket connection, the closing party MUST initiate the WebSocket closing handshake (see Section 7.1.2 of [RFC6455]).
要关闭WebSocket连接，关闭方必须启动WebSocket关闭握手（见[RFC6455]第7.1.2节）。
An example of ending an XMPP-over-WebSocket session by first closing the XMPP stream layer and then the WebSocket connection layer:
通过先关闭XMPP流层，然后关闭WebSocket连接层来结束XMPP over WebSocket会话的示例：
Client (XMPP WSS) Server
| | | |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |------------------------------------------------------------>| |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |<------------------------------------------------------------| |
| | | |
| | (XMPP Stream Closed) | |
| +-------------------------------------------------------------+ |
| |
| WS CLOSE FRAME |
|------------------------------------------------------------------>|
| WS CLOSE FRAME |
|<------------------------------------------------------------------|
| |
| (Connection Closed) |
+-------------------------------------------------------------------+
Client (XMPP WSS) Server
| | | |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |------------------------------------------------------------>| |
| | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> | |
| |<------------------------------------------------------------| |
| | | |
| | (XMPP Stream Closed) | |
| +-------------------------------------------------------------+ |
| |
| WS CLOSE FRAME |
|------------------------------------------------------------------>|
| WS CLOSE FRAME |
|<------------------------------------------------------------------|
| |
| (Connection Closed) |
+-------------------------------------------------------------------+
If the WebSocket connection is closed or broken without the XMPP stream having been closed first, then the XMPP stream is considered implicitly closed and the XMPP session ended; however, if the use of stream management resumption was negotiated (see [XEP-0198]), the server SHOULD consider the XMPP session still alive for a period of time based on server policy as specified in [XEP-0198].
如果WebSocket连接在XMPP流未首先关闭的情况下关闭或中断，则XMPP流被视为隐式关闭，XMPP会话结束；但是，如果协商使用流管理恢复（见[XEP-0198]），服务器应该考虑XMPP会话仍然存活一段时间，这是基于[XEP 0198]中指定的服务器策略。
At any point, if the server wishes to instruct the client to move to a different WebSocket endpoint (e.g., for load-balancing purposes), then a <close/> element is sent with the 'see-other-uri' attribute set to the URI of the new connection endpoint (which MAY be for a different transport method, such as BOSH (see [XEP-0124] and [XEP-0206])).
在任何时候，如果服务器希望指示客户端移动到不同的WebSocket端点（例如，出于负载平衡的目的），则发送<close/>元素，并将“see other uri”属性设置为新连接端点的uri（这可能是用于不同的传输方法，例如BOSH（参见[XEP-0124]和[XEP-0206]）。
Clients MUST NOT accept suggested endpoints with a lower security context (e.g., moving from a 'wss://' endpoint to a 'ws://' or 'http://' endpoint).
客户端不得接受具有较低安全上下文的建议终结点（例如，从“wss://”终结点移动到“ws://”或“http://”终结点）。
An example of the server closing a stream and instructing the client to connect at a different WebSocket endpoint:
服务器关闭流并指示客户端连接到不同WebSocket端点的示例：
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
see-other-uri="wss://otherendpoint.example/xmpp-bind" />
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
see-other-uri="wss://otherendpoint.example/xmpp-bind" />
Whenever a stream restart is mandated (see Section 4.3.3 of [RFC6120]), both the server and client streams are implicitly closed and new streams MUST be opened, using the same process as in Section 3.4.
每当强制重新启动流时（参见[RFC6120]第4.3.3节），服务器和客户端流都会隐式关闭，新流必须使用与第3.4节相同的过程打开。
The client MUST send a new stream <open/> element and MUST NOT send a closing <close/> element.
客户端必须发送新的流<open/>元素，而不能发送关闭<close/>元素。
An example of restarting the stream after successful Simple Authentication and Security Layer (SASL) negotiation:
简单身份验证和安全层（SASL）协商成功后重新启动流的示例：
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />
[Streams implicitly closed]
[隐式关闭的流]
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
to="example.com"
version="1.0" />
Traditionally, XMPP servers and clients often send "whitespace keepalives" (see Section 4.6.1 of [RFC6120]) between stanzas to maintain an XML stream. However, for the XMPP subprotocol each message is required to start with a '<' character, and, as such, whitespace keepalives MUST NOT be used.
传统上，XMPP服务器和客户端通常在节之间发送“空白保留页”（参见[RFC6120]的第4.6.1节），以维护XML流。但是，对于XMPP子脚本，每条消息都必须以“<”字符开头，因此，不能使用空格keepalives。
As alternatives, the XMPP Ping extension [XEP-0199] and the XMPP Stream Management extension [XEP-0198] provide pinging mechanisms. Either of these extensions (or both) MAY be used to determine the state of the connection.
作为替代方案，XMPP Ping扩展[XEP-0199]和XMPP流管理扩展[XEP-0198]提供Ping机制。这些扩展中的一个（或两个）可用于确定连接的状态。
Clients and servers MAY also use WebSocket ping control frames for this purpose, but note that some environments, such as browsers, do not provide access for generating or monitoring ping control frames.
客户端和服务器也可以为此使用WebSocket ping控制框架，但请注意，某些环境（如浏览器）不提供生成或监视ping控制框架的访问。
Transport Layer Security (TLS) cannot be used at the XMPP subprotocol layer because the subprotocol does not allow for raw binary data to be sent. Instead, when TLS is used, it MUST be enabled at the WebSocket layer using secure WebSocket connections via the 'wss' URI scheme. (See Section 10.6 of [RFC6455].)
传输层安全性（TLS）不能在XMPP子目录层使用，因为子目录不允许发送原始二进制数据。相反，当使用TLS时，必须通过“wss”URI方案在WebSocket层使用安全WebSocket连接启用TLS。（见[RFC6455]第10.6节）
Because TLS is to be provided outside of the XMPP subprotocol layer, a server MUST NOT advertise TLS as a stream feature (see Section 4.6 of [RFC6120]) when using the XMPP subprotocol. Likewise, a client MUST ignore any advertised TLS stream feature when using the XMPP subprotocol.
由于TLS是在XMPP子目录层之外提供的，因此在使用XMPP子目录时，服务器不得将TLS作为流功能发布（请参见[RFC6120]第4.6节）。同样，客户机在使用XMPP子策略时必须忽略任何公布的TLS流特性。
In order to alleviate the problems of temporary disconnections, the client MAY use the XMPP Stream Management extension [XEP-0198] to confirm when stanzas have been received by the server.
为了缓解临时断开连接的问题，客户机可以使用XMPP流管理扩展[XEP-0198]来确认服务器何时收到节。
In particular, the client MAY use session resumption as described in [XEP-0198] to recreate the same stream session state after a temporary network unavailability or after navigating to a new URL in a browser.
具体而言，客户端可以使用[XEP-0198]中所述的会话恢复来在临时网络不可用或在浏览器中导航到新URL后重新创建相同的流会话状态。
Section 3 of [RFC6120] defines a procedure for connecting to an XMPP server, including ways to discover the TCP/IP address and port of the server using Domain Name System service (DNS SRV) records [RFC2782]. When using the WebSocket binding as specified in this document (instead of the TCP binding as specified in [RFC6120]), a client needs an alternative way to discover information about the server's connection methods, since web browsers and other WebSocket-capable software applications typically cannot obtain such information from the DNS.
[RFC6120]第3节定义了连接到XMPP服务器的过程，包括使用域名系统服务（DNS SRV）记录发现服务器TCP/IP地址和端口的方法[RFC2782]。当使用本文档中指定的WebSocket绑定（而不是[RFC6120]中指定的TCP绑定）时，客户端需要另一种方法来发现有关服务器连接方法的信息，因为web浏览器和其他支持WebSocket的软件应用程序通常无法从DNS获取此类信息。
The alternative lookup process uses Web-host Metadata [RFC6415] and Web Linking [RFC5988], where the link relation type is "urn:xmpp:alt-connections:websocket" as described in "Discovering Alternative XMPP Connection Methods" [XEP-0156]. Conceptually, the host-meta lookup process used for the WebSocket binding is analogous to the DNS SRV lookup process used for the TCP binding. The process is as follows.
备选查找过程使用Web主机元数据[RFC6415]和Web链接[RFC5988]，其中链接关系类型为“urn:xmpp:alt connections:websocket”，如“发现备选xmpp连接方法”[XEP-0156]中所述。从概念上讲，用于WebSocket绑定的主机元查找过程类似于用于TCP绑定的DNS SRV查找过程。过程如下。
1. Send a request over secure HTTP to the path "/.well-known/host-meta" at an HTTP origin [RFC6454] that matches the XMPP service domain (e.g., a URL of "https://im.example.org/.well-known/host-meta" if the XMPP service domain is "im.example.org").
1. 通过安全HTTP将请求发送到与XMPP服务域匹配的HTTP源[RFC6454]处的路径“/.well-known/host-meta”（例如，URL）https://im.example.org/.well-known/host-meta如果XMPP服务域是“im.example.org”）。
2. Retrieve a host-meta document specifying a link relation type of "urn:xmpp:alt-connections:websocket", such as:
2. 检索指定链接关系类型为“urn:xmpp:alt connections:websocket”的主机元文档，例如：
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel="urn:xmpp:alt-connections:websocket"
href="wss://im.example.org:443/ws" />
</XRD>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
<Link rel="urn:xmpp:alt-connections:websocket"
href="wss://im.example.org:443/ws" />
</XRD>
Servers MAY expose discovery information using host-meta documents, and clients MAY use such information to determine the WebSocket endpoint for a server.
服务器可以使用主机元文档公开发现信息，客户端可以使用这些信息来确定服务器的WebSocket端点。
In cases where the XMPP service domain does not match the discovered web origin of the WebSocket endpoint, the Web-host Metadata SHOULD be used to establish trust between the XMPP server domain and the WebSocket endpoint as long as the host-meta request and response occurred over secure HTTP; this is especially relevant in multi-tenant situations where the same WebSocket endpoint is serving multiple XMPP domains (e.g., the XMPP service domains for both "example.com" and "im.example.org" might be serviced by the same WebSocket endpoint at "hosting.example.net"). See Section 6 for related discussion.
在XMPP服务域与发现的WebSocket端点的web源不匹配的情况下，只要主机元请求和响应发生在安全HTTP上，就应使用web主机元数据在XMPP服务器域和WebSocket端点之间建立信任；这在多租户情况下尤其重要，因为同一WebSocket端点为多个XMPP域提供服务（例如，“example.com”和“im.example.org”的XMPP服务域可能由位于“hosting.example.net”的同一WebSocket端点提供服务）。相关讨论见第6节。
IANA has registered the WebSocket XMPP subprotocol in the "WebSocket Subprotocol Name Registry", with the following data:
IANA已使用以下数据在“WebSocket子目录名称注册表”中注册WebSocket XMPP子目录：
Subprotocol Identifier: xmpp
子目录标识符：xmpp
Subprotocol Common Name: WebSocket Transport for the Extensible Messaging and Presence Protocol (XMPP)
子目录通用名称：可扩展消息和状态协议（XMPP）的WebSocket传输
Subprotocol Definition: this document
次级方案定义：本文件
A URN sub-namespace for framing of Extensible Messaging and Presence Protocol (XMPP) streams is defined as follows.
可扩展消息和状态协议（XMPP）流框架的URN子命名空间定义如下。
URI: urn:ietf:params:xml:ns:xmpp-framing
URI: urn:ietf:params:xml:ns:xmpp-framing
Specification: this document
规格：本文件
Description: This is the XML namespace name for framing of Extensible Messaging and Presence Protocol (XMPP) streams as defined by RFC 7395.
描述：这是RFC 7395定义的可扩展消息和状态协议（XMPP）流框架的XML命名空间名称。
Registrant Contact: IESG <iesg@ietf.org>
Registrant Contact: IESG <iesg@ietf.org>
The WebSocket binding for XMPP differs in several respects from the TCP binding defined in [RFC6120]:
XMPP的WebSocket绑定在几个方面不同于[RFC6120]中定义的TCP绑定：
1. As described in Section 4 of this document, the method for discovering a connection endpoint does not use DNS SRV records as in the TCP binding but instead uses Web-host Metadata files retrieved via HTTPS from a URL at the XMPP service domain. From a security standpoint, this is functionally equivalent to resolution via DNS SRV records (and still relies on the DNS for resolution of the XMPP source domain).
1. 如本文档第4节所述，发现连接端点的方法不使用TCP绑定中的DNS SRV记录，而是使用通过HTTPS从XMPP服务域的URL检索的Web主机元数据文件。从安全角度来看，这在功能上等同于通过DNS SRV记录进行解析（并且仍然依赖DNS解析XMPP源域）。
2. The method for authenticating a connection endpoint uses TLS (typically with PKIX certificates) as in the TCP binding, but the identity to be authenticated is the connection endpoint address instead of the XMPP service domain; delegation from the XMPP service domain to the connection endpoint address (if any) is accomplished via the discovery method described in Section 4. Thus, the connection endpoint is still authenticated, and the delegation is secure as long as the Web-host Metadata file is retrieved via HTTPS. However, note that, in practice, this option might not be employed when user agents are configured or deployed for a particular delegated domain.
2. 验证连接端点的方法使用TLS（通常带有PKIX证书），就像在TCP绑定中一样，但是要验证的身份是连接端点地址，而不是XMPP服务域；从XMPP服务域到连接端点地址（如果有）的委托是通过第4节中描述的发现方法完成的。因此，连接端点仍然是经过身份验证的，只要通过HTTPS检索Web主机元数据文件，委托就安全。但是，请注意，在实践中，当为特定委派域配置或部署用户代理时，可能不会使用此选项。
3. The framing method described in Section 3.3 follows the WebSocket pattern by sending one top-level XML element per WebSocket message, instead of using streaming XML as in the TCP binding. However, the framing method has no impact on the security properties of an XMPP session (e.g., end-to-end encryption of XML stanzas can be accomplished just as easily with WebSocket framing as with streaming XML).
3. 第3.3节中描述的框架方法遵循WebSocket模式，每个WebSocket消息发送一个顶级XML元素，而不是像TCP绑定中那样使用流式XML。但是，成帧方法对XMPP会话的安全属性没有影响（例如，XML节的端到端加密可以通过WebSocket成帧和流式XML轻松实现）。
4. In all other respects (e.g., user authentication via SASL, allowable characters in XMPP addresses, and reuse of various technologies such as Base 64, SASL mechanisms, UTF-8, and XML), the WebSocket binding does not differ from the TCP binding and, thus, does not modify the security properties of the protocol. In all these respects, the security considerations of [RFC6120] apply directly to the WebSocket binding.
4. 在所有其他方面（例如，通过SASL的用户身份验证、XMPP地址中允许的字符以及各种技术的重用，如Base 64、SASL机制、UTF-8和XML），WebSocket绑定与TCP绑定没有区别，因此不会修改协议的安全属性。在所有这些方面，[RFC6120]的安全注意事项直接适用于WebSocket绑定。
In order to ensure that communications over the WebSocket binding are as secure as communications over the TCP binding, an operator needs to (1) serve the Web-host Metadata file for the XMPP service domain over secure HTTP ('https' URIs) only, (2) configure the WebSocket connection endpoint to use TLS ('wss' URIs) only, and (3) deploy certificates that properly identify the XMPP service domain and WebSocket connection endpoint for usages (1) and (2), respectively.
为了确保通过WebSocket绑定的通信与通过TCP绑定的通信一样安全，操作员需要（1）仅通过安全HTTP（“https”URI）为XMPP服务域提供Web主机元数据文件，（2）将WebSocket连接端点配置为仅使用TLS（“wss”URI），以及（3）部署证书，分别正确标识XMPP服务域和WebSocket连接端点的用法（1）和（2）。
Since application-level TLS cannot be used (see Section 3.9), applications need to protect the privacy of XMPP traffic at the WebSocket or other appropriate layer.
由于无法使用应用程序级TLS（参见第3.9节），应用程序需要在WebSocket或其他适当层保护XMPP通信的隐私。
Browser-based applications are not able to inspect and verify, at the application layer, the certificate used for the WebSocket connection to ensure that it corresponds to the domain specified as the 'to' address of the XMPP stream. There are two cases:
基于浏览器的应用程序无法在应用程序层检查和验证用于WebSocket连接的证书，以确保它对应于指定为XMPP流的“收件人”地址的域。有两种情况：
1. If the XMPP service domain matches the origin for the WebSocket connection, the relevant check is already performed by the browser. For example, the XMPP service domain might be "foo.example", and the WebSocket endpoint discovered for the link relation type of "urn:xmpp:alt-connections:websocket" might be "wss://foo.example/websocket". As long as the certificate provided over WebSocket or HTTPS is verified according to the rules defined for secure HTTP [RFC2818], then the browser will report the successful establishment of a secure connection to the application. (However, as noted, the application is still not able to independently inspect and verify the certificate, and needs to trust the browser; this is a limitation of existing browser technologies and thus cannot be worked around by WebSocket applications.)
1. 如果XMPP服务域与WebSocket连接的源匹配，则浏览器已执行相关检查。例如，XMPP服务域可能是“foo.example”，为链接关系类型“urn:XMPP:alt connections:WebSocket”发现的WebSocket端点可能是wss://foo.example/websocket". 只要根据为安全HTTP定义的规则[RFC2818]验证通过WebSocket或HTTPS提供的证书，浏览器就会报告成功建立了与应用程序的安全连接。（但是，如上所述，应用程序仍然无法独立检查和验证证书，需要信任浏览器；这是现有浏览器技术的限制，因此WebSocket应用程序无法解决。）
2. In situations where the user agent has to deal with delegation and the domain of the XMPP server does not match the web origin of the WebSocket endpoint (such as multi-tenant hosting situations), the host-meta process described in Section 4 SHOULD be used to delegate trust from the XMPP server domain to the WebSocket origin, as long as the host-meta request and response occurred over secure HTTP (with appropriate certificate verification as defined in [RFC2818]).
2. 在用户代理必须处理委托且XMPP服务器的域与WebSocket端点的web源不匹配的情况下（如多租户托管情况），应使用第4节中描述的主机元进程将信任从XMPP服务器域委托给WebSocket源，只要主机元请求和响应发生在安全HTTP上（使用[RFC2818]中定义的适当证书验证）。
When presented with a new WebSocket endpoint via the 'see-other-uri' attribute of a <close/> element, clients MUST NOT accept the suggestion if the security context of the new endpoint is lower than the current one in order to prevent downgrade attacks from a 'wss://' endpoint to 'ws://'.
当通过<close/>元素的“see other uri”属性显示新的WebSocket端点时，如果新端点的安全上下文低于当前端点，则客户端不得接受该建议，以防止从“wss://”端点降级为“ws://”。
The security considerations for both WebSocket (see Section 10 of [RFC6455]) and XMPP (see Section 13 of [RFC6120]) apply to the WebSocket XMPP subprotocol.
WebSocket（参见[RFC6455]第10节）和XMPP（参见[RFC6120]第13节）的安全注意事项均适用于WebSocket XMPP子目录。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 28182000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010, <http://www.rfc-editor.org/info/rfc5988>.
[RFC5988]诺丁汉，M.，“网络链接”，RFC 5988，2010年10月<http://www.rfc-editor.org/info/rfc5988>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月<http://www.rfc-editor.org/info/rfc6120>.
[RFC6415] Hammer-Lahav, E. and B. Cook, "Web Host Metadata", RFC 6415, October 2011, <http://www.rfc-editor.org/info/rfc6415>.
[RFC6415]Hammer Lahav，E.和B.Cook，“网络主机元数据”，RFC 64152011年10月<http://www.rfc-editor.org/info/rfc6415>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011, <http://www.rfc-editor.org/info/rfc6455>.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 64552011年12月<http://www.rfc-editor.org/info/rfc6455>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011, <http://www.rfc-editor.org/info/rfc6121>.
[RFC6121]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 61212011年3月<http://www.rfc-editor.org/info/rfc6121>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP", RFC 6202, April 2011, <http://www.rfc-editor.org/info/rfc6202>.
[RFC6202]Loreto，S.，Saint Andre，P.，Salsano，S.，和G.Wilkins，“双向HTTP中使用长轮询和流的已知问题和最佳实践”，RFC 6202，2011年4月<http://www.rfc-editor.org/info/rfc6202>.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月<http://www.rfc-editor.org/info/rfc6454>.
[XEP-0124] Paterson, I., Smith, D., Saint-Andre, P., Moffitt, J., Stout, L., and W. Tilanus, "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF XEP 0124, April 2014.
[XEP-0124]Paterson，I.，Smith，D.，Saint Andre，P.，Moffitt，J.，Stout，L.，和W.Tilanus，“同步HTTP（BOSH）上的双向流”，XSF XEP 0124，2014年4月。
[XEP-0156] Hildebrand, J., Saint-Andre, P., and L. Stout, "Discovering Alternative XMPP Connection Methods", XSF XEP 0156, January 2014.
[XEP-0156]Hildebrand，J.，Saint Andre，P.，和L.Stout，“发现替代XMPP连接方法”，XSF XEP 0156，2014年1月。
[XEP-0198] Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F., Cridland, D., and M. Wild, "Stream Management", XSF XEP 0198, June 2011.
[XEP-0198]Karneges，J.，Saint Andre，P.，Hildebrand，J.，Forno，F.，Cridland，D.，和M.Wild，“河流管理”，XSF XEP 0198，2011年6月。
[XEP-0199] Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009.
[XEP-0199]圣安德烈，P.，“XMPP Ping”，XSF XEP 0199，2009年6月。
[XEP-0206] Paterson, I., Saint-Andre, P., Stout, L., and W. Tilanus, "XMPP Over BOSH", XSF XEP 0206, April 2014.
[XEP-0206]Paterson，I.，Saint Andre，P.，Stout，L.，和W.Tilanus，“波什上方的XMPP”，XSF XEP 0206，2014年4月。
[XML-SCHEMA] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XML-SCHEMA]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
The following schema formally defines the 'urn:ietf:params:xml:ns:xmpp-framing' namespace used in this document, in conformance with W3C XML Schema [XML-SCHEMA]. Because validation of XML streams and stanzas is optional, this schema is not normative and is provided for descriptive purposes only.
以下模式正式定义了本文档中使用的“urn:ietf:params:xml:ns:xmpp framing”命名空间，符合W3C xml模式[xml-schema]。因为XML流和节的验证是可选的，所以此模式不是规范性的，仅用于描述目的。
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-framing'
xmlns='urn:ietf:params:xml:ns:xmpp-framing'
elementFormDefault='unqualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-framing'
xmlns='urn:ietf:params:xml:ns:xmpp-framing'
elementFormDefault='unqualified'>
<xs:element name='open'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='open'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='close'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='see-other-uri' type='xs:anyURI'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='close'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='from' type='xs:string'
use='optional'/>
<xs:attribute name='id' type='xs:string'
use='optional'/>
<xs:attribute name='see-other-uri' type='xs:anyURI'
use='optional'/>
<xs:attribute name='to' type='xs:string'
use='optional'/>
<xs:attribute name='version' type='xs:decimal'
use='optional'/>
<xs:attribute ref='xml:lang'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
Acknowledgements
致谢
The authors wish to thank the following individuals for their feedback: Andreas Guth, Bjoern Hoerhmann, Dave Cridland, Florian Zeitz, Kurt Zeilenga, Matt Miller, Matthew Wild, Paul Aurich, Sergey Dobrov, and Waqas Hussain.
作者希望感谢以下个人的反馈：Andreas Guth、Bjoern Hoerhmann、Dave Cridland、Florian Zeitz、Kurt Zeilenga、Matt Miller、Matthew Wild、Paul Aurich、Sergey Dobrov和Waqas Hussain。
Dan Romascanu reviewed the document on behalf of the General Area Review Team.
Dan Romascanu代表一般区域审查小组审查了该文件。
During IESG review, Barry Leiba, Benoit Claise, Dan Romascanu, Jari Arkko, Juergen Schoenwaelder, Spencer Dawkins, Stephen Farrell, Ted Lemon, Kathleen Moriarty, and Pete Resnick caught several issues that needed to be addressed.
在IESG审查期间，巴里·莱巴、贝诺特·克莱斯、丹·罗马斯坎努、贾里·阿尔科、尤尔根·舍恩瓦埃尔德、斯宾塞·道金斯、斯蒂芬·法雷尔、泰德·莱蒙、凯瑟琳·莫里亚蒂和皮特·雷斯尼克抓住了几个需要解决的问题。
The authors gratefully acknowledge the assistance of Peter Saint-Andre as document shepherd, Ben Campbell and Joe Hildebrand as the working group chairs, and Richard Barnes as the sponsoring Area Director.
作者感谢彼得·圣安德烈（Peter Saint Andre）担任文件保管人，本·坎贝尔（Ben Campbell）和乔·希尔德布兰德（Joe Hildebrand）担任工作组主席，理查德·巴恩斯（Richard Barnes）担任赞助区域主任。
Authors' Addresses
作者地址
Lance Stout (editor) &yet
兰斯·斯托特（编辑）&还没有
EMail: lance@andyet.net
EMail: lance@andyet.net
Jack Moffitt Mozilla
杰克·莫菲特·莫兹拉
EMail: jack@metajack.im
EMail: jack@metajack.im
Eric Cestari cstar industries
埃里克·塞斯塔里·科斯塔工业公司
EMail: eric@cstar.io
EMail: eric@cstar.io