[要約] RFC 7395は、WebSocketのためのXMPPサブプロトコルであり、メッセージングとプレゼンスの機能を拡張することを目的としています。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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上でExtensible Messaging and Presence Protocol（XMPP）（[RFC6120]と[RFC6121]を参照）を使用するアプリケーションは、双方向HTTPを介した双方向HTTP（BOSH）（[XEP-0124]と[XEP -0206]）、HTTPへのXMPPバインディング。 BOSHはHTTPの「ロングポーリング」技術に基づいており、TCPへのXMPPのネイティブバインディングと比較してトランスポートオーバーヘッドが高くなります。さらに、BOSHベースのシステムに影響を与えるロングポーリング[RFC6202]には、他にもいくつかの既知の問題があります。
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 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.
ほとんどの場合、XMPPをHTTPのロングポーリング接続でトンネリングせずに、XMPPを直接使用する方がはるかに良いでしょう。ただし、ブラウザが提供するAPIとサンドボックスでは、これは許可されていません。 WebSocketプロトコル[RFC6455]は、これらの種類の問題を解決するために存在し、シンプルなメッセージベースのフレーミングレイヤーを提供する双方向プロトコルであり、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ストリーム内の各ドキュメントの第1レベルの子のサブセットです（[RFC6120]のセクション9を参照）。 XMPPには、メッセージの概念もあります。これは、最上位の要素が<message />のスタンザです。このドキュメントでは、「メッセージ」という言葉は、XMPPメッセージスタンザではなく、WebSocketメッセージを意味します（特に明記されていない限り）。
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[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-Protocol」ヘッダーのプロトコルのリストに値「xmpp」を含める必要があります。 XMPPサブプロトコル接続を確立するために、サーバーからの応答には、独自の「Sec-WebSocket-Protocol」ヘッダーに「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
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" />
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ストリームの開始は、適切な属性と名前空間宣言（セクション3.3.2を参照）を持つ<open />要素である開始 "ストリームヘッダー"の使用によってマークされます。 <open />要素の属性は、 'http：//etherx.jabber.org/streams'名前空間[RFC6120]に対して定義された<stream />要素の属性と同じであり、同じセマンティクスと制限があります。
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ストリームの終わりは、関連する属性と名前空間宣言を持つ<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メッセージと1対1で対応し、すべての関連する名前空間と言語宣言を備えたスタンドアロンのXMLドキュメントとして解析可能でなければなりません。ただし、WebSocketメッセージはすでにUTF-8でエンコードされるように義務付けられているため、XML宣言を含めることはお勧めしません。各メッセージに宣言を含めると、各メッセージのフレーミングオーバーヘッドが増えるだけです。
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>
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>
-- OR --
-または-
<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" />
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ストリームを多重化してはなりません（MUST NOT）。
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.
ストリームのオープン中にエラーが発生した場合、サーバーは最初のオープンエレメント応答を送信しなければならず、その後に2番目の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バインディングの終了プロセスを反映していますが、終了の</ stream：stream>タグの代わりに<close />要素が使用されています。
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.
サーバーまたはクライアントのいずれかがいつでも接続を閉じることができます。接続を閉じる前に、閉じる側は、「urn：ietf：params：xml：ns：xmpp」で修飾された<close />要素を含むメッセージを送信して、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) |
+-------------------------------------------------------------------+
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].
XMPPストリームが最初に閉じられていない状態でWebSocket接続が閉じられるか切断されると、XMPPストリームは暗黙的に閉じられたと見なされ、XMPPセッションが終了します。ただし、ストリーム管理再開の使用がネゴシエートされた場合（[XEP-0198]を参照）、サーバーは、[XEP-0198]で指定されているサーバーポリシーに基づいて、XMPPセッションが一定期間存続していると見なすべきです（SHOULD）。
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" />
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と同じプロセスを使用して、サーバーストリームとクライアントストリームの両方が暗黙的に閉じられ、新しいストリームを開かなければなりません（MUST）。
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:
Simple Authentication and Security Layer（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" />
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サブプロトコルの場合、各メッセージは「<」文字で始まる必要があるため、空白のキープアライブを使用してはなりません（MUST NOT）。
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メカニズムを提供します。これらの拡張のどちらか（または両方）を使用して、接続の状態を判別できます（MAY）。
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].) 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.
XMPPサブプロトコルレイヤーではトランスポート層セキュリティ（TLS）を使用できません。これは、サブプロトコルでは未加工のバイナリデータを送信できないためです。代わりに、TLSを使用する場合は、「wss」URIスキームを介した安全なWebSocket接続を使用してWebSocketレイヤーで有効にする必要があります。 （[RFC6455]のセクション10.6を参照してください。）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は、ドメインネームシステムサービス（DNS SRV）レコードを使用してサーバーのTCP / IPアドレスとポートを検出する方法など、XMPPサーバーに接続する手順を定義しています[RFC2782]。このドキュメントで指定されているように（[RFC6120]で指定されているTCPバインディングではなく）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. XMPPサービスドメインと一致するHTTPオリジン[RFC6454]のパス "/.well-known/host-meta"にセキュアHTTP経由でリクエストを送信します（例： "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>
Servers MAY expose discovery information using host-meta documents, and clients MAY use such information to determine the WebSocket endpoint for a server.
サーバーはホストメタドキュメントを使用して検出情報を公開することができ（MAY）、クライアントはそのような情報を使用してサーバーのWebSocketエンドポイントを決定することができます（MAY）。
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起点と一致しない場合、ホストメタ要求と応答が発生する限り、XMPPサーバードメインとWebSocketエンドポイント間の信頼を確立するためにWebホストメタデータを使用する必要があります（SHOULD）。安全なHTTP経由。これは、同じWebSocketエンドポイントが複数のXMPPドメインにサービスを提供しているマルチテナントの状況で特に関連します（たとえば、「example.com」と「im.example.org」の両方のXMPPサービスドメインは、同じWebSocketエンドポイントによってサービスされます「hosting.example.net」）。関連する議論についてはセクション6を参照してください。
IANA has registered the WebSocket XMPP subprotocol in the "WebSocket Subprotocol Name Registry", with the following data:
IANAは、WebSocket XMPPサブプロトコルを「WebSocketサブプロトコル名レジストリ」に次のデータとともに登録しました。
Subprotocol Identifier: xmpp
サブプロトコル識別子：xmpp
Subprotocol Common Name: WebSocket Transport for the Extensible Messaging and Presence Protocol (XMPP)
サブプロトコルの一般名：Extensible Messaging and Presence Protocol（XMPP）のWebSocketトランスポート
Subprotocol Definition: this document
サブプロトコルの定義：このドキュメント
A URN sub-namespace for framing of Extensible Messaging and Presence Protocol (XMPP) streams is defined as follows.
Extensible Messaging and Presence Protocol（XMPP）ストリームをフレーミングするためのURNサブ名前空間は、次のように定義されます。
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で定義されているExtensible Messaging and Presence Protocol（XMPP）ストリームのフレーミング用のXML名前空間名です。
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レコードを使用せず、代わりにXMPPサービスドメインのURLからHTTPS経由で取得したWebホストメタデータファイルを使用します。セキュリティの観点からは、これは機能的にDNS SRVレコードによる解決と同等です（XMPPソースドメインの解決はDNSに依存しています）。
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. 接続エンドポイントを認証する方法は、TCPバインディングと同様にTLS（通常はPKIX証明書を使用）を使用しますが、認証されるIDはXMPPサービスドメインではなく接続エンドポイントアドレスです。 XMPPサービスドメインから接続エンドポイントアドレス（存在する場合）への委任は、セクション4で説明する検出方法を介して行われます。したがって、接続エンドポイントは引き続き認証され、Webホストメタデータファイルが存在する限り、委任は安全です。 HTTPS経由で取得されます。ただし、実際には、このオプションは、特定の委任されたドメインに対してユーザーエージェントが構成または展開されている場合は使用されない場合があります。
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で説明するフレーミングメソッドは、TCPバインディングのようにストリーミングXMLを使用する代わりに、WebSocketメッセージごとに1つのトップレベルXML要素を送信することにより、WebSocketパターンに従います。ただし、フレーミング方式はXMPPセッションのセキュリティプロパティに影響を与えません（たとえば、XMLスタンザのエンドツーエンドの暗号化は、ストリーミングXMLと同じようにWebSocketフレーミングを使用すると簡単に実行できます）。
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）TLS（「wss」URI）のみを使用するようにWebSocket接続エンドポイントを構成し、（3）用途（1）および（2）のXMPPサービスドメインとWebSocket接続エンドポイントをそれぞれ適切に識別する証明書をデプロイします。
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ストリームの「宛先」アドレスとして指定されたドメインに対応していることを確認できません。 2つのケースがあります。
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」のようになります。 。 WebSocketまたはHTTPSで提供された証明書がセキュアHTTP [RFC2818]に定義されたルールに従って検証されている限り、ブラウザはアプリケーションへのセキュア接続の確立が成功したことを報告します。 （ただし、前述のように、アプリケーションは証明書を個別に検査および検証することができず、ブラウザーを信頼する必要があります。これは既存のブラウザーテクノロジーの制限であるため、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で説明されているホストメタプロセスを使用する必要があります（SHOULD）ホストメタ要求と応答が安全なHTTP経由で発生する限り（[RFC2818]で定義されている適切な証明書検証を使用）、XMPPサーバードメインからWebSocketオリジンに信頼を委任します。
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エンドポイントを提示する場合、ダウングレードを防ぐために、クライアントは新しいエンドポイントのセキュリティコンテキストが現在のものよりも低い場合、提案を受け入れてはなりません（MUST NOT） 「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。、「HTTP Over TLS」、RFC 2818、2000年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。、「Webリンク」、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。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年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、「Web Host Metadata」、RFC 6415、2011年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、「The WebSocket Protocol」、RFC 6455、2011年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 RR（DNS SRV）」、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。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、2011年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。、「The Web Origin Concept」、RFC 6454、2011年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、「Bidirectional-streams Over Synchronous 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、「Discovering Alternative XMPP Connection Methods」、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] Saint-Andre、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 Over BOSH」、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 Schema Part 1：Structures Second Edition」、World Wide Web Consortium Recommendation REC-xmlschema-1-20041028、10月2004、<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'?>
<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='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: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は、General Area Review Teamに代わってドキュメントをレビューしました。
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.
著者は、ピーターセントアンドレ氏の支援をドキュメントシェパードとして、ベンキャンベル氏とジョーヒルデブランドをワーキンググループチェアとして、リチャードバーンズ氏がスポンサーエリアディレクターを務めたことに感謝します。
Authors' Addresses
著者のアドレス
Lance Stout (editor) &yet
ランス・スタウト（編集者）＆まだ
EMail: lance@andyet.net
Jack Moffitt Mozilla
ジャック・モフィット・モジラ
EMail: jack@metajack.im
Eric Cestari cstar industries
エリックセスタリcstar Industries
EMail: eric@cstar.io