[要約] RFC 3920は、XMPPのコアプロトコルであり、メッセージングとプレゼンス情報の交換を可能にする。このRFCの目的は、XMPPの基本的な仕組みと機能を定義し、拡張性と相互運用性を提供することである。
Network Working Group P. Saint-Andre, Ed.
Request for Comments: 3920 Jabber Software Foundation
Category: Standards Track October 2004
Extensible Messaging and Presence Protocol (XMPP): Core
拡張可能なメッセージと存在プロトコル（XMPP）：コア
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
このメモは、拡張可能なマークアップ言語（XML）要素をストリーミングするためのプロトコルである拡張可能なメッセージングおよび存在プロトコル（XMPP）のコア機能を定義し、任意の2つのネットワークエンドポイント間で構造化された情報をリアルタイムに交換します。XMPPは、XMLデータを交換するための一般化された拡張可能なフレームワークを提供しますが、主にRFC 2779の要件を満たすインスタントメッセージングと存在アプリケーションを構築する目的で使用されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37
8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41
9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58
11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60
12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62
13. Internationalization Considerations . . . . . . . . . . . . 64
14. Security Considerations . . . . . . . . . . . . . . . . . . 64
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76
C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78
D. Differences Between Core Jabber Protocols and XMPP . . . . . 87
Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 89
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90
The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language [XML] protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, the current memo defines the core features of XMPP 1.0; the extensions required to provide the instant messaging and presence functionality defined in RFC 2779 [IMP-REQS] are specified in the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [XMPP-IM].
拡張可能なメッセージングおよび存在プロトコル（XMPP）は、ほぼリアルタイムメッセージング、存在、およびリクエスト応答サービスのためのオープンな拡張可能なマークアップ言語[XML]プロトコルです。基本的な構文とセマンティクスは、主に1999年にJabberのオープンソースコミュニティ内で元々開発されました。2002年、XMPP WGは、IETFインスタントメッセージング（IM）および存在感として適したJabberプロトコルの適応を開発することに焦点を合わせました。テクノロジー。XMPP WGによる作業の結果として、現在のメモはXMPP 1.0のコア機能を定義しています。RFC 2779 [IMP-REQS]で定義されているインスタントメッセージングと存在機能を提供するために必要な拡張機能は、拡張可能なメッセージングおよび存在プロトコル（XMPP）で指定されています：インスタントメッセージングと存在[XMPP-IM]。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [TERMS].
大文字のキーワード「必須」、「必要」、「必須」、「「shall」、「shall」、「shall "、" should "、" nove "、" becommended "、" may "、および" optional "）BCP 14、RFC 2119 [用語]に記載されているとおりに解釈されます。
Although XMPP is not wedded to any specific network architecture, to date it usually has been implemented via a client-server architecture wherein a client utilizing XMPP accesses a server over a [TCP] connection, and servers also communicate with each other over TCP connections.
XMPPは特定のネットワークアーキテクチャに結婚していませんが、これまでにXMPPを使用しているクライアントが[TCP]接続を介してサーバーにアクセスし、サーバーもTCP接続を介して通信するクライアントサーバーアーキテクチャを介して実装されています。
The following diagram provides a high-level overview of this architecture (where "-" represents communications that use XMPP and "=" represents communications that use any other protocol).
次の図は、このアーキテクチャの高レベルの概要を示します（ここで、「 - 」はXMPPを使用する通信を表し、「=」は他のプロトコルを使用する通信を表します）。
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
The symbols are as follows:
シンボルは次のとおりです。
o C1, C2, C3 = XMPP clients
o C1、C2、C3 = XMPPクライアント
o S1, S2 = XMPP servers
o S1、S2 = XMPPサーバー
o G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network
o G1 = XMPPと外国（XMPP以外の）メッセージングネットワークで使用されるプロトコルとの間に変換されるゲートウェイ
o FN1 = A foreign messaging network
o FN1 =外国メッセージングネットワーク
o FC1 = A client on a foreign messaging network
o FC1 =外国のメッセージングネットワーク上のクライアント
A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:
サーバーは、XMPP通信のインテリジェントな抽象化レイヤーとして機能します。その主な責任は次のとおりです。
o to manage connections from or sessions for other entities, in the form of XML streams (Section 4) to and from authorized clients, servers, and other entities
o XMLストリーム（セクション4）の形で、他のエンティティからの接続またはセッションを管理するために、承認されたクライアント、サーバー、およびその他のエンティティと
o to route appropriately-addressed XML stanzas (Section 9) among such entities over XML streams
o XMLストリームを介したそのようなエンティティの中で、適切にアドレスしたXMLスタンザ（セクション9）をルーティングする
Most XMPP-compliant servers also assume responsibility for the storage of data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the XML data is processed directly by the server itself on behalf of the client and is not routed to another entity.
ほとんどのXMPPに準拠したサーバーは、クライアントが使用するデータのストレージについても責任を負います（たとえば、XMPPベースのインスタントメッセージングおよび存在アプリケーションのユーザーの連絡先リスト）。この場合、XMLデータは、クライアントに代わってサーバー自体によって直接処理され、別のエンティティにルーティングされていません。
Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., <node@domain/ home> vs. <node@domain/work>) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)).
ほとんどのクライアントは、[TCP]接続を介してサーバーに直接接続し、XMPPを使用して、サーバーと関連するサービスが提供する機能を最大限に活用します。複数のリソース（デバイスや場所など）は、各承認されたクライアントに代わってサーバーに同時に接続でき、各リソースはXMPPアドレスのリソース識別子によって区別されます（例：<node@domain/ home> vs. <node@domain/work>）アドレス指定スキームで定義されている（セクション3）。クライアントとサーバー間の接続に推奨されるポートは5222で、IANAに登録されています（ポート番号（セクション15.9）を参照）。
A gateway is a special-purpose server-side service whose primary function is to translate XMPP into the protocol used by a foreign (non-XMPP) messaging system, as well as to translate the return data back into XMPP. Examples are gateways to email (see [SMTP]), Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message Service (SMS), and legacy instant messaging services such as AIM, ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications between gateways and servers, and between gateways and the foreign messaging system, are not defined in this document.
ゲートウェイは、XMPPを外国（XMPP以外の）メッセージングシステムが使用するプロトコルに変換し、リターンデータをXMPPに戻すことを主な機能である特別な目的のサーバー側サービスです。例は、電子メールへのゲートウェイ（[SMTP]を参照）、インターネットリレーチャット（[IRC]を参照）、Simple（[Simple]を参照）、Shortメッセージサービス（SMS）、およびAIM、ICQ、MSNメッセンジャーなどのレガシーインスタントメッセージングサービスです。、そしてYahoo！インスタントメッセンジャー。ゲートウェイとサーバー間の通信、およびゲートウェイと外国メッセージングシステム間の通信は、このドキュメントでは定義されていません。
Because each server is identified by a network address and because server-to-server communications are a straightforward extension of the client-to-server protocol, in practice, the system consists of a network of servers that inter-communicate. Thus, for example, <juliet@example.com> is able to exchange messages, presence, and other information with <romeo@example.net>. This pattern is familiar from messaging protocols (such as [SMTP]) that make use of network addressing standards. Communications between any two servers are OPTIONAL. If enabled, such communications SHOULD occur over XML streams that are bound to [TCP] connections. The RECOMMENDED port for connections between servers is 5269, as registered with the IANA (see Port Numbers (Section 15.9)).
各サーバーはネットワークアドレスによって識別され、サーバー間通信がクライアントからサーバーへのプロトコルの簡単な拡張であるため、実際には、システムは相互通信するサーバーのネットワークで構成されています。したがって、たとえば、<juliet@example.com>は、<romeo@example.net>でメッセージ、存在、その他の情報を交換できます。このパターンは、ネットワークアドレス指定標準を使用するメッセージングプロトコル（[SMTP]など）から馴染みがあります。任意の2つのサーバー間の通信はオプションです。有効にすると、[TCP]接続に結合したXMLストリームを介してそのような通信が発生するはずです。サーバー間の接続に推奨されるポートは5269で、IANAに登録されています（ポート番号（セクション15.9）を参照）。
An entity is anything that can be considered a network endpoint (i.e., an ID on the network) and that can communicate using XMPP. All such entities are uniquely addressable in a form that is consistent with RFC 2396 [URI]. For historical reasons, the address of an XMPP entity is called a Jabber Identifier or JID. A valid JID contains a set of ordered elements formed of a domain identifier, node identifier, and resource identifier.
エンティティは、ネットワークエンドポイント（つまり、ネットワーク上のID）と見なされ、XMPPを使用して通信できるものです。そのようなエンティティはすべて、RFC 2396 [URI]と一致する形式でユニークにアドレス指定可能です。歴史的な理由から、XMPPエンティティのアドレスは、Jabber IdentifierまたはJIDと呼ばれます。有効なJIDには、ドメイン識別子、ノード識別子、およびリソース識別子に形成された一連の順序付けされた要素が含まれています。
The syntax for a JID is defined below using the Augmented Backus-Naur Form as defined in [ABNF]. (The IPv4address and IPv6address rules are defined in Appendix B of [IPv6]; the allowable character sequences that conform to the node rule are defined by the Nodeprep profile of [STRINGPREP] as documented in Appendix A of this memo; the allowable character sequences that conform to the resource rule are defined by the Resourceprep profile of [STRINGPREP] as documented in Appendix B of this memo; and the sub-domain rule makes reference to the concept of an internationalized domain label as described in [IDNA].)
JIDの構文は、[abnf]で定義されている拡張されたバックスノール形式を使用して、以下に定義されています。（IPv4AddressおよびIPv6Addressルールは、[IPv6]の付録Bで定義されています。ノードルールに準拠する許容文字シーケンスは、このメモの付録Aに文書化されている[StringPrep]のnodePrepプロファイルによって定義されます。リソースルールへの適合は、このメモの付録Bに記載されている[StringPrep]のリソースプレッププロファイルによって定義されます。サブドメインルールは、[IDNA]で説明されているように国際化ドメインラベルの概念に言及しています。
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
All JIDs are based on the foregoing structure. The most common use of this structure is to identify an instant messaging user, the server to which the user connects, and the user's connected resource (e.g., a specific client) in the form of <user@host/resource>. However, node types other than clients are possible; for example, a specific chat room offered by a multi-user chat service could be addressed as <room@service> (where "room" is the name of the chat room and "service" is the hostname of the multi-user chat service) and a specific occupant of such a room could be addressed as <room@service/nick> (where "nick" is the occupant's room nickname). Many other JID types are possible (e.g., <domain/resource> could be a server-side script or service).
すべてのJIDは、前述の構造に基づいています。この構造の最も一般的な使用は、インスタントメッセージングユーザー、ユーザーが接続するサーバー、および<user@host/resource>の形でユーザーの接続されたリソース（特定のクライアントなど）を識別することです。ただし、クライアント以外のノードタイプは可能です。たとえば、マルチユーザーチャットサービスが提供する特定のチャットルームは、<room@service>（「ルーム」はチャットルームの名前であり、「サービス」はマルチユーザーチャットサービスのホスト名です。）そして、そのような部屋の特定の居住者は、<room@service/nick>（「ニック」が居住者の部屋のニックネームです）として扱うことができます。他の多くのJIDタイプが可能です（例：<domain/resource>は、サーバー側のスクリプトまたはサービスになる可能性があります）。
Each allowable portion of a JID (node identifier, domain identifier, and resource identifier) MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes.
JID（ノード識別子、ドメイン識別子、およびリソース識別子）の各許容部分は、長さが1023バイトを超えてはならず、3071バイトの最大合計サイズ（@'および'/'セパレーターを含む）になります。
The domain identifier is the primary identifier and is the only REQUIRED element of a JID (a mere domain identifier is a valid JID). It usually represents the network gateway or "primary" server to which other entities connect for XML routing and data management capabilities. However, the entity referenced by a domain identifier is not always a server, and may be a service that is addressed as a subdomain of a server that provides functionality above and beyond the capabilities of a server (e.g., a multi-user chat service, a user directory, or a gateway to a foreign messaging system).
ドメイン識別子は主要な識別子であり、JIDの唯一の要素です（単なるドメイン識別子は有効なJIDです）。通常、他のエンティティがXMLルーティングとデータ管理機能に接続するネットワークゲートウェイまたは「プライマリ」サーバーを表します。ただし、ドメイン識別子によって参照されるエンティティは常にサーバーではなく、サーバーの機能を超えて機能する機能を提供するサーバーのサブドメインとしてアドレス指定されるサービスである可能性があります（たとえば、マルチユーザーチャットサービス、ユーザーディレクトリ、または外国のメッセージングシステムへのゲートウェイ）。
The domain identifier for every server or service that will communicate over a network MAY be an IP address but SHOULD be a fully qualified domain name (see [DNS]). A domain identifier MUST be an "internationalized domain name" as defined in [IDNA], to which the Nameprep [NAMEPREP] profile of stringprep [STRINGPREP] can be applied without failing. Before comparing two domain identifiers, a server MUST (and a client SHOULD) first apply the Nameprep profile to the labels (as defined in [IDNA]) that make up each identifier.
ネットワークを介して通信するすべてのサーバーまたはサービスのドメイン識別子はIPアドレスである可能性がありますが、完全に適格なドメイン名である必要があります（[DNS]を参照）。ドメイン識別子は、[IDNA]で定義されている「国際化ドメイン名」でなければなりません。そこでは、stringprep [stringprep]のnameprep [nameprep]プロファイルを失敗なく適用できます。2つのドメイン識別子を比較する前に、サーバーは最初に各識別子を構成するラベル（[IDNA]で定義されているように）にNAMEPREPプロファイルをラベルに適用する必要があります（およびクライアントはそうする必要があります）。
The node identifier is an optional secondary identifier placed before the domain identifier and separated from the latter by the '@' character. It usually represents the entity requesting and using network access provided by the server or gateway (i.e., a client), although it can also represent other kinds of entities (e.g., a chat room associated with a multi-user chat service). The entity represented by a node identifier is addressed within the context of a specific domain; within instant messaging and presence applications of XMPP, this address is called a "bare JID" and is of the form <node@domain>.
ノード識別子は、ドメイン識別子の前に配置され、後者から「@」文字によって分離されたオプションのセカンダリ識別子です。通常、サーバーまたはゲートウェイ（クライアント）が提供するネットワークアクセスを要求および使用するエンティティを表しますが、他の種類のエンティティ（マルチユーザーチャットサービスに関連付けられたチャットルームなど）を表すこともできます。ノード識別子で表されるエンティティは、特定のドメインのコンテキスト内でアドレス指定されます。XMPPのインスタントメッセージングおよび存在アプリケーション内で、このアドレスは「ベアジッド」と呼ばれ、フォーム<node@domain>です。
A node identifier MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied to it without failing. Before comparing two node identifiers, a server MUST (and a client SHOULD) first apply the Nodeprep profile to each identifier.
[StringPrep]のnodePrepプロファイルを必ず適用できるように、ノード識別子をフォーマットする必要があります。2つのノード識別子を比較する前に、サーバーは最初に各識別子にnodePrepプロファイルを適用する必要があります（およびクライアントは必要です）。
The resource identifier is an optional tertiary identifier placed after the domain identifier and separated from the latter by the '/' character. A resource identifier may modify either a <node@domain> or a mere <domain> address. It usually represents a specific session, connection (e.g., a device or location), or object (e.g., a participant in a multi-user chat room) belonging to the entity associated with a node identifier. A resource identifier is opaque to both servers and other clients, and is typically defined by a client implementation when it provides the information necessary to complete Resource Binding (Section 7) (although it may be generated by a server on behalf of a client), after which it is referred to as a "connected resource". An entity MAY maintain multiple connected resources simultaneously, with each connected resource differentiated by a distinct resource identifier.
リソース識別子は、ドメイン識別子の後に配置され、後者から「/」文字によって分離されたオプションの三次識別子です。リソース識別子は、a <node@domain>またはmere <domain>アドレスのいずれかを変更できます。通常、特定のセッション、接続（デバイスまたは場所など）、またはノード識別子に関連付けられたエンティティに属するオブジェクト（マルチユーザーチャットルームの参加者など）を表します。リソース識別子は、サーバーと他のクライアントの両方に不透明であり、通常、リソースバインディングを完了するために必要な情報（セクション7）を提供するときにクライアントの実装によって定義されます（クライアントに代わってサーバーによって生成される場合があります）、その後、それは「接続されたリソース」と呼ばれます。エンティティは、複数の接続されたリソースを同時に維持する場合があり、それぞれの接続されたリソースが異なるリソース識別子によって区別されます。
A resource identifier MUST be formatted such that the Resourceprep profile of [STRINGPREP] can be applied without failing. Before comparing two resource identifiers, a server MUST (and a client SHOULD) first apply the Resourceprep profile to each identifier.
[StringPrep]のリソースプレッププロファイルを失敗なく適用できるように、リソース識別子をフォーマットする必要があります。2つのリソース識別子を比較する前に、サーバーは最初に各識別子にリソースプレッププロファイルを適用する必要があります（およびクライアントは必要です）。
After SASL negotiation (Section 6) and, if appropriate, Resource Binding (Section 7), the receiving entity for a stream MUST determine the initiating entity's JID.
SASL交渉（セクション6）および必要に応じて、リソース拘束力（セクション7）（セクション7）の後、ストリームの受信エンティティは開始エンティティのJIDを決定する必要があります。
For server-to-server communications, the initiating entity's JID SHOULD be the authorization identity, derived from the authentication identity, as defined by the Simple Authentication and Security Layer (SASL) specification [SASL], if no authorization identity was specified during SASL negotiation (Section 6).
サーバー間通信の場合、SASL交渉中に認証IDが指定されていない場合、Simple Authentication and Security Layer（SASL）仕様[SASL]で定義されているように、開始エンティティのJIDは認証IDから派生した認証IDである必要があります。（セクション6）。
For client-to-server communications, the "bare JID" (<node@domain>) SHOULD be the authorization identity, derived from the authentication identity, as defined in [SASL], if no authorization identity was specified during SASL negotiation (Section 6); the resource identifier portion of the "full JID" (<node@domain/resource>) SHOULD be the resource identifier negotiated by the client and server during Resource Binding (Section 7).
クライアント間通信の場合、[sasl]で定義されているように、「bare jid」（<node@domain>）は、認証アイデンティティから派生した認証アイデンティティである必要があります。6）;「Full Jid」（<node@domain/resource>）のリソース識別子部分は、リソースバインディング中にクライアントとサーバーによって交渉されたリソース識別子である必要があります（セクション7）。
The receiving entity MUST ensure that the resulting JID (including node identifier, domain identifier, resource identifier, and separator characters) conforms to the rules and formats defined earlier in this section; to meet this restriction, the receiving entity may need to replace the JID sent by the initiating entity with the canonicalized JID as determined by the receiving entity.
受信エンティティは、結果のJID（ノード識別子、ドメイン識別子、リソース識別子、およびセパレーター文字を含む）が、このセクションで前述したルールとフォーマットに準拠することを確認する必要があります。この制限を満たすには、受信エンティティは、開始エンティティから送信されたJIDを、受信エンティティによって決定された標準化されたJIDに置き換える必要がある場合があります。
Two fundamental concepts make possible the rapid, asynchronous exchange of relatively small payloads of structured information between presence-aware entities: XML streams and XML stanzas. These terms are defined as follows: Definition of XML Stream: An XML stream is a container for the exchange of XML elements between any two entities over a network. The start of an XML stream is denoted unambiguously by an opening XML <stream> tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML </stream> tag. During the life of the stream, the entity that initiated it can send an unbounded number of XML elements over the stream, either elements used to negotiate the stream (e.g., to negotiate Use of TLS (Section 5) or use of SASL (Section 6)) or XML stanzas (as defined herein, <message/>, <presence/>, or <iq/> elements qualified by the default namespace). The "initial stream" is negotiated from the initiating entity (usually a client or server) to the receiving entity (usually a server), and can be seen as corresponding to the initiating entity's "session" with the receiving entity. The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the "response stream").
2つの基本的な概念により、存在するエンティティ間の構造化された情報の比較的小さなペイロードの迅速で非同期交換、XMLストリームとXMLスタンザが可能になります。これらの用語は次のように定義されます。XMLストリームの定義：XMLストリームは、ネットワーク上の任意の2つのエンティティ間でXML要素を交換するためのコンテナです。XMLストリームの開始は、XML <Stream>タグ（適切な属性と名前空間宣言を使用）で明確に示され、XMLストリームの終了はXML </stream>タグの閉じることによって明確に示されます。ストリームの存続期間中、それを開始したエンティティは、ストリームの交渉に使用される要素（たとえば、TLSの使用（セクション5）を交渉するために、またはSASLの使用（セクション6）のいずれかの要素をストリーム上に送信できます。）またはXML Stanzas（本明細書で定義されているように、<メッセージ/>、<infaction/>、または<IQ/>要素はデフォルトの名前空間で資格があります）。「初期ストリーム」は、開始エンティティ（通常はクライアントまたはサーバー）から受信エンティティ（通常はサーバー）に交渉され、受信エンティティとの開始エンティティの「セッション」に対応すると見なすことができます。初期のストリームにより、開始エンティティから受信エンティティへの単方向通信が可能になります。受信エンティティから開始エンティティへの情報交換を有効にするために、受信エンティティは反対方向にストリームをネゴシエートする必要があります（「応答ストリーム」）。
Definition of XML Stanza: An XML stanza is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream. An XML stanza exists at the direct child level of the root <stream/> element and is said to be well-balanced if it matches the production [43] content of [XML]. The start of any XML stanza is denoted unambiguously by the element start tag at depth=1 of the XML stream (e.g., <presence>), and the end of any XML stanza is denoted unambiguously by the corresponding close tag at depth=1 (e.g., </presence>). An XML stanza MAY contain child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information. The only XML stanzas defined herein are the <message/>, <presence/>, and <iq/> elements qualified by the default namespace for the stream, as described under XML Stanzas (Section 9); an XML element sent for the purpose of Transport Layer Security (TLS) negotiation (Section 5), Simple Authentication and Security Layer (SASL) negotiation (Section 6), or server dialback (Section 8) is not considered to be an XML stanza.
XMLスタンザの定義：XMLスタンザは、XMLストリームを介してあるエンティティから別のエンティティに送信される構造化された情報の個別の意味ユニットです。XMLスタンザは、ルート<ストリーム/>要素の直接の子レベルに存在し、[XML]の生産[43]コンテンツに一致する場合、バランスが取れていると言われています。XMLスタンザの開始は、XMLストリームの深さ= 1の要素開始タグ（例：<プレゼンス>）によって明確に示され、XMLスタンザの終わりは、depth = 1の対応する近接タグによって明確に示されます（例えば、</存在>）。XML Stanzaには、必要に応じて、必要に応じて、必要に応じて、必要に応じて、子どもの要素（付随する属性、要素、XML文字データを含む）を含む場合があります。ここで定義されている唯一のXMLスタンザは、xMLスタンザ（セクション9）で説明されているように、ストリームのデフォルトの名前空間で資格がある<メッセージ/>、<IC/>要素です。輸送層のセキュリティ（TLS）交渉（セクション5）、シンプルな認証およびセキュリティ層（SASL）交渉（セクション6）、またはサーバーダイヤルバック（セクション8）の目的で送信されたXML要素は、XMLスタンザとは見なされません。
Consider the example of a client's session with a server. In order to connect to a server, a client MUST initiate an XML stream by sending an opening <stream> tag to the server, optionally preceded by a text declaration specifying the XML version and the character encoding supported (see Inclusion of Text Declaration (Section 11.4); see also Character Encoding (Section 11.5)). Subject to local policies and service provisioning, the server SHOULD then reply with a second XML stream back to the client, again optionally preceded by a text declaration. Once the client has completed SASL negotiation (Section 6), the client MAY send an unbounded number of XML stanzas over the stream to any recipient on the network. When the client desires to close the stream, it simply sends a closing </stream> tag to the server (alternatively, the stream may be closed by the server), after which both the client and server SHOULD terminate the underlying connection (usually a TCP connection) as well.
サーバーを使用したクライアントのセッションの例を考えてください。サーバーに接続するには、クライアントは、XMLバージョンとサポートされているエンコードエンコードを指定するテキスト宣言がオプションで先行する前に、サーバーにopene <stream>タグを送信してXMLストリームを開始する必要があります（テキスト宣言の包含を参照してください（セクションを参照してください11.4）;文字エンコード（セクション11.5）も参照してください。ローカルポリシーとサービスのプロビジョニングに従って、サーバーは2番目のXMLストリームをクライアントに戻すと、オプションでテキスト宣言が前に返信する必要があります。クライアントがSASLの交渉を完了すると（セクション6）、クライアントは、ネットワーク上の任意の受信者にストリーム上に無制限の数のXMLスタンザを送信することができます。クライアントがストリームを閉じることを希望する場合、クロージング</stream>タグをサーバーに送信するだけです（あるいは、サーバーによってストリームが閉じられる場合があります）。その後、クライアントとサーバーの両方が基礎となる接続を終了する必要があります（通常、TCP接続）も同様です。
Those who are accustomed to thinking of XML in a document-centric manner may wish to view a client's session with a server as consisting of two open-ended XML documents: one from the client to the server and one from the server to the client. From this perspective, the root <stream/> element can be considered the document entity for each "document", and the two "documents" are built up through the accumulation of XML stanzas sent over the two XML streams. However, this perspective is a convenience only; XMPP does not deal in documents but in XML streams and XML stanzas.
ドキュメント中心の方法でXMLを考えることに慣れている人は、クライアントからサーバーからサーバーへ、もう1つはサーバーからクライアントへの2つのオープンエンドXMLドキュメントで構成されるサーバーでのクライアントのセッションを表示することをお勧めします。この観点から、ルート<ストリーム/>要素は、各「ドキュメント」のドキュメントエンティティと見なすことができ、2つの「ドキュメント」は、2つのXMLストリームに送信されるXMLスタンザの蓄積によって構築されます。ただし、この視点は利便性のみです。XMPPはドキュメントではなく、XMLストリームとXMLスタンザで扱っています。
In essence, then, an XML stream acts as an envelope for all the XML stanzas sent during a session. We can represent this in a simplistic fashion as follows:
本質的に、XMLストリームは、セッション中に送信されたすべてのXMLスタンザの封筒として機能します。これを次のように単純化する方法で表現できます。
|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to='foo'> |
| <body/> |
| </message> |
|--------------------|
| <iq to='bar'> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|
Although there is no necessary coupling of an XML stream to a [TCP] connection (e.g., two entities could connect to each other via another mechanism such as polling over [HTTP]), this specification defines a binding of XMPP to TCP only. In the context of client-to-server communications, a server MUST allow a client to share a single TCP connection for XML stanzas sent from client to server and from server to client. In the context of server-to-server communications, a server MUST use one TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections.
[TCP]接続へのXMLストリームの必要な結合はありませんが（たとえば、[HTTP]ポーリングなどの別のメカニズムを介して2つのエンティティが相互に接続できます）、この仕様はXMPPのTCPへの結合のみを定義します。クライアント間通信のコンテキストでは、サーバーは、クライアントからサーバーからサーバーからサーバーに送信されたXMLスタンザの単一のTCP接続をクライアントに共有できるようにする必要があります。サーバーからサーバーへの通信のコンテキストでは、サーバーはサーバーからピアに送信されたXMLスタンザに1つのTCP接続を使用する必要があります。2つのTCP接続の。
When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as defined under Use of TLS (Section 5) and SASL MUST be used as defined under Use of SASL (Section 6). The "initial stream" (i.e., the stream from the initiating entity to the receiving entity) and the "response stream" (i.e., the stream from the receiving entity to the initiating entity) MUST be secured separately, although security in both directions MAY be established via mechanisms that provide mutual authentication. An entity SHOULD NOT attempt to send XML Stanzas (Section 9) over the stream before the stream has been authenticated, but if it does, then the other entity MUST NOT accept such stanzas and SHOULD return a <not-authorized/> stream error and then terminate both the XML stream and the underlying TCP connection; note well that this applies to XML stanzas only (i.e., <message/>, <presence/>, and <iq/> elements scoped by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to negotiate Use of TLS (Section 5) or Use of SASL (Section 6)).
XMPP 1.0でXMLストリームを交渉する場合、TLSをTLS（セクション5）の使用で定義するようにTLSを使用する必要があり、SASLはSASLの使用（セクション6）の使用で定義されている必要があります。「初期ストリーム」（つまり、開始エンティティから受信エンティティへのストリーム）と「応答ストリーム」（つまり、受信エンティティから開始エンティティへのストリーム）は個別に保護されなければなりませんが、相互認証を提供するメカニズムを介して確立されます。エンティティは、ストリームが認証される前にXMLスタンザ（セクション9）をストリーム上に送信しようとしないでください。次に、XMLストリームと基礎となるTCP接続の両方を終了します。これは、XMLスタンザのみに適用されることに注意してください（つまり、<メッセージ/>、<プレゼンス/>、および<IQ/>要素がデフォルトの名前空間によってスコープされた要素）、ストリームネゴシエーションに使用されるXML要素（たとえば、交渉に使用される要素TLSの使用（セクション5）またはSASLの使用（セクション6））。
The attributes of the stream element are as follows:
ストリーム要素の属性は次のとおりです。
o to -- The 'to' attribute SHOULD be used only in the XML stream header from the initiating entity to the receiving entity, and MUST be set to a hostname serviced by the receiving entity. There SHOULD NOT be a 'to' attribute set in the XML stream header by which the receiving entity replies to the initiating entity; however, if a 'to' attribute is included, it SHOULD be silently ignored by the initiating entity.
o to--「to」属性は、開始エンティティから受信エンティティへのXMLストリームヘッダーでのみ使用する必要があり、受信エンティティがサービスするホスト名に設定する必要があります。XMLストリームヘッダーにセットされた「to」属性は、受信エンティティが開始エンティティに応答するものではありません。ただし、「to」属性が含まれている場合、開始エンティティによって静かに無視される必要があります。
o from -- The 'from' attribute SHOULD be used only in the XML stream header from the receiving entity to the initiating entity, and MUST be set to a hostname serviced by the receiving entity that is granting access to the initiating entity. There SHOULD NOT be a 'from' attribute on the XML stream header sent from the initiating entity to the receiving entity; however, if a 'from' attribute is included, it SHOULD be silently ignored by the receiving entity.
o from -'from'属性は、受信エンティティから開始エンティティまでのXMLストリームヘッダーでのみ使用する必要があり、開始エンティティへのアクセスを許可している受信エンティティがサービスするホスト名に設定する必要があります。開始エンティティから受信エンティティに送信されたXMLストリームヘッダーに「From」属性はありません。ただし、「From」属性が含まれている場合、受信エンティティによって静かに無視される必要があります。
o id -- The 'id' attribute SHOULD be used only in the XML stream header from the receiving entity to the initiating entity. This attribute is a unique identifier created by the receiving entity to function as a session key for the initiating entity's streams with the receiving entity, and MUST be unique within the receiving application (normally a server). Note well that the stream ID may be security-critical and therefore MUST be both unpredictable and nonrepeating (see [RANDOM] for recommendations regarding randomness for security purposes). There SHOULD NOT be an 'id' attribute on the XML stream header sent from the initiating entity to the receiving entity; however, if an 'id' attribute is included, it SHOULD be silently ignored by the receiving entity.
o ID-「ID」属性は、受信エンティティから開始エンティティまでのXMLストリームヘッダーでのみ使用する必要があります。この属性は、受信エンティティによって作成されたユニークな識別子であり、受信エンティティを使用した開始エンティティのストリームのセッションキーとして機能し、受信アプリケーション（通常はサーバー）内で一意でなければなりません。ストリームIDはセキュリティが批判的である可能性があるため、予測不可能で非回復の両方でなければならないことに注意してください（セキュリティ目的のランダム性に関する推奨事項については[ランダム]を参照）。開始エンティティから受信エンティティに送信されたXMLストリームヘッダーに「ID」属性があるべきではありません。ただし、「ID」属性が含まれている場合、受信エンティティによって静かに無視される必要があります。
o xml:lang -- An 'xml:lang' attribute (as defined in Section 2.12 of [XML]) SHOULD be included by the initiating entity on the header for the initial stream to specify the default language of any human-readable XML character data it sends over that stream. If the attribute is included, the receiving entity SHOULD remember that value as the default for both the initial stream and the response stream; if the attribute is not included, the receiving entity SHOULD use a configurable default value for both streams, which it MUST communicate in the header for the response stream. For all stanzas sent over the initial stream, if the initiating entity does not include an 'xml:lang' attribute, the receiving entity SHOULD apply the default value; if the initiating entity does include an 'xml:lang' attribute, the receiving entity MUST NOT modify or delete it (see also xml:lang (Section 9.1.5)). The value of the 'xml:lang' attribute MUST be an NMTOKEN (as defined in Section 2.3 of [XML]) and MUST conform to the format defined in RFC 3066 [LANGTAGS].
o XML：Lang-an 'xml：lang'属性（[xml]のセクション2.12で定義されているように）は、初期ストリームのヘッダー上の開始エンティティが、人間が読み取れるXML文字データのデフォルト言語を指定する必要がありますそれはそのストリームの上に送られます。属性が含まれている場合、受信エンティティは、初期ストリームと応答ストリームの両方のデフォルトとしてその値を覚えておく必要があります。属性が含まれていない場合、受信エンティティは両方のストリームに対して構成可能なデフォルト値を使用する必要があります。これは、応答ストリームのヘッダーで通信する必要があります。最初のストリームを介して送信されたすべてのスタンザについて、開始エンティティに 'xml：lang'属性が含まれていない場合、受信エンティティはデフォルト値を適用する必要があります。開始エンティティに 'xml：lang'属性が含まれている場合、受信エンティティはそれを変更または削除してはなりません（xml：lang（セクション9.1.5）も参照）。'xml：lang'属性の値は、nmtoken（[xml]のセクション2.3で定義されている）でなければならず、RFC 3066 [langtags]で定義されている形式に準拠する必要があります。
o version -- The presence of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols (including stream features) defined in this specification. Detailed rules regarding the generation and handling of this attribute are defined below.
o バージョン - この仕様で定義されているストリーム関連のプロトコル（ストリーム機能を含む）の値に設定されたバージョン属性の存在。この属性の生成と取り扱いに関する詳細なルールを以下に定義します。
We can summarize as follows:
次のように要約できます。
| initiating to receiving | receiving to initiating
---------+---------------------------+-----------------------
to | hostname of receiver | silently ignored
from | silently ignored | hostname of receiver
id | silently ignored | session key
xml:lang | default language | default language
version | signals XMPP 1.0 support | signals XMPP 1.0 support
The version of XMPP specified herein is "1.0"; in particular, this encapsulates the stream-related protocols (Use of TLS (Section 5), Use of SASL (Section 6), and Stream Errors (Section 4.7)), as well as the semantics of the three defined XML stanza types (<message/>, <presence/>, and <iq/>). The numbering scheme for XMPP versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "XMPP 2.4" would be a lower version than "XMPP 2.13", which in turn would be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be sent.
ここで指定されたXMPPのバージョンは「1.0」です。特に、これはストリーム関連のプロトコル（TLS（セクション5）、SASLの使用（セクション6）、およびストリームエラー（セクション4.7）の使用）、および3つの定義されたXMLスタンザタイプのセマンティクスをカプセル化します（<メッセージ/>、<存在/>、および<iq/>）。XMPPバージョンの番号付けスキームは「<major>。<minal>」です。主要な数字と少数は別々の整数として扱わなければならず、各数値は1桁よりも高く増加することができます。したがって、「XMPP 2.4」は「XMPP 2.13」よりも低いバージョンであり、「XMPP 12.3」よりも低くなります。主要なゼロ（「XMPP 6.01」など）は、受信者が無視する必要があり、送信してはなりません。
The major version number should be incremented only if the stream and stanza formats or required actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions specified in the older specification. The minor version number indicates new capabilities, and MUST be ignored by an entity with a smaller minor version number, but used for informational purposes by the entity with the larger minor version number. For example, a minor version number might indicate the ability to process a newly defined value of the 'type' attribute for message, presence, or IQ stanzas; the entity with the larger minor version number would simply note that its correspondent would not be able to understand that value of the 'type' attribute and therefore would not send it.
メジャーバージョン番号は、ストリームとスタンザ形式または必要なアクションが非常に劇的に変更された場合にのみインクリメントする必要があります。古い仕様で指定されたアクションを取得しました。マイナーバージョン番号は新しい機能を示しており、より小さなマイナーバージョン番号を持つエンティティでは無視する必要がありますが、より大きなマイナーバージョン番号を持つエンティティによって情報目的で使用されます。たとえば、マイナーバージョン番号は、メッセージ、存在、またはIQスタンザの「タイプ」属性の新たに定義された値を処理する機能を示している場合があります。より大きなマイナーバージョン番号を持つエンティティは、その特派員が「タイプ」属性のその価値を理解できないため、それを送信しないことに単純に注意します。
The following rules apply to the generation and handling of the 'version' attribute within stream headers by implementations:
次のルールは、実装によるストリームヘッダー内の「バージョン」属性の生成と処理に適用されます。
1. The initiating entity MUST set the value of the 'version' attribute on the initial stream header to the highest version number it supports (e.g., if the highest version number it supports is that defined in this specification, it MUST set the value to "1.0").
1. 開始エンティティは、初期ストリームヘッダーの「バージョン」属性の値をサポートする最高バージョン番号に設定する必要があります（たとえば、サポートする最高のバージョン番号がこの仕様で定義されている場合、値を "1.0に設定する必要があります。"）。
2. The receiving entity MUST set the value of the 'version' attribute on the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower. The receiving entity MUST perform a numeric comparison on the major and minor version numbers, not a string match on "<major>.<minor>".
2. 受信エンティティは、応答ストリームヘッダーの「バージョン」属性の値を、開始エンティティによって提供される値または受信エンティティによってサポートされる最高バージョン番号のいずれか低い方に設定する必要があります。受信エンティティは、「<major>。<minor>」の文字列マッチではなく、メジャーバージョンとマイナーバージョンの数値で数値比較を実行する必要があります。
3. If the version number included in the response stream header is at least one major version lower than the version number included in the initial stream header and newer version entities cannot interoperate with older version entities as described above, the initiating entity SHOULD generate an <unsupported-version/> stream error and terminate the XML stream and underlying TCP connection.
3. 応答ストリームヘッダーに含まれるバージョン番号が、初期ストリームヘッダーに含まれるバージョン番号よりも少なくとも1つのメジャーバージョンであり、新しいバージョンエンティティが上記のように古いバージョンエンティティと相互運用できない場合、開始エンティティは<unsported- unsported-を生成する必要があります。バージョン/>ストリームエラーとXMLストリームと基礎となるTCP接続を終了します。
4. If either entity receives a stream header with no 'version' attribute, the entity MUST consider the version supported by the other entity to be "0.0" and SHOULD NOT include a 'version' attribute in the stream header it sends in reply.
4. いずれかのエンティティが「バージョン」属性のないストリームヘッダーを受信した場合、エンティティは、他のエンティティによってサポートされているバージョンを「0.0」と見なし、返信して送信するストリームヘッダーに「バージョン」属性を含めるべきではありません。
The stream element MUST possess both a streams namespace declaration and a default namespace declaration (as "namespace declaration" is defined in the XML namespaces specification [XML-NAMES]). For detailed information regarding the streams namespace and default namespace, see Namespace Names and Prefixes (Section 11.2).
ストリーム要素には、ストリーム名空間宣言とデフォルトの名前空間宣言の両方を所有する必要があります（「名前空間宣言」はXML Namespaces Specification [XML-Names]で定義されています）。Streamsの名前空間とデフォルトの名前空間に関する詳細については、名前空間名とプレフィックス（セクション11.2）を参照してください。
If the initiating entity includes the 'version' attribute set to a value of at least "1.0" in the initial stream header, the receiving entity MUST send a <features/> child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any stream-level features that can be negotiated (or capabilities that otherwise need to be advertised). Currently, this is used only to advertise Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7) as defined herein, and for Session Establishment as defined in [XMPP-IM]; however, the stream features functionality could be used to advertise other negotiable features in the future. If an entity does not understand or support some features, it SHOULD silently ignore them. If one or more security features (e.g., TLS and SASL) need to be successfully negotiated before a non-security-related feature (e.g., Resource Binding) can be offered, the non-security-related feature SHOULD NOT be included in the stream features that are advertised before the relevant security features have been negotiated.
開始エンティティに、初期ストリームヘッダーの「バージョン」属性が少なくとも「1.0」の値に設定されている場合、受信エンティティは開始エンティティに<feature/> child要素（streams namespace prefixの接頭辞）を送信する必要があります。ネゴシエートできるストリームレベルの機能（または宣伝する必要がある機能）を発表するため。現在、これは、TLS（セクション5）、SASL（セクション6）の使用、および[XMPP-IM]で定義されているセッション確立（セクション7）の使用を宣伝するためにのみ使用されています。ただし、ストリーム機能機能は、将来、他の交渉可能な機能を宣伝するために使用できます。エンティティがいくつかの機能を理解またはサポートしていない場合、それらを静かに無視する必要があります。非セキュリティ関連の機能（リソースバインディングなど）を提供する前に、1つ以上のセキュリティ機能（TLSやSASLなど）をうまく交渉する必要がある場合、セキュリティ関連の機能以外の機能をストリームに含めないでください関連するセキュリティ機能が交渉される前に宣伝されている機能。
The root stream element MAY contain an <error/> child element that is prefixed by the streams namespace prefix. The error child MUST be sent by a compliant entity (usually a server rather than a client) if it perceives that a stream-level error has occurred.
ルートストリーム要素には、Streams Namespace Prefixによってプレフィックスされた<エラー/>子要素が含まれている場合があります。エラー子は、ストリームレベルのエラーが発生したと認識している場合、準拠したエンティティ（通常はクライアントではなくサーバー）によって送信される必要があります。
The following rules apply to stream-level errors:
以下のルールは、ストリームレベルのエラーに適用されます。
o It is assumed that all stream-level errors are unrecoverable; therefore, if an error occurs at the level of the stream, the entity that detects the error MUST send a stream error to the other entity, send a closing </stream> tag, and terminate the underlying TCP connection.
o すべてのストリームレベルのエラーは回復できないと想定されています。したがって、ストリームのレベルでエラーが発生した場合、エラーを検出するエンティティは、他のエンティティにストリームエラーを送信し、クロージング</stream>タグを送信し、基礎となるTCP接続を終了する必要があります。
o If the error occurs while the stream is being set up, the receiving entity MUST still send the opening <stream> tag, include the <error/> element as a child of the stream element, send the closing </stream> tag, and terminate the underlying TCP connection. In this case, if the initiating entity provides an unknown host in the 'to' attribute (or provides no 'to' attribute at all), the server SHOULD provide the server's authoritative hostname in the 'from' attribute of the stream header sent before termination.
o ストリームがセットアップされている間にエラーが発生した場合、受信エンティティはまだ<エラー/>要素をストリーム要素の子として<エラー/>要素を含める必要があります</stream>タグを送信し、基礎となるTCP接続を終了します。この場合、開始エンティティが「to」属性に不明なホストを提供する場合（または '属性に属性を提供することはありません）、サーバーは以前に送信されたストリームヘッダーの「From」属性にサーバーの信頼できるホスト名を提供する必要があります終了。
The syntax for stream errors is as follows:
ストリームエラーの構文は次のとおりです。
<stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</stream:error>
The <error/> element:
<エラー/>要素：
o MUST contain a child element corresponding to one of the defined stanza error conditions defined below; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace
o 以下に定義されている定義されたスタンザエラー条件の1つに対応する子要素を含める必要があります。この要素は、「urn：ietf：params：xml：ns：xmpp-streams 'namespace」によって資格を与える必要があります
o MAY contain a <text/> child containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess an 'xml:lang' attribute specifying the natural language of the XML character data
o エラーをより詳細に説明するXML文字データを含む<テキスト/>子が含まれる場合があります。この要素は、「urn：ietf：params：xml：ns：xmpp-streams 'namespace」によって資格を付ける必要があります。
o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application-defined namespace, and its structure is defined by that namespace
o アプリケーション固有のエラー条件のための子要素が含まれる場合があります。この要素はアプリケーション定義の名前空間で適格である必要があり、その構造はその名前空間で定義されます
The <text/> element is OPTIONAL. If included, it SHOULD be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It SHOULD NOT be interpreted programmatically by an application. It SHOULD NOT be used as the error message presented to a user, but MAY be shown in addition to the error message associated with the included condition element (or elements).
<テキスト/>要素はオプションです。含まれている場合は、定義された条件またはアプリケーション固有の条件の意味を補完する記述情報または診断情報を提供するためにのみ使用する必要があります。アプリケーションによってプログラムで解釈されるべきではありません。ユーザーに提示されたエラーメッセージとして使用する必要はありませんが、含まれている条件要素（または要素）に関連付けられたエラーメッセージに加えて表示される場合があります。
The following stream-level error conditions are defined:
次のストリームレベルエラー条件が定義されています。
o <bad-format/> -- the entity has sent XML that cannot be processed; this error MAY be used instead of the more specific XML-related errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, and <xml-not-well-formed/>, although the more specific errors are preferred.
o <bad-format/> - エンティティは、処理できないXMLを送信しました。このエラーは、<bad-namespace-prefix/>、<invalid-xml/>、<risted-xml/>、<unsupported-encoding/>、<xmlなど、より特定のXML関連エラーの代わりに使用できます。-Well-formed/>、より具体的なエラーが推奨されますが。
o <bad-namespace-prefix/> -- the entity has sent a namespace prefix that is unsupported, or has sent no namespace prefix on an element that requires such a prefix (see XML Namespace Names and Prefixes (Section 11.2)).
o <bad-namespace-prefix/> - エンティティは、サポートされていない名前空間プレフィックスを送信するか、そのようなプレフィックスを必要とする要素に名前空間プレフィックスを送信していません（XMLネームスペース名とプレフィックス（セクション11.2）を参照）。
o <conflict/> -- the server is closing the active stream for this entity because a new stream has been initiated that conflicts with the existing stream.
o <comples/> - 既存のストリームと競合する新しいストリームが開始されたため、サーバーはこのエンティティのアクティブストリームを閉じています。
o <connection-timeout/> -- the entity has not generated any traffic over the stream for some period of time (configurable according to a local service policy).
o <Connection-TimeOut/> - エンティティは、ある期間ストリーム上のトラフィックを生成していません（ローカルサービスポリシーに従って構成可能）。
o <host-gone/> -- the value of the 'to' attribute provided by the initiating entity in the stream header corresponds to a hostname that is no longer hosted by the server.
o <host-gone/> - ストリームヘッダーの開始エンティティによって提供される 'to'属性の値は、サーバーによってホストされなくなったホスト名に対応します。
o <host-unknown/> -- the value of the 'to' attribute provided by the initiating entity in the stream header does not correspond to a hostname that is hosted by the server.
o <host-unknown/> - ストリームヘッダーの開始エンティティによって提供される 'to'属性の値は、サーバーがホストするホスト名に対応するものではありません。
o <improper-addressing/> -- a stanza sent between two servers lacks a 'to' or 'from' attribute (or the attribute has no value).
o <Impoper-Addressing/> - 2つのサーバー間で送信されるスタンザには、 'to'または '属性（または属性には値がありません）がありません。
o <internal-server-error/> -- the server has experienced a misconfiguration or an otherwise-undefined internal error that prevents it from servicing the stream.
o <internal-server-error/> - サーバーは、誤った構成またはそれ以外の場合は未定義の内部エラーが発生し、ストリームのサービスを防ぎます。
o <invalid-from/> -- the JID or hostname provided in a 'from' address does not match an authorized JID or validated domain negotiated between servers via SASL or dialback, or between a client and a server via authentication and resource binding.
o <invalid-from/> - 「From」アドレスで提供されるJIDまたはホスト名は、SASLまたはダイヤルバックを介してサーバー間、または認証とリソースのバインディングを介してクライアントとサーバー間で交渉された認定JIDまたは検証済みドメインと一致しません。
o <invalid-id/> -- the stream ID or dialback ID is invalid or does not match an ID previously provided.
o <invalid-id/> - ストリームIDまたはダイヤルバックIDが無効であるか、以前に提供されたIDと一致しません。
o <invalid-namespace/> -- the streams namespace name is something other than "http://etherx.jabber.org/streams" or the dialback namespace name is something other than "jabber:server:dialback" (see XML Namespace Names and Prefixes (Section 11.2)).
o <invalid-namespace/> - ストリーム名空間名は「http://etherx.jabber.org/streams」以外のものです。およびプレフィックス（セクション11.2））。
o <invalid-xml/> -- the entity has sent invalid XML over the stream to a server that performs validation (see Validation (Section 11.3)).
o <invalid-xml/> - エンティティは、検証を実行するサーバーにストリームを介して無効なXMLを送信しました（検証（セクション11.3）を参照）。
o <not-authorized/> -- the entity has attempted to send data before the stream has been authenticated, or otherwise is not authorized to perform an action related to stream negotiation; the receiving entity MUST NOT process the offending stanza before sending the stream error.
o <not-outhorized/> - エンティティは、ストリームが認証される前にデータを送信しようとしました。受信エンティティは、ストリームエラーを送信する前に問題のあるスタンザを処理してはなりません。
o <policy-violation/> -- the entity has violated some local service policy; the server MAY choose to specify the policy in the <text/> element or an application-specific condition element.
o <Policy-Violation/> - エンティティは、いくつかのローカルサービスポリシーに違反しています。サーバーは、<テキスト/>要素またはアプリケーション固有の条件要素でポリシーを指定することを選択できます。
o <remote-connection-failed/> -- the server is unable to properly connect to a remote entity that is required for authentication or authorization.
o <remote-connection-fail/> - サーバーは、認証または承認に必要なリモートエンティティに適切に接続できません。
o <resource-constraint/> -- the server lacks the system resources necessary to service the stream.
o <Resource-Constraint/> - サーバーには、ストリームのサービスに必要なシステムリソースがありません。
o <restricted-xml/> -- the entity has attempted to send restricted XML features such as a comment, processing instruction, DTD, entity reference, or unescaped character (see Restrictions (Section 11.1)).
o <restricted-xml/> - エンティティは、コメント、処理命令、DTD、エンティティリファレンス、または非避けた文字などの制限付きXML機能を送信しようとしました（制限（セクション11.1）を参照）。
o <see-other-host/> -- the server will not provide service to the initiating entity but is redirecting traffic to another host; the server SHOULD specify the alternate hostname or IP address (which MUST be a valid domain identifier) as the XML character data of the <see-other-host/> element.
o <see-other-host/> - サーバーは開始エンティティにサービスを提供するのではなく、別のホストへのトラフィックをリダイレクトしています。サーバーは、<see-other-host/>要素のXML文字データとして、代替ホスト名またはIPアドレス（有効なドメイン識別子である必要があります）を指定する必要があります。
o <system-shutdown/> -- the server is being shut down and all active streams are being closed.
o <System-Shutdown/> - サーバーがシャットダウンされており、すべてのアクティブストリームが閉じられています。
o <undefined-condition/> -- the error condition is not one of those defined by the other conditions in this list; this error condition SHOULD be used only in conjunction with an application-specific condition.
o <未定義の条件/> - エラー条件は、このリストの他の条件で定義されている条件の1つではありません。このエラー条件は、アプリケーション固有の条件と組み合わせてのみ使用する必要があります。
o <unsupported-encoding/> -- the initiating entity has encoded the stream in an encoding that is not supported by the server (see Character Encoding (Section 11.5)).
o <unsupported-encoding/> - 開始エンティティは、サーバーによってサポートされていないエンコードでストリームをエンコードしました（文字エンコード（セクション11.5）を参照）。
o <unsupported-stanza-type/> -- the initiating entity has sent a first-level child of the stream that is not supported by the server.
o <unsupported-stanza-type/> - 開始エンティティは、サーバーによってサポートされていないストリームの第1レベルの子を送信しました。
o <unsupported-version/> -- the value of the 'version' attribute provided by the initiating entity in the stream header specifies a version of XMPP that is not supported by the server; the server MAY specify the version(s) it supports in the <text/> element.
o <unsupported-version/> - ストリームヘッダー内の開始エンティティが提供する「バージョン」属性の値は、サーバーによってサポートされていないXMPPのバージョンを指定します。サーバーは、<text/>要素でサポートするバージョンを指定できます。
o <xml-not-well-formed/> -- the initiating entity has sent XML that is not well-formed as defined by [XML].
o <xml-not-well-formed/> - 開始エンティティは、[xml]で定義されているようによく形成されていないXMLを送信しました。
As noted, an application MAY provide application-specific stream error information by including a properly-namespaced child in the error element. The application-specific element SHOULD supplement or further qualify a defined element. Thus the <error/> element will contain two or three child elements:
前述のように、アプリケーションは、エラー要素に適切に名前付けされた子供を含めることにより、アプリケーション固有のストリームエラー情報を提供する場合があります。アプリケーション固有の要素は、定義された要素を補足するか、さらに修飾する必要があります。したがって、<エラー/>要素には2つまたは3つの子要素が含まれます。
<stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/>
</stream:error>
</stream:stream>
This section contains two simplified examples of a stream-based "session" of a client on a server (where the "C" lines are sent from the client to the server, and the "S" lines are sent from the server to the client); these examples are included for the purpose of illustrating the concepts introduced thus far.
このセクションには、サーバー上のクライアントのストリームベースの「セッション」の2つの簡略化された例（「C」行がクライアントからサーバーに送信され、「S」行がサーバーからクライアントに送信されます。）;これらの例は、これまでに導入された概念を説明する目的で含まれています。
A basic "session":
基本的な「セッション」：
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message from='juliet@example.com'
to='romeo@example.net'
xml:lang='en'>
C: <body>Art thou not Romeo, and a Montague?</body>
C: </message>
S: <message from='romeo@example.net'
to='juliet@example.com'
xml:lang='en'>
S: <body>Neither, fair saint, if either thee dislike.</body>
S: </message>
C: </stream:stream>
S: </stream:stream>
A "session" gone bad:
C: <?xml version='1.0'?>
<stream:stream
to='example.com'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='someid'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
version='1.0'>
... encryption, authentication, and resource binding ...
C: <message xml:lang='en'>
<body>Bad XML, no closing body tag!
</message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
S: </stream:stream>
XMPP includes a method for securing the stream from tampering and eavesdropping. This channel encryption method makes use of the Transport Layer Security (TLS) protocol [TLS], along with a "STARTTLS" extension that is modelled after similar extensions for the IMAP [IMAP], POP3 [POP3], and ACAP [ACAP] protocols as described in RFC 2595 [USINGTLS]. The namespace name for the STARTTLS extension is 'urn:ietf:params:xml:ns:xmpp-tls'.
XMPPには、改ざんや盗聴からストリームを保護する方法が含まれています。このチャネル暗号化法は、IMAP [IMAP]、POP3 [POP3]、およびACAP [ACAP]プロトコルの同様の拡張後にモデル化された「startTLS」拡張機能とともに、トランスポートレイヤーセキュリティ（TLS）プロトコル[TLS]を使用します。RFC 2595で説明されているように[を使用]。startTLS拡張子の名前空間名は「urn：ietf：params：xml：ns：xmpp-tls」です。
An administrator of a given domain MAY require the use of TLS for client-to-server communications, server-to-server communications, or both. Clients SHOULD use TLS to secure the streams prior to attempting the completion of SASL negotiation (Section 6), and servers SHOULD use TLS between two domains for the purpose of securing server-to-server communications.
特定のドメインの管理者は、クライアント間通信、サーバー間通信、またはその両方にTLSを使用する必要がある場合があります。クライアントは、SASL交渉の完了を試みる前にTLSを使用してストリームを保護する必要があり（セクション6）、サーバーはサーバー間通信を保護するために2つのドメイン間でTLSを使用する必要があります。
The following rules apply:
次のルールが適用されます。
1. An initiating entity that complies with this specification MUST include the 'version' attribute set to a value of "1.0" in the initial stream header.
1. この仕様に準拠する開始エンティティには、初期ストリームヘッダーの「1.0」の値に設定された「バージョン」属性を含める必要があります。
2. If the TLS negotiation occurs between two servers, communications MUST NOT proceed until the Domain Name System (DNS) hostnames asserted by the servers have been resolved (see Server-to-Server Communications (Section 14.4)).
2. TLS交渉が2つのサーバー間で発生した場合、サーバーによって主張されたドメイン名システム（DNS）ホスト名が解決されるまで通信を進めてはなりません（サーバー間通信（セクション14.4）を参照）。
3. When a receiving entity that complies with this specification receives an initial stream header that includes the 'version' attribute set to a value of at least "1.0", after sending a stream header in reply (including the version flag), it MUST include a <starttls/> element (qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list of other stream features it supports.
3. この仕様に準拠する受信エンティティが、応答（バージョンフラグを含む）でストリームヘッダーを送信した後、少なくとも「1.0」の値に設定された「バージョン」属性を含む初期ストリームヘッダーを受信する場合、それは含める必要があります。<starttls/> element（ 'urn：ietf：params：xml：ns：xmpp-tls' namespaceで認定されます）と、サポートする他のストリーム機能のリスト。
4. If the initiating entity chooses to use TLS, TLS negotiation MUST be completed before proceeding to SASL negotiation; this order of negotiation is required to help safeguard authentication information sent during SASL negotiation, as well as to make it possible to base the use of the SASL EXTERNAL mechanism on a certificate provided during prior TLS negotiation.
4. 開始エンティティがTLSを使用することを選択した場合、SASL交渉に進む前にTLS交渉を完了する必要があります。この交渉の順序は、SASL交渉中に送信された認証情報を保護するのを支援し、以前のTLS交渉中に提供された証明書にSASL外部メカニズムの使用を可能にするために必要です。
5. During TLS negotiation, an entity MUST NOT send any white space characters (matching production [3] content of [XML]) within the root stream element as separators between elements (any white space characters shown in the TLS examples below are included for the sake of readability only); this prohibition helps to ensure proper security layer byte precision.
5. TLS交渉中、エンティティは、要素間の分離器としてルートストリーム要素内でホワイトスペース文字（[XML]の一致[3]コンテンツ）を送信してはなりません（以下のTLSの例に示されている空白の文字は、ために含まれています。読みやすさのみ）;この禁止は、適切なセキュリティレイヤーバイトの精度を確保するのに役立ちます。
6. The receiving entity MUST consider the TLS negotiation to have begun immediately after sending the closing ">" character of the <proceed/> element. The initiating entity MUST consider the TLS negotiation to have begun immediately after receiving the closing ">" character of the <proceed/> element from the receiving entity.
6. 受信エンティティは、<進行/>要素の閉鎖「>」文字を送信した直後にTLS交渉が始まったと考える必要があります。開始エンティティは、受信エンティティから<継続/>要素の閉鎖「>」文字を受け取った直後にTLS交渉が始まったと考える必要があります。
7. The initiating entity MUST validate the certificate presented by the receiving entity; see Certificate Validation (Section 14.2) regarding certificate validation procedures.
7. 開始エンティティは、受信エンティティによって提示された証明書を検証する必要があります。証明書の検証手順に関する証明書の検証（セクション14.2）を参照してください。
8. Certificates MUST be checked against the hostname as provided by the initiating entity (e.g., a user), not the hostname as resolved via the Domain Name System; e.g., if the user specifies a hostname of "example.com" but a DNS SRV [SRV] lookup returned
8. ドメイン名システムを介して解決されたホスト名ではなく、開始エンティティ（例：ユーザー）が提供するホスト名に対して証明書を確認する必要があります。たとえば、ユーザーが「Example.com」のホスト名を指定しているが、DNS SRV [SRV]ルックアップが返された場合
"im.example.com", the certificate MUST be checked as "example.com". If a JID for any kind of XMPP entity (e.g., client or server) is represented in a certificate, it MUST be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id-on-xmppAddr" specified in Section 5.1.1 of this document.
「im.example.com」、証明書は「example.com」としてチェックする必要があります。あらゆる種類のXMPPエンティティ（クライアントまたはサーバーなど）のJIDが証明書に表されている場合、[asn.1]オブジェクト識別子 "id-onを使用して、subjectaltname内の他の名前のエンティティ内のutf8stringとして表現する必要があります。-XMPPADDR」このドキュメントのセクション5.1.1で指定されています。
9. If the TLS negotiation is successful, the receiving entity MUST discard any knowledge obtained in an insecure manner from the initiating entity before TLS takes effect.
9. TLS交渉が成功した場合、受信エンティティは、TLSが有効になる前に、開始エンティティから不安定な方法で得られた知識を廃棄する必要があります。
10. If the TLS negotiation is successful, the initiating entity MUST discard any knowledge obtained in an insecure manner from the receiving entity before TLS takes effect.
10. TLS交渉が成功した場合、開始エンティティは、TLSが有効になる前に、受信エンティティから取得されていない方法で得られた知識を廃棄する必要があります。
11. If the TLS negotiation is successful, the receiving entity MUST NOT offer the STARTTLS extension to the initiating entity along with the other stream features that are offered when the stream is restarted.
11. TLS交渉が成功した場合、受信エンティティは、ストリームの再起動時に提供される他のストリーム機能とともに、開始エンティティにStartTLS拡張機能を提供してはなりません。
12. If the TLS negotiation is successful, the initiating entity MUST continue with SASL negotiation.
12. TLS交渉が成功した場合、開始エンティティはSASL交渉を続けなければなりません。
13. If the TLS negotiation results in failure, the receiving entity MUST terminate both the XML stream and the underlying TCP connection.
13. TLS交渉が失敗につながる場合、受信エンティティはXMLストリームと基礎となるTCP接続の両方を終了する必要があります。
14. See Mandatory-to-Implement Technologies (Section 14.7) regarding mechanisms that MUST be supported.
14. サポートする必要があるメカニズムについては、必須の実装技術（セクション14.7）を参照してください。
The [ASN.1] Object Identifier "id-on-xmppAddr" described above is defined as follows:
上記の[asn.1]オブジェクト識別子「id-on-xmppaddr」は、次のように定義されています。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
XmppAddr ::= UTF8String
This Object Identifier MAY also be represented in the dotted display format as "1.3.6.1.5.5.7.8.5".
このオブジェクト識別子は、点線ディスプレイ形式で「1.3.6.1.1.5.5.7.8.8.5」として表現することもできます。
When an initiating entity secures a stream with a receiving entity using TLS, the steps involved are as follows:
開始エンティティがTLSを使用して受信エンティティでストリームを確保する場合、関連するステップは次のとおりです。
1. The initiating entity opens a TCP connection and initiates the stream by sending the opening XML stream header to the receiving entity, including the 'version' attribute set to a value of at least "1.0".
1. 開始エンティティは、TCP接続を開き、オープニングXMLストリームヘッダーを受信エンティティに送信することによりストリームを開始します。
2. The receiving entity responds by opening a TCP connection and sending an XML stream header to the initiating entity, including the 'version' attribute set to a value of at least "1.0".
2. 受信エンティティは、TCP接続を開き、XMLストリームヘッダーを開始エンティティに送信することにより応答します。これには、「バージョン」属性が少なくとも「1.0」の値に設定されています。
3. The receiving entity offers the STARTTLS extension to the initiating entity by including it with the list of other supported stream features (if TLS is required for interaction with the receiving entity, it SHOULD signal that fact by including a <required/> element as a child of the <starttls/> element).
3. 受信エンティティは、他のサポートされているストリーム機能のリストに含めることにより、開始エンティティへのStartTLS拡張を提供します（受信エンティティとの相互作用にTLSが必要な場合、子供として必要な/>要素を含めることにより、その事実を示す必要があります。<starttls/>要素の）。
4. The initiating entity issues the STARTTLS command (i.e., a <starttls/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the receiving entity that it wishes to begin a TLS negotiation to secure the stream.
4. 開始エンティティは、StartTLSコマンド（つまり、 'urn：ietf：params：xml：ns：xmpp-tls' namespaceによって認定された<starttls/>要素）を発行します。ストリームを確保します。
5. The receiving entity MUST reply with either a <proceed/> element or a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case occurs, the receiving entity MUST terminate both the XML stream and the underlying TCP connection. If the proceed case occurs, the entities MUST attempt to complete the TLS negotiation over the TCP connection and MUST NOT send any further XML data until the TLS negotiation is complete.
5. 受信エンティティは、 'urn：ietf：params：xml：ns：xmpp-tls' namespaceで認定されたa <継続/>要素または<故障/>要素のいずれかで返信する必要があります。障害ケースが発生した場合、受信エンティティはXMLストリームと基礎となるTCP接続の両方を終了する必要があります。続行ケースが発生した場合、エンティティはTCP接続を介したTLS交渉を完了しようとする必要があり、TLS交渉が完了するまでXMLデータをさらに送信してはなりません。
6. The initiating entity and receiving entity attempt to complete a TLS negotiation in accordance with [TLS].
6. 開始エンティティと受信エンティティは、[TLS]に従ってTLS交渉を完了しようとします。
7. If the TLS negotiation is unsuccessful, the receiving entity MUST terminate the TCP connection. If the TLS negotiation is successful, the initiating entity MUST initiate a new stream by sending an opening XML stream header to the receiving entity (it is not necessary to send a closing </stream> tag first, since the receiving entity and initiating entity MUST consider the original stream to be closed upon successful TLS negotiation).
7. TLS交渉が失敗した場合、受信エンティティはTCP接続を終了する必要があります。TLS交渉が成功した場合、開始エンティティは、受信エンティティと開始エンティティが必要なため、最初のXMLストリームヘッダーを受信エンティティに送信して新しいストリームを開始する必要があります</stream>タグを最初に送信する必要はありません</stream>タグを送信する必要はありません。成功したTLS交渉時に閉鎖される元のストリームを考慮してください）。
8. Upon receiving the new stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity along with the available features (but not including the STARTTLS feature).
8. 開始エンティティから新しいストリームヘッダーを受信すると、受信エンティティは、利用可能な機能とともに新しいXMLストリームヘッダーを開始エンティティに送信することで応答する必要があります（ただし、StartTLS機能は含まれません）。
The following example shows the data flow for a client securing a stream using STARTTLS (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
次の例は、startTLSを使用してストリームを保護するクライアントのデータフローを示しています（注：障害ケースのプロトコルを説明するために、以下に示す別の手順は提供されています。網羅的ではなく、例で送信されたデータによって必ずしもトリガーされるわけではありません。）。
Step 1: Client initiates stream to server:
ステップ1：クライアントはストリームをサーバーに開始します：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server responds by sending a stream tag to client:
ステップ2：サーバーは、クライアントにストリームタグを送信することで応答します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_123'
from='example.com'
version='1.0'>
Step 3: Server sends the STARTTLS extension to client along with authentication mechanisms and any other stream features:
ステップ3：サーバーは、認証メカニズムとその他のストリーム機能とともに、StartTLS拡張機能をクライアントに送信します。
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Step 4: Client sends the STARTTLS command to server:
ステップ4：クライアントはStartTLSコマンドをサーバーに送信します。
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> Step 5: Server informs client that it is allowed to proceed:
<starttls xmlns = 'urn：ietf：params：xml：ns：xmpp-tls'/>ステップ5：サーバーは、続行が許可されていることをクライアントに通知します。
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5 (alt): Server informs client that TLS negotiation has failed and closes both stream and TCP connection:
ステップ5（ALT）：サーバーは、TLS交渉が失敗し、ストリームとTCP接続の両方を閉じることをクライアントに通知します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
Step 6: Client and server attempt to complete TLS negotiation over the existing TCP connection.
ステップ6：クライアントとサーバーは、既存のTCP接続を介したTLS交渉を完了しようとします。
Step 7: If TLS negotiation is successful, client initiates a new stream to server:
ステップ7：TLS交渉が成功した場合、クライアントはサーバーに新しいストリームを開始します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP connection.
ステップ7（ALT）：TLS交渉に失敗した場合、サーバーはTCP接続を閉じます。
Step 8: Server responds by sending a stream header to client along with any available stream features:
ステップ8：サーバーは、利用可能なストリーム機能とともにクライアントにストリームヘッダーを送信することで応答します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='c2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
Step 9: Client continues with SASL negotiation (Section 6).
ステップ9：クライアントはSASL交渉を続けます（セクション6）。
The following example shows the data flow for two servers securing a stream using STARTTLS (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
次の例は、StartTLSを使用してストリームを保護する2つのサーバーのデータフローを示しています（注：障害ケースのプロトコルを説明するために、以下に示す代替手順は網羅的ではなく、例で送信されたデータによって必ずしもトリガーされるわけではありません。）。
Step 1: Server1 initiates stream to Server2:
ステップ1：Server1はStreamをServer2に開始します。
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server2 responds by sending a stream tag to Server1:
ステップ2：Server2は、Server1にストリームタグを送信して応答します。
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_123'
version='1.0'>
Step 3: Server2 sends the STARTTLS extension to Server1 along with authentication mechanisms and any other stream features:
ステップ3：server2は、認証メカニズムとその他のストリーム機能とともに、StartTLS拡張機能をServer1に送信します。
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
Step 4: Server1 sends the STARTTLS command to Server2:
ステップ4：server1 starttlsコマンドをserver2に送信します。
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5: Server2 informs Server1 that it is allowed to proceed:
ステップ5：server2は、server1に続行できることを通知します。
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed and closes stream:
<xmlns = 'urn：ietf：params：xml：ns：xmpp-tls'/>ステップ5（alt）：server2に、TLS交渉が失敗し、ストリームを閉じることをserver1に通知します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
Step 6: Server1 and Server2 attempt to complete TLS negotiation via TCP.
ステップ6：Server1とServer2は、TCPを介したTLS交渉を完了しようとします。
Step 7: If TLS negotiation is successful, Server1 initiates a new stream to Server2:
ステップ7：TLS交渉が成功した場合、Server1はServer2の新しいストリームを開始します。
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP connection.
ステップ7（ALT）：TLSネゴシエーションが失敗した場合、Server2はTCP接続を閉じます。
Step 8: Server2 responds by sending a stream header to Server1 along with any available stream features:
ステップ8：Server2は、利用可能なストリーム機能とともにServer1にストリームヘッダーを送信して応答します。
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
Step 9: Server1 continues with SASL negotiation (Section 6).
ステップ9：Server1はSASL交渉（セクション6）で続行します。
XMPP includes a method for authenticating a stream by means of an XMPP-specific profile of the Simple Authentication and Security Layer (SASL) protocol [SASL]. SASL provides a generalized method for adding authentication support to connection-based protocols, and XMPP uses a generic XML namespace profile for SASL that conforms to the profiling requirements of [SASL].
XMPPには、単純な認証およびセキュリティレイヤー（SASL）プロトコル[SASL]のXMPP固有のプロファイルを使用して、ストリームを認証する方法が含まれています。SASLは、接続ベースのプロトコルに認証サポートを追加するための一般化された方法を提供し、XMPPは[SASL]のプロファイリング要件に準拠するSASLの汎用XMLネームスペースプロファイルを使用します。
The following rules apply:
次のルールが適用されます。
1. If the SASL negotiation occurs between two servers, communications MUST NOT proceed until the Domain Name System (DNS) hostnames asserted by the servers have been resolved (see Server-to-Server Communications (Section 14.4)).
1. SASLの交渉が2つのサーバー間で発生した場合、サーバーによって主張されたドメイン名システム（DNS）ホスト名が解決されるまで通信を進めてはなりません（サーバー間通信（セクション14.4）を参照）。
2. If the initiating entity is capable of SASL negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the initial stream header.
2. 開始エンティティがSASL交渉が可能である場合、「バージョン」属性を初期ストリームヘッダーの少なくとも「1.0」の値に含める必要があります。
3. If the receiving entity is capable of SASL negotiation, it MUST advertise one or more authentication mechanisms within a <mechanisms/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the opening stream tag received from the initiating entity (if the opening stream tag included the 'version' attribute set to a value of at least "1.0").
3. 受信エンティティがSASL交渉が可能である場合、 'urn：ietf：xml：ns：xmpp-sasl' namkesspaceによって認定された<メカニズム/>要素内で1つ以上の認証メカニズムを宣伝する必要があります。開始エンティティから受信したタグ（オープニングストリームタグに、「バージョン」属性が少なくとも「1.0」の値に設定されている場合）。
4. During SASL negotiation, an entity MUST NOT send any white space characters (matching production [3] content of [XML]) within the root stream element as separators between elements (any white space characters shown in the SASL examples below are included for the sake of readability only); this prohibition helps to ensure proper security layer byte precision.
4. SASLの交渉中、エンティティは、要素間の分離器としてルートストリーム要素内でホワイトスペース文字（[xml]の一致[3]コンテンツ）を送信してはなりません（以下のSASLの例に示されている空白の文字は、ために含まれています。読みやすさのみ）;この禁止は、適切なセキュリティレイヤーバイトの精度を確保するのに役立ちます。
5. Any XML character data contained within the XML elements used during SASL negotiation MUST be encoded using base64, where the encoding adheres to the definition in Section 3 of RFC 3548 [BASE64].
5. SASLネゴシエーション中に使用されるXML要素に含まれるXML文字データは、base64を使用してエンコードする必要があります。ここで、エンコーディングはRFC 3548のセクション3の定義を順守します[Base64]。
6. If provision of a "simple username" is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in a domain identifier) in the case of server-to-server communications or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communications.
6. 「単純なユーザー名」の提供が選択されたSASLメカニズム（例えば、これはダイジェストMD5およびCRAM-MD5メカニズムによってサポートされているが、外部およびGSSAPIメカニズムによってはサポートされていない場合）では、認証中に開始エンティティは提供する必要があります。サーバーからサーバーへの通信またはその登録アカウント名（XMPPノード識別子に含まれるユーザーまたはノード名）の場合の送信ドメイン（ドメイン識別子に含まれるIPアドレスまたは完全に適格なドメイン名）クライアント間通信のケース。
7. If the initiating entity wishes to act on behalf of another entity and the selected SASL mechanism supports transmission of an authorization identity, the initiating entity MUST provide an authorization identity during SASL negotiation. If the initiating entity does not wish to act on behalf of another entity, it MUST NOT provide an authorization identity. As specified in [SASL], the initiating entity MUST NOT provide an authorization identity unless the authorization identity is different from the default authorization identity derived from the authentication identity as described in [SASL]. If provided, the value of the authorization identity MUST be of the form <domain> (i.e., a domain identifier only) for servers and of the form <node@domain> (i.e., node identifier and domain identifier) for clients.
7. 開始エンティティが別のエンティティに代わって行動したい場合、選択されたSASLメカニズムが認可IDの送信をサポートする場合、開始エンティティはSASL交渉中に認可IDを提供する必要があります。開始エンティティが別のエンティティに代わって行動することを望まない場合、承認アイデンティティを提供してはなりません。[SASL]で指定されているように、[SASL]で説明されているように認証IDから導出されたデフォルトの認証IDとは異なる場合を除き、開始エンティティは認証IDを提供してはなりません。提供されている場合、承認IDの値は、サーバーのフォーム<domain>（つまり、ドメイン識別子のみ）およびクライアントのフォーム<node@domain>（すなわち、ノード識別子とドメイン識別子）のフォームでなければなりません。
8. Upon successful SASL negotiation that involves negotiation of a security layer, the receiving entity MUST discard any knowledge obtained from the initiating entity which was not obtained from the SASL negotiation itself.
8. セキュリティレイヤーの交渉を伴うSASL交渉が成功した場合、受信エンティティは、SASL交渉自体から得られなかった開始エンティティから得られた知識を捨てなければなりません。
9. Upon successful SASL negotiation that involves negotiation of a security layer, the initiating entity MUST discard any knowledge obtained from the receiving entity which was not obtained from the SASL negotiation itself.
9. セキュリティレイヤーの交渉を伴うSASL交渉が成功した場合、開始エンティティは、SASL交渉自体から得られなかった受信エンティティから得られた知識を破棄しなければなりません。
10. See Mandatory-to-Implement Technologies (Section 14.7) regarding mechanisms that MUST be supported.
10. サポートする必要があるメカニズムについては、必須の実装技術（セクション14.7）を参照してください。
When an initiating entity authenticates with a receiving entity using SASL, the steps involved are as follows:
SASLを使用して開始エンティティが受信エンティティで認証される場合、関連するステップは次のとおりです。
1. The initiating entity requests SASL authentication by including the 'version' attribute in the opening XML stream header sent to the receiving entity, with the value set to "1.0".
1. 開始エンティティは、値を「1.0」に設定して、受信エンティティに送信されたXMLストリームヘッダーの「バージョン」属性を含めることにより、SASL認証を要求します。
2. After sending an XML stream header in reply, the receiving entity advertises a list of available SASL authentication mechanisms; each of these is a <mechanism/> element included as a child within a <mechanisms/> container element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a child of a <features/> element in the streams namespace. If Use of TLS (Section 5) needs to be established before a particular authentication mechanism may be used, the receiving entity MUST NOT provide that mechanism in the list of available SASL authentication mechanisms prior to TLS negotiation. If the initiating entity presents a valid certificate during prior TLS negotiation, the receiving entity SHOULD offer the SASL EXTERNAL mechanism to the initiating entity during SASL negotiation (refer to [SASL]), although the EXTERNAL mechanism MAY be offered under other circumstances as well.
2. XMLストリームヘッダーを返信して送信した後、受信エンティティは利用可能なSASL認証メカニズムのリストを宣伝します。これらのそれぞれは、<メカニズム/>>コンテナ要素内の子供として 'urn：ietf：params：xml：ns：xmpp-sasl' namespaceによって含まれる<メカニズム/>要素に含まれています。<feature/> streams namespaceの要素。特定の認証メカニズムを使用する前にTLS（セクション5）を確立する必要がある場合、受信エンティティは、TLS交渉前に利用可能なSASL認証メカニズムのリストにそのメカニズムを提供してはなりません。開始エンティティが以前のTLS交渉中に有効な証明書を提示する場合、受信エンティティはSASL交渉中にSASL外部メカニズムを開始エンティティに提供する必要があります（[SASL]を参照）が、外部メカニズムは他の状況下でも提供される場合があります。
3. The initiating entity selects a mechanism by sending an <auth/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity and including an appropriate value for the 'mechanism' attribute. This element MAY contain XML character data (in SASL terminology, the "initial response") if the mechanism supports or requires it; if the initiating entity needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ("="), which indicates that the response is present but contains no data.
3. 開始エンティティは、「urn：ietf：params：xml：ns：xmpp-sasl」名前空間によって認定された<auth/>要素を受信エンティティに送信し、「メカニズム」属性の適切な値を含めることにより、メカニズムを選択します。この要素には、メカニズムがそれをサポートまたは要求する場合、XML文字データ（SASL用語、「初期応答」）が含まれる場合があります。開始エンティティがゼロの長さの初期応答を送信する必要がある場合、応答が存在するがデータが含まれていないことを示す単一の等しい記号（ "="）として応答を送信する必要があります。
4. If necessary, the receiving entity challenges the initiating entity by sending a <challenge/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity; this element MAY contain XML character data (which MUST be computed in accordance with the definition of the SASL mechanism chosen by the initiating entity).
4. 必要に応じて、受信エンティティは、「urn：ietf：params：xml：ns：xmpp-sasl 'namespace」によって認定された<challenge/>要素を送信することにより、開始エンティティに挑戦します。この要素には、XML文字データが含まれている場合があります（開始エンティティによって選択されたSASLメカニズムの定義に従って計算する必要があります）。
5. The initiating entity responds to the challenge by sending a <response/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity; this element MAY contain XML character data (which MUST be computed in accordance with the definition of the SASL mechanism chosen by the initiating entity).
5. 開始エンティティは、「urn：ietf：params：xml：ns：xmpp-sasl 'namespace」によって認定された<応答/>要素を受信エンティティに送信することにより、チャレンジに対応します。この要素には、XML文字データが含まれている場合があります（開始エンティティによって選択されたSASLメカニズムの定義に従って計算する必要があります）。
6. If necessary, the receiving entity sends more challenges and the initiating entity sends more responses.
6. 必要に応じて、受信エンティティはより多くの課題を送信し、開始エンティティはより多くの応答を送信します。
This series of challenge/response pairs continues until one of three things happens:
この一連のチャレンジ/応答ペアは、3つのことのいずれかが起こるまで続きます。
1. The initiating entity aborts the handshake by sending an <abort/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving entity. Upon receiving an <abort/> element, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2), after which it MUST terminate the TCP connection; this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly-provided credentials (e.g., a mistyped password) without being forced to reconnect.
1. 開始エンティティは、「urn：ietf：params：xml：ns：xmpp-sasl 'namespace」によって認定された<abort/>要素を受信エンティティに送信することにより、握手を中止します。<abort/>要素を受信すると、受信エンティティは構成可能だが合理的な数のレトリ（少なくとも2）を許可する必要があります。その後、TCP接続を終了する必要があります。これにより、開始エンティティ（エンドユーザークライアントなど）が、再接続を強いられずに、誤って提供された資格情報（例：誤ったパスワード）を許容できるようになります。
2. The receiving entity reports failure of the handshake by sending a <failure/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity (the particular cause of failure SHOULD be communicated in an appropriate child element of the <failure/> element as defined under SASL Errors (Section 6.4)). If the failure case occurs, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2), after which it MUST terminate the TCP connection; this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly-provided credentials (e.g., a mistyped password) without being forced to reconnect.
2. 受信エンティティは、「urn：ietf：params：xml：ns：xmpp-sasl 'namespaceが開始エンティティに認定された<故障/>要素を送信することにより、握手の障害を報告します（障害の特定の原因は、SASLエラー（セクション6.4）で定義されている<故障/>要素の適切な子要素。障害ケースが発生した場合、受信エンティティは構成可能だが合理的な数のレトリ（少なくとも2）を許可する必要があります。その後、TCP接続を終了する必要があります。これにより、開始エンティティ（エンドユーザークライアントなど）が、再接続を強いられずに、誤って提供された資格情報（例：誤ったパスワード）を許容できるようになります。
3. The receiving entity reports success of the handshake by sending a <success/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating entity; this element MAY contain XML character data (in SASL terminology, "additional data with success") if required by the chosen SASL mechanism. Upon receiving the <success/> element, the initiating entity MUST initiate a new stream by sending an opening XML stream header to the receiving entity (it is not necessary to send a closing </stream> tag first, since the receiving entity and initiating entity MUST consider the original stream to be closed upon sending or receiving the <success/> element). Upon receiving the new stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity, along with any available features (but not including the STARTTLS and SASL features) or an empty <features/> element (to signify that no additional features are available); any such additional features not defined herein MUST be defined by the relevant extension to XMPP.
3. 受信エンティティは、「urn：ietf：params：xml：ns：xmpp-sasl 'namespace」によって認定された<success/>要素を開始エンティティに送信することにより、握手の成功を報告します。この要素には、選択されたSASLメカニズムで要求されている場合、XML文字データ（SASL用語、「成功した追加データ」）が含まれる場合があります。<success/>要素を受信すると、開始エンティティはxmlストリームヘッダーを受信エンティティに送信して新しいストリームを開始する必要があります（受信エンティティと開始から開始するため、最初に</stream>タグを送信する必要はありません</stream>タグを送信する必要はありません。エンティティは、<success/>要素を送信または受信すると、元のストリームを閉じていると考える必要があります。開始エンティティから新しいストリームヘッダーを受信すると、受信エンティティは、新しいXMLストリームヘッダーを開始エンティティに送信して応答する必要があります。要素（追加機能が利用できないことを意味するため）;本明細書で定義されていないこのような追加機能は、XMPPへの関連する拡張機能によって定義する必要があります。
The profiling requirements of [SASL] require that the following information be supplied by a protocol definition:
[SASL]のプロファイリング要件は、次の情報をプロトコル定義によって提供する必要があります。
service name: "xmpp"
サービス名：「XMPP」
initiation sequence: After the initiating entity provides an opening XML stream header and the receiving entity replies in kind, the receiving entity provides a list of acceptable authentication methods. The initiating entity chooses one method from the list and sends it to the receiving entity as the value of the 'mechanism' attribute possessed by an <auth/> element, optionally including an initial response to avoid a round trip.
開始シーケンス：開始エンティティがXMLストリームヘッダーを開始し、受信エンティティが種類の応答を提供した後、受信エンティティは許容可能な認証方法のリストを提供します。開始エンティティは、リストから1つのメソッドを選択し、<auth/>要素が所有する「メカニズム」属性の値として受信エンティティに送信します。
exchange sequence: Challenges and responses are carried through the exchange of <challenge/> elements from receiving entity to initiating entity and <response/> elements from initiating entity to receiving entity. The receiving entity reports failure by sending a <failure/> element and success by sending a <success/> element; the initiating entity aborts the exchange by sending an <abort/> element. Upon successful negotiation, both sides consider the original XML stream to be closed and new stream headers are sent by both entities.
交換シーケンス：課題と応答は、受信エンティティからエンティティの開始への<challenge/>要素の交換と、エンティティの開始から受信エンティティへの<応答/>要素の交換を通じて行われます。受信エンティティは、<fails/>要素と成功を送信して<success/>要素を送信することにより障害を報告します。開始エンティティは、<abort/>要素を送信することにより、交換を中止します。交渉が成功すると、双方は元のXMLストリームを閉じていると考え、新しいストリームヘッダーは両方のエンティティによって送信されます。
security layer negotiation: The security layer takes effect immediately after sending the closing ">" character of the <success/> element for the receiving entity, and immediately after receiving the closing ">" character of the <success/> element for the initiating entity. The order of layers is first [TCP], then [TLS], then [SASL], then XMPP.
セキュリティ層の交渉：セキュリティレイヤーは、受信エンティティの<success/>要素の閉鎖「>」文字を送信した直後に有効になり、開始のための<success/>要素のクロージング「>」文字を受信した直後に有効になります。実在物。層の順序は最初に[TCP]、次に[TLS]、[SASL]、次にXMPPです。
use of the authorization identity: The authorization identity may be used by xmpp to denote the non-default <node@domain> of a client or the sending <domain> of a server.
承認IDの使用：承認IDは、クライアントの非デフォルト<node@domain>またはサーバーの送信<ドメイン>を示すためにXMPPによって使用される場合があります。
The following SASL-related error conditions are defined:
次のSASL関連のエラー条件が定義されています。
o <aborted/> -- The receiving entity acknowledges an <abort/> element sent by the initiating entity; sent in reply to the <abort/> element.
o <aborted/> - 受信エンティティは、開始エンティティによって送信された<abort/>要素を認めます。<abort/>要素に返信します。
o <incorrect-encoding/> -- The data provided by the initiating entity could not be processed because the [BASE64] encoding is incorrect (e.g., because the encoding does not adhere to the definition in Section 3 of [BASE64]); sent in reply to a <response/> element or an <auth/> element with initial response data.
o <誤ったエンコード/> - [base64]エンコードが正しくないため、開始エンティティによって提供されるデータを処理できませんでした（たとえば、エンコードは[base64]のセクション3の定義に付着していないため）。<response/>要素または初期応答データを使用して<auth/>要素に返信します。
o <invalid-authzid/> -- The authzid provided by the initiating entity is invalid, either because it is incorrectly formatted or because the initiating entity does not have permissions to authorize that ID; sent in reply to a <response/> element or an <auth/> element with initial response data.
o <invalid-authzid/> - 開始エンティティによって提供されるauthzidは、誤ってフォーマットされているか、開始エンティティがそのidを承認する許可を持っていないためです。<response/>要素または初期応答データを使用して<auth/>要素に返信します。
o <invalid-mechanism/> -- The initiating entity did not provide a mechanism or requested a mechanism that is not supported by the receiving entity; sent in reply to an <auth/> element.
o <無効機器/> - 開始エンティティは、メカニズムを提供しなかったか、受信エンティティによってサポートされていないメカニズムを要求しませんでした。<auth/>要素に返信します。
o <mechanism-too-weak/> -- The mechanism requested by the initiating entity is weaker than server policy permits for that initiating entity; sent in reply to a <response/> element or an <auth/> element with initial response data.
o <メカニズム-Weak/> - 開始エンティティによって要求されるメカニズムは、その開始エンティティのサーバーポリシー許可よりも弱い。<response/>要素または初期応答データを使用して<auth/>要素に返信します。
o <not-authorized/> -- The authentication failed because the initiating entity did not provide valid credentials (this includes but is not limited to the case of an unknown username); sent in reply to a <response/> element or an <auth/> element with initial response data.
o <not-authorized/> - 開始エンティティが有効な資格情報を提供しなかったために認証に失敗しました（これには、未知のユーザー名の場合は含まれますが、これらに限定されません）。<response/>要素または初期応答データを使用して<auth/>要素に返信します。
o <temporary-auth-failure/> -- The authentication failed because of a temporary error condition within the receiving entity; sent in reply to an <auth/> element or <response/> element.
o <一時的なauth-failure/> - 受信エンティティ内の一時的なエラー条件のために認証が失敗しました。<auth/>要素または<response/>要素に返信して送信されます。
The following example shows the data flow for a client authenticating with a server using SASL, normally after successful TLS negotiation (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
次の例は、SASLを使用してサーバーを使用して認証するクライアントのデータフローを示しています。通常、TLS交渉が成功した後です（注：障害ケースのプロトコルを説明するために、以下に示す代替手順が提供されています。例で送信されたデータによって）。
Step 1: Client initiates stream to server:
ステップ1：クライアントはストリームをサーバーに開始します：
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server responds with a stream tag sent to client:
ステップ2：サーバーは、クライアントに送信されたストリームタグで応答します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_234'
from='example.com'
version='1.0'>
Step 3: Server informs client of available authentication mechanisms:
ステップ3：サーバーは、利用可能な認証メカニズムをクライアントに通知します。
<stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> </stream:features> Step 4: Client selects an authentication mechanism:
<stream：feation> <mechanisms xmlns = 'urn：ietf：params：xml：ns：xmpp-sasl'> <mechantims> digest-md5 </mechanism> <mechanism> plain </mechanisms> </stream：機能>ステップ4：クライアントは認証メカニズムを選択します。
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
Step 5: Server sends a [BASE64] encoded challenge to client:
ステップ5：サーバーは[Base64]エンコードされたチャレンジをクライアントに送信します。
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>
The decoded challenge is:
デコードされた課題は次のとおりです。
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server returns error to client:
ステップ5（alt）：サーバーはクライアントにエラーを返します：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
Step 6: Client sends a [BASE64] encoded response to the challenge:
ステップ6：クライアントは[base64]エンコードされた応答を課題に送信します。
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
YXJzZXQ9dXRmLTgK
</response>
The decoded response is:
デコードされた応答は次のとおりです。
username="somenode",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.com",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server sends another [BASE64] encoded challenge to client:
ステップ7：サーバーは、別の[base64]エンコードされたチャレンジをクライアントに送信します。
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </challenge> The decoded challenge is:
<Challenge xmlns = 'urn：ietf：params：xml：ns：xmpp-sasl'> cnnwyxv0ad1lytqwzjywmzm1yzqyn2i1nti3yjg0zgjhymnkzmzmzao = </課題の課題は次のとおりです。
rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server returns error to client:
ステップ7（alt）：サーバーはクライアントにエラーを返します：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
Step 8: Client responds to the challenge:
ステップ8：クライアントは課題に応答します。
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server informs client of successful authentication:
ステップ9：サーバーは、クライアントに成功した認証を通知します。
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server informs client of failed authentication:
ステップ9（ALT）：サーバーは、認証の失敗をクライアントに通知します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
Step 10: Client initiates a new stream to server:
ステップ10：クライアントはサーバーに新しいストリームを開始します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):
ステップ11：サーバーは、追加機能（または空の機能要素）とともにクライアントにストリームヘッダーを送信することで応答します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
The following example shows the data flow for a server authenticating with another server using SASL, normally after successful TLS negotiation (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
次の例は、SASLを使用して別のサーバーで認証するサーバーのデータフローを示しています。通常、TLS交渉が成功した後です（注：障害ケースのプロトコルを説明するために、以下に示す代替手順が提供されています。例で送信されたデータによって）。
Step 1: Server1 initiates stream to Server2:
ステップ1：Server1はStreamをServer2に開始します。
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server2 responds with a stream tag sent to Server1:
ステップ2：Server2は、Server1に送信されたストリームタグで応答します。
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
Step 3: Server2 informs Server1 of available authentication mechanisms:
ステップ3：Server2は、使用可能な認証メカニズムをServer1に通知します。
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
Step 4: Server1 selects an authentication mechanism:
ステップ4：server1認証メカニズムを選択します。
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
Step 5: Server2 sends a [BASE64] encoded challenge to Server1:
ステップ5：server2は[base64]エンコードされたチャレンジをserver1に送信します。
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz </challenge> The decoded challenge is:
<Challenge XMLNS = 'URN：IETF：PARAMS：XML：NS：XMPP-SASL'> CMVHBG09INNVBWVYZWFSBSBM9UY2U9IK9BNK1HOXRFUUDTMMHOIIXXB3A9IMF1DGGILGNOYXJXXXXXFGSPGSPGSPGSPGDPCSPGSPGILGNOYXJXXFUUDTMHOIIXXB3A9IMF1HOXRFUUDTMMHOIIXXB3A9IMF1 zzxnz </challenge>デコードされた課題は次のとおりです。
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server2 returns error to Server1:
ステップ5（alt）：server2はエラーをserver1に返します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
Step 6: Server1 sends a [BASE64] encoded response to the challenge:
ステップ6：server1は、[base64]課題に対するエンコードされた応答を送信します。
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j
ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v
cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3
LGNoYXJzZXQ9dXRmLTgK
</response>
The decoded response is:
デコードされた応答は次のとおりです。
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server2 sends another [BASE64] encoded challenge to Server1:
ステップ7：server2は、server1に別の[base64]エンコードされたチャレンジを送信します。
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
The decoded challenge is:
デコードされた課題は次のとおりです。
rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server2 returns error to Server1:
ステップ7（alt）：server2はエラーをserver1に返します：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
Step 8: Server1 responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 8 (alt): Server1 aborts negotiation:
ステップ8（alt）：server1は交渉を中止します：
<abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server2 informs Server1 of successful authentication:
ステップ9：server2に成功した認証をServer1に通知します。
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server2 informs Server1 of failed authentication:
ステップ9（alt）：server2は、認証の失敗をserver1に通知します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<aborted/>
</failure>
</stream:stream>
Step 10: Server1 initiates a new stream to Server2:
ステップ10：server1は、サーバーへの新しいストリームを開始します2：
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 11: Server2 responds by sending a stream header to Server1 along with any additional features (or an empty features element):
ステップ11：Server2は、追加機能（または空の機能要素）とともにServer1にストリームヘッダーを送信することで応答します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_345'
version='1.0'>
<stream:features/>
After SASL negotiation (Section 6) with the receiving entity, the initiating entity MAY want or need to bind a specific resource to that stream. In general this applies only to clients: in order to conform to the addressing format (Section 3) and stanza delivery rules (Section 10) specified herein, there MUST be a resource identifier associated with the <node@domain> of the client (which is either generated by the server or provided by the client application); this ensures that the address for use over that stream is a "full JID" of the form <node@domain/resource>.
SASLの交渉（セクション6）の受信エンティティとの後、開始エンティティは、特定のリソースをそのストリームにバインドすることを望んでいるか、または必要とします。一般に、これはクライアントにのみ適用されます。ここで指定されたアドレス指定形式（セクション3）およびスタンザ配信ルール（セクション10）に準拠するために、クライアントの<node@domain>に関連付けられたリソース識別子が必要です（これサーバーによって生成されるか、クライアントアプリケーションによって提供されます）;これにより、そのストリームで使用するアドレスがフォーム<node@domain/resource>の「完全なJID」であることが保証されます。
Upon receiving a success indication within the SASL negotiation, the client MUST send a new stream header to the server, to which the server MUST respond with a stream header as well as a list of available stream features. Specifically, if the server requires the client to bind a resource to the stream after successful SASL negotiation, it MUST include an empty <bind/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features list it presents to the client upon sending the header for the response stream sent after successful SASL negotiation (but not before):
SASLネゴシエーション内で成功指示を受けると、クライアントはサーバーに新しいストリームヘッダーをサーバーに送信する必要があります。サーバーは、ストリームヘッダーと使用可能なストリーム機能のリストで応答する必要があります。具体的には、サーバーがSASLネゴシエーションを成功させた後、クライアントがリソースをストリームにバインドするように要求する場合、 'urn：ietf：params：xml：xmpp-bind'ネームスペースで認定された空の<bind/>要素を含める必要があります。ストリーム機能は、SASLの交渉が成功した後に送信された応答ストリームのヘッダーを送信すると、クライアントに提示するリストのリスト：
Server advertises resource binding feature to client:
サーバーはクライアントにリソースバインディング機能を宣伝します。
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features>
Upon being so informed that resource binding is required, the client MUST bind a resource to the stream by sending to the server an IQ stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace.
リソースバインディングが必要であることを知らされると、クライアントはサーバーに「セット」タイプのIQスタンザ（IQセマンティクス（セクション9.2.3）を参照）を「urn」で認定されたデータを含むデータを送信することにより、ストリームにリソースをバインドする必要があります。：ietf：params：xml：ns：xmpp-bind 'namespace。
If the client wishes to allow the server to generate the resource identifier on its behalf, it sends an IQ stanza of type "set" that contains an empty <bind/> element:
クライアントがサーバーに代わってリソース識別子を生成できるようにしたい場合、空の<bind/>要素を含む「セット」のIQスタンザを送信します。
Client asks server to bind a resource:
クライアントはサーバーにリソースをバインドするように依頼します。
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>
A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>.
リソースバインディングをサポートするサーバーは、クライアントに代わってリソース識別子を生成できる必要があります。サーバーによって生成されたリソース識別子は、その<node@domain>に対して一意でなければなりません。
If the client wishes to specify the resource identifier, it sends an IQ stanza of type "set" that contains the desired resource identifier as the XML character data of a <resource/> element that is a child of the <bind/> element:
クライアントがリソース識別子の指定を希望する場合、目的のリソース識別子を含むタイプ「セット」のIQスタンザを送信します。
Client binds a resource:
クライアントはリソースをバインドします：
<iq type='set' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>
Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server:
サーバーがクライアントのリソース識別子を生成するか、クライアントが提供するリソース識別子を受け入れた場合、クライアントに「結果」のIQスタンザを返す必要があります。サーバーによって決定された接続されたリソースのJID：
Server informs client of successful resource binding:
サーバーは、クライアントにリソースバインディングの成功を通知します。
<iq type='result' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates; in this case, the server SHOULD NOT return a stanza error (e.g., <forbidden/>) to the client but instead SHOULD communicate the generated resource identifier to the client in the IQ result as shown above.
サーバーは、クライアントが提供するリソース識別子を受け入れる必要がありますが、サーバーが生成するリソース識別子でオーバーライドする場合があります。この場合、サーバーはStanzaエラー（例：<forbidden/>）をクライアントに返すべきではなく、上記のようにIQ結果の生成されたリソース識別子をIQ結果のクライアントに通信する必要があります。
When a client supplies a resource identifier, the following stanza error conditions are possible (see Stanza Errors (Section 9.3)):
クライアントがリソース識別子を提供する場合、次のスタンザエラー条件が可能です（スタンザエラー（セクション9.3）を参照）：
o The provided resource identifier cannot be processed by the server in accordance with Resourceprep (Appendix B).
o 提供されたリソース識別子は、ResourcePrep（付録B）に従ってサーバーによって処理することはできません。
o The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed).
o クライアントは、リソースをストリームにバインドすることは許可されていません（たとえば、ノードまたはユーザーが許可されている接続リソースの数に制限に達したためです）。
o The provided resource identifier is already in use but the server does not allow binding of multiple connected resources with the same identifier.
o 提供されたリソース識別子はすでに使用されていますが、サーバーは同じ識別子を持つ複数の接続されたリソースのバインディングを許可していません。
The protocol for these error conditions is shown below.
これらのエラー条件のプロトコルを以下に示します。
Resource identifier cannot be processed:
リソース識別子を処理できません：
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Client is not allowed to bind a resource:
クライアントはリソースをバインドすることを許可されていません：
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Resource identifier is in use:
リソース識別子が使用されています：
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a <bind/> child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a <not-authorized/> stanza error to the client.
リソースバインディングステップを完了する前に、クライアントは、「urn：ietf：xml：ns：xmpp-bind 'ネームスペース、' urn：ietf：params：xmpl：xmpp-bind」の資格を持つ<bind/>子でIQスタンザ以外のXMLスタンザを送信しようとした場合サーバーはStanzaを処理してはならず、クライアントに<authorized/> stanzaエラーを返す必要があります。
The Jabber protocols from which XMPP was adapted include a "server dialback" method for protecting against domain spoofing, thus making it more difficult to spoof XML stanzas. Server dialback is not a security mechanism, and results in weak verification of server identities only (see Server-to-Server Communications (Section 14.4) regarding this method's security characteristics). Domains requiring robust security SHOULD use TLS and SASL; see Server-to-Server Communications (Section 14.4) for details. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary. Documentation of dialback is included mainly for the sake of backward-compatibility with existing implementations and deployments.
XMPPが適応されたJabberプロトコルには、ドメインのスプーフィングから保護するための「サーバーダイヤルバック」方法が含まれているため、XMLスタンザのスプーフィングがより困難になります。サーバーのダイヤルバックはセキュリティメカニズムではなく、サーバーのアイデンティティのみが弱い検証をもたらします（このメソッドのセキュリティ特性に関するサーバー間通信（セクション14.4）を参照）。堅牢なセキュリティを必要とするドメインは、TLSとSASLを使用する必要があります。詳細については、サーバー間通信（セクション14.4）を参照してください。SASLがサーバーからサーバーへの認証に使用される場合、それは不要なため、ダイヤルバックは使用しないでください。ダイヤルバックのドキュメントは、主に既存の実装と展開との後方互換性のために含まれています。
The server dialback method is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain. Because dialback depends on DNS, inter-domain communications MUST NOT proceed until the Domain Name System (DNS) hostnames asserted by the servers have been resolved (see Server-to-Server Communications (Section 14.4)).
サーバーのダイヤルバック法は、ドメイン名システム（DNS）の存在によって可能になります。これは、1つのサーバーが特定のドメインの権威あるサーバーを（通常）発見できるためです。ダイヤルバックはDNSに依存するため、ドメイン間通信は、サーバーによって主張されたドメイン名システム（DNS）ホスト名が解決されるまで続行してはなりません（サーバー間通信（セクション14.4）を参照）。
Server dialback is uni-directional, and results in (weak) verification of identities for one stream in one direction. Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback. Therefore, server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains.
サーバーのダイヤルバックは一方向であり、一方向の1つのストリームのアイデンティティの（弱い）検証をもたらします。サーバーのダイヤルバックは認証メカニズムではないため、ダイヤルバックを介して相互認証は不可能です。したがって、2つのドメイン間の双方向通信を有効にするために、サーバーダイヤルバックを各方向に完了する必要があります。
The method for generating and verifying the keys used in server dialback MUST take into account the hostnames being used, the stream ID generated by the receiving server, and a secret known by the authoritative server's network. The stream ID is security-critical in server dialback and therefore MUST be both unpredictable and non-repeating (see [RANDOM] for recommendations regarding randomness for security purposes).
サーバーダイヤルバックで使用されるキーを生成および検証する方法は、使用されているホスト名、受信サーバーによって生成されたストリームID、および権威あるサーバーのネットワークで既知の秘密を考慮する必要があります。ストリームIDはサーバーダイヤルバックでセキュリティが批判的であるため、予測不可能で非回復的でなければなりません（セキュリティ目的でのランダム性に関する推奨事項については[ランダム]を参照）。
Any error that occurs during dialback negotiation MUST be considered a stream error, resulting in termination of the stream and of the underlying TCP connection. The possible error conditions are specified in the protocol description below.
ダイヤルバックネゴシエーション中に発生するエラーは、ストリームエラーと見なされる必要があり、その結果、ストリームと基礎となるTCP接続の終了が得られます。可能なエラー条件は、以下のプロトコルの説明で指定されています。
The following terminology applies:
次の用語が適用されます。
o Originating Server -- the server that is attempting to establish a connection between two domains.
o 発信するサーバー - 2つのドメイン間の接続を確立しようとしているサーバー。
o Receiving Server -- the server that is trying to authenticate that the Originating Server represents the domain which it claims to be.
o 受信サーバー - 元のサーバーが主張するドメインを表すことを認証しようとしているサーバー。
o Authoritative Server -- the server that answers to the DNS hostname asserted by the Originating Server; for basic environments this will be the Originating Server, but it could be a separate machine in the Originating Server's network.
o 権威あるサーバー - 発信元サーバーによって主張されたDNSホスト名に応答するサーバー。基本的な環境の場合、これは元のサーバーになりますが、発信するサーバーのネットワーク内の別のマシンになる可能性があります。
The following is a brief summary of the order of events in dialback:
以下は、ダイヤルバックのイベントの順序の簡単な要約です。
1. The Originating Server establishes a connection to the Receiving Server.
1. 元のサーバーは、受信サーバーへの接続を確立します。
2. The Originating Server sends a 'key' value over the connection to the Receiving Server.
2. 元のサーバーは、受信サーバーへの接続上で「キー」値を送信します。
3. The Receiving Server establishes a connection to the Authoritative Server.
3. 受信サーバーは、権威あるサーバーへの接続を確立します。
4. The Receiving Server sends the same 'key' value to the Authoritative Server.
4. 受信サーバーは、同じ「キー」値を権威あるサーバーに送信します。
5. The Authoritative Server replies that key is valid or invalid.
5. 権威あるサーバーは、キーが有効または無効であると答えます。
6. The Receiving Server informs the Originating Server whether it is authenticated or not.
6. 受信サーバーは、元のサーバーに認証されているかどうかを通知します。
We can represent this flow of events graphically as follows:
このイベントの流れをグラフィカルに次のように表現できます。
Originating Receiving
Server Server
----------- ---------
| |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| | Authoritative
| send dialback key | Server
| ----------------------> | -------------
| | |
| establish connection |
| ----------------------> |
| |
| send stream header |
| ----------------------> |
| |
| send stream header |
| <---------------------- |
| |
| send verify request |
| ----------------------> |
| |
| send verify response |
| <---------------------- |
|
| report dialback result |
| <---------------------- |
| |
The detailed protocol interaction between the servers is as follows:
サーバー間の詳細なプロトコル相互作用は次のとおりです。
1. The Originating Server establishes TCP connection to the Receiving Server.
1. 発信元のサーバーは、受信サーバーへのTCP接続を確立します。
2. The Originating Server sends a stream header to the Receiving Server:
2. 元のサーバーは、ストリームヘッダーを受信サーバーに送信します。
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports dialback. If the namespace name is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.
注：「to」と「from」属性は、ルートストリーム要素でオプションです。xmlns：db namespace宣言が表示されている名前のdbを含めることは、表示サーバーがダイヤルバックをサポートしていることを受信サーバーに示します。名前空間名が正しくない場合、受信サーバーは<invalid-namespace/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。
3. The Receiving Server SHOULD send a stream header back to the Originating Server, including a unique ID for this interaction:
3. 受信サーバーは、このインタラクションの一意のIDを含む、ストリームヘッダーを元のサーバーに送信する必要があります。
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='457F9224A0...'>
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Originating Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. Note well that the Receiving Server SHOULD reply but MAY silently terminate the XML stream and underlying TCP connection depending on security policies in place; however, if the Receiving Server desires to proceed, it MUST send a stream header back to the Originating Server.
注：「to」と「from」属性は、ルートストリーム要素でオプションです。名前空間名が正しくない場合、発信するサーバーは<invalid-namespace/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。受信サーバーは返信する必要がありますが、XMLストリームと基礎となるTCP接続を静かに終了する可能性があることに注意してください。ただし、受信サーバーが続行したい場合は、ストリームヘッダーを元のサーバーに戻す必要があります。
4. The Originating Server sends a dialback key to the Receiving Server:
4. 元のサーバーは、受信サーバーにダイヤルバックキーを送信します。
<db:result
to='Receiving Server'
from='Originating Server'>
98AF014EDC0...
</db:result>
Note: This key is not examined by the Receiving Server, since the Receiving Server does not keep information about the Originating Server between sessions. The key generated by the Originating Server MUST be based in part on the value of the ID provided by the Receiving Server in the previous step, and in part on a secret shared by the Originating Server and Authoritative Server. If the value of the 'to' address does not match a hostname recognized by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address matches a domain with which the Receiving Server already has an established connection, then the Receiving Server MUST maintain the existing connection until it validates whether the new connection is legitimate; additionally, the Receiving Server MAY choose to generate a <not-authorized/> stream error condition for the new connection and then terminate both the XML stream and the underlying TCP connection related to the new request.
注：受信サーバーはセッション間の発信サーバーに関する情報を保持していないため、このキーは受信サーバーによって検査されません。発生するサーバーによって生成されるキーは、以前のステップで受信サーバーが提供するIDの値に一部基づいている必要があります。「to」アドレスの値が受信サーバーによって認識されたホスト名と一致しない場合、受信サーバーはa <host-known/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。「From」アドレスの値が、受信サーバーがすでに確立された接続を持っているドメインと一致する場合、受信サーバーは、新しい接続が合法かどうかを検証するまで既存の接続を維持する必要があります。さらに、受信サーバーは、新しい接続のA <nothorized/>ストリームエラー条件を生成し、XMLストリームと新しいリクエストに関連する基礎となるTCP接続の両方を終了することを選択できます。
5. The Receiving Server establishes a TCP connection back to the domain name asserted by the Originating Server, as a result of which it connects to the Authoritative Server. (Note: As an optimization, an implementation MAY reuse an existing connection here.)
5. 受信サーバーは、元のサーバーによって主張されたドメイン名に戻るTCP接続を確立し、その結果、権威あるサーバーに接続します。（注：最適化として、実装はここで既存の接続を再利用する場合があります。）
6. The Receiving Server sends the Authoritative Server a stream header:
6. 受信サーバーは、権威あるサーバーにストリームヘッダーを送信します。
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'>
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Authoritative Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.
注：「to」と「from」属性は、ルートストリーム要素でオプションです。名前空間名が正しくない場合、権威あるサーバーは<invalid-namespace/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。
7. The Authoritative Server sends the Receiving Server a stream header:
7. 権威あるサーバーは、受信サーバーにストリームヘッダーを送信します。
<stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
id='1251A342B...'>
Note: If the namespace name is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection between it and the Authoritative Server. If a stream error occurs between the Receiving Server and the Authoritative Server, then the Receiving Server MUST generate a <remote-connection-failed/> stream error condition and terminate both the XML stream and the underlying TCP connection between it and the Originating Server.
注：名前空間名が正しくない場合、受信サーバーは<invalid-namespace/>ストリームエラー条件を生成し、XMLストリームとその基礎となるTCP接続と権威あるサーバーの両方を終了する必要があります。受信サーバーと権威あるサーバーの間でストリームエラーが発生した場合、受信サーバーは<リモート接続ファイル/>ストリームエラー条件を生成し、XMLストリームとITと発信元サーバーの間の基礎となるTCP接続の両方を終了する必要があります。
8. The Receiving Server sends the Authoritative Server a request for verification of a key:
8. 受信サーバーは、権威あるサーバーにキーの検証のリクエストを送信します。
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
Note: Passed here are the hostnames, the original identifier from the Receiving Server's stream header to the Originating Server in Step 3, and the key that the Originating Server sent to the Receiving Server in Step 4. Based on this information, as well as shared secret information within the Authoritative Server's network, the key is verified. Any verifiable method MAY be used to generate the key. If the value of the 'to' address does not match a hostname recognized by the Authoritative Server, then the Authoritative Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address does not match the hostname represented by the Receiving Server when opening the TCP connection (or any validated domain thereof, such as a validated subdomain of the Receiving Server's hostname or another validated domain hosted by the Receiving Server), then the Authoritative Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection.
注：ここに渡されたホスト名、受信サーバーのストリームヘッダーからステップ3の発信元サーバーへの元の識別子、およびステップ4で受信サーバーに送信された元のサーバーがこの情報と共有権威あるサーバーのネットワーク内で、キーが検証されています。検証可能な方法は、キーを生成するために使用できます。「to」アドレスの値が権威あるサーバーによって認識されたホスト名と一致しない場合、権威あるサーバーは<ホストと知られている/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。「From」アドレスの値が、受信サーバーのホスト名の検証済みサブドメインや受信サーバーによってホストされている別の検証ドメインなど、TCP接続（またはその検証済みドメインなど、受信サーバーが表すホスト名と一致しない場合）、権威あるサーバーは、<無効な/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。
9. The Authoritative Server verifies whether the key was valid or invalid:
9. 権威あるサーバーは、キーが有効か無効であるかを確認します。
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
or
または又はそれとも若しくは乃至或るいは
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
Note: If the ID does not match that provided by the Receiving Server in Step 3, then the Receiving Server MUST generate an <invalid-id/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'to' address does not match a hostname recognized by the Receiving Server, then the Receiving Server MUST generate a <host-unknown/> stream error condition and terminate both the XML stream and the underlying TCP connection. If the value of the 'from' address does not match the hostname represented by the Originating Server when opening the TCP connection (or any validated domain thereof, such as a validated subdomain of the Originating Server's hostname or another validated domain hosted by the Originating Server), then the Receiving Server MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection. After returning the verification to the Receiving Server, the Authoritative Server SHOULD terminate the stream between them.
注：IDがステップ3で受信サーバーによって提供されたものと一致しない場合、受信サーバーは<無効なID/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。「to」アドレスの値が受信サーバーによって認識されたホスト名と一致しない場合、受信サーバーはa <host-known/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。「FROM」アドレスの値が、TCP接続（または元のサーバーのホスト名の検証済みサブドメインや、元のサーバーによってホストされている別の検証済みドメインなど、TCP接続（またはその検証済みドメイン）を開くときに発生するサーバーが表すホスト名と一致しない場合）、レシーブサーバーは、<無効な/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。確認を受信サーバーに返した後、権威あるサーバーはそれらの間のストリームを終了する必要があります。
10. The Receiving Server informs the Originating Server of the result:
10. 受信サーバーは、発信者の結果を結果の通知にします。
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
Note: At this point, the connection has either been validated via a type='valid', or reported as invalid. If the connection is invalid, then the Receiving Server MUST terminate both the XML stream and the underlying TCP connection. If the connection is validated, data can be sent by the Originating Server and read by the Receiving Server; before that, all XML stanzas sent to the Receiving Server SHOULD be silently dropped.
注：この時点で、接続はtype = '有効'を介して検証されているか、無効であると報告されています。接続が無効な場合、受信サーバーはXMLストリームと基礎となるTCP接続の両方を終了する必要があります。接続が検証されている場合、データは元のサーバーによって送信され、受信サーバーによって読み取られます。その前に、受信サーバーに送信されるすべてのXMLスタンザは静かに削除する必要があります。
The result of the foregoing is that the Receiving Server has verified the identity of the Originating Server, so that the Originating Server can send, and the Receiving Server can accept, XML stanzas over the "initial stream" (i.e., the stream from the Originating Server to the Receiving Server). In order to verify the identities of the entities using the "response stream" (i.e., the stream from the Receiving Server to the Originating Server), dialback MUST be completed in the opposite direction as well.
前述の結果、受信サーバーが発信するサーバーのIDを確認し、発信元のサーバーが送信できるようにし、受信サーバーは「初期ストリーム」（つまり、発信元のストリームからのストリームをXMLスタンザ）サーバーから受信サーバーへ）。「応答ストリーム」（つまり、受信サーバーから発信者サーバーへのストリーム）を使用してエンティティのIDを確認するには、ダイヤルバックも反対方向に完了する必要があります。
After successful dialback negotiation, the Receiving Server SHOULD accept subsequent <db:result/> packets (e.g., validation requests sent to a subdomain or other hostname serviced by the Receiving Server) from the Originating Server over the existing validated connection; this enables "piggybacking" of the original validated connection in one direction.
ダイヤルバックの交渉が成功した後、受信サーバーは、既存の検証された接続を介して元のサーバーから元気なサーバーからサブドメインまたはその他のホスト名に送信されたサブドメインまたはその他のホスト名に送信された、後続の<db：result/>パケット（たとえば、検証要求）を受け入れる必要があります。これにより、元の検証された接続の「ピギーバック」が一方向に可能になります。
Even if dialback negotiation is successful, a server MUST verify that all XML stanzas received from the other server include a 'from' attribute and a 'to' attribute; if a stanza does not meet this restriction, the server that receives the stanza MUST generate an <improper-addressing/> stream error condition and terminate both the XML stream and the underlying TCP connection. Furthermore, a server MUST verify that the 'from' attribute of stanzas received from the other server includes a validated domain for the stream; if a stanza does not meet this restriction, the server that receives the stanza MUST generate an <invalid-from/> stream error condition and terminate both the XML stream and the underlying TCP connection. Both of these checks help to prevent spoofing related to particular stanzas.
ダイヤルバックのネゴシエーションが成功したとしても、サーバーは他のサーバーから受け取ったすべてのXMLスタンザに「From」属性と 'to'属性が含まれていることを確認する必要があります。スタンザがこの制限を満たしていない場合、スタンザを受信するサーバーは、<Improper-Addressing/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。さらに、サーバーは、他のサーバーから受信したスタンザの「From」属性に、ストリームの検証済みドメインが含まれていることを確認する必要があります。スタンザがこの制限を満たしていない場合、スタンザを受信するサーバーは、<無効な/>ストリームエラー条件を生成し、XMLストリームと基礎となるTCP接続の両方を終了する必要があります。これらのチェックは両方とも、特定のスタンザに関連するスプーフィングを防ぐのに役立ちます。
After TLS negotiation (Section 5) if desired, SASL negotiation (Section 6), and Resource Binding (Section 7) if necessary, XML stanzas can be sent over the streams. Three kinds of XML stanza are defined for the 'jabber:client' and 'jabber:server' namespaces: <message/>, <presence/>, and <iq/>. In addition, there are five common attributes for these kinds of stanza. These common attributes, as well as the basic semantics of the three stanza kinds, are defined herein; more detailed information regarding the syntax of XML stanzas in relation to instant messaging and presence applications is provided in [XMPP-IM].
必要に応じてTLS交渉（セクション5）の後（セクション5）、SASL交渉（セクション6）、およびリソース拘束力（セクション7）が必要に応じて、XMLスタンザをストリームに送信できます。3種類のXMLスタンザは、「Jabber：client」および「Jabber：server」名前空間で定義されています。さらに、これらの種類のスタンザには5つの一般的な属性があります。これらの一般的な属性と、3つのスタンザ種類の基本的なセマンティクスは、本明細書で定義されています。インスタントメッセージングおよび存在アプリケーションに関連するXMLスタンザの構文に関するより詳細な情報は、[XMPP-IM]に記載されています。
The following five attributes are common to message, presence, and IQ stanzas:
次の5つの属性は、メッセージ、存在、およびIQスタンザに共通しています。
The 'to' attribute specifies the JID of the intended recipient for the stanza.
「to」属性は、スタンザの意図した受信者のJIDを指定します。
In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' attribute, although a stanza sent from a client to a server for handling by that server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute.
「Jabber：クライアント」の名前空間では、スタンザは「属性」を所有する必要がありますが、スタンザはそのサーバーによって処理するためにクライアントからサーバーに送信されます（例えば、他のエンティティにブロードキャストのためにサーバーに送信される存在）「to」属性を所有しています。
In the 'jabber:server' namespace, a stanza MUST possess a 'to' attribute; if a server receives a stanza that does not meet this restriction, it MUST generate an <improper-addressing/> stream error condition and terminate both the XML stream and the underlying TCP connection with the offending server.
「Jabber：Server」の名前空間では、スタンザは「」属性を所有する必要があります。サーバーがこの制限を満たさないスタンザを受信した場合、<Impoper-Addressing/>ストリームエラー条件を生成し、XMLストリームと問題のあるサーバーとの基礎となるTCP接続の両方を終了する必要があります。
If the value of the 'to' attribute is invalid or cannot be contacted, the entity discovering that fact (usually the sender's or recipient's server) MUST return an appropriate error to the sender, setting the 'from' attribute of the error stanza to the value provided in the 'to' attribute of the offending stanza.
「to」属性の値が無効であるか、接触できない場合、その事実を発見するエンティティ（通常は送信者または受信者のサーバー）が送信者に適切なエラーを返す必要があり、エラースタンザの「From」属性を設定する必要があります。問題のあるスタンザの「to」属性に提供される価値。
The 'from' attribute specifies the JID of the sender.
「From」属性は、送信者のJIDを指定します。
When a server receives an XML stanza within the context of an authenticated stream qualified by the 'jabber:client' namespace, it MUST do one of the following:
「Jabber：Client」ネームスペースによって認定された認証されたストリームのコンテキスト内でサーバーがXMLスタンザを受信する場合、次のいずれかを実行する必要があります。
1. validate that the value of the 'from' attribute provided by the client is that of a connected resource for the associated entity
1. クライアントが提供する「From」属性の値は、関連するエンティティの接続されたリソースの値であることを検証します
2. add a 'from' address to the stanza whose value is the bare JID (<node@domain>) or the full JID (<node@domain/resource>) determined by the server for the connected resource that generated the stanza (see Determination of Addresses (Section 3.5))
2. Stanzaを生成した接続されたリソースのためにサーバーによって決定されたFull Jid（<node@domain>）またはフルJID（<node@domain/resource>）である値があるStanzaに「From」アドレスを追加アドレスの（セクション3.5））
If a client attempts to send an XML stanza for which the value of the 'from' attribute does not match one of the connected resources for that entity, the server SHOULD return an <invalid-from/> stream error to the client. If a client attempts to send an XML stanza over a stream that is not yet authenticated, the server SHOULD return a <not-authorized/> stream error to the client. If generated, both of these conditions MUST result in closure of the stream and termination of the underlying TCP connection; this helps to prevent a denial of service attack launched from a rogue client.
クライアントがXMLスタンザを送信しようとする場合、「From」属性の値がそのエンティティの接続されたリソースの1つと一致しない場合、サーバーはクライアントに<invalid-from/>ストリームエラーを返す必要があります。クライアントがまだ認証されていないストリーム上でXMLスタンザを送信しようとする場合、サーバーはクライアントに<非承認/>ストリームエラーを返す必要があります。生成された場合、これらの条件は両方とも、ストリームの閉鎖と基礎となるTCP接続の終了につながる必要があります。これは、不正なクライアントから開始されたサービス拒否攻撃を防ぐのに役立ちます。
When a server generates a stanza from the server itself for delivery to a connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (1) not include a 'from' attribute or (2) include a 'from' attribute whose value is the account's bare JID (<node@domain>) or client's full JID (<node@domain/resource>). A server MUST NOT send to the client a stanza without a 'from' attribute if the stanza was not generated by the server itself. When a client receives a stanza that does not include a 'from' attribute, it MUST assume that the stanza is from the server to which the client is connected.
サーバーが、接続されたクライアントに配信するためにサーバー自体からスタンザを生成する場合（たとえば、クライアントに代わってサーバーが提供するデータストレージサービスのコンテキストで）、スタンザは（1）「from」を含めてはいけません。属性または（2）には、accountのbare jid（<node@domain>）またはクライアントのフルJid（<node@domain/resurce>）である「from」属性が含まれます。サーバーがサーバー自体によって生成されなかった場合、サーバーは「From」属性なしでクライアントにスタンザを送信してはなりません。クライアントが「From」属性を含まないスタンザを受信する場合、スタンザはクライアントが接続されているサーバーからであると仮定する必要があります。
In the 'jabber:server' namespace, a stanza MUST possess a 'from' attribute; if a server receives a stanza that does not meet this restriction, it MUST generate an <improper-addressing/> stream error condition. Furthermore, the domain identifier portion of the JID contained in the 'from' attribute MUST match the hostname of the sending server (or any validated domain thereof, such as a validated subdomain of the sending server's hostname or another validated domain hosted by the sending server) as communicated in the SASL negotiation or dialback negotiation; if a server receives a stanza that does not meet this restriction, it MUST generate an <invalid-from/> stream error condition. Both of these conditions MUST result in closing of the stream and termination of the underlying TCP connection; this helps to prevent a denial of service attack launched from a rogue server.
「jabber：server」の名前空間では、スタンザは「from」属性を所有する必要があります。サーバーがこの制限を満たさないスタンザを受信した場合、<Impoper-Addressing/>ストリームエラー条件を生成する必要があります。さらに、「From」属性に含まれるJIDのドメイン識別子部分は、送信サーバーのホスト名（またはその検証済みのドメイン）と一致する必要があります。）SASL交渉またはダイヤルバック交渉で伝えられている。サーバーがこの制限を満たさないスタンザを受信した場合、<invalid-from/>ストリームエラー条件を生成する必要があります。これらの条件は両方とも、ストリームの閉鎖と基礎となるTCP接続の終了につながる必要があります。これにより、Rogue Serverから開始されたサービス拒否攻撃を防ぐのに役立ちます。
The optional 'id' attribute MAY be used by a sending entity for internal tracking of stanzas that it sends and receives (especially for tracking the request-response interaction inherent in the semantics of IQ stanzas). It is OPTIONAL for the value of the 'id' attribute to be unique globally, within a domain, or within a stream. The semantics of IQ stanzas impose additional restrictions; see IQ Semantics (Section 9.2.3).
オプションの「ID」属性は、送信して受信するスタンザの内部追跡のために送信エンティティによって使用される場合があります（特に、IQスタンザのセマンティクスに固有のリクエスト応答相互作用を追跡するため）。「ID」属性の値がグローバルに、ドメイン内、またはストリーム内で一意になることがオプションです。IQスタンザのセマンティクスは、追加の制限を課します。IQセマンティクス（セクション9.2.3）を参照してください。
The 'type' attribute specifies detailed information about the purpose or context of the message, presence, or IQ stanza. The particular allowable values for the 'type' attribute vary depending on whether the stanza is a message, presence, or IQ; the values for message and presence stanzas are specific to instant messaging and presence applications and therefore are defined in [XMPP-IM], whereas the values for IQ stanzas specify the role of an IQ stanza in a structured request-response "conversation" and thus are defined under IQ Semantics (Section 9.2.3) below. The only 'type' value common to all three stanzas is "error"; see Stanza Errors (Section 9.3).
「タイプ」属性は、メッセージ、存在、またはIQスタンザの目的またはコンテキストに関する詳細情報を指定します。「タイプ」属性の特定の許容値は、スタンザがメッセージ、存在、またはIQであるかどうかによって異なります。メッセージと存在の値の値はインスタントメッセージングと存在アプリケーションに固有のものであるため、[XMPP-IM]で定義されますが、IQスタンザの値は、構造化されたリクエスト応答「会話」におけるIQスタンザの役割を指定し、したがって以下のIQセマンティクス（セクション9.2.3）で定義されています。3つのスタンザすべてに共通する唯一の「タイプ」値は「エラー」です。スタンザエラー（セクション9.3）を参照してください。
A stanza SHOULD possess an 'xml:lang' attribute (as defined in Section 2.12 of [XML]) if the stanza contains XML character data that is intended to be presented to a human user (as explained in RFC 2277 [CHARSET], "internationalization is for humans"). The value of the 'xml:lang' attribute specifies the default language of any such human-readable XML character data, which MAY be overridden by the 'xml:lang' attribute of a specific child element. If a stanza does not possess an 'xml:lang' attribute, an implementation MUST assume that the default language is that specified for the stream as defined under Stream Attributes (Section 4.4) above. The value of the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the format defined in RFC 3066 [LANGTAGS].
スタンザには、人間のユーザーに提示されることを目的としたXML文字データが含まれている場合、スタンザには「XML：lang」属性（[xml]のセクション2.12で定義されています）を所有する必要があります（RFC 2277 [charset]、 "で説明されています。国際化は人間のためのものです」）。'xml：lang'属性の値は、特定の子要素の「xml：lang」属性によって上書きされる可能性のある、そのような人間読み取り可能なxml文字データのデフォルト言語を指定します。スタンザが「XML：Lang」属性を所有していない場合、実装は、上記のストリーム属性（セクション4.4）で定義されているストリームに対して指定されているデフォルト言語であると想定する必要があります。'xml：lang'属性の値はnmtokenでなければならず、RFC 3066 [langtags]で定義されている形式に準拠する必要があります。
The <message/> stanza kind can be seen as a "push" mechanism whereby one entity pushes information to another entity, similar to the communications that occur in a system such as email. All message stanzas SHOULD possess a 'to' attribute that specifies the intended recipient of the message; upon receiving such a stanza, a server SHOULD route or deliver it to the intended recipient (see Server Rules for Handling XML Stanzas (Section 10) for general routing and delivery rules related to XML stanzas).
<メッセージ/>スタンザの種類は、電子メールなどのシステムで発生する通信と同様に、あるエンティティが別のエンティティに情報をプッシュする「プッシュ」メカニズムと見なすことができます。すべてのメッセージスタンザは、メッセージの意図した受信者を指定する「to」属性を所有する必要があります。そのようなスタンザを受信すると、サーバーはそれを意図した受信者にルーティングまたは配信する必要があります（XMLスタンザに関連する一般的なルーティングおよび配信ルールについては、XMLスタンザ（セクション10）の処理に関するサーバールールを参照）。
The <presence/> element can be seen as a basic broadcast or "publish-subscribe" mechanism, whereby multiple entities receive information about an entity to which they have subscribed (in this case, network availability information). In general, a publishing entity SHOULD send a presence stanza with no 'to' attribute, in which case the server to which the entity is connected SHOULD broadcast or multiplex that stanza to all subscribing entities. However, a publishing entity MAY also send a presence stanza with a 'to' attribute, in which case the server SHOULD route or deliver that stanza to the intended recipient. See Server Rules for Handling XML Stanzas (Section 10) for general routing and delivery rules related to XML stanzas, and [XMPP-IM] for presence-specific rules in the context of an instant messaging and presence application.
<プレゼンス/>要素は、基本的なブロードキャストまたは「パブリッシュサブスクライブ」メカニズムとして見ることができます。これにより、複数のエンティティがサブスクライブしたエンティティ（この場合はネットワーク可用性情報）に関する情報を受け取ります。一般に、パブリッシングエンティティは、「属性なし」のないスタンザを送信する必要があります。その場合、エンティティが接続されているサーバーは、そのスタンザをすべての購読エンティティにブロードキャストまたはマルチプレックスする必要があります。ただし、出版社は、「To」属性を持つスタンザを存在する場合もあります。その場合、サーバーはそのスタンザを意図した受信者にルーティングまたは配信する必要があります。XML Stanzasに関連する一般的なルーティングおよび配信ルールについては、XMLスタンザ（セクション10）を処理するためのサーバールール、およびインスタントメッセージングおよび存在アプリケーションのコンテキストでの存在固有のルールについては[XMPP-IM]を参照してください。
Info/Query, or IQ, is a request-response mechanism, similar in some
ways to [HTTP]. The semantics of IQ enable an entity to make a
request of, and receive a response from, another entity. The data
content of the request and response is defined by the namespace
declaration of a direct child element of the IQ element, and the
interaction is tracked by the requesting entity through use of the
'id' attribute. Thus, IQ interactions follow a common pattern of
structured data exchange such as get/result or set/result (although
an error may be returned in reply to a request if appropriate):
Requesting Responding
Entity Entity
---------- ----------
| |
| <iq type='get' id='1'> |
| ------------------------> |
| |
| <iq type='result' id='1'> |
| <------------------------ |
| |
| <iq type='set' id='2'> |
| ------------------------> |
| |
| <iq type='error' id='2'> |
| <------------------------ |
| |
In order to enforce these semantics, the following rules apply:
これらのセマンティクスを実施するために、次のルールが適用されます。
1. The 'id' attribute is REQUIRED for IQ stanzas.
1. IQスタンザには「ID」属性が必要です。
2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST be one of the following:
2. IQスタンザには「タイプ」属性が必要です。値は次のいずれかでなければなりません。
* get -- The stanza is a request for information or requirements.
* 取得 - スタンザは情報または要件のリクエストです。
* set -- The stanza provides required data, sets new values, or replaces existing values.
* SET -STANZAは、必要なデータを提供したり、新しい値を設定したり、既存の値を置き換えたりします。
* result -- The stanza is a response to a successful get or set request.
* 結果-Stanzaは、Get Requestの成功またはセットリクエストへの応答です。
* error -- An error has occurred regarding processing or delivery of a previously-sent get or set (see Stanza Errors (Section 9.3)).
* エラー - 以前にセントの取得または設定の処理または配信に関してエラーが発生しました（スタンザエラー（セクション9.3）を参照）。
3. An entity that receives an IQ request of type "get" or "set" MUST reply with an IQ response of type "result" or "error" (the response MUST preserve the 'id' attribute of the request).
3. タイプ「get」または「set」のIQ要求を受信するエンティティは、「結果」または「エラー」のIQ応答で返信する必要があります（応答は、リクエストの「ID」属性を保持する必要があります）。
4. An entity that receives a stanza of type "result" or "error" MUST NOT respond to the stanza by sending a further IQ response of type "result" or "error"; however, as shown above, the requesting entity MAY send another request (e.g., an IQ of type "set" in order to provide required information discovered through a get/result pair).
4. タイプ「結果」または「エラー」のスタンザを受け取るエンティティは、「結果」または「エラー」のタイプのIQ応答をさらに送信してスタンザに応答してはなりません。ただし、上記のように、リクエストエンティティは別の要求を送信する場合があります（たとえば、GET/結果ペアから発見された必要な情報を提供するために、「セット」タイプのIQ）。
5. An IQ stanza of type "get" or "set" MUST contain one and only one child element that specifies the semantics of the particular request or response.
5. タイプ「get」または「set」のIQスタンザには、特定のリクエストまたは応答のセマンティクスを指定する1つの子要素のみを含める必要があります。
6. An IQ stanza of type "result" MUST include zero or one child elements.
6. タイプ「結果」のIQスタンザには、ゼロまたは1つの子要素を含める必要があります。
7. An IQ stanza of type "error" SHOULD include the child element contained in the associated "get" or "set" and MUST include an <error/> child; for details, see Stanza Errors (Section 9.3).
7. タイプ「エラー」のIQスタンザには、関連する「get」または「set」に含まれる子要素を含める必要があり、<error/>子を含める必要があります。詳細については、スタンザエラー（セクション9.3）を参照してください。
Stanza-related errors are handled in a manner similar to stream errors (Section 4.7). However, unlike stream errors, stanza errors are recoverable; therefore error stanzas include hints regarding actions that the original sender can take in order to remedy the error.
スタンザ関連のエラーは、ストリームエラーと同様の方法で処理されます（セクション4.7）。ただし、ストリームエラーとは異なり、スタンザエラーは回復可能です。したがって、エラースタンザには、元の送信者がエラーを改善するために取ることができるアクションに関するヒントが含まれています。
The following rules apply to stanza-related errors:
次のルールは、スタンザ関連のエラーに適用されます。
o The receiving or processing entity that detects an error condition in relation to a stanza MUST return to the sending entity a stanza of the same kind (message, presence, or IQ), whose 'type' attribute is set to a value of "error" (such a stanza is called an "error stanza" herein).
o スタンザに関連するエラー条件を検出する受信または処理エンティティは、「タイプ」属性が「エラー」の値に設定されている同じ種類のスタンザ（メッセージ、存在、またはIQ）を送信エンティティに戻す必要があります。（このようなスタンザは、ここでは「エラースタンザ」と呼ばれます）。
o The entity that generates an error stanza SHOULD include the original XML sent so that the sender can inspect and, if necessary, correct the XML before attempting to resend.
o スタンザを生成するエンティティは、送信者が再送信する前にXMLを検査し、必要に応じて修正できるように送信された元のXMLを含める必要があります。
o An error stanza MUST contain an <error/> child element.
o エラースタンザには、<エラー/>子要素を含める必要があります。
o An <error/> child MUST NOT be included if the 'type' attribute has a value other than "error" (or if there is no 'type' attribute).
o <エラー/>「型」属性が「エラー」以外の値（または「タイプ」属性がない場合）以外の値がある場合、子を含めてはなりません。
o An entity that receives an error stanza MUST NOT respond to the stanza with a further error stanza; this helps to prevent looping.
o スタンザのエラーを受け取るエンティティは、さらなるエラースタンザでスタンザに応答してはなりません。これは、ループを防ぐのに役立ちます。
The syntax for stanza-related errors is as follows:
スタンザ関連のエラーの構文は次のとおりです。
<stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here]
<error type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</error>
</stanza-kind>
The stanza-kind is one of message, presence, or iq.
スタンザはメッセージ、存在、またはIQの1つです。
The value of the <error/> element's 'type' attribute MUST be one of the following:
<error/>要素の「型」属性の値は、次のいずれかでなければなりません。
o cancel -- do not retry (the error is unrecoverable) o continue -- proceed (the condition was only a warning) o modify -- retry after changing the data sent o auth -- retry after providing credentials o wait -- retry after waiting (the error is temporary)
o キャンセル - 再試行しないでください（エラーは回復不能）o続行 - 続行（条件は警告のみでした）o修正 - o authを変更した後に再試行 - 資格情報を提供した後に再試行 - 待機後に再試行（エラーは一時的です）
The <error/> element:
<エラー/>要素：
o MUST contain a child element corresponding to one of the defined stanza error conditions specified below; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
o 以下に指定された定義されたスタンザエラー条件の1つに対応する子要素を含める必要があります。この要素は、「urn：ietf：params：xml：ns：xmpp-stanzas 'namespace」によって資格を付ける必要があります。
o MAY contain a <text/> child containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess an 'xml:lang' attribute.
o エラーをより詳細に説明するXML文字データを含む<テキスト/>子が含まれる場合があります。この要素は、 'urn：ietf：params：xml：ns：xmpp-stanzas' namespaceによって資格を付ける必要があり、 'xml：lang'属性を所有する必要があります。
o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application-defined namespace, and its structure is defined by that namespace.
o アプリケーション固有のエラー条件のための子要素が含まれる場合があります。この要素は、アプリケーション定義の名前空間で適格である必要があり、その構造はその名前空間によって定義されます。
The <text/> element is OPTIONAL. If included, it SHOULD be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It SHOULD NOT be interpreted programmatically by an application. It SHOULD NOT be used as the error message presented to a user, but MAY be shown in addition to the error message associated with the included condition element (or elements).
<テキスト/>要素はオプションです。含まれている場合は、定義された条件またはアプリケーション固有の条件の意味を補完する記述情報または診断情報を提供するためにのみ使用する必要があります。アプリケーションによってプログラムで解釈されるべきではありません。ユーザーに提示されたエラーメッセージとして使用する必要はありませんが、含まれている条件要素（または要素）に関連付けられたエラーメッセージに加えて表示される場合があります。
Finally, to maintain backward compatibility, the schema (specified in [XMPP-IM]) allows the optional inclusion of a 'code' attribute on the <error/> element.
最後に、逆方向の互換性を維持するために、スキーマ（[XMPP-IM]で指定）により、<エラー/>要素に「コード」属性をオプションの含めることができます。
The following conditions are defined for use in stanza errors.
次の条件は、スタンザエラーで使用するために定義されています。
o <bad-request/> -- the sender has sent XML that is malformed or that cannot be processed (e.g., an IQ stanza that includes an unrecognized value of the 'type' attribute); the associated error type SHOULD be "modify".
o <bad-request/> - 送信者は、奇形または処理できないXMLを送信しました（たとえば、「タイプ」属性の認識されていない値を含むIQスタンザ）。関連するエラータイプは「変更」する必要があります。
o <conflict/> -- access cannot be granted because an existing resource or session exists with the same name or address; the associated error type SHOULD be "cancel".
o <comples/> - 既存のリソースまたはセッションが同じ名前または住所で存在するため、アクセスを許可できません。関連するエラータイプは「キャンセル」する必要があります。
o <feature-not-implemented/> -- the feature requested is not implemented by the recipient or server and therefore cannot be processed; the associated error type SHOULD be "cancel".
o <feature-not-implemented/> - 要求された機能は、受信者またはサーバーによって実装されていないため、処理できません。関連するエラータイプは「キャンセル」する必要があります。
o <forbidden/> -- the requesting entity does not possess the required permissions to perform the action; the associated error type SHOULD be "auth".
o <forbidden/> - 要求エンティティは、アクションを実行するために必要なアクセス許可を所有していません。関連するエラータイプは「auth」でなければなりません。
o <gone/> -- the recipient or server can no longer be contacted at this address (the error stanza MAY contain a new address in the XML character data of the <gone/> element); the associated error type SHOULD be "modify".
o <gon/> - 受信者またはサーバーは、このアドレスで連絡することができなくなりました（エラーStanzaには、<sone/>要素のXML文字データに新しいアドレスが含まれる場合があります）。関連するエラータイプは「変更」する必要があります。
o <internal-server-error/> -- the server could not process the stanza because of a misconfiguration or an otherwise-undefined internal server error; the associated error type SHOULD be "wait".
o <internal-server-error/> - サーバーは、誤った構成またはそうでない場合に定義されている内部サーバーエラーのためにスタンザを処理できませんでした。関連するエラータイプは「待機」する必要があります。
o <item-not-found/> -- the addressed JID or item requested cannot be found; the associated error type SHOULD be "cancel".
o <item-not-found/> - 要求されたアドレス指定されたJIDまたはアイテムは見つかりません。関連するエラータイプは「キャンセル」する必要があります。
o <jid-malformed/> -- the sending entity has provided or communicated an XMPP address (e.g., a value of the 'to' attribute) or aspect thereof (e.g., a resource identifier) that does not adhere to the syntax defined in Addressing Scheme (Section 3); the associated error type SHOULD be "modify".
o <jid-malformed/> - 送信エンティティは、XMPPアドレス（例：「to」属性の値）またはその側面（例：リソース識別子）を提供または伝達しました。スキーム（セクション3）;関連するエラータイプは「変更」する必要があります。
o <not-acceptable/> -- the recipient or server understands the request but is refusing to process it because it does not meet criteria defined by the recipient or server (e.g., a local policy regarding acceptable words in messages); the associated error type SHOULD be "modify".
o <容認できない/> - 受信者またはサーバーは、リクエストを理解しているが、受信者またはサーバーによって定義された基準を満たしていないため、処理を拒否しています（たとえば、メッセージの許容可能な単語に関するローカルポリシー）。関連するエラータイプは「変更」する必要があります。
o <not-allowed/> -- the recipient or server does not allow any entity to perform the action; the associated error type SHOULD be "cancel".
o <not-allowed/> - 受信者またはサーバーは、エンティティがアクションを実行することを許可しません。関連するエラータイプは「キャンセル」する必要があります。
o <not-authorized/> -- the sender must provide proper credentials before being allowed to perform the action, or has provided improper credentials; the associated error type SHOULD be "auth".
o <not-authorized/> - 送信者は、アクションの実行を許可される前に適切な資格情報を提供するか、不適切な資格情報を提供する必要があります。関連するエラータイプは「auth」でなければなりません。
o <payment-required/> -- the requesting entity is not authorized to access the requested service because payment is required; the associated error type SHOULD be "auth".
o <支払いrequed/> - 支払いが必要なため、要求されたエンティティは要求されたサービスにアクセスする権限がありません。関連するエラータイプは「auth」でなければなりません。
o <recipient-unavailable/> -- the intended recipient is temporarily unavailable; the associated error type SHOULD be "wait" (note: an application MUST NOT return this error if doing so would provide information about the intended recipient's network availability to an entity that is not authorized to know such information).
o <受信者 - 利用可能/> - 意図した受信者は一時的に利用できません。関連するエラータイプは「待機」でなければなりません（注：アプリケーションは、そのような情報を知ることを許可されていないエンティティに意図した受信者のネットワークの可用性に関する情報を提供する場合、このエラーを返してはなりません）。
o <redirect/> -- the recipient or server is redirecting requests for this information to another entity, usually temporarily (the error stanza SHOULD contain the alternate address, which MUST be a valid JID, in the XML character data of the <redirect/> element); the associated error type SHOULD be "modify".
o <redirect/> - 受信者またはサーバーは、この情報のリクエストを通常のエンティティにリダイレクトしています（通常は一時的に）<redirect/>>>>要素）;関連するエラータイプは「変更」する必要があります。
o <registration-required/> -- the requesting entity is not authorized to access the requested service because registration is required; the associated error type SHOULD be "auth".
o <登録要件/> - 登録が必要なため、要求されたエンティティは要求されたサービスにアクセスする権限がありません。関連するエラータイプは「auth」でなければなりません。
o <remote-server-not-found/> -- a remote server or service specified as part or all of the JID of the intended recipient does not exist; the associated error type SHOULD be "cancel".
o <remote-server-not-found/> - 意図した受信者の一部またはすべてのJIDとして指定されたリモートサーバーまたはサービスは存在しません。関連するエラータイプは「キャンセル」する必要があります。
o <remote-server-timeout/> -- a remote server or service specified as part or all of the JID of the intended recipient (or required to fulfill a request) could not be contacted within a reasonable amount of time; the associated error type SHOULD be "wait".
o <remote-server-timeout/> - 意図した受信者の一部またはすべてのJIDとして指定されたリモートサーバーまたはサービス（またはリクエストを満たすために必要な）は、合理的な時間内に連絡することはできませんでした。関連するエラータイプは「待機」する必要があります。
o <resource-constraint/> -- the server or recipient lacks the system resources necessary to service the request; the associated error type SHOULD be "wait".
o <Resource-Constraint/> - サーバーまたは受信者には、リクエストのサービスに必要なシステムリソースがありません。関連するエラータイプは「待機」する必要があります。
o <service-unavailable/> -- the server or recipient does not currently provide the requested service; the associated error type SHOULD be "cancel".
o <Service-Unavailable/> - サーバーまたは受信者は現在、要求されたサービスを提供していません。関連するエラータイプは「キャンセル」する必要があります。
o <subscription-required/> -- the requesting entity is not authorized to access the requested service because a subscription is required; the associated error type SHOULD be "auth".
o <subscription-Required/> - 要求エンティティは、サブスクリプションが必要なため、要求されたサービスにアクセスすることを許可されていません。関連するエラータイプは「auth」でなければなりません。
o <undefined-condition/> -- the error condition is not one of those defined by the other conditions in this list; any error type may be associated with this condition, and it SHOULD be used only in conjunction with an application-specific condition.
o <未定義の条件/> - エラー条件は、このリストの他の条件で定義されている条件の1つではありません。任意のエラータイプはこの条件に関連付けられている可能性があり、アプリケーション固有の条件と組み合わせてのみ使用する必要があります。
o <unexpected-request/> -- the recipient or server understood the request but was not expecting it at this time (e.g., the request was out of order); the associated error type SHOULD be "wait".
o <予期しないrequest/> - 受信者またはサーバーは要求を理解していましたが、現時点ではそれを期待していませんでした（たとえば、リクエストは故障していませんでした）。関連するエラータイプは「待機」する必要があります。
As noted, an application MAY provide application-specific stanza error information by including a properly-namespaced child in the error element. The application-specific element SHOULD supplement or further qualify a defined element. Thus, the <error/> element will contain two or three child elements:
前述のように、アプリケーションは、エラー要素に適切に名前付けされた子供を含めることにより、アプリケーション固有のStanzaエラー情報を提供する場合があります。アプリケーション固有の要素は、定義された要素を補足するか、さらに修飾する必要があります。したがって、<エラー/>要素には2つまたは3つの子要素が含まれます。
<iq type='error' id='some-id'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<too-many-parameters xmlns='application-ns'/>
</error>
</iq>
<message type='error' id='another-id'>
<error type='modify'>
<undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Some special application diagnostic information...
</text>
<special-application-condition xmlns='application-ns'/>
</error>
</message>
Compliant server implementations MUST ensure in-order processing of XML stanzas between any two entities.
準拠したサーバーの実装では、任意の2つのエンティティ間でXMLスタンザの順序処理を確保する必要があります。
Beyond the requirement for in-order processing, each server implementation will contain its own "delivery tree" for handling stanzas it receives. Such a tree determines whether a stanza needs to be routed to another domain, processed internally, or delivered to a resource associated with a connected node. The following rules apply:
注文処理の要件を超えて、各サーバーの実装には、受信するスタンザを処理するための独自の「配信ツリー」が含まれます。このようなツリーは、スタンザを別のドメインにルーティングする必要があるか、内部で処理されるか、接続されたノードに関連付けられたリソースに配信する必要があるかどうかを決定します。次のルールが適用されます。
If the stanza possesses no 'to' attribute, the server SHOULD process it on behalf of the entity that sent it. Because all stanzas received from other servers MUST possess a 'to' attribute, this rule applies only to stanzas received from a registered entity (such as a client) that is connected to the server. If the server receives a presence stanza with no 'to' attribute, the server SHOULD broadcast it to the entities that are subscribed to the sending entity's presence, if applicable (the semantics of presence broadcast for instant messaging and presence applications are defined in [XMPP-IM]). If the server receives an IQ stanza of type "get" or "set" with no 'to' attribute and it understands the namespace that qualifies the content of the stanza, it MUST either process the stanza on behalf of the sending entity (where the meaning of "process" is determined by the semantics of the qualifying namespace) or return an error to the sending entity.
Stanzaが「to」属性を所有していない場合、サーバーはそれを送信したエンティティに代わって処理する必要があります。他のサーバーから受け取ったすべてのスタンザは、「to」属性を所有する必要があるため、このルールは、サーバーに接続されている登録エンティティ（クライアントなど）から受け取ったスタンザにのみ適用されます。サーバーが「to」属性のない存在スタンザを受信した場合、サーバーは該当する場合は送信エンティティの存在にサブスクライブするエンティティにブロードキャストする必要があります（インスタントメッセージングおよび存在アプリケーションの存在放送のセマンティクスは[xmppで定義されます。-私は]）。サーバーが 'to'属性で「取得」または「設定」のIQスタンザを受信し、スタンザのコンテンツを適格にする名前空間を理解している場合、送信エンティティに代わってスタンザを処理する必要があります（ここで「プロセス」の意味は、適格な名前空間のセマンティクスによって決定されるか、送信エンティティにエラーを返します。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute does not match one of the configured hostnames of the server itself or a subdomain thereof, the server SHOULD route the stanza to the foreign domain (subject to local service provisioning and security policies regarding inter-domain communication). There are two possible cases:
「to」属性に含まれるJIDのドメイン識別子部分のホスト名が、サーバー自体の構成されたホスト名のいずれかまたはそのサブドメインと一致しない場合、サーバーはスタンザを外部ドメインにルーティングする必要があります（ローカルサービスの対象となりますドメイン間通信に関するプロビジョニングおよびセキュリティポリシー）。可能な2つのケースがあります。
A server-to-server stream already exists between the two domains: The sender's server routes the stanza to the authoritative server for the foreign domain over the existing stream
サーバーからサーバーへのストリームは、2つのドメインの間に既に存在します。送信者のサーバーは、既存のストリーム上の外部ドメインのためにStanzaを権威あるサーバーにルーティングします
There exists no server-to-server stream between the two domains: The sender's server (1) resolves the hostname of the foreign domain (as defined under Server-to-Server Communications (Section 14.4)), (2) negotiates a server-to-server stream between the two domains (as defined under Use of TLS (Section 5) and Use of SASL (Section 6)), and (3) routes the stanza to the authoritative server for the foreign domain over the newly-established stream
2つのドメイン間にサーバーからサーバーへのストリームは存在しません。送信者のサーバー（1）は、外部ドメインのホスト名（サーバーからサーバーへの通信（セクション14.4）で定義されている）を解決します。2つのドメインの間のサーバーストリーム（TLSの使用（セクション5）およびSASLの使用（セクション6）の使用で定義されています）、および（3）は、新たに確立されたストリーム上の外部ドメインのためにスタンザを権威あるサーバーにルーティングします
If routing to the recipient's server is unsuccessful, the sender's server MUST return an error to the sender; if the recipient's server can be contacted but delivery by the recipient's server to the recipient is unsuccessful, the recipient's server MUST return an error to the sender by way of the sender's server.
受信者のサーバーへのルーティングが失敗した場合、送信者のサーバーは送信者にエラーを返す必要があります。受信者のサーバーに連絡できるが、受信者のサーバーから受信者への配信が失敗した場合、受信者のサーバーは送信者のサーバーを介して送信者にエラーを返す必要があります。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute matches a subdomain of one of the configured hostnames of the server itself, the server MUST either process the stanza itself or route the stanza to a specialized service that is responsible for that subdomain (if the subdomain is configured), or return an error to the sender (if the subdomain is not configured).
「to」属性に含まれるJIDのドメイン識別子部分のホスト名が、サーバー自体の構成されたホスト名の1つのサブドメインと一致する場合、サーバーはスタンザ自体を処理するか、スタンザをスタンザを専門のサービスにルーティングする必要があります。そのサブドメインの責任（サブドメインが構成されている場合）、または送信者にエラーを返します（サブドメインが構成されていない場合）。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute matches a configured hostname of the server itself and the JID contained in the 'to' attribute is of the form <domain> or <domain/resource>, the server (or a defined resource thereof) MUST either process the stanza as appropriate for the stanza kind or return an error stanza to the sender.
「to」属性に含まれるJIDのドメイン識別子部分のホスト名がサーバー自体の構成ホスト名と一致し、「to」属性に含まれるJIDがフォーム<ドメイン>または<ドメイン/リソース>のフォームです。サーバー（またはその定義されたリソース）は、スタンザの種類に適したスタンザを処理するか、エラースタンザを送信者に返しなければなりません。
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute matches a configured hostname of the server itself and the JID contained in the 'to' attribute is of the form <node@domain> or <node@domain/resource>, the server SHOULD deliver the stanza to the intended recipient of the stanza as represented by the JID contained in the 'to' attribute. The following rules apply:
「to」属性に含まれるJIDのドメイン識別子部分のホスト名がサーバー自体の設定されたホスト名と一致し、 'to'属性に含まれるJIDは<Node@Domain>または<node@domainの形式です。/リソース>、サーバーは、「to」属性に含まれるJIDが表すように、スタンザの意図した受信者にスタンザを配信する必要があります。次のルールが適用されます。
1. If the JID contains a resource identifier (i.e., is of the form <node@domain/resource>) and there exists a connected resource that matches the full JID, the recipient's server SHOULD deliver the stanza to the stream or session that exactly matches the resource identifier.
1. JIDにリソース識別子が含まれている場合（つまり、フォーム<Node@Domain/Resource>）、完全なJIDと一致する接続されたリソースが存在する場合、受信者のサーバーはStanzaをストリームまたはセッションに正確に一致させるセッションに配信する必要があります。リソース識別子。
2. If the JID contains a resource identifier and there exists no connected resource that matches the full JID, the recipient's server SHOULD return a <service-unavailable/> stanza error to the sender.
2. JIDにリソース識別子が含まれており、完全なJIDと一致する接続されたリソースが存在しない場合、受信者のサーバーは<Service-Unavailable/> Stanzaエラーを送信者に返す必要があります。
3. If the JID is of the form <node@domain> and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources, according to application-specific rules (a set of delivery rules for instant messaging and presence applications is defined in [XMPP-IM]).
3. jidがフォーム<node@domain>であり、ノードに少なくとも1つの接続されたリソースが存在する場合、受信者のサーバーは、アプリケーション固有のルール（一連のセットのセットに従って、少なくとも1つの接続リソースにスタンザを配信する必要があります。インスタントメッセージングおよび存在アプリケーションの配信ルールは、[xmpp-im]）で定義されています。
XMPP is a simplified and specialized protocol for streaming XML elements in order to exchange structured information in close to real time. Because XMPP does not require the parsing of arbitrary and complete XML documents, there is no requirement that XMPP needs to support the full feature set of [XML]. In particular, the following restrictions apply.
XMPPは、構造化された情報をリアルタイムに交換するために、XML要素をストリーミングするための簡素化された専門的なプロトコルです。XMPPは任意の完全なXMLドキュメントの解析を必要としないため、XMPPが[XML]の完全な機能セットをサポートする必要があるという要件はありません。特に、次の制限が適用されます。
With regard to XML generation, an XMPP implementation MUST NOT inject into an XML stream any of the following:
XML生成に関しては、XMPP実装はXMLストリームに注入してはなりません。
o comments (as defined in Section 2.5 of [XML])
o コメント（[XML]のセクション2.5で定義されています）
o processing instructions (Section 2.6 therein)
o 処理手順（セクション2.6）
o internal or external DTD subsets (Section 2.8 therein)
o 内部または外部のDTDサブセット（セクション2.8）
o internal or external entity references (Section 4.2 therein) with the exception of predefined entities (Section 4.6 therein)
o 事前定義されたエンティティ（セクション4.6）を除き、内部または外部のエンティティ参照（セクション4.2）
o character data or attribute values containing unescaped characters that map to the predefined entities (Section 4.6 therein); such characters MUST be escaped
o 事前定義されたエンティティにマッピングされるUnescaped文字を含む文字データまたは属性値（そこにあるセクション4.6）。そのようなキャラクターは逃げる必要があります
With regard to XML processing, if an XMPP implementation receives such restricted XML data, it MUST ignore the data.
XML処理に関しては、XMPP実装がこのような制限されたXMLデータを受信する場合、データを無視する必要があります。
XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to create strict boundaries of data ownership. The basic function of namespaces is to separate different vocabularies of XML elements that are structurally mixed together. Ensuring that XMPP-compliant XML is namespace-aware enables any allowable XML to be structurally mixed with any data element within XMPP. Rules for XML namespace names and prefixes are defined in the following subsections.
XML Namespaces [XML-Names]は、すべてのXMPP準拠XML内で使用され、データ所有権の厳格な境界を作成します。名前空間の基本的な機能は、構造的に混合されるXML要素の異なる語彙を分離することです。XMPPに準拠したXMLがNamespace-Awareであることを確認することで、許容可能なXMLをXMPP内のデータ要素と構造的に混合できるようにします。XMLネームスペース名とプレフィックスのルールは、次のサブセクションで定義されています。
A streams namespace declaration is REQUIRED in all XML stream headers. The name of the streams namespace MUST be 'http://etherx.jabber.org/streams'. The element names of the <stream/> element and its <features/> and <error/> children MUST be qualified by the streams namespace prefix in all instances. An implementation SHOULD generate only the 'stream:' prefix for these elements, and for historical reasons MAY accept only the 'stream:' prefix.
すべてのXMLストリームヘッダーでは、Streamsの名前空間宣言が必要です。Streams NameSpaceの名前は「http://etherx.jabber.org/streams」でなければなりません。<stream/>要素の要素名とその<feature/>および<error/>子供は、すべてのインスタンスでStreams NameSpace Prefixで資格を取得する必要があります。実装は、これらの要素の「ストリーム：」のプレフィックスのみを生成する必要があり、歴史的な理由で「ストリーム：」プレフィックスのみを受け入れる場合があります。
A default namespace declaration is REQUIRED and is used in all XML streams in order to define the allowable first-level children of the root stream element. This namespace declaration MUST be the same for the initial stream and the response stream so that both streams are qualified consistently. The default namespace declaration applies to the stream and all stanzas sent within a stream (unless explicitly qualified by another namespace, or by the prefix of the streams namespace or the dialback namespace).
ルートストリーム要素の許容される第1レベルの子供を定義するために、デフォルトの名前空間宣言が必要であり、すべてのXMLストリームで使用されます。この名前空間宣言は、両方のストリームが一貫して資格があるように、初期ストリームと応答ストリームで同じでなければなりません。デフォルトの名前空間宣言は、ストリームとストリーム内で送信されるすべてのスタンザに適用されます（別の名前空間、またはストリーム名空間またはダイヤルバック名空間のプレフィックスによって明示的に適格でない限り）。
A server implementation MUST support the following two default namespaces (for historical reasons, some implementations MAY support only these two default namespaces):
サーバーの実装は、次の2つのデフォルトの名前空間をサポートする必要があります（歴史的な理由で、一部の実装では、これら2つのデフォルトの名前空間のみをサポートする場合があります）：
o jabber:client -- this default namespace is declared when the stream is used for communications between a client and a server
o Jabber：クライアント - このデフォルトの名前空間は、クライアントとサーバー間の通信にストリームが使用されるときに宣言されます
o jabber:server -- this default namespace is declared when the stream is used for communications between two servers
o Jabber：サーバー - このデフォルトの名前空間は、ストリームが2つのサーバー間の通信に使用されるときに宣言されます
A client implementation MUST support the 'jabber:client' default namespace, and for historical reasons MAY support only that default namespace.
クライアントの実装は、「Jabber：クライアント」デフォルトの名前空間をサポートする必要があり、歴史的な理由でそのデフォルトの名前空間のみをサポートする場合があります。
An implementation MUST NOT generate namespace prefixes for elements in the default namespace if the default namespace is 'jabber:client' or 'jabber:server'. An implementation SHOULD NOT generate namespace prefixes for elements qualified by content (as opposed to stream) namespaces other than 'jabber:client' and 'jabber:server'.
デフォルトの名前空間が「jabber：client」または「jabber：server」の場合、実装はデフォルトの名前空間の要素の名前空間プレフィックスを生成してはなりません。実装では、「Jabber：Client」および「Jabber：Server」以外のコンテンツ（ストリーミングではなく）の名前空間で適格な要素の名前空間プレフィックスを生成してはなりません。
Note: The 'jabber:client' and 'jabber:server' namespaces are nearly identical but are used in different contexts (client-to-server communications for 'jabber:client' and server-to-server communications for 'jabber:server'). The only difference between the two is that the 'to' and 'from' attributes are OPTIONAL on stanzas sent within 'jabber:client', whereas they are REQUIRED on stanzas sent within 'jabber:server'. If a compliant implementation accepts a stream that is qualified by the 'jabber:client' or 'jabber:server' namespace, it MUST support the common attributes (Section 9.1) and basic semantics (Section 9.2) of all three core stanza kinds (message, presence, and IQ).
注：「Jabber：Client」と「Jabber：Server」の名前空間はほぼ同じですが、異なるコンテキストで使用されます（「Jabber：クライアント」のクライアント間通信および「Jabber：Server」のサーバーからサーバーへの通信）。2つの唯一の違いは、「jabber：client」内で送信されるスタンザで「to」と「from」属性がオプションであるのに対し、「Jabber：server」内で送信されるスタンザで必要です。準拠した実装が「Jabber：client」または「Jabber：server」名前空間によって適格なストリームを受け入れる場合、3つのコアスタンザ種類の共通属性（セクション9.1）と基本的なセマンティクス（セクション9.2）をサポートする必要があります（メッセージメッセージ（セクション9.2）、存在、およびIQ）。
A dialback namespace declaration is REQUIRED for all elements used in server dialback (Section 8). The name of the dialback namespace MUST be 'jabber:server:dialback'. All elements qualified by this namespace MUST be prefixed. An implementation SHOULD generate only the 'db:' prefix for such elements and MAY accept only the 'db:' prefix.
サーバーダイヤルバックで使用されるすべての要素（セクション8）には、ダイヤルバックの名前空間宣言が必要です。ダイヤルバック名の名前は「Jabber：server：dialback」でなければなりません。この名前空間で資格のあるすべての要素をプレフィックスする必要があります。実装は、そのような要素の 'db：'プレフィックスのみを生成し、 'db：'プレフィックスのみを受け入れることができます。
Except as noted with regard to 'to' and 'from' addresses for stanzas within the 'jabber:server' namespace, a server is not responsible for validating the XML elements forwarded to a client or another server; an implementation MAY choose to provide only validated data elements but this is OPTIONAL (although an implementation MUST NOT accept XML that is not well-formed). Clients SHOULD NOT rely on the ability to send data which does not conform to the schemas, and SHOULD ignore any non-conformant elements or attributes on the incoming XML stream. Validation of XML streams and stanzas is OPTIONAL, and schemas are included herein for descriptive purposes only.
「jabber：server 'namespace内のスタンザの「to」および「from」に関して言及されている場合を除き、サーバーは、クライアントまたは別のサーバーに転送されたXML要素を検証する責任を負いません。実装では、検証済みのデータ要素のみを提供することを選択できますが、これはオプションです（ただし、実装は、適切に形成されていないXMLを受け入れてはなりません）。クライアントは、スキーマに準拠していないデータを送信する機能に依存しないでください。また、着信XMLストリーム上の非変性要素または属性を無視する必要があります。XMLストリームとスタンザの検証はオプションであり、説明的な目的のみでスキーマが含まれています。
Implementations SHOULD send a text declaration before sending a stream header. Applications MUST follow the rules in [XML] regarding the circumstances under which a text declaration is included.
実装は、ストリームヘッダーを送信する前にテキスト宣言を送信する必要があります。アプリケーションは、テキスト宣言が含まれている状況に関する[XML]のルールに従う必要があります。
Implementations MUST support the UTF-8 (RFC 3629 [UTF-8]) transformation of Universal Character Set (ISO/IEC 10646-1 [UCS2]) characters, as required by RFC 2277 [CHARSET]. Implementations MUST NOT attempt to use any other encoding.
実装は、RFC 2277 [Charset]で要求されるように、UTF-8（RFC 3629 [UTF-8]）普遍的文字セット（ISO/IEC 10646-1 [UCS2]）文字の変換をサポートする必要があります。実装は、他のエンコードを使用しようとしてはなりません。
This section summarizes the specific aspects of the Extensible Messaging and Presence Protocol that MUST be supported by servers and clients in order to be considered compliant implementations, as well as additional protocol aspects that SHOULD be supported. For compliance purposes, we draw a distinction between core protocols (which MUST be supported by any server or client, regardless of the specific application) and instant messaging protocols (which MUST be supported only by instant messaging and presence applications built on top of the core protocols). Compliance requirements that apply to all servers and clients are specified in this section; compliance requirements for instant messaging servers and clients are specified in the corresponding section of [XMPP-IM].
このセクションでは、準拠した実装と、サポートすべき追加のプロトコルの側面と見なされるためには、サーバーとクライアントがサポートする必要がある拡張可能なメッセージングと存在プロトコルの特定の側面をまとめたものです。コンプライアンスのために、コアプロトコル（特定のアプリケーションに関係なく、任意のサーバーまたはクライアントによってサポートされる必要がある）とインスタントメッセージングプロトコル（コアの上に構築されたインスタントメッセージングとプレゼンスアプリケーションによってのみサポートされる必要があります。プロトコル）。このセクションでは、すべてのサーバーとクライアントに適用されるコンプライアンス要件が指定されています。インスタントメッセージングサーバーとクライアントのコンプライアンス要件は、[XMPP-IM]の対応するセクションで指定されています。
In addition to all defined requirements with regard to security, XML usage, and internationalization, a server MUST support the following core protocols in order to be considered compliant:
セキュリティ、XML使用、および国際化に関するすべての定義された要件に加えて、サーバーは準拠と見なされるために、次のコアプロトコルをサポートする必要があります。
o Application of the [NAMEPREP], Nodeprep (Appendix A), and Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses (including ensuring that domain identifiers are internationalized domain names as defined in [IDNA])
o [nameprep]、nodeprep（付録A）、およびリソースプレップ（付録B）の[StringPrep]のプロファイル（StringPrep]のアドレスへの適用（ドメイン識別子が[IDNA]で定義されているように国際化ドメイン名であることを保証することを含む）
o XML streams (Section 4), including Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7)
o XMLストリーム（セクション4）、TLSの使用（セクション5）、SASLの使用（セクション6）、およびリソースバインディング（セクション7）
o The basic semantics of the three defined stanza kinds (i.e., <message/>, <presence/>, and <iq/>) as specified in stanza semantics (Section 9.2)
o Stanza Semanticsで指定されている3つの定義されたスタンザ種類（つまり、<メッセージ/>、<encless/>、および<IQ/>）の基本的なセマンティクス（セクション9.2）
o Generation (and, where appropriate, handling) of error syntax and semantics related to streams, TLS, SASL, and XML stanzas
o エラーの構文とストリーム、TLS、SASL、XMLスタンザに関連するセマンティクスの生成（および適切な場合、取り扱い）
In addition, a server MAY support the following core protocol:
さらに、サーバーは次のコアプロトコルをサポートできます。
o Server dialback (Section 8)
o サーバーダイヤルバック（セクション8）
A client MUST support the following core protocols in order to be considered compliant:
クライアントは、準拠と見なされるために、次のコアプロトコルをサポートする必要があります。
o XML streams (Section 4), including Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7)
o XMLストリーム（セクション4）、TLSの使用（セクション5）、SASLの使用（セクション6）、およびリソースバインディング（セクション7）
o The basic semantics of the three defined stanza kinds (i.e., <message/>, <presence/>, and <iq/>) as specified in stanza semantics (Section 9.2)
o Stanza Semanticsで指定されている3つの定義されたスタンザ種類（つまり、<メッセージ/>、<encless/>、および<IQ/>）の基本的なセマンティクス（セクション9.2）
o Handling (and, where appropriate, generation) of error syntax and semantics related to streams, TLS, SASL, and XML stanzas
o エラーの構文と、ストリーム、TLS、SASL、XMLスタンザに関連するエラー構文とセマンティクスのハンドリング（および生成）
In addition, a client SHOULD support the following core protocols:
さらに、クライアントは次のコアプロトコルをサポートする必要があります。
o Generation of addresses to which the [NAMEPREP], Nodeprep (Appendix A), and Resourceprep (Appendix B) profiles of [STRINGPREP] can be applied without failing
o [nameprep]、nodeprep（付録A）、および[stringprep]のプロファイルを失敗なく適用できるアドレスの生成
XML streams MUST be encoded in UTF-8 as specified under Character Encoding (Section 11.5). As specified under Stream Attributes (Section 4.4), an XML stream SHOULD include an 'xml:lang' attribute that is treated as the default language for any XML character data sent over the stream that is intended to be presented to a human user. As specified under xml:lang (Section 9.1.5), an XML stanza SHOULD include an 'xml:lang' attribute if the stanza contains XML character data that is intended to be presented to a human user. A server SHOULD apply the default 'xml:lang' attribute to stanzas it routes or delivers on behalf of connected entities, and MUST NOT modify or delete 'xml:lang' attributes from stanzas it receives from other entities.
XMLストリームは、文字エンコード（セクション11.5）で指定されているように、UTF-8でエンコードする必要があります。ストリーム属性（セクション4.4）で指定されているように、XMLストリームには、人間のユーザーに提示されることを目的としたXML文字データのデフォルト言語として扱われる「XML：LANG」属性を含める必要があります。XML：Lang（セクション9.1.5）で指定されているように、XMLスタンザには、スタンザに人間のユーザーに提示されることを目的としたXML文字データが含まれている場合、「XML：Lang」属性を含める必要があります。サーバーは、接続されたエンティティに代わってルートまたは配信するスタンザにデフォルトの「XML：LANG」属性を適用する必要があり、他のエンティティから受け取るスタンザから 'XML：lang'属性を変更または削除してはなりません。
For the purposes of XMPP communications (client-to-server and server-to-server), the term "high security" refers to the use of security technologies that provide both mutual authentication and integrity-checking; in particular, when using certificate-based authentication to provide high security, a chain-of-trust SHOULD be established out-of-band, although a shared certificate authority signing certificates could allow a previously unknown certificate to establish trust in-band. See Section 14.2 below regarding certificate validation procedures.
XMPP通信（クライアントからサーバー、サーバーからサーバー）の目的のために、「高セキュリティ」という用語は、相互認証と整合性チェックの両方を提供するセキュリティテクノロジーの使用を指します。特に、証明書ベースの認証を使用して高度なセキュリティを提供する場合、帯域外のチェーンを確立する必要があります。証明書の検証手順については、以下のセクション14.2を参照してください。
Implementations MUST support high security. Service provisioning SHOULD use high security, subject to local security policies.
実装は、高いセキュリティをサポートする必要があります。サービスプロビジョニングは、ローカルセキュリティポリシーを条件として、高いセキュリティを使用する必要があります。
When an XMPP peer communicates with another peer securely, it MUST validate the peer's certificate. There are three possible cases:
XMPPピアが別のピアと安全に通信する場合、ピアの証明書を検証する必要があります。3つのケースがあります。
Case #1: The peer contains an End Entity certificate which appears to be certified by a chain of certificates terminating in a trust anchor (as described in Section 6.1 of [X509]).
ケース＃1：ピアには、[X509]のセクション6.1で説明されているように、信託アンカーで終了する証明書のチェーンによって認定されていると思われるエンディティ証明書が含まれています。
Case #2: The peer certificate is certified by a Certificate Authority not known to the validating peer.
ケース＃2：ピア証明書は、有効なピアに知られていない証明書当局によって認定されます。
Case #3: The peer certificate is self-signed.
ケース＃3：ピア証明書は自己署名です。
In Case #1, the validating peer MUST do one of two things:
ケース＃1では、検証済みのピアは2つのことのいずれかを行う必要があります。
1. Verify the peer certificate according to the rules of [X509]. The certificate SHOULD then be checked against the expected identity of the peer following the rules described in [HTTP-TLS], except that a subjectAltName extension of type "xmpp" MUST be used as the identity if present. If one of these checks fails, user-oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients SHOULD terminate the connection (with a bad certificate error) and log the error to an appropriate audit log. Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting that enables it.
1. [x509]のルールに従ってピア証明書を確認します。[http-tls]で説明されているルールに従って、ピアの予想される身元に対して証明書を確認する必要があります。ただし、タイプ「xmpp」のsumbutaltname拡張は、存在する場合は識別として使用する必要があります。これらのチェックのいずれかが失敗した場合、ユーザー指向のクライアントは、ユーザーに通知する必要があります（クライアントは、いずれにしてもユーザーに接続を継続する機会を与えます）か、悪い証明書エラーで接続を終了する必要があります。自動化されたクライアントは、接続を終了し（悪い証明書エラーを使用して）、エラーを適切な監査ログにログに記録する必要があります。自動化されたクライアントは、このチェックを無効にする構成設定を提供する場合がありますが、それを有効にする設定を提供する必要があります。
2. The peer SHOULD show the certificate to a user for approval, including the entire certificate chain. The peer MUST cache the certificate (or some non-forgeable representation such as a hash). In future connections, the peer MUST verify that the same certificate was presented and MUST notify the user if it has changed.
2. ピアは、証明書チェーン全体を含む承認のために証明書をユーザーに表示する必要があります。ピアは証明書（またはハッシュなどの焦点をかけない表現）をキャッシュする必要があります。将来の接続では、ピアは同じ証明書が提示されたことを確認し、ユーザーが変更された場合にユーザーに通知する必要があります。
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
ケース＃2およびケース＃3では、上記の（2）のように実装が機能する必要があります。
A compliant client implementation MUST support both TLS and SASL for connections to a server.
準拠したクライアントの実装は、サーバーへの接続についてTLSとSASLの両方をサポートする必要があります。
The TLS protocol for encrypting XML streams (defined under Use of TLS (Section 5)) provides a reliable mechanism for helping to ensure the confidentiality and data integrity of data exchanged between two entities.
XMLストリームを暗号化するためのTLSプロトコル（TLSの使用（セクション5）の使用で定義）は、2つのエンティティ間で交換されるデータの機密性とデータの整合性を確保するための信頼できるメカニズムを提供します。
The SASL protocol for authenticating XML streams (defined under Use of SASL (Section 6)) provides a reliable mechanism for validating that a client connecting to a server is who it claims to be.
XMLストリームを認証するためのSASLプロトコル（SASLの使用（セクション6）の使用で定義）は、サーバーに接続するクライアントがそれが主張する人であることを検証するための信頼できるメカニズムを提供します。
Client-to-server communications MUST NOT proceed until the DNS hostname asserted by the server has been resolved. Such resolutions SHOULD first attempt to resolve the hostname using an [SRV] Service of "xmpp-client" and Proto of "tcp", resulting in resource records such as "_xmpp-client._tcp.example.com." (the use of the string
クライアント間通信は、サーバーによって主張されたDNSホスト名が解決されるまで続行してはなりません。このような解決策は、最初に「XMPP-Client」の[srv]サービスと「TCP」のプロトを使用してホスト名を解決しようとする必要があり、「_xmpp-client._tcp.example.com」などのリソースレコードを作成します。（文字列の使用
"xmpp-client" for the service identifier is consistent with the IANA registration). If the SRV lookup fails, the fallback is a normal IPv4/IPv6 address record resolution to determine the IP address, using the "xmpp-client" port of 5222, registered with the IANA.
サービス識別子の「XMPP-Client」は、IANA登録と一致しています）。SRVルックアップが失敗した場合、フォールバックは、IANAに登録された5222の「XMPP-Client」ポートを使用して、IPアドレスを決定するための通常のIPv4/IPv6アドレスレコード解像度です。
The IP address and method of access of clients MUST NOT be made public by a server, nor are any connections other than the original server connection required. This helps to protect the client's server from direct attack or identification by third parties.
クライアントのIPアドレスとアクセス方法は、サーバーによって公開されてはならず、元のサーバー接続以外の接続も必要です。これにより、クライアントのサーバーが第三者による直接的な攻撃または識別から保護するのに役立ちます。
A compliant server implementation MUST support both TLS and SASL for inter-domain communications. For historical reasons, a compliant implementation SHOULD also support Server Dialback (Section 8).
準拠したサーバーの実装は、ドメイン間通信のためにTLSとSASLの両方をサポートする必要があります。歴史的な理由から、準拠した実装はサーバーのダイヤルバックもサポートする必要があります（セクション8）。
Because service provisioning is a matter of policy, it is OPTIONAL for any given domain to communicate with other domains, and server-to-server communications MAY be disabled by the administrator of any given deployment. If a particular domain enables inter-domain communications, it SHOULD enable high security.
サービスプロビジョニングはポリシーの問題であるため、特定のドメインが他のドメインと通信することはオプションであり、サーバー間通信は、特定の展開の管理者によって無効になる場合があります。特定のドメインがドメイン間通信を有効にする場合、高いセキュリティを有効にする必要があります。
Administrators may want to require use of SASL for server-to-server communications in order to ensure both authentication and confidentiality (e.g., on an organization's private network). Compliant implementations SHOULD support SASL for this purpose.
管理者は、認証と機密性の両方を確保するために、サーバー間通信にSASLの使用を要求することをお勧めします（たとえば、組織のプライベートネットワークで）。準拠した実装は、この目的のためにSASLをサポートする必要があります。
Inter-domain connections MUST NOT proceed until the DNS hostnames asserted by the servers have been resolved. Such resolutions MUST first attempt to resolve the hostname using an [SRV] Service of "xmpp-server" and Proto of "tcp", resulting in resource records such as "_xmpp-server._tcp.example.com." (the use of the string "xmpp-server" for the service identifier is consistent with the IANA registration; note well that the "xmpp-server" service identifier supersedes the earlier use of a "jabber" service identifier, since the earlier usage did not conform to [SRV]; implementations desiring to be backward compatible should continue to look for or answer to the "jabber" service identifier as well). If the SRV lookup fails, the fallback is a normal IPv4/IPv6 address record resolution to determine the IP address, using the "xmpp-server" port 5269, registered with the IANA.
ドメイン間接続は、サーバーによって主張されたDNSホスト名が解決されるまで続行してはなりません。このような解決策は、最初に「XMPP-Server」の[srv]サービスと「TCP」のプロトを使用してホスト名を解決しようとする必要があり、「_xmpp-server._tcp.example.com」などのリソースレコードを作成しなければなりません。（サービス識別子の文字列「xmpp-server」の使用は、IANA登録と一致しています。「xmpp-server」サービス識別子は、以前の使用法が以前に使用したため、「Jabber」サービス識別子の以前の使用に取って代わることに注意してください。[srv]に準拠していない;後方互換性を持つことを望む実装は、「Jabber」サービス識別子を探したり、答えたりする必要があります）。SRVルックアップが失敗した場合、フォールバックは、IANAに登録された「XMPP-Server」ポート5269を使用して、IPアドレスを決定するための通常のIPv4/IPv6アドレスレコード解像度です。
Server dialback helps protect against domain spoofing, thus making it more difficult to spoof XML stanzas. It is not a mechanism for authenticating, securing, or encrypting streams between servers as is done via SASL and TLS, and results in weak verification of server identities only. Furthermore, it is susceptible to DNS poisoning attacks unless DNSSec [DNSSEC] is used, and even if the DNS information is accurate, dialback cannot protect from attacks where the attacker is capable of hijacking the IP address of the remote domain. Domains requiring robust security SHOULD use TLS and SASL. If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary.
サーバーのダイヤルバックは、ドメインのスプーフィングから保護するのに役立ち、XMLスタンザをスプーフィングすることをより困難にします。SASLとTLSを介して行われるように、サーバー間でストリームを認証、保護、または暗号化するメカニズムではなく、サーバーのアイデンティティのみが弱い検証をもたらします。さらに、DNSSEC [DNSSEC]を使用しない限り、DNS中毒攻撃の影響を受けやすく、DNS情報が正確であっても、ダイヤルバックは攻撃者がリモートドメインのIPアドレスをハイジャックできる攻撃から保護できません。堅牢なセキュリティを必要とするドメインは、TLSとSASLを使用する必要があります。SASLがサーバーからサーバーへの認証に使用される場合、それは不要なため、ダイヤルバックは使用しないでください。
The order of layers in which protocols MUST be stacked is as follows:
プロトコルを積み重ねなければならない層の順序は次のとおりです。
1. TCP 2. TLS 3. SASL 4. XMPP
1. TCP 2. TLS 3. SASL 4. XMPP
The rationale for this order is that [TCP] is the base connection layer used by all of the protocols stacked on top of TCP, [TLS] is often provided at the operating system layer, [SASL] is often provided at the application layer, and XMPP is the application itself.
この順序の理論的根拠は、[TCP]はTCPの上に積み重ねられたすべてのプロトコルで使用されるベース接続レイヤーであり、[TLS]はオペレーティングシステム層でしばしば提供され、[SASL]はアプリケーション層でしばしば提供されることです。XMPPはアプリケーション自体です。
The SASL framework does not provide a mechanism to bind SASL authentication to a security layer providing confidentiality and integrity protection that was negotiated at a lower layer. This lack of a "channel binding" prevents SASL from being able to verify that the source and destination end points to which the lower layer's security is bound are equivalent to the end points that SASL is authenticating. If the end points are not identical, the lower layer's security cannot be trusted to protect data transmitted between the SASL authenticated entities. In such a situation, a SASL security layer should be negotiated that effectively ignores the presence of the lower layer security.
SASLフレームワークは、SASL認証をセキュリティレイヤーに結合するメカニズムを提供しません。この「チャネルバインディング」の欠如により、SASLは、下層のセキュリティが拘束されるソースと宛先のエンドポイントがSASLが認証しているエンドポイントと同等であることを確認することができなくなります。エンドポイントが同一でない場合、SASL認証エンティティ間で送信されるデータを保護するために、下層のセキュリティを信頼することはできません。このような状況では、下層セキュリティの存在を効果的に無視するSASLセキュリティ層を交渉する必要があります。
At a minimum, all implementations MUST support the following mechanisms:
少なくとも、すべての実装は次のメカニズムをサポートする必要があります。
for authentication: the SASL [DIGEST-MD5] mechanism
認証用：SASL [Digest-MD5]メカニズム
for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
機密性について：TLS（TLS_RSA_WITH_3DES_EDE_CBC_SHA CIPHERを使用）
for both: TLS plus SASL EXTERNAL(using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
両方の場合：TLS Plus SASL外部（TLS_RSA_WITH_3DES_EDE_CBC_SHAクライアント側の証明書をサポートする）
Communications using XMPP normally occur over [TCP] connections on port 5222 (client-to-server) or port 5269 (server-to-server), as registered with the IANA (see IANA Considerations (Section 15)). Use of these well-known ports allows administrators to easily enable or disable XMPP activity through existing and commonly-deployed firewalls.
XMPPを使用した通信は通常、IANAに登録されているように、ポート5222（クライアントからサーバー）またはポート5269（サーバーからサーバー）の[TCP]接続を介して発生します（IANAの考慮事項（セクション15）を参照）。これらの有名なポートを使用すると、管理者は既存の一般的に展開されているファイアウォールを介してXMPPアクティビティを簡単に有効または無効にすることができます。
Both the client and the server MUST verify any [BASE64] data received during SASL negotiation. An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the base64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of base64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. Base 64 encoding visually hides otherwise easily recognized information, such as passwords, but does not provide any computational confidentiality. Base 64 encoding MUST follow the definition in Section 3 of RFC 3548 [BASE64].
クライアントとサーバーの両方が、SASL交渉中に受信した[base64]データを確認する必要があります。実装は、base64アルファベットで明示的に許可されていない文字を拒否する必要があります（無視しません）。これは、情報を「漏れ」に使用できる秘密のチャネルの作成を防ぐのに役立ちます。実装は無効な入力で壊れてはならず、その文字がデータの最後の文字以外のもの（ "= aaa"または "bbbb以外のものとして含まれている場合、パッド（ '='）文字を含むbase64文字のシーケンスを拒否する必要があります= ccc "）;これは、バッファーオーバーフロー攻撃や実装に対するその他の攻撃を防ぐのに役立ちます。ベース64エンコーディングは、パスワードなど、簡単に認識された情報を視覚的に隠しますが、計算の機密性は提供されません。ベース64エンコーディングは、RFC 3548 [Base64]のセクション3の定義に従う必要があります。
XMPP makes use of the [NAMEPREP] profile of [STRINGPREP] for the processing of domain identifiers; for security considerations related to Nameprep, refer to the appropriate section of [NAMEPREP].
XMPPは、ドメイン識別子の処理に[StringPrep]の[nameprep]プロファイルを使用します。NamePrepに関連するセキュリティ上の考慮事項については、[NamePrep]の適切なセクションを参照してください。
In addition, XMPP defines two profiles of [STRINGPREP]: Nodeprep (Appendix A) for node identifiers and Resourceprep (Appendix B) for resource identifiers.
さらに、XMPPは[StringPrep]の2つのプロファイルを定義します：ノード識別子のnodeprep（付録A）とリソース識別子のリソースプレップ（付録B）。
The Unicode and ISO/IEC 10646 repertoires have many characters that look similar. In many cases, users of security protocols might do visual matching, such as when comparing the names of trusted third parties. Because it is impossible to map similar-looking characters without a great deal of context, such as knowing the fonts used, stringprep does nothing to map similar-looking characters together, nor to prohibit some characters because they look like others.
UnicodeおよびISO/IEC 10646レパートリーには、似たように見える多くの文字があります。多くの場合、セキュリティプロトコルのユーザーは、信頼できるサードパーティの名前を比較する場合など、視覚的なマッチングを行う場合があります。使用されているフォントを知るなど、多くのコンテキストなしで似たようなキャラクターをマッピングすることは不可能であるため、StringPrepは似たようなキャラクターをマッピングすることも、他の文字のように見えるため、一部の文字を禁止することもできません。
A node identifier can be employed as one part of an entity's address in XMPP. One common usage is as the username of an instant messaging user; another is as the name of a multi-user chat room; many other kinds of entities could use node identifiers as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized node identifier; for example, a user entering a single internationalized node identifier could access another user's account information, or a user could gain access to an otherwise restricted chat room or service.
ノード識別子は、XMPPのエンティティのアドレスの一部として使用できます。1つの一般的な使用法は、インスタントメッセージングユーザーのユーザー名です。もう1つは、マルチユーザーチャットルームの名前としてです。他の多くの種類のエンティティは、アドレスの一部としてノード識別子を使用できます。このようなサービスのセキュリティは、国際化されたノード識別子のさまざまな解釈に基づいて侵害される可能性があります。たとえば、単一の国際化ノード識別子を入力するユーザーは、別のユーザーのアカウント情報にアクセスしたり、ユーザーが制限付きのチャットルームまたはサービスにアクセスすることができます。
A resource identifier can be employed as one part of an entity's address in XMPP. One common usage is as the name for an instant messaging user's connected resource (active session); another is as the nickname of a user in a multi-user chat room; many other kinds of entities could use resource identifiers as part of their addresses. The security of such services could be compromised based on different interpretations of the internationalized resource identifier; for example, a user could attempt to initiate multiple sessions with the same name, or a user could send a message to someone other than the intended recipient in a multi-user chat room.
リソース識別子は、XMPPのエンティティのアドレスの一部として使用できます。1つの一般的な使用法は、インスタントメッセージングユーザーの接続リソース（アクティブセッション）の名前としてです。もう1つは、マルチユーザーチャットルームのユーザーのニックネームとしてです。他の多くの種類のエンティティは、アドレスの一部としてリソース識別子を使用できます。このようなサービスのセキュリティは、国際化された資源識別子のさまざまな解釈に基づいて侵害される可能性があります。たとえば、ユーザーは同じ名前の複数のセッションを開始しようとするか、ユーザーがマルチユーザーチャットルームで意図した受信者以外の誰かにメッセージを送信することができます。
A URN sub-namespace for TLS-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in The IETF XML Registry [XML-REG].)
拡張可能なメッセージと存在プロトコル（XMPP）のTLS関連データのurnサブネームスペースは、次のように定義されます。（この名前空間名は、IETF XMLレジストリ[XML-REG]で定義されている形式に付着します。）
URI: urn:ietf:params:xml:ns:xmpp-tls
Specification: RFC 3920
Description: This is the XML namespace name for TLS-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for SASL-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
拡張可能なメッセージと存在プロトコル（XMPP）のSASL関連データのurnサブネームスペースは、次のように定義されます。（この名前空間名は、[xml-reg]で定義されている形式に準拠しています。）
URI: urn:ietf:params:xml:ns:xmpp-sasl
Specification: RFC 3920
Description: This is the XML namespace name for SASL-related data in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for stream-related error data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
拡張可能なメッセージと存在プロトコル（XMPP）のストリーム関連エラーデータのURNサブネームスペースは、次のように定義されます。（この名前空間名は、[xml-reg]で定義されている形式に準拠しています。）
URI: urn:ietf:params:xml:ns:xmpp-streams
Specification: RFC 3920
Description: This is the XML namespace name for stream-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for resource binding in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
拡張可能なメッセージングおよび存在プロトコル（XMPP）でのリソースバインディングのためのURNサブネームスペースは、次のように定義されます。（この名前空間名は、[xml-reg]で定義されている形式に準拠しています。）
URI: urn:ietf:params:xml:ns:xmpp-bind
Specification: RFC 3920
Description: This is the XML namespace name for resource binding in
the Extensible Messaging and Presence Protocol (XMPP) as defined
by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
A URN sub-namespace for stanza-related error data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].)
拡張可能なメッセージと存在プロトコル（XMPP）のスタンザ関連エラーデータのurnサブネームスペースは、次のように定義されます。（この名前空間名は、[xml-reg]で定義されている形式に準拠しています。）
URI: urn:ietf:params:xml:ns:xmpp-stanzas
Specification: RFC 3920
Description: This is the XML namespace name for stanza-related error
data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3920.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
The Nodeprep profile of stringprep is defined under Nodeprep (Appendix A). The IANA has registered Nodeprep in the stringprep profile registry.
stringprepのnodeprepプロファイルは、nodeprep（付録A）の下で定義されています。IANAは、stringprepプロファイルレジストリにnodeprepを登録しています。
Name of this profile:
このプロファイルの名前：
Nodeprep
nodeprep
RFC in which the profile is defined:
プロファイルが定義されているRFC：
RFC 3920
RFC 3920
Indicator whether or not this is the newest version of the profile:
これがプロファイルの最新バージョンであるかどうかをインジケーター：
This is the first version of Nodeprep
これはnodeprepの最初のバージョンです
The Resourceprep profile of stringprep is defined under Resourceprep (Appendix B). The IANA has registered Resourceprep in the stringprep profile registry.
StringPrepのResourcePrepプロファイルは、ResourcePrep（付録B）で定義されています。IANAは、StringPrepプロファイルレジストリにResourcePrepを登録しています。
Name of this profile:
このプロファイルの名前：
Resourceprep
ResourcePrep
RFC in which the profile is defined:
プロファイルが定義されているRFC：
RFC 3920
RFC 3920
Indicator whether or not this is the newest version of the profile:
これがプロファイルの最新バージョンであるかどうかをインジケーター：
This is the first version of Resourceprep
これは、ResourcePrepの最初のバージョンです
The IANA has registered "xmpp" as a GSSAPI [GSS-API] service name, as defined under SASL Definition (Section 6.3).
IANAは、SASL定義（セクション6.3）で定義されているように、「XMPP」をGSSAPI [GSS-API]サービス名として登録しています。
The IANA has registered "xmpp-client" and "xmpp-server" as keywords for [TCP] ports 5222 and 5269 respectively.
IANAは、それぞれ[TCP]ポート5222および5269のキーワードとして「XMPP-Client」と「XMPP-Server」を登録しています。
These ports SHOULD be used for client-to-server and server-to-server communications respectively, but their use is OPTIONAL.
これらのポートは、それぞれクライアント間およびサーバー間通信に使用する必要がありますが、それらの使用はオプションです。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[Base64] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 3548、2003年7月。
[CHARSET] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[Charset] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[Digest-MD5] Leach、P。and C. Newman、「SASLメカニズムとしての消化認証を使用」、RFC 2831、2000年5月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[GSS-API] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[GSS-API] Linn、J。、「Generic Security Service Application Program Interface Version 2、Update 1」、RFC 2743、2000年1月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS] Rescorla、E。、「TLS上のHTTP」、RFC 2818、2000年5月。
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA] Faltstrom、P.、Hoffman、P.、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[IPv6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[IPv6] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アーキテクチャへの対処」、RFC 3513、2003年4月。
[LANGTAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[Langtags] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[NamePrep] Hoffman、P。and M. Blanchet、「NamePrep：国際化ドメイン名のStringPrepプロファイル（IDN）」、RFC 3491、2003年3月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[ランダム] Eastlake 3rd、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[SRV] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep] Hoffman、P。and M. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[用語] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[UCS2] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, October 1996.
[UCS2]国際標準化機関、「情報技術 - ユニバーサルマルチオクテットコード化された文字セット（UCS） - 修正2：UCS変換形式8（UTF-8）」、ISO標準10646-1補遺2、1996年10月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X509] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[XML] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C.、およびE. Maler、「拡張可能なマークアップ言語（XML）1.0（2番目のED）」、W3C Rec-XML、2000年10月、<HTTP：//www.w3.org/tr/rec-xml>。
[XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XML-Names] Bray、T.、Hollander、D.、A。Layman、「XMLの名前空間」、W3C Rec-Xml-Names、1999年1月、<http://www.w3.org/tr/rec-xml-names>。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP] Newman、C。and J. Myers、「ACAP-アプリケーション構成アクセスプロトコル」、RFC 2244、1997年11月。
[ASN.1] CCITT, "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)", 1988.
[ASN.1] CCITT、「推奨X.208：抽象的構文表記の仕様（ASN.1）」、1988。
[DNSSEC] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]イーストレイク3rd、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP/1.1」、RFC 2616、1999年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[Imp-reqs] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「インスタントメッセージング /存在プロトコル要件」、RFC 2779、2000年2月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J。およびD. Reed、「インターネットリレーチャットプロトコル」、RFC 1459、1993年5月。
[JEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", JSF JEP 0029, October 2003.
[JEP-0029] Kaes、C。、「Jabber Identiers（JIDS）の定義」、JSF JEP 0029、2003年10月。
[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.
[JEP-0078] Saint-Andre、P。、「非SASL認証」、JSF JEP 0078、2004年7月。
[JEP-0086] Norris, R. and P. Saint-Andre, "Error Condition Mappings", JSF JEP 0086, February 2004.
[JEP-0086] Norris、R。and P. Saint-Andre、「エラー状態マッピング」、JSF JEP 0086、2004年2月。
[JSF] Jabber Software Foundation, "Jabber Software Foundation", <http://www.jabber.org/>.
[JSF] Jabber Software Foundation、「Jabber Software Foundation」、<http://www.jabber.org/>。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3] Myers、J。and M. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[SIMPLE] SIMPLE Working Group, "SIMPLE WG", <http://www.ietf.org/html.charters/simple-charter.html>.
[Simple]シンプルなワーキンググループ、「Simple WG」、<http://www.ietf.org/html.charters/simple-charter.html>。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifiers（URI）：Generic Syntax」、RFC 2396、1998年8月。
[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[使用]ニューマン、C。、「IMAP、POP3およびACAPでTLSを使用」、RFC 2595、1999年6月。
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[XML-Reg] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM] Saint-Andre、P.、ed。、「拡張可能なメッセージと存在プロトコル（XMPP）：インスタントメッセージングと存在」、RFC 3921、2004年10月。
This appendix defines the "Nodeprep" profile of [STRINGPREP]. As such, it specifies processing rules that will enable users to enter internationalized node identifiers in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP node identifier is the optional portion of an XMPP address that precedes a domain identifier and the '@' separator; it is often but not exclusively associated with an instant messaging username.) These processing rules are intended only for XMPP node identifiers and are not intended for arbitrary text or any other aspect of an XMPP address.
この付録は、[stringprep]の「nodeprep」プロファイルを定義しています。そのため、ユーザーが拡張可能なメッセージとプレゼンスプロトコル（XMPP）に国際的なノード識別子を入力できるようにする処理ルールを指定し、文字列のコンテンツを正しくする可能性が最も高くなります。（XMPPノード識別子は、ドメイン識別子と「@'セパレーターの前にあるXMPPアドレスのオプション部分です。多くの場合、インスタントメッセージングのユーザー名に排他的に関連付けられていません。）これらの処理ルールは、XMPPノード識別子とのみを対象としています。任意のテキストまたはXMPPアドレスのその他の側面を目的としていません。
This profile defines the following, as required by [STRINGPREP]:
このプロファイルは、[StringPrep]で要求されるように、以下を定義します。
o The intended applicability of the profile: internationalized node identifiers within XMPP o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in Section 2 of this Appendix o The mappings used: specified in Section 3 o The Unicode normalization used: specified in Section 4 o The characters that are prohibited as output: specified in Section 5 o Bidirectional character handling: specified in Section 6
o プロファイルの意図された適用可能性：XMPP内の国際化ノード識別子o入力と出力の文字レパートリーのstringprep：unicode 3.2、この付録oのセクション2で指定されているunicode 3.2：セクション3で指定セクション4で指定o出力として禁止されている文字：セクション5で指定o双方向の文字処理：セクション6で指定
This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both defined in Appendix A of [STRINGPREP].
このプロファイルでは、Unicode 3.2を使用して、[StringPrep]の付録Aで定義されているテーブルA.1である未割り当てコードポイントのリストがあります。
This profile specifies mapping using the following tables from [STRINGPREP]:
このプロファイルは、[StringPrep]の次のテーブルを使用してマッピングを指定します。
Table B.1 Table B.2
表B.1表B.2
This profile specifies the use of Unicode normalization form KC, as described in [STRINGPREP].
このプロファイルは、[StringPrep]で説明されているように、ユニコード正規化フォームKCの使用を指定します。
This profile specifies the prohibition of using the following tables from [STRINGPREP].
このプロファイルは、[StringPrep]から次のテーブルを使用することの禁止を指定します。
Table C.1.1 Table C.1.2 Table C.2.1 Table C.2.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9
表C.1.1表C.1.2表C.2.1表C.2.2表C.3表C.3表C.4表C.6表C.7表C.7表C.8表C.9
In addition, the following Unicode characters are also prohibited:
さらに、次のユニコード文字も禁止されています。
#x22 (")
#x26 (&)
#x27 (')
#x2F (/)
#x3A (:)
#x3C (<)
#x3E (>)
#x40 (@)
This profile specifies the checking of bidirectional strings, as described in Section 6 of [STRINGPREP].
このプロファイルは、[StringPrep]のセクション6で説明されているように、双方向文字列のチェックを指定します。
This appendix defines the "Resourceprep" profile of [STRINGPREP]. As such, it specifies processing rules that will enable users to enter internationalized resource identifiers in the Extensible Messaging and Presence Protocol (XMPP) and have the highest chance of getting the content of the strings correct. (An XMPP resource identifier is the optional portion of an XMPP address that follows a domain identifier and the '/' separator; it is often but not exclusively associated with an instant messaging session name.) These processing rules are intended only for XMPP resource identifiers and are not intended for arbitrary text or any other aspect of an XMPP address.
この付録は、[StringPrep]の「リソースプレップ」プロファイルを定義しています。そのため、ユーザーが拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）に国際化されたリソース識別子を入力できるようにする処理ルールを指定し、文字列のコンテンツを正しくする可能性が最も高くなります。（XMPPリソース識別子は、ドメイン識別子と '/'セパレーターに続くXMPPアドレスのオプション部分です。これは、インスタントメッセージングセッション名に排他的に関連しているわけではありません。）これらの処理ルールは、XMPPリソース識別子のみを対象としています。任意のテキストやXMPPアドレスのその他の側面を目的としていません。
This profile defines the following, as required by [STRINGPREP]:
このプロファイルは、[StringPrep]で要求されるように、以下を定義します。
o The intended applicability of the profile: internationalized resource identifiers within XMPP
o プロファイルの意図された適用性：XMPP内の国際化されたリソース識別子
o The character repertoire that is the input and output to stringprep: Unicode 3.2, specified in Section 2 of this Appendix
o この付録のセクション2で指定されているStringPrep：Unicode 3.2への入力と出力であるキャラクターレパートリー
o The mappings used: specified in Section 3
o 使用されるマッピング：セクション3で指定されています
o The Unicode normalization used: specified in Section 4
o 使用されるユニコード正規化：セクション4で指定されています
o The characters that are prohibited as output: specified in Section 5
o 出力として禁止されている文字：セクション5で指定
o Bidirectional character handling: specified in Section 6
o 双方向の文字処理：セクション6で指定
This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both defined in Appendix A of [STRINGPREP].
このプロファイルでは、Unicode 3.2を使用して、[StringPrep]の付録Aで定義されているテーブルA.1である未割り当てコードポイントのリストがあります。
This profile specifies mapping using the following tables from [STRINGPREP]:
このプロファイルは、[StringPrep]の次のテーブルを使用してマッピングを指定します。
Table B.1
表B.1
This profile specifies using Unicode normalization form KC, as described in [STRINGPREP].
このプロファイルは、[StringPrep]で説明されているように、Unicode正規化フォームKCを使用して指定します。
This profile specifies prohibiting use of the following tables from [STRINGPREP].
このプロファイルは、[StringPrep]から次のテーブルの使用を禁止することを指定しています。
Table C.1.2 Table C.2.1 Table C.2.2 Table C.3 Table C.4 Table C.5 Table C.6 Table C.7 Table C.8 Table C.9
表C.1.2表C.2.1表C.2.2表C.3表C.3表C.5表C.6表C.7表C.8表C.9表C.9
This profile specifies checking bidirectional strings as described in Section 6 of [STRINGPREP].
このプロファイルは、[StringPrep]のセクション6で説明されているように、双方向文字列のチェックを指定します。
The following XML schemas are descriptive, not normative. For schemas defining the 'jabber:client' and 'jabber:server' namespaces, refer to [XMPP-IM].
次のXMLスキーマは記述的であり、規範ではありません。「jabber：client」と「jabber：server」名前空間を定義するスキーマについては、[xmpp-im]を参照してください。
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://etherx.jabber.org/streams'
xmlns='http://etherx.jabber.org/streams'
elementFormDefault='unqualified'>
<xs:element name='stream'>
<xs:complexType>
<xs:sequence xmlns:client='jabber:client'
xmlns:server='jabber:server'
xmlns:db='jabber:server:dialback'>
<xs:element ref='features' minOccurs='0' maxOccurs='1'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='client:message'/>
<xs:element ref='client:presence'/>
<xs:element ref='client:iq'/>
</xs:choice>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='server:message'/>
<xs:element ref='server:presence'/>
<xs:element ref='server:iq'/>
<xs:element ref='db:result'/>
<xs:element ref='db:verify'/>
</xs:choice>
</xs:choice>
<xs:element ref='error' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='from' type='xs:string' use='optional'/>
<xs:attribute name='id' type='xs:NMTOKEN' 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:complexType>
</xs:element>
<xs:element name='features'>
<xs:complexType>
<xs:all xmlns:tls='urn:ietf:params:xml:ns:xmpp-tls'
xmlns:sasl='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns:bind='urn:ietf:params:xml:ns:xmpp-bind'
xmlns:sess='urn:ietf:params:xml:ns:xmpp-session'>
<xs:element ref='tls:starttls' minOccurs='0'/>
<xs:element ref='sasl:mechanisms' minOccurs='0'/>
<xs:element ref='bind:bind' minOccurs='0'/>
<xs:element ref='sess:session' minOccurs='0'/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name='error'>
<xs:complexType>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-streams'>
<xs:group ref='err:streamErrorGroup'/>
<xs:element ref='err:text'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-streams'
xmlns='urn:ietf:params:xml:ns:xmpp-streams'
elementFormDefault='qualified'>
<xs:element name='bad-format' type='empty'/>
<xs:element name='bad-namespace-prefix' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-from' type='empty'/>
<xs:element name='invalid-id' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/>
<xs:element name='invalid-xml' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='restricted-xml' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/>
<xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='empty'/>
<xs:element name='xml-not-well-formed' type='empty'/>
<xs:group name='streamErrorGroup'>
<xs:choice>
<xs:element ref='bad-format'/>
<xs:element ref='bad-namespace-prefix'/>
<xs:element ref='conflict'/>
<xs:element ref='connection-timeout'/>
<xs:element ref='host-gone'/>
<xs:element ref='host-unknown'/>
<xs:element ref='improper-addressing'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='invalid-from'/>
<xs:element ref='invalid-id'/>
<xs:element ref='invalid-namespace'/>
<xs:element ref='invalid-xml'/>
<xs:element ref='not-authorized'/>
<xs:element ref='policy-violation'/>
<xs:element ref='remote-connection-failed'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='restricted-xml'/>
<xs:element ref='see-other-host'/>
<xs:element ref='system-shutdown'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unsupported-encoding'/>
<xs:element ref='unsupported-stanza-type'/>
<xs:element ref='unsupported-version'/>
<xs:element ref='xml-not-well-formed'/>
</xs:choice>
</xs:group>
<xs:element name='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<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>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-tls'
xmlns='urn:ietf:params:xml:ns:xmpp-tls'
elementFormDefault='qualified'>
<xs:element name='starttls'>
<xs:complexType>
<xs:sequence>
<xs:element
name='required'
minOccurs='0'
maxOccurs='1'
type='empty'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='proceed' type='empty'/>
<xs:element name='failure' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
elementFormDefault='qualified'>
<xs:element name='mechanisms'>
<xs:complexType>
<xs:sequence>
<xs:element name='mechanism'
maxOccurs='unbounded'
type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='auth'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='mechanism'
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='challenge' type='xs:string'/>
<xs:element name='response' type='xs:string'/>
<xs:element name='abort' type='empty'/>
<xs:element name='success' type='empty'/>
<xs:element name='failure'>
<xs:complexType>
<xs:choice minOccurs='0'>
<xs:element name='aborted' type='empty'/>
<xs:element name='incorrect-encoding' type='empty'/>
<xs:element name='invalid-authzid' type='empty'/>
<xs:element name='invalid-mechanism' type='empty'/>
<xs:element name='mechanism-too-weak' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='temporary-auth-failure' type='empty'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-bind'
xmlns='urn:ietf:params:xml:ns:xmpp-bind'
elementFormDefault='qualified'>
<xs:element name='bind'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:element name='resource' type='xs:string'/>
<xs:element name='jid' type='xs:string'/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:server:dialback'
xmlns='jabber:server:dialback'
elementFormDefault='qualified'>
<xs:element name='result'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<xs:attribute name='to' type='xs:string' use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='verify'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<xs:attribute name='id' type='xs:NMTOKEN' use='required'/>
<xs:attribute name='to' type='xs:string' use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
elementFormDefault='qualified'>
<xs:element name='bad-request' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='feature-not-implemented' type='empty'/>
<xs:element name='forbidden' type='empty'/>
<xs:element name='gone' type='xs:string'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='item-not-found' type='empty'/>
<xs:element name='jid-malformed' type='empty'/>
<xs:element name='not-acceptable' type='empty'/>
<xs:element name='not-allowed' type='empty'/>
<xs:element name='payment-required' type='empty'/>
<xs:element name='recipient-unavailable' type='empty'/>
<xs:element name='redirect' type='xs:string'/>
<xs:element name='registration-required' type='empty'/>
<xs:element name='remote-server-not-found' type='empty'/>
<xs:element name='remote-server-timeout' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='service-unavailable' type='empty'/>
<xs:element name='subscription-required' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unexpected-request' type='empty'/>
<xs:group name='stanzaErrorGroup'>
<xs:choice>
<xs:element ref='bad-request'/>
<xs:element ref='conflict'/>
<xs:element ref='feature-not-implemented'/>
<xs:element ref='forbidden'/>
<xs:element ref='gone'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='item-not-found'/>
<xs:element ref='jid-malformed'/>
<xs:element ref='not-acceptable'/>
<xs:element ref='not-allowed'/>
<xs:element ref='payment-required'/>
<xs:element ref='recipient-unavailable'/>
<xs:element ref='redirect'/>
<xs:element ref='registration-required'/>
<xs:element ref='remote-server-not-found'/>
<xs:element ref='remote-server-timeout'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='service-unavailable'/>
<xs:element ref='subscription-required'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unexpected-request'/>
</xs:choice>
</xs:group>
<xs:element name='text'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<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>
This section is non-normative.
このセクションは非規範的です。
XMPP has been adapted from the protocols originally developed in the Jabber open-source community, which can be thought of as "XMPP 0.9". Because there exists a large installed base of Jabber implementations and deployments, it may be helpful to specify the key differences between the relevant Jabber protocols and XMPP in order to expedite and encourage upgrades of those implementations and deployments to XMPP. This section summarizes the core differences, while the corresponding section of [XMPP-IM] summarizes the differences that relate specifically to instant messaging and presence applications.
XMPPは、「XMPP 0.9」と考えることができるJabberオープンソースコミュニティで元々開発されたプロトコルから採用されています。Jabberの実装と展開の大きなインストールベースが存在するため、関連するJabberプロトコルとXMPPの重要な違いを指定して、それらの実装とXMPPへの展開のアップグレードを促進および奨励することが役立つ場合があります。このセクションでは、コアの違いを要約しますが、[XMPP-IM]の対応するセクションは、特にインスタントメッセージングおよび存在アプリケーションに関連する違いを要約します。
It was common practice in the Jabber community to use SSL for channel encryption on ports other than 5222 and 5269 (the convention is to use ports 5223 and 5270). XMPP uses TLS over the IANA-registered ports for channel encryption, as defined under Use of TLS (Section 5) herein.
Jabberコミュニティでは、5222および5269以外のポートでのチャネル暗号化にSSLを使用することが一般的な慣行でした（条約はポート5223および5270を使用することです）。XMPPは、本明細書でTLS（セクション5）の使用で定義されているように、チャネル暗号化にIANA登録ポートでTLSを使用します。
The client-server authentication protocol developed in the Jabber community used a basic IQ interaction qualified by the 'jabber:iq:auth' namespace (documentation of this protocol is contained in [JEP-0078], published by the Jabber Software Foundation [JSF]). XMPP uses SASL for authentication, as defined under Use of SASL (Section 6) herein.
Jabberコミュニティで開発されたクライアントサーバー認証プロトコルは、「Jabber：IQ：Auth」ネームスペースによって適格な基本的なIQインタラクションを使用しました（このプロトコルのドキュメントは[JEP-0078]に含まれています。）。XMPPは、SASL（セクション6）の使用で定義されているように、認証にSASLを使用します。
The Jabber community did not develop an authentication protocol for server-to-server communications, only the Server Dialback (Section 8) protocol to prevent server spoofing. XMPP supersedes Server Dialback with a true server-to-server authentication protocol, as defined under Use of SASL (Section 6) herein.
Jabberコミュニティは、サーバーからサーバーへの通信のための認証プロトコルを開発しませんでした。サーバーのスプーフィングを防ぐためのサーバーダイヤルバック（セクション8）プロトコルのみです。XMPPは、SASL（セクション6）の使用で定義されているように、真のサーバーからサーバーへの認証プロトコルを使用してサーバーダイヤルバックに優先します。
Resource binding in the Jabber community was handled via the 'jabber:iq:auth' namespace (which was also used for client authentication with a server). XMPP defines a dedicated namespace for resource binding as well as the ability for a server to generate a resource identifier on behalf of a client, as defined under Resource Binding (Section 7).
Jabberコミュニティでのリソースバインディングは、「Jabber：IQ：Auth」ネームスペースを介して処理されました（サーバーでのクライアント認証にも使用されました）。XMPPは、リソースバインディングのためのリソースバインディング用の専用の名前空間を定義し、リソースバインディングで定義されているように、クライアントに代わってリソース識別子を生成する機能を定義します（セクション7）。
JID processing was somewhat loosely defined by the Jabber community (documentation of forbidden characters and case handling is contained in [JEP-0029], published by the Jabber Software Foundation [JSF]). XMPP specifies the use of [NAMEPREP] for domain identifiers and supplements Nameprep with two additional [STRINGPREP] profiles for JID processing: Nodeprep (Appendix A) for node identifiers and Resourceprep (Appendix B) for resource identifiers.
JID処理は、Jabberコミュニティによって多少ゆるく定義されていました（禁止された文字とケース処理のドキュメントは、Jabber Software Foundation [JSF]が発行した[JEP-0029]に含まれています）。XMPPは、ドメイン識別子とサプリメントに[NamePrep]の使用を指定します。NamePrepは、JID処理の2つの追加の[StringPrep]プロファイル：ノード識別子のnodeprep（付録A）およびリソース識別子のリソースプレップ（付録B）を指定します。
Stream-related errors were handled in the Jabber community via XML character data text in a <stream:error/> element. In XMPP, stream-related errors are handled via an extensible mechanism defined under Stream Errors (Section 4.7) herein.
ストリーム関連のエラーは、<ストリーム：エラー/>要素のXML文字データテキストを介してJabberコミュニティで処理されました。XMPPでは、ここでは、ストリームエラー（セクション4.7）で定義された拡張可能なメカニズムを介して、ストリーム関連のエラーが処理されます。
Stanza-related errors were handled in the Jabber community via HTTP-style error codes. In XMPP, stanza-related errors are handled via an extensible mechanism defined under Stanza Errors (Section 9.3) herein. (Documentation of a mapping between Jabber and XMPP error handling mechanisms is contained in [JEP-0086], published by the Jabber Software Foundation [JSF].)
スタンザ関連のエラーは、HTTPスタイルのエラーコードを介してJabberコミュニティで処理されました。XMPPでは、スタンザ関連のエラーは、スタンザエラー（セクション9.3）で定義された拡張可能なメカニズムを介して処理されます。（JabberとXMPPエラー処理メカニズムの間のマッピングのドキュメントは、Jabber Software Foundation [JSF]が発行した[JEP-0086]に含まれています。）
Although use of UTF-8 has always been standard practice within the Jabber community, the community did not define mechanisms for specifying the language of human-readable text provided in XML character data. XMPP specifies the use of the 'xml:lang' attribute in such contexts, as defined under Stream Attributes (Section 4.4) and xml:lang (Section 9.1.5) herein.
UTF-8の使用はJabberコミュニティ内で常に標準的な慣行でしたが、コミュニティはXML文字データで提供される人間の読み取り可能なテキストの言語を指定するためのメカニズムを定義していませんでした。XMPPは、このようなコンテキストで「XML：LANG」属性の使用を指定します。
The Jabber community did not include a 'version' attribute in stream headers. XMPP specifies inclusion of that attribute as a way to signal support for the stream features (authentication, encryption, etc.) defined under Version Support (Section 4.4.1) herein.
Jabberコミュニティには、ストリームヘッダーに「バージョン」属性は含まれていませんでした。XMPPは、本明細書のバージョンサポート（セクション4.4.1）で定義されているストリーム機能（認証、暗号化など）のサポートを信号する方法として、その属性を含めることを指定します。
Contributors
貢献者
Most of the core aspects of the Extensible Messaging and Presence Protocol were developed originally within the Jabber open-source community in 1999. This community was founded by Jeremie Miller, who released source code for the initial version of the jabber server in January 1999. Major early contributors to the base protocol also included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave Smith. Work by the XMPP Working Group has concentrated especially on security and internationalization; in these areas, protocols for the use of TLS and SASL were originally contributed by Rob Norris, and stringprep profiles were originally contributed by Joe Hildebrand. The error code syntax was suggested by Lisa Dusseault.
拡張可能なメッセージと存在プロトコルのコア側面のほとんどは、1999年にJabberオープンソースコミュニティ内で元々開発されました。このコミュニティは、1999年1月にJabber Serverの初期バージョンのソースコードをリリースしたJeremie Millerによって設立されました。基本プロトコルへの初期の貢献者には、ライアン・イートモン、ピーター・ミラード、トーマス・マルダウニー、デイブ・スミスも含まれます。XMPPワーキンググループによる作業は、特にセキュリティと国際化に集中しています。これらの分野では、TLSとSASLの使用のためのプロトコルはもともとRob Norrisによって寄稿され、StringPrepプロファイルはもともとJoe Hildebrandによって寄稿されました。エラーコードの構文は、Lisa Dusseaultによって提案されました。
Acknowledgements
謝辞
Thanks are due to a number of individuals in addition to the contributors listed. Although it is difficult to provide a complete list, the following individuals were particularly helpful in defining the protocols or in commenting on the specifications in this memo: Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov, Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David Waite. Thanks also to members of the XMPP Working Group and the IETF community for comments and feedback provided throughout the life of this memo.
リストされている貢献者に加えて、多くの個人に感謝します。完全なリストを提供することは困難ですが、次の個人は、プロトコルの定義やこのメモの仕様についてコメントするのに特に役立ちました：トーマス・チャロン、リチャード・ドブソン、サム・ハートマン、スカイラー・ヒース、ジョナサン・ホッグ、カレン・ジェニングス、クレイグ・ケーズ、Jacek Konieczny、Alexey Melnikov、Keith Minkler、Julian Missig、Pete Resnick、Marshall Rose、Alexey Shchepin、Jean-Louis Seguineau、Iain Shigeoka、Greg Troxel、David Waite。XMPPワーキンググループとIETFコミュニティのメンバーにも感謝します。このメモの生涯を通じて提供されているコメントとフィードバック。
Author's Address
著者の連絡先
Peter Saint-Andre (editor) Jabber Software Foundation
Peter Saint-Andre（編集者）Jabber Software Foundation
EMail: stpeter@jabber.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。