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
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）インターネット協会（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.
このメモは、拡張メッセージングおよびプレゼンスプロトコル（XMPP）、任意の2つのネットワークエンドポイントとの間でリアルタイムに近い構造化情報を交換するために、拡張マークアップ言語（XML）要素をストリーミングするためのプロトコルのコア機能を定義します。 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]のプロトコルです。基本的な構文とセマンティクスは、主に2002年には1999年に、もともとJabberのオープンソース・コミュニティ内で開発された、XMPP WGは、IETFインスタントメッセージング（IM）およびプレゼンスとして適切であるのJabberプロトコルの適応を開発したチャーター技術。 XMPPワーキンググループによる作業の結果として、現在のメモはXMPP 1.0のコア機能を定義します。インスタントメッセージングとプレゼンス[XMPP-IM]：RFC 2779で定義されているインスタントメッセージングとプレゼンス機能を提供するために必要な拡張[IMP-REQS]は拡張メッセージングおよびプレゼンスプロトコル（XMPP）で指定されています。
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].
この文書に記載されている大文字のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" 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
または他のエンティティのためのセッション、XMLストリーム（第4節）の形で認証されたクライアント、サーバ、および他のエンティティへとからの接続を管理するためのO
o to route appropriately-addressed XML stanzas (Section 9) among such entities over XML streams
ルートに対するO適切に対処XMLスタンザ（セクション9）XMLストリーム上にそのようなエンティティ間
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アドレスのリソース識別子（例えば、<ノード@ドメイン/ホーム>対<ノード@ドメインによって区別される各リソースで、各許可クライアントに代わってサーバーに同時に接続することができ/>仕事）スキーム（第3節）をアドレッシングの下で定義されています。クライアントとサーバ間の接続のための推奨ポートは、IANAに登録され（ポート番号（セクション15.9）を参照）、5222です。
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]を参照）、ショートメッセージサービス（SMS）、および、そのようなAIM、ICQ、MSN Messengerなどのレガシーインスタントメッセージングサービスです・ヤフーインスタントメッセンジャー。ゲートウェイとサーバー間、およびゲートウェイと外部のメッセージングシステムとの間の通信は、この文書で定義されていません。
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ストリーム上で発生する必要があります。 IANAに登録され、サーバ間の接続のための推奨ポートは5269で、（ポート番号（セクション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の識別子または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で定義されている; STRINGPREPこのメモの付録Aに記載されるようにNodeprepプロファイルによって定義されているノード・ルールに準拠許容文字列を、許容可能な文字列をそのリソース・ルールに準拠してこのメモの付録Bに記載されているように[STRINGPREP]のResourceprepプロファイルによって定義され、そして[IDNA]で説明されるようにサブドメインルールが国際化ドメインラベルの概念を参照します）。
jid = [ node "@" ] domain [ "/" resource ] domain = fqdn / address-literal fqdn = (sub-domain 1*("." sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address
JID = [ノード "@"]ドメイン[ "/" リソース]ドメイン= FQDN /アドレスリテラルFQDN =（サブドメイン1 *（ "" サブドメイン））サブドメイン=（国際化ドメインラベル）ADDRESS-リテラル= 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は、上記の構造に基づいています。この構造の最も一般的な用途は、<ユーザ@ホスト/リソース>の形でインスタント・メッセージング・ユーザ、ユーザが接続するサーバ、およびユーザの接続リソース（例えば、特定のクライアント）を識別することです。しかし、クライアント以外のノードタイプが可能です。 <ルーム@サービス>（ここで、「部屋」は、チャットルームの名前で、「サービス」は、マルチユーザーチャットサービスのホスト名であるとして、たとえば、マルチユーザーチャットサービスが提供する特定のチャットルームに対処することができ）と、そのような部屋の特定の乗員は、<ルーム@サービス/ニック>（「ニック」は、乗員の部屋のニックネームです）として取り組むことができました。他の多くのJIDの種類（例えば、<ドメイン/リソース>サーバーサイドスクリプトまたはサービスであってもよい）が可能です。
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（ノード識別子、ドメイン識別子、およびリソース識別子）の各許容部分は、3071バイト（「@」と「/」セパレータを含む）の最大合計サイズをもたらす、長さ以上1023バイトであるはずがありません。
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]を参照）完全修飾ドメイン名である必要があります。文字列準備[STRINGPREP]のNAMEPREP [NAMEPREP]プロファイルは失敗することなく適用可能な、[IDNA]で定義されるようにドメイン識別子は、「国際化ドメイン名」でなければなりません。 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のインスタントメッセージングとプレゼンスアプリケーション内で、このアドレスは「裸のJID」と呼ばれ、フォーム<ノード@ドメイン>です。
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.
リソース識別子は、オプションの第三識別子ドメイン識別子の後に置き、「/」文字で後者から分離されます。リソース識別子は、<ノード@ドメイン>または単なる<ドメイン>アドレスのいずれかを変更することがあります。これは通常、特定のセッション、接続（例えば、装置又は場所）、またはオブジェクトを表す（例えば、マルチユーザチャットルームの参加者）ノード識別子に関連付けられたエンティティに属します。リソース識別子は、サーバや他のクライアントの両方に不透明で、それが結合するリソース（セクション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]のResourceprepプロファイルは失敗することなく適用することができるようにフォーマットする必要があります。 2つのリソース識別子を比較する前に、サーバーMUST最初の各識別子にResourceprepプロファイルを適用（クライアントは必要があります）。
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）の後に、ストリームに対する受信エンティティは、開始エンティティの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）仕様で定義されているサーバー間の通信のために、開始エンティティのJIDは、認証アイデンティティ由来認可ID、あるべきである[SASL]、一切認可IDは、SASLネゴシエーション中に指定されていない場合（セクション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]で定義されているいかなる認可IDはSASLネゴシエーション中に指定されていない場合は、クライアントからサーバーへの通信については、「裸のJID」（<ノード@ドメイン>）は、認証アイデンティティ由来認可ID、あるべきである（セクション6）。 「完全JID」（<ノード@ドメイン/リソース>）のリソース識別子部分は、リソース間に、クライアントとサーバの結合（第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:
XMLストリームおよびXMLスタンザ：二つの基本的な概念は存在を意識したエンティティ間の構造化された情報の比較的小さなペイロードの急速な、非同期の交換を可能にします。次のようにこれらの用語は定義されています。
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").
XMLストリームの定義：XMLストリームは、ネットワーク上の任意の2つのエンティティ間のXML要素を交換するためのコンテナです。 XMLストリームの端部が閉鎖XML </ストリーム>タグによって一義的に表わされている間、XMLストリームの開始は、（適切な属性とネームスペース宣言で）開口XML <ストリーム>タグによって一義的示されます。ストリームの人生、それはTLS（第5節）の使用やSASLの使用を交渉するために、ストリーム上でストリームを交渉するために使用される要素（例えば、いずれかのXMLエレメントの数は無制限を送信することができます開始したエンティティ（第6節の間に））またはXMLスタンザ（本明細書で定義されるように、<メッセージ/>、<存在/>、または<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スタンザの端部は、深さ= 1（に対応する終了タグによって明確に示され例えば、</プレゼンス>）。 XMLスタンザは、必要な情報を伝えるために、必要に応じて（付随する属性、要素、およびXML文字データで）子要素を含んでいてもよいです。 XMLスタンザ（セクション9）で説明したように、本明細書に定義された唯一のXMLスタンザは、<メッセージ/>、<存在/>、およびストリームのデフォルトの名前空間で修飾<IQ />要素です。トランスポート層セキュリティ（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バージョンとサポートされている文字コードを指定するテキスト宣言が先行サーバへの開口部<ストリーム>タグを送信することによって、XMLストリームを開始しなければならない（テキスト宣言（セクションの包含を参照11.4）;また、文字エンコーディング（11.5節を参照））。ローカルポリシーとサービスプロビジョニングを条件として、サーバが再度必要に応じてテキスト宣言が先行し、クライアントに戻す第二XMLストリームで応答すべきです。クライアントは、SASLネゴシエーション（第6節）を完了すると、クライアントはネットワーク上の任意の受信者にストリーム上のXMLスタンザの無制限数を送信することができます。クライアントがストリームを閉じたい場合は、単にサーバにタグ閉鎖</ストリーム>を送信する（あるいは、ストリームがサーバによって閉じることができる）、クライアントとサーバの両方は、基礎となる接続を終了すべきた後（通常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.
クライアントからサーバーへの1と、サーバからクライアントへ1を：ドキュメント中心の方法でXMLの思考に慣れている方は、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]コネクション（例えば、2つのエンティティは、[HTTP]上のポーリングのような他の機構を介して相互に接続することができる）にXMLストリームのいかなる必要な結合はないが、本明細書は、TCPのXMPPの結合を定義します。クライアントからサーバへの通信のコンテキストでは、サーバーは、クライアントがクライアントからサーバに、サーバからクライアントに送信されるXMLスタンザのための単一のTCP接続を共有することを許容しなければなりません。サーバー間通信の文脈では、サーバは、合計で、ピア及びサーバへのピアからスタンザのための（ピアによって開始された）別の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（セクション5）とSASLの使用で定義したSASL（第6節）の使用の下で定義されるように、TLSを使用しなければならない使用されてください。 「最初のストリーム」（受信エンティティに開始エンティティからすなわち、ストリーム）と両方向のセキュリティがかもしれないが、「応答ストリーム」（すなわち、開始エンティティに受信エンティティからのストリーム）は、別途確保しなければなりません相互認証を提供するメカニズムを介して確立すること。エンティティは、ストリームが認証される前にストリーム上で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.
○ - 「」の属性は、受信エンティティに開始エンティティからXMLストリームヘッダで使用する必要があり、受信エンティティによってサービスホスト名に設定しなければなりません。受信エンティティは、開始エンティティに返信これにより、XMLストリームヘッダーに設定「から」属性が存在すべきではありません。 「から」属性が含まれている場合しかし、それは静かに開始するエンティティによって無視されるべきです。
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から - 「から」属性は、開始エンティティに受信エンティティからXMLストリームヘッダで使用する必要があり、そして開始エンティティへのアクセスを許可された受信エンティティによってサービスホスト名に設定しなければなりません。受信エンティティに開始エンティティから送信されたXMLストリームヘッダの「から」属性が存在すべきではありません。 「から」属性が含まれている場合しかし、それは静かに受信エンティティによって無視されるべきです。
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の - 「のxml：langの」属性は（[XML]のセクション2.12で定義されている）すべての人間が読み取り可能なXML文字のデフォルト言語を指定するには、最初のストリームのヘッダに開始する事業体に含まれるべきですデータには、そのストリーム上で送信します。属性が含まれている場合は、受信エンティティは、初期ストリームと応答ストリームの両方のデフォルトとしてその価値を忘れてはなりません。属性が含まれていない場合、受信エンティティは、応答ストリームのヘッダに通信しなければならない両方のストリームのための設定可能なデフォルト値を使用すべきです。開始エンティティは「XML：LANG」が含まれていない場合、最初のストリームを介して送信されるすべてのスタンザの場合は、属性を、受信エンティティは、デフォルト値を適用する必要があります。開始エンティティは「XML：LANG」含まれている場合、属性を、受信エンティティは、それを変更したり、削除してはなりません（また、XMLを参照してください。LANG（セクション9.1.5を））。 「XML：langの」の値属性は、（[XML]のセクション2.3で定義されるように）NMTOKENなければならず、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バージョン - 本明細書で定義される（ストリーム機能を含む）ストリームに関連するプロトコルの少なくとも「1.0」信号サポートの値に設定し、バージョン属性の存在。この属性の生成と取り扱いに関する詳細なルールは以下のように定義されます。
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バージョンの番号付けスキームは、「<主要な>。<マイナー>」です。メジャー番号とマイナー番号は、別々の整数として扱わなければならないと、それぞれ番号が一桁以上高い増分することができます。このように、「XMPP 2.4は、」今度は「XMPP 12.3」よりも低くなる「XMPP 2.13」よりも低いバージョン、だろう。先頭のゼロは（例えば、「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>".
前記受信エンティティは、開始エンティティにより供給された値以下である方受信エンティティによってサポートされる最も高いバージョン番号のいずれかに応答ストリームヘッダに「バージョン」属性の値を設定しなければなりません。受信エンティティは、「<主要な>。<マイナー>」のメジャーバージョン番号とマイナーバージョン番号ではなく、文字列一致の数値比較を実行しなければなりません。
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つのメジャーバージョン低い場合、上述のように、開始エンティティが生成するべきです<サポートされていないバージョン/>ストリームエラーと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名前空間仕様で定義される通りである[XML-NAMES]）。ストリームの名前空間とデフォルトの名前空間に関する詳細な情報については、名前空間名と接頭辞（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」の値に設定「バージョン」属性が含まれている場合、受信エンティティは、開始エンティティに（ストリームの名前空間接頭辞で始まる）<特長/>子要素を送らなければなりません（それ以外の場合は宣伝する必要がありますまたは機能）任意のストリームレベルの交渉することができる機能を発表するためです。現在、これは、TLS（セクション5）の使用を宣伝するためにのみ使用され、SASL（第6節）、およびリソースの使用は、本明細書で定義される（セクション7）に結合し、セッション確立のための[XMPP-IM]で定義されます。しかし、ストリーム機能の機能は、将来的に他の交渉の機能を宣伝するために使用することができます。エンティティが理解したり、一部の機能をサポートしていない場合、それは静かにそれらを無視すべきです。 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.
ルートストリーム要素は、ストリームの名前空間接頭辞が付けられ、<誤り/>子要素を含むかもしれません。それは、ストリームレベルのエラーが発生したことを認識する場合は、エラーの子は、対応するエンティティ（通常はサーバーではなくクライアント）によって送らなければなりません。
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すべてのストリームレベルのエラーが回復不能であることが想定されます。誤差ストリームのレベルで発生した場合、したがって、エラーを検出したエンティティは、閉鎖</ストリーム>タグを送信し、他のエンティティへのストリームのエラーを送信し、そして下にある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、受信エンティティは、依然として、閉鎖</ストリーム>タグを送信し、ストリーム要素の子として<誤り/>要素を含む<ストリーム>タグを開口を送らなければなりません基礎となるTCP接続を終了します。開始エンティティは属性「から」で未知のホストを提供していない（あるいは全くの属性「に」はを提供します）この場合、サーバは、サーバの正式なホスト名を提供するべきである前に、送信されたストリームのヘッダの属性「から」終了。
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>
<ストリーム：エラー> <定義された条件のxmlns = 'URN：IETF：paramsは：XML：NS：XMPPストリーム' /> <テキストのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPストリーム' XML：langの= 'langcode'> OPTIONAL説明文</テキスト> [オプションのアプリケーション固有の条件要素</ストリーム：エラー>
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つに対応する子要素を含まなければなりません。名前空間この要素は、「：IETF：のparams：XML：：NS XMPPストリーム壷」によって修飾されなければなりません
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文字データを含む<テキスト/>子を含む可能性があります。この要素はで修飾されなければならない「壷：IETF：のparams：XML：NS：XMPPストリーム」名前空間と持っていなければならない「XMLを：LANG」属性は、XMLの文字データの自然言語を指定します
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 <悪いフォーマット/> - エンティティが処理できないXMLを送信しました。このエラーは、代わりに、このような<悪い名前空間接頭辞/>、<無効-XML />、<制限-XML />、<サポートされていないエンコード/>、そして<XMLなど、より具体的なXML関連のエラー、を用いてもよいですより具体的なエラーが好ましいが、/> -not-整形。
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 <悪い名前空間接頭辞/> - エンティティはサポートされていない名前空間接頭辞を送信した、または（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 <紛争/> - 新しいストリームが開始されたため、サーバーは、このエンティティのアクティブなストリームを閉じている既存のストリームと競合こと。
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 <接続タイムアウト/> - エンティティ（ローカルサービスポリシーに応じて設定可能）ある期間にわたってストリームトラフィックを生成しませんでした。
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 <ホストなくなっ/> - ストリームヘッダに開始する事業体が提供する「と」属性の値は、もはやサーバーでホストされているホスト名に対応しています。
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 <ホスト不明/> - サーバーによってホストされているホスト名に対応していないストリームのヘッダに開始エンティティによって提供「」の属性の値。
o <improper-addressing/> -- a stanza sent between two servers lacks a 'to' or 'from' attribute (or the attribute has no value).
O <不適切なアドレッシング/> - 2つのサーバー間で送信されるスタンザが「と」または「から」属性を持たない（または属性に値がありません）。
o <internal-server-error/> -- the server has experienced a misconfiguration or an otherwise-undefined internal error that prevents it from servicing the stream.
O <サーバ内蔵エラー/> - サーバーは、設定ミスやストリームをサービスするのを防止する、さもなければ、未定義の内部エラーが発生しました。
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 <無効-から/> - 「」からアドレスを認証し、リソースの結合を介してSASLまたはダイヤルバックを経由して、またはクライアントとサーバ間の許可JIDやサーバー間で交渉検証ドメインと一致しないで提供JIDまたはホスト名。
o <invalid-id/> -- the stream ID or dialback ID is invalid or does not match an ID previously provided.
O <無効-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 <無効な名前空間/> - ストリームの名前空間名は「http://etherx.jabber.org/streams」以外のものであるか、ダイヤルバックの名前空間名以外の何かである「ジャバー：サーバー：ダイヤルバック」（XML名前空間を参照してください名前とプレフィックス（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 </無効-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 <-許可していない/> - エンティティは、ストリームが認証されている前にデータを送信しようとした、またはそうでなければ交渉をストリーミングするために関連するアクションを実行するために許可されていません。受信エンティティは、ストリームエラーを送信する前に、問題のスタンザを処理してはいけません。
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 <ポリシー違反/> - エンティティは、いくつかのローカルサービスポリシーに違反しました。サーバーは、<テキスト/>要素またはアプリケーション固有の条件要素にポリシーを指定することもできます。
o <remote-connection-failed/> -- the server is unable to properly connect to a remote entity that is required for authentication or authorization.
O <リモート接続に失敗した/> - サーバーが正しく認証や承認のために必要とされるリモートエンティティに接続することができません。
o <resource-constraint/> -- the server lacks the system resources necessary to service the stream.
O <リソース制約/> - サーバーは、ストリームにサービスを提供するために必要なシステムリソースが不足しています。
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 <制限-XML /> - エンティティは、そのようなコメント、処理命令、DTD、エンティティ参照、またはエスケープ文字（制限事項（11.1節）を参照）などの制限されたXML機能を送信しようとしました。
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 <参照-他のホスト/> - サーバーが開始したエンティティにサービスを提供することはありませんが、別のホストへのトラフィックをリダイレクトされます。サーバーは、<参照-他のホストを/>要素のXML文字データとして（有効なドメイン識別子でなければなりません）、代替ホスト名またはIPアドレスを指定する必要があります。
o <system-shutdown/> -- the server is being shut down and all active streams are being closed.
O <システムシャットダウン/> - サーバがシャットダウンされ、すべてのアクティブなストリームが閉じられています。
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 <不定状態/> - エラー状態は、このリスト内の他の条件によって定義されたものではありません。このエラー状態は、アプリケーション固有の条件と組み合わせて使用する必要があり。
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 <サポートされていないエンコード/> - 開始エンティティはサーバでサポートされていない符号化でストリームを符号化された（文字エンコードを参照して（セクション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 <サポートされていない-スタンザ型/> - 開始エンティティは、サーバーでサポートされていないストリームの最初のレベルの子を送りました。
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 <サポートされていないバージョン/> - ストリームヘッダで開始エンティティによって提供される「バージョン」属性の値は、サーバでサポートされていないXMPPのバージョンを指定します。サーバーは、それが<テキスト/>要素でサポートするバージョン（複数可）を指定するかもしれません。
o <xml-not-well-formed/> -- the initiating entity has sent XML that is not well-formed as defined by [XML].
O </ XML-ウェルに形成されていない> - 開始エンティティは[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>
<ストリーム：エラー> <XML-不整形のxmlns = 'URN：IETF：paramsは：XML：NS：XMPPストリーム' /> <テキストXML：IETF：paramsはLANG =のxmlns = 'URN 'EN'： XML：NS：XMPPストリーム>いくつかの特別なアプリケーションの診断情報！ </テキスト> <エスケープ - あなたのデータのxmlns = 'アプリケーション-NS' /> </ストリーム：エラー> </ストリーム：ストリーム>
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.
このセクションでは、「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>
C：<？xmlのバージョン= '1.0'？> <ストリーム：のxmlns：ストリーム=：= 'example.com' のxmlns = 'クライアントジャバー' への流れ 'のhttp：//etherx.jabber.org/streams' バージョン=」 1.0 '> Sます。<？xml version =' 1.0 '> <ストリーム：？=からのストリーム'：クライアントexample.com 'のid = 'someid' のxmlns = 'おしゃべり' のxmlns：ストリーム=' のhttp：//etherx.jabber .ORG /ストリームバージョン= '1.0'> ...暗号化、認証、およびリソース結合... C：<メッセージfrom='juliet@example.com 'to='romeo@example.net' のxml：LANG = 'EN'> C：<BODY>アートなたないロミオ、そしてモンタギュー</ BODY> C </メッセージ> S <メッセージfrom='romeo@example.net 'to='juliet@example.com' XML：LANG = 'EN'> S：<身体>どちらも、公正聖人、どちらかあなたが嫌いならば、</ body>のS：</メッセージ> C：</ストリーム：ストリーム> S：</ストリーム：ストリーム>
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>
C：<？xmlのバージョン= '1.0'？> <ストリーム：のxmlns：ストリーム=：= 'example.com' のxmlns = 'クライアントジャバー' への流れ 'のhttp：//etherx.jabber.org/streams' バージョン=」 1.0 '> Sます。<？xml version =' 1.0 '> <ストリーム：？=からのストリーム'：クライアントexample.com 'のid = 'someid' のxmlns = 'おしゃべり' のxmlns：ストリーム=' のhttp：//etherx.jabber .ORG /ストリームバージョン= '1.0'> ...暗号化、認証、およびリソース結合... C：<メッセージのXML：LANG = 'EN'> <身体>悪いXML、ノー終了bodyタグ！ </メッセージ> S <ストリーム：エラー> <XML-不整形のxmlns = 'URN：IETF：paramsは：XML：NS：XMPPストリーム' /> </ストリーム：エラー> S </ストリーム：ストリーム>
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]について同様の拡張機能をモデルにして、「STARTTLS」の拡張子と一緒に、トランスポート層セキュリティ（TLS）プロトコル[TLS]を利用して、ACAP [ACAP]プロトコルRFC 2595 [USINGTLS]に記載されているように。 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ネゴシエーション（第6節）の完了を試行する前にストリームを保護するためにTLSを使用する必要があり、サーバーは、サーバー間の通信を確保するために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.
この仕様に準拠する受信エンティティは、（バージョンフラグを含む）応答でストリームヘッダを送信した後、少なくとも「1.0」の値に設定「バージョン」属性を含む初期ストリームヘッダを受信3.それがなければなりませんそれがサポートする他のストリーム機能のリストと一緒に（名前空間 'XMPP-TLS：IETF：のparams：XML：：NS壷' によって修飾）<STARTTLS />要素が含まれます。
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.
開始実体がTLSを使用することを選択した場合4、TLSネゴシエーションがSASL交渉に進む前に完了しなければなりません。交渉のこの順序は、SASLネゴシエーション中に送信されたセーフガードの認証情報を助けるために、だけでなく、それが可能前TLSネゴシエーション中に提供される証明書にSASL EXTERNALメカニズムの使用をベースに行う必要があります。
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.
TLSネゴシエーション、エンティティ間5.（以下TLS例に示す任意の空白文字がために含まれる要素間のセパレータとしてルートストリーム要素内（[3] [XML]の内容を生産と一致）任意の空白文字を送ってはいけません読みやすさのためのみ）。この禁止は、適切なセキュリティレイヤバイト精度を確保するのに役立ちます。
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.
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オン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.5.5.7.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接続を開き、少なくとも「1.0」の値に設定「バージョン」属性を含む、受信エンティティに開口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".
前記受信エンティティは、少なくとも「1.0」の値に設定「バージョン」属性を含む、TCP接続を開き、開始エンティティにXMLストリームヘッダを送信することによって応答します。
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).
TLSは、受信エンティティとの相互作用のために必要とされる場合3.受信エンティティはサポートされている他のストリームの特徴のリストでそれを含めることによって開始エンティティにSTARTTLS拡張を提供し（、それは<必須/>要素などを含めることによって、その旨を通知すべきです<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.
それはTLSを開始することを希望する受信エンティティを指示する4.開始エンティティは、STARTTLSコマンド（名前空間「XMPP-TLS：IETF：のparams：XML：：NS壷」によって修飾すなわち、<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.
名前空間前記受信エンティティは、<進行/>要素又は '：IETF：paramsは：XML：NS XMPP-TLS URN' によって修飾<故障/>要素のいずれかで応答しなければなりません。障害ケースが発生した場合、受信エンティティは、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ストリームヘッダを送信することによって、新たなストリームを開始しなければならない（受信エンティティから、第一開閉</ストリーム>タグを送信する必要はなく、エンティティを開始MUST成功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、受信エンティティは、利用可能な機能（しかしSTARTTLS機能を含まない）と一緒に開始エンティティに新しいXMLストリームヘッダを送信することによって応答しなければなりません。
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'>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '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'>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンからのid = 'c2s_123'= '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>
<ストリーム：機能> <STARTTLS用のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-TLS'> <必須/> </ STARTTLS> <機構のxmlns = 'URN：IETF：paramsは：XML：NS：xmpp- SASL '> <メカニズム> DIGEST-MD5 </機構> <メカニズム> PLAIN </機構> </メカニズム> </ストリーム：機能>
Step 4: Client sends the STARTTLS command to server:
ステップ4：クライアントは、サーバーへのSTARTTLSコマンドを送信します。
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<STARTTLS用のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-TLS' />
Step 5: Server informs client that it is allowed to proceed:
ステップ5：サーバーは、進行させているクライアントに通知：
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<の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>
<障害のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-TLS' /> </ストリーム：ストリーム>
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'>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '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>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' のid = 'c2s_234' バージョンから= '1.0'> <ストリーム：機能> <機構のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <メカニズム> DIGEST-MD5 </機構> <メカニズム> PLAIN </機構> <メカニズム> EXTERNAL </機構> </機構> </ストリーム：特長>
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：サーバ1は、サーバー2にストリームを開始します。
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '1.0'>
Step 2: Server2 responds by sending a stream tag to Server1:
ステップ2：サーバー2は、サーバ1へのストリームタグを送信することで応答します。
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_123' version='1.0'>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' のid = 's2s_123' バージョンから= '1.0'>
Step 3: Server2 sends the STARTTLS extension to Server1 along with authentication mechanisms and any other stream features:
ステップ3：サーバー2は、認証メカニズムと他のストリーム機能と共にサーバ1に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>KERBEROS_V4</mechanism> </mechanisms> </stream:features>
<ストリーム：機能> <STARTTLS用のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-TLS'> <必須/> </ STARTTLS> <機構のxmlns = 'URN：IETF：paramsは：XML：NS：xmpp- SASL '> <メカニズム> DIGEST-MD5 </機構> <メカニズム> KERBEROS_V4 </機構> </メカニズム> </ストリーム：機能>
Step 4: Server1 sends the STARTTLS command to Server2:
ステップ4：サーバ1は、サーバー2にSTARTTLSコマンドを送信します。
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<STARTTLS用のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-TLS' />
Step 5: Server2 informs Server1 that it is allowed to proceed:
ステップ5：サーバー2は、進行させることのServer1に知らせます：
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<のxmlns =進む 'URNを：IETF：paramsは：XML：NS：XMPP-TLS' />
Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed and closes stream:
ステップ5（ALT）：Server2がTLSネゴシエーションが失敗したことのServer1を通知し、ストリームを閉じます。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> </stream:stream>
<障害のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-TLS' /> </ストリーム：ストリーム>
Step 6: Server1 and Server2 attempt to complete TLS negotiation via TCP.
ステップ6：TCP経由でTLSネゴシエーションを完了するためにServer1とServer2の試み。
Step 7: If TLS negotiation is successful, Server1 initiates a new stream to Server2:
ステップ7：TLSネゴシエーションが成功した場合、サーバ1は、サーバー2に新しいストリームを開始します。
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '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：サーバー2は任意の利用可能なストリーム機能と共にサーバー1へのストリーム・ヘッダを送信することによって応答します。
<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>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' のid = 's2s_234' バージョンから= '1.0'> <ストリーム：機能> <機構のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <メカニズム> DIGEST-MD5 </機構> <メカニズム> KERBEROS_V4 </機構> <メカニズム> EXTERNAL </機構> </機構> </ストリーム：特長>
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").
前記受信エンティティは、SASLネゴシエーションが可能である場合、それは「URN XMPP-SASL：IETF：paramsは：XML：NS」によって修飾<機構/>要素内の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ネゴシエーション中に、エンティティは、（以下SASL例に示す任意の空白文字がために含まれる要素間のセパレータとしてルートストリーム要素内（[3] [XML]の内容を生産と一致）任意の空白文字を送ってはいけません読みやすさのためのみ）。この禁止は、適切なセキュリティレイヤバイト精度を確保するのに役立ちます。
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文字データは、符号化は、RFC 3548のセクション3 [BASE64]における定義に付着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機構（例えば、これは、DIGEST-MD5やCRAM-MD5メカニズムではなく、EXTERNALと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メカニズムは認証アイデンティティの伝送をサポートしている場合、開始実体はSASLネゴシエーション中に、承認のアイデンティティを提供しなければなりません。開始エンティティが別のエンティティを代表して行動したくない場合は、認証アイデンティティを提供してはなりません。 [SASL]で指定されているように[SASL]で説明したように認証アイデンティティは、認証アイデンティティーに由来し、デフォルトの認可IDと異なっている場合を除き、開始エンティティは、認証アイデンティティを提供してはなりません。提供された場合、承認のアイデンティティの値は、サーバ用とクライアント用のフォーム<ノード@ドメイン>（即ち、ノード識別子及びドメイン識別子）から（すなわち、ドメイン識別子のみ）形式<ドメイン>でなければなりません。
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.
セキュリティ層のネゴシエーションを伴う成功SASLネゴシエーション時8は、受信エンティティは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.
セキュリティ層のネゴシエーションを伴う成功SASLネゴシエーションの際9、開始エンティティは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
2.応答のXMLストリームヘッダを送信した後、受信エンティティは、利用可能なSASL認証メカニズムのリストをアドバタイズ。今度はの子である名前空間、これらの各々は、<機構/>要素は、「：IETF：paramsは：XML：NS XMPP-SASL URN」によって修飾<機構/>コンテナ要素内の子として含まれます<特長/>ストリーム名前空間の要素。 TLS（第5節）の使用は、特定の前に確立する必要がある場合
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.
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.
名前空間受信エンティティへと「機構」属性の適切な値を含む前記開始エンティティは、「：IETF：paramsは：XML：NS XMPP-SASL URN」によって修飾<AUTH />要素を送信することによって、機構を選択します。この要素は、メカニズムがサポートしているか、それを必要とする場合（SASLの用語、「初期応答」で）XML文字データを含む可能性があります。開始エンティティが長さゼロの初期応答を送信する必要がある場合、それは応答が存在することを示しているが、データを含まない単一の等号（「=」）として応答を送信しなければなりません。
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」によって修飾要素の開始エンティティへの名前空間。この要素は、（開始エンティティによって選ばれたSASL機構の定義に従って計算しなければならない）XML文字データを含むかもしれません。
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.開始エンティティは、「：IETF：のparams：XML：NS：URN XMPP-SASL」によって修飾<応答/>要素送ることによって、課題に応答受信エンティティへの名前空間を。この要素は、（開始エンティティによって選ばれたSASL機構の定義に従って計算しなければならない）XML文字データを含むかもしれません。
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.開始エンティティは、「XMPP-SASL：IETF：のparams：XML：：NS壷」によって修飾<アボート/>要素を送信することにより、ハンドシェイクを中止します。 <アボート/>要素を受信すると、受信エンティティは、TCP接続を終了しなければならない後にリトライ（少なくとも2）の構成が、合理的な数を、可能にするべきです。これは、再接続することを余儀なくされることなく、誤っ-提供された資格情報（例えば、入力ミスパスワード）を許容するために、開始エンティティ（例えば、エンドユーザクライアント）を可能にします。
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.
（故障の特定の原因が通信されるべきである（SHOULD）開始エンティティに名前空間「XMPP-SASL：IETF：のparams：XML：：NS壷」2.受信エンティティは、によって資格<失敗/>要素を送信することにより、ハンドシェイクの失敗を報告します<故障/>要素の適切な子要素でSASLエラー（セクション6.4））で定義しました。失敗事例が発生した場合、受信エンティティは、TCP接続を終了しなければならない後に、再試行の設定が、妥当な数（少なくとも2つ）を可能にすべきです。これは、再接続することを余儀なくされることなく、誤っ-提供された資格情報（例えば、入力ミスパスワード）を許容するために、開始エンティティ（例えば、エンドユーザクライアント）を可能にします。
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.受信エンティティは、「：IETF：のparams：XML：NS：URN XMPP-SASL」によって修飾<成功/>要素送信することにより、ハンドシェイクの成功を報告開始エンティティに名前空間を。この要素は、選択されたSASLメカニズムによって要求された場合（SASLの用語では、「成功と追加データ」）XML文字データを含むかもしれません。 <成功/>要素を受信すると、開始エンティティは、受信エンティティから、（最初に閉じる</ストリーム>タグを送信する必要がなく、受信エンティティに開口XMLストリームヘッダを送信すると開始することによって、新たなストリームを開始しなければなりませんエンティティは、元のストリームは<成功/>要素）を送信または受信したときに閉じられるように考慮しなければなりません。開始エンティティから新たなストリームヘッダを受信すると、受信エンティティは、任意の利用可能な機能と一緒に、開始エンティティに新しいXMLストリームヘッダを送信することによって応答する（しかしSTARTTLSとSASL機能を含まない）または空の<機能/>しなければなりません要素（追加の機能が利用できないことを意味します）。本明細書で定義されていない任意のこのような付加的な特徴は、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.
交換シーケンス：課題と応答は、エンティティと受信エンティティにエンティティを開始するから、<応答/>要素を開始するエンティティを受信してから<チャレンジ/>要素の交換により実施されています。受信エンティティは、<成功/>要素を送信することによって、<失敗/>要素と成功を送信することにより、障害を報告します。開始エンティティは、<アボート/>要素を送信することにより、交換を中止します。成功した交渉の際に、双方は、元の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.
セキュリティ層の交渉：セキュリティ層は、直ちに閉鎖を送った後に有効になります「>」の文字<成功/>受信エンティティのための要素、そしてすぐに閉鎖を受けた後に「>」開始するための<成功/>要素の文字エンティティ。層の順序は、最初の[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がサーバーのクライアントのデフォルト以外の<ノード@ドメイン>または送信<ドメイン>を示すために、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 <アボート/> - 受信エンティティは、開始エンティティによって送信された<アボート/>要素を認めます。 <アボート/>要素に応答して送信。
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において定義に準拠していないため）処理することができませんでした。 <応答/>要素または初期応答データと<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 <無効authzidは/> - 開始エンティティによって提供authzidはが無効である、のいずれかでそれが正しくフォーマットされているため、または開始エンティティがそのIDを承認する権限を持っていないからです。 <応答/>要素または初期応答データと<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 <メカニズム-あまりにも弱/> - 開始するエンティティによって要求されたメカニズムは、その開始エンティティのサーバーポリシーで許可さよりも弱いです。 <応答/>要素または初期応答データと<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 <-許可していない/> - 開始エンティティが有効な資格情報を（これは含むが、未知のユーザ名の場合に限定されるものではない）を提供していなかったため、認証に失敗しました。 <応答/>要素または初期応答データと<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-故障/> - 認証が原因で、受信エンティティ内の一時的なエラー状態のために失敗しました。 <AUTH />要素又は<応答/>要素への応答で送信されました。
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).
それらは網羅的ではなく、必ずしもトリガされないであろう。以下に示す代替的なステップは、故障の場合のためのプロトコルを説明するために提供されている次の例は、（注意通常成功TLSネゴシエーション後に、SASLを使用してサーバでの認証クライアントのデータフローを示します例では送信されたデータ）によります。
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'>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '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'>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンからのid = 'c2s_234'= '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>
<ストリーム：機能> <機構のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <メカニズム> DIGEST-MD5 </機構> <メカニズム> PLAIN </機構> </メカニズム> </ストリーム：特長>
Step 4: Client selects an authentication mechanism:
ステップ4：クライアントが認証メカニズムを選択します。
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
<AUTHのxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL' メカニズム= '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>
<チャレンジのxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg == </挑戦>
The decoded challenge is:
デコードされた課題は、次のとおりです。
realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess
分野= "somerealm"、ナンス= "OA6MG9tEQGm2hh" \ QOP = "AUTH" のcharset = UTF-8アルゴリズム= MD5-のSES
Step 5 (alt): Server returns error to client:
ステップ5（ALT）：サーバーはクライアントにエラーを返します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <incorrect-encoding/> </failure> </stream:stream>
<障害のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <誤った符号化/> </失敗> </ストリーム：ストリーム>
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>
<応答のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo YXJzZXQ9dXRmLTgK </レスポンス>
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
ユーザ名= "somenode"、レルムは= "somerealm"、\ナンス= "OA6MG9tEQGm2hh"、cnonce = "OA6MHXh6VqTrRk"、\ NC = 00000001、QOP = AUTH、ダイジェスト-URI = "XMPP / example.com"、\応答= d388dad90d4bbd760a152321f2143af7 、文字セット= 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>
<チャレンジのxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo = </挑戦>
The decoded challenge is:
デコードされた課題は、次のとおりです。
rspauth=ea40f60335c427b5527b84dbabcdfffd
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>
<障害のxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL'> <一時的-AUTH-失敗/> </失敗> </ストリーム：ストリーム>
Step 8: Client responds to the challenge:
ステップ8：クライアントは、チャレンジに応答します。
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<応答の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'/>
<成功のxmlns = '壷：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>
<障害のxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL'> <一時的-AUTH-失敗/> </失敗> </ストリーム：ストリーム>
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'>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '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>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンからのid = 'c2s_345'= '1.0'> <ストリーム：機能> <バインドのxmlns = '壷：IETF：のparams：XML：NS：XMPP-バインド' /> <セッションのxmlns = '壷：IETF：のparams：XML：NS：XMPPセッション' /> </ストリーム：特長>
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).
それらは網羅的ではなく、必ずしもトリガされないであろう。以下に示す代替的なステップは、故障の場合のためのプロトコルを説明するために提供されている次の例は、（注意通常成功TLSネゴシエーション後に、SASLを使用して別のサーバと認証サーバのデータフローを示します例では送信されたデータ）によります。
Step 1: Server1 initiates stream to Server2:
ステップ1：サーバ1は、サーバー2にストリームを開始します。
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '1.0'>
Step 2: Server2 responds with a stream tag sent to Server1:
ステップ2：サーバー2は、サーバ1に送信されたストリームタグで応答します。
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' のid = 's2s_234' バージョンから= '1.0'>
Step 3: Server2 informs Server1 of available authentication mechanisms:
ステップ3：サーバー2が使用可能な認証メカニズムのサーバ1に通知：
<stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>KERBEROS_V4</mechanism> </mechanisms> </stream:features>
<ストリーム：機能> <機構のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <メカニズム> DIGEST-MD5 </機構> <メカニズム> KERBEROS_V4 </機構> </メカニズム> </ストリーム：特長>
Step 4: Server1 selects an authentication mechanism:
ステップ4：サーバ1は、認証機構を選択します。
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
<AUTHのxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL' メカニズム= 'DIGEST-MD5' />
Step 5: Server2 sends a [BASE64] encoded challenge to Server1:
ステップ5：サーバー2は、サーバ1へ[BASE64]エンコードされたチャレンジを送信：
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz </challenge>
<チャレンジのxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz </挑戦>
The decoded challenge is:
デコードされた課題は、次のとおりです。
realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess
分野= "somerealm"、ナンス= "OA6MG9tEQGm2hh" \ QOP = "AUTH" のcharset = UTF-8アルゴリズム= MD5-のSES
Step 5 (alt): Server2 returns error to Server1:
ステップ5（ALT）：サーバー2は、サーバ1にエラーを返します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <incorrect-encoding/> </failure> </stream:stream>
<障害のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <誤った符号化/> </失敗> </ストリーム：ストリーム>
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>
<応答のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3 LGNoYXJzZXQ9dXRmLTgK </レスポンス>
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
ユーザ名= "example.org"、レルムは= "somerealm"、\ナンス= "OA6MG9tEQGm2hh"、cnonce = "OA6MHXh6VqTrRk"、\ NC = 00000001、QOP = AUTH、ダイジェスト-URI = "XMPP / example.org"、\応答= d388dad90d4bbd760a152321f2143af7、文字セット= 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>
<チャレンジのxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo = </挑戦>
The decoded challenge is:
デコードされた課題は、次のとおりです。
rspauth=ea40f60335c427b5527b84dbabcdfffd
rspauth = ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server2 returns error to Server1:
ステップ7（ALT）：サーバー2は、サーバ1にエラーを返します。
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <invalid-authzid/> </failure> </stream:stream>
<障害のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <無効authzidは/> </失敗> </ストリーム：ストリーム>
Step 8: Server1 responds to the challenge:
ステップ8：サーバ1は、チャレンジに応答します。
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<応答の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'/>
<のxmlns =アボート 'URNを：IETF：paramsは：XML：NS：XMPP-SASL' />
Step 9: Server2 informs Server1 of successful authentication:
手順9：サーバー2が成功した認証のサーバ1に通知：
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<成功のxmlns = '壷：IETF：のparams：XML：NS：XMPP-SASL' />
Step 9 (alt): Server2 informs Server1 of failed authentication:
ステップ9（ALT）：Server2が失敗した認証のサーバ1に通知します：
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <aborted/> </failure> </stream:stream>
<障害のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-SASL'> <中止/> </失敗> </ストリーム：ストリーム>
Step 10: Server1 initiates a new stream to Server2:
ステップ10：サーバ1は、サーバー2に新しいストリームを開始します。
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
<ストリーム：ストリームのxmlns = 'おしゃべり：サーバののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンへ= '1.0'>
Step 11: Server2 responds by sending a stream header to Server1 along with any additional features (or an empty features element):
ステップ11：サーバ2は、任意の付加的な特徴（又は空の機能要素）と共にサーバ1へのストリーム・ヘッダを送信することによって応答します。
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_345' version='1.0'> <stream:features/>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' のid = 's2s_345' バージョンから= '1.0'> <ストリーム：機能/>
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）に適合するためにどのサーバーによって生成されたか、クライアントアプリケーションによって提供されますか）。これは、そのストリームを超える使用のためのアドレスは<ノード@ドメイン/リソース>フォームの「完全な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交渉の後ストリームにリソースをバインドするために、クライアントを必要とする場合具体的には、「XMPP-バインド：IETF：のparams：XML：：NS壷」によって修飾空の<バインド/>要素を含まなければなりませんそれは（ではないの前に）成功した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>
<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンからのid = 'c2s_345'= '1.0'> <ストリーム：機能> <バインドのxmlns = '壷：IETF：のparams：XML：NS：XMPP-バインド' /> </ストリーム：特長>
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-バインド」の名前空間。
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:
クライアントはサーバが代わってリソース識別子を生成することを可能にすることを希望する場合は、空の<バインド/>要素が含まれているタイプの「セット」のIQスタンザを送信します。
Client asks server to bind a resource:
クライアントがリソースをバインドするためにサーバーを要求します：
<iq type='set' id='bind_1'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> </iq>
<IQタイプ= 'セット' ID = 'bind_1'> <バインドのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPバインド' /> </ 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>.
バインディングのリソースをサポートするサーバーは、クライアントに代わってリソース識別子を生成できなければなりません。サーバーによって生成されたリソース識別子は、その<ノード@ドメイン>一意である必要があります。
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:
クライアントがリソース識別子を指定したい場合は、<バインド/>要素の子である<リソース/>要素のXML文字データなどの所望のリソース識別子が含まれているタイプの「セット」の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>
<IQタイプ= 'セット' ID = 'bind_2'> <バインドのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPバインド'> <リソース> someresource </リソース> </バインド> </ 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:
サーバがクライアントのリソース識別子を生成したり、クライアントが提供するリソース識別子を受理したら、それは完全なを指定する<JID />子要素を含める必要があり、クライアントにタイプ「結果」の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>
<IQタイプ= '結果' のid = 'bind_2'> <バインドのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPバインド'> <JID> somenode@example.com/someresource </ JID> </バインド> </ 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.
サーバーは、クライアントが提供するリソース識別子を受け入れる必要がありますが、サーバーが生成するリソース識別子とそれを無効にすることができます。この場合、サーバは、クライアントに（例えば、<禁止/>）スタンザエラーを返すべきではなく、代わりに、上記のような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>
<IQタイプ= 'エラー' ID = 'bind_2'> <バインドのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPバインド'> <リソース> someresource </リソース> </バインド> <エラータイプ=」修正 '> <悪い要求のxmlns =' 壷：IETF：のparams：XML：NS：XMPP-スタンザ/> </エラー> </ 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>
<IQタイプ= 'エラー' ID = 'bind_2'> <バインドのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPバインド'> <リソース> someresource </リソース> </バインド> <エラータイプ=」キャンセル '> <-許可されていないのxmlns =' 壷：IETF：のparams：XML：NS：XMPP-スタンザ/> </エラー> </ 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>
<IQタイプ= 'エラー' ID = 'bind_2'> <バインドのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPバインド'> <リソース> someresource </リソース> </バインド> <エラータイプ=」キャンセル '> <紛争のxmlns =' 壷：IETF：のparams：XML：NS：XMPP-スタンザ/> </エラー> </ 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.
「：IETF：のparams：XML：NS：XMPP-バインド壷」名前空間、リソース結合ステップを完了する前に、クライアントがで修飾<バインド/>子供とIQスタンザ以外のXMLスタンザを送信しようとした場合サーバーは、スタンザを処理してはならないし、クライアントに<-許可されていない/>スタンザエラーを返すべきです。
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）の存在によって可能になります。ダイヤルバックは、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発信サーバ - の二つのドメイン間の接続を確立しようとしているサーバー。
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.受信サーバーは、権限のあるサーバーに同じ「キー」値を送信します。
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'>
<ストリーム：ストリームのxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams' のxmlns = 'おしゃべり：サーバののxmlns：DB = 'のjabber：サーバー：ダイヤルバック'>
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.
注：「から」と属性「から」ルートストリーム要素のオプションです。 xmlnsを含める：示された名前のDBの名前空間宣言は、元のサーバーは、ダイヤルバックをサポートし、受信側のサーバーに示します。名前空間名が正しくない場合は、受信サーバは、<無効な名前空間/>ストリームのエラー状態を生成し、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...'>
<ストリーム：ストリームのxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams' のxmlns = 'おしゃべり：サーバののxmlns：DB = 'のjabber：サーバー：ダイヤルバック' 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.
注：「から」と属性「から」ルートストリーム要素のオプションです。名前空間名が正しくない場合は、元のサーバーは、<無効な名前空間/>ストリームのエラー状態を生成し、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>
<DB：= '元のサーバー' から= '受信サーバー' になる> <：結果/ DB> 98AF014EDC0 ...
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
注意：受信サーバがセッション間で元のサーバーに関する情報を保持していないので、このキーは、受信サーバによって検査されていません。起点のサーバによって生成された鍵は、によって提供されるIDの値に部分的に基づくものでなければなりません
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.
元のサーバーと権限のあるサーバーで共有される秘密に前のステップでは、部分的に受信サーバ。もしアドレスが受信サーバが認識したホスト名と一致しません「に」の場合、受信サーバーは、<ホスト-不明/>ストリームのエラー状態を生成し終えなければなりませんXMLストリームの両方の値が、基礎となるTCP接続。 「から」アドレスの値が受信サーバがすでに確立された接続を持っていると、ドメインと一致した場合、それは新しい接続が正当であるかどうかが検証されるまで、その後、受信サーバは、既存の接続を維持しなければなりません。さらに、受信サーバーは、新しい接続のための<-許可されていません/>ストリームのエラー状態を生成し、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'>
<ストリーム：ストリームのxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams' のxmlns = 'おしゃべり：サーバののxmlns：DB = 'のjabber：サーバー：ダイヤルバック'>
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.
注：「から」と属性「から」ルートストリーム要素のオプションです。名前空間名が正しくない場合は、権限のあるサーバーは、<無効な名前空間/>ストリームのエラー状態を生成し、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...'>
<ストリーム：ストリームのxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams' のxmlns = 'おしゃべり：サーバののxmlns：DB = 'のjabber：サーバー：ダイヤルバック' 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.
注意：名前空間名が正しくない場合は、受信サーバーは、<無効な名前空間/>ストリームのエラー状態を生成し、XMLストリームとそれと権限のあるサーバー間の基本的なTCP接続の両方を終えなければなりません。ストリームエラーが受信サーバと権限のあるサーバー間で発生した場合、受信サーバは、<リモート接続に失敗した/>ストリームのエラー状態を生成し、XMLストリームと、それとの間に根本的な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>
<DB：= '元のサーバー' ID =へ= '受信サーバー' から検証する '457F9224A0 ...'> 98AF014EDC0 ... </ DB：検証>
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で受信サーバに送信されたことを鍵となるだけでなく、共有権限のあるサーバーのネットワーク内の秘密情報は、キーが検証されます。任意の検証可能な方法は、鍵を生成するために使用され得ます。アドレスは、権限のあるサーバーが認識したホスト名と一致していない「から」、そして権威サーバは、<ホスト-不明/>ストリームのエラー状態を生成し、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...'/>
<DB：= '受信サーバ' タイプ= '有効' のid = '457F9224A0 ...' へ= '元のサーバー' から検証/>
or
または
<db:verify from='Originating Server' to='Receiving Server' type='invalid' id='457F9224A0...'/>
<DB：= '受信サーバ' タイプ= '無効' の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接続の両方を終えなければなりません。もしアドレスが受信サーバが認識したホスト名と一致しません「に」の場合、受信サーバーは、<ホスト-不明/>ストリームのエラー状態を生成し終えなければなりませんXMLストリームの両方の値が、基礎となるTCP接続。 「From」アドレスの値は、元のサーバーのホスト名の検証サブドメインや元のサーバーでホストされている別の検証ドメインとして、その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'/>
<DB：=「元のサーバー」タイプに=「受信サーバ」に起因=「有効」/>
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.
注：この時点で、接続は=「有効」タイプを経由して検証されたか、または無効として報告しました。接続が無効な場合は、受信サーバは、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.
以上の結果は、「初期ストリーム」（すなわち、発信からのストリーム上のXMLスタンザ、元のサーバーが送信することができ、および受信サーバが受け入れることができるように、受信サーバーは、元のサーバーの身元を確認したことがあります受信サーバへのサーバ）。 「応答ストリーム」を用いてエンティティの身元を確認するために（すなわち、元のサーバーに受信側サーバーからのストリーム）は、ダイヤルバックは、同様に反対方向に完了しなければなりません。
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.
成功したダイヤルバックネゴシエーションの後、受信サーバは受け入れるべきで、その後の<デシベル：結果/>パケット（例えば、受信サーバがサービスを提供するサブドメインまたは他のホスト名に送信された検証要求）既存の検証接続を介して元のサーバーから。これは一方向の元に検証接続の「ピギーバック」を可能にします。
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スタンザは、「から」属性と「に」属性を含む他のサーバから受信したことを確かめなければなりませんスタンザはこの制限を満たしていない場合は、スタンザを受けたサーバは、<不適切なアドレッシング/>ストリームのエラー状態を生成し、XMLストリームおよび基礎となるTCP接続の両方を終えなければなりません。また、サーバは他のサーバから受信したスタンザの「から」属性は、ストリームのために検証されたドメインが含まれていることを確認しなければなりません。スタンザはこの制限を満たしていない場合は、スタンザを受けたサーバは、<無効-から/>ストリームのエラー状態を生成し、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章）、SASLネゴシエーション（第6節）、およびリソースの結合（セクション7）必要に応じて後、XMLスタンザは、ストリームを介して送信することができます。 「：クライアントおしゃべり」と 'おしゃべり：サーバの名前空間：XMLスタンザ3種類のために定義されている<メッセージ/>、<存在/>、および<IQ />。また、スタンザのこれらの種類のための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.
「から」属性がスタンザのために意図された受取人の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.
「おしゃべり：クライアント」は、そのサーバによって処理のためにクライアントからサーバに送られたスタンザが（例えば、存在が他のエンティティへの放送のためにサーバーに送信された）が、名前空間、スタンザはないはず、「から」属性を持っていなければなりません「から」属性を持っています。
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.
「ジャバー：サーバー」は名前空間、スタンザは「から」属性を持っていなければなりません。サーバーは、この制限を満たしていないスタンザを受信した場合、それは<不適切なアドレッシング/>ストリームのエラー状態を生成し、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.
属性「から」の値が無効であるか、またはエンティティが事実（通常、送信者や受信者のサーバー）は、エラースタンザの属性「から」に設定すると、送信者に適切なエラーを返さなければならないことを発見し、接続できない場合問題のスタンザの「と」属性で指定した値。
The 'from' attribute specifies the JID of the sender.
「から」属性は、送信者の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:
サーバは「おしゃべり：クライアント」で資格認証されたストリームのコンテキスト内で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.クライアントによって提供される属性「から」の値は、関連するエンティティのための接続リソースのものであることを検証します
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.スタンザを発生接続リソースに対してサーバーにより決定される値裸JID（<ノード@ドメイン>）または完全JID（<ノード@ドメイン/リソース>）であるスタンザにアドレス「から」を追加（アドレスの決意を参照してください（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スタンザを送信しようとした場合クライアントがまだ認証されていないストリーム上の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）「から」を含めることはできませんいずれか属性または（2）は、その値がアカウントの裸JID（<ノード@ドメイン>）である属性またはクライアントの完全なJID（<ノード@ドメイン/リソース>「）から」が含まれています。スタンザは、サーバー自体によって生成されなかった場合、サーバーは、属性「から」せずにクライアントにスタンザを送ってはいけません。クライアントは「から」属性が含まれていないスタンザを受け取ると、それはスタンザは、クライアントが接続しているサーバーからのものであることを仮定しなければなりません。
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.
「ジャバー：サーバー」は名前空間、スタンザは「から」属性を持っていなければなりません。サーバーは、この制限を満たしていないスタンザを受信した場合、それは<不適切なアドレッシング/>ストリームのエラー状態を発生させなければなりません。また、属性「から」に含まれるJIDのドメイン識別子部分は、送信サーバのホスト名の検証サブドメインまたは送信サーバによってホストされる別の検証ドメインとして、送信サーバ（またはそれらの任意の検証ドメインのホスト名と一致しなければなりません）SASLネゴシエーションまたはダイヤルバックネゴシエーションに通信されます。サーバーは、この制限を満たしていないスタンザを受信した場合、それは<無効-から/>ストリームのエラー状態を発生させなければなりません。これらの条件の両方が流れ、基礎となるTCP接続の終了の閉鎖をもたらさなければなりません。これは、不正なサーバーから起動サービス拒否攻撃を防ぐのに役立ちます。
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」属性の値は、ドメイン内、またはストリーム内、グローバルに一意であることがOPTIONALです。 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であるかどうかに依存して変化します。 IQスタンザの値がこのように構成要求 - 応答「会話」のIQスタンザの役割を指定し、一方、メッセージ及びプレゼンススタンザの値は、インスタントメッセージングおよびプレゼンスアプリケーションに固有したがって[XMPP-IM]で定義されています以下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].
スタンザは、人間のユーザ（RFC 2277で説明したように、[CHARSET]、 "に提示されることを意図されたXML文字データが含まれている場合は、属性（[XML]のセクション2.12で定義されている）：スタンザは「LANGのxml」を有していなければなりません国際化）は、「人間のためです。 「XML：LANG」の値：特定の子要素の属性属性は「LANGのxml」で上書きすることができ、そのような人間が読める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).
<メッセージ/>スタンザの種類は、一つのエンティティが、電子メールのようなシステムで発生する通信と同様の別のエンティティに情報をプッシュすることにより、「プッシュ」メカニズムとして見ることができます。すべてのメッセージスタンザは、メッセージの目的の受信者を指定する「から」属性を持っていなければなりません。 （XMLスタンザに関連する一般的なルーティングと配信ルールのXMLスタンザ（セクション10）を処理するためのサーバルールを参照）、このようなスタンザを受信すると、サーバは、ルートSHOULDまたは意図された受信者に配信。
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.
<存在/>要素は、基本的なブロードキャストまたは複数のエンティティは、それらが（この場合には、ネットワーク利用可能性情報）を登録しているためにエンティティに関する情報を受信することにより、「パブリッシュ・サブスクライブ」機構として見ることができます。一般的には、発行エンティティは、エンティティが接続されているサーバがすべてのサブスクライブエンティティにそのスタンザを放送するか、多重化すべきである。その場合には、属性、「に」ノーと存在スタンザを送るべきです。しかし、発行エンティティは、その場合には、サーバSHOULDルートかは、目的の受信者にそのスタンザを届ける、「から」属性でのプレゼンススタンザを送信することができます。インスタントメッセージングおよびプレゼンスアプリケーションのコンテキストで存在する固有のルールのXMLスタンザ、および[XMPP-IM]に関連する一般的なルーティングと配信ルールのXMLスタンザ（セクション10）を処理するためのサーバルールを参照。
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):
先/クエリ、またはIQは、[HTTP]にいくつかの点で類似要求応答メカニズムです。 IQのセマンティクスはの要求を行うエンティティを有効にし、別のエンティティからの応答を受け取ります。要求および応答のデータ内容は、IQ要素の直接の子要素の名前空間宣言によって定義され、そして相互作用が「ID」属性の使用を介して要求エンティティによって追跡されます。したがって、IQの相互作用は、（適切な場合は、エラーが要求に対する応答で返されてもよいが）、このような取得/結果としての構造化データの交換や設定/結果の一般的なパターンに従います。
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:
これらのセマンティクスを施行するためには、次の規則が適用されます。
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.
*セット - スタンザは、必要なデータを提供し、新しい値を設定し、または既存の値を置き換えます。
* result -- The stanza is a response to a successful get or set 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」または「セット」IQタイプ「結果」の応答または「エラー」（レスポンスは、リクエストの「ID」属性を保持しなければならない）で応答しなければならないのIQ要求を受信するエンティティ。
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種類の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スタンザは、中に含まれる子要素を含めるべきである関連する「取得」または「セット」および<誤り/>子を含まなければなりません。詳細については、スタンザ・エラー（セクション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>
IETF：paramsは：XML：NS <= '送信側' タイプ= 'エラー' にスタンザ-種類> <エラーの種類= 'エラータイプ'> <定義された条件のxmlns = 'URN [ここで、送信者XMLを含むことを推奨]。 XMPP-スタンザ '/> <テキストのxmlns =' URN：IETF：paramsは：XML：NS：XMPP-スタンザXML：LANG = 'langcode'> OPTIONAL説明文</テキスト> [オプションのアプリケーション固有の条件要素</エラー> </スタンザ-種類>
The stanza-kind is one of message, presence, or iq.
スタンザ種は、メッセージ、プレゼンス、またはIQの一つです。
The value of the <error/> element's 'type' attribute MUST be one of the following:
<エラー/>要素の「type」属性の値は、次のいずれかを指定します。
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変更（条件は警告のみだった）進む - - AUTH oを送られたデータを変更した後に再試行 - 待機oを資格情報を提供した後に再試行 - 再試行した後、O継続（エラーが回復不能である）を再試行しません。待っている（エラーは一時的なものです）
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つに対応する子要素を含まなければなりません。名前空間この要素は '：IETF：のparams：XML：：NS-XMPPスタンザ壷' によって修飾する必要があります。
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文字データを含む<テキスト/>子を含む可能性があります。この要素は、「：IETF：のparams：XML：NS：URNのXMPPスタンザ」で修飾されている必要があり、名前空間と「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 <悪い要求/> - 送信者は、不正な形式であるか、またはそれが処理できない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 <紛争/> - 既存のリソースやセッションが同じ名前またはアドレスで存在しているため、アクセスが許可されません。関連するエラーのタイプは、「キャンセル」であるべきです。
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 <特徴-実装されていません/> - 要求された機能は、受信者またはサーバによって実装されていない、従って、処理することができません。関連するエラーのタイプは、「キャンセル」であるべきです。
o <forbidden/> -- the requesting entity does not possess the required permissions to perform the action; the associated error type SHOULD be "auth".
O </禁断の> - 要求エンティティは、アクションを実行するために必要な権限を持っていません。関連するエラーのタイプは、「認証」する必要があります。
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 </なくなっ> - 受信者またはサーバーは、もはや（エラースタンザが<ゴーン/>要素の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 <サーバ内蔵エラー/> - サーバーが原因で誤設定または他の方法で、未定義の内部サーバーエラーのスタンザを処理できませんでした。関連するエラーのタイプは、「待機」であるべきです。
o <item-not-found/> -- the addressed JID or item requested cannot be found; the associated error type SHOULD be "cancel".
Oの<item-見つかりません/> - 対処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-奇形/> - 送信エンティティは、提供またはXMPPアドレスを伝えている（例えば、属性「へ」の値）、またはこれらの局面（例えば、リソース識別子）で定義された構文に準拠しませんスキーム（第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 <-許可されていません/> - 受信者またはサーバーは、任意のエンティティは、アクションを実行することはできません。関連するエラーのタイプは、「キャンセル」であるべきです。
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 <-許可していない/> - 送信者がアクションを実行することが許可される前に適切な資格情報を提供しなければならない、または不適切な資格情報を提供してきました。関連するエラーのタイプは、「認証」する必要があります。
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 <支払いに必要な/> - 要求エンティティは、支払いが必要とされているため、要求されたサービスにアクセスすることを許可されていません。関連するエラーのタイプは、「認証」する必要があります。
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 <リダイレクト/> - <リダイレクトのXML文字データで有効JIDでなければならない受信者またはサーバが別のエンティティにこの情報の要求をリダイレクトされ、通常は一時的に（エラースタンザが含まれているべきである代替アドレス、/ >要素）。関連するエラーのタイプは、「変更」であるべきです。
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 <登録に必要な/> - 要求エンティティは、登録が必要とされているため、要求されたサービスにアクセスすることを許可されていません。関連するエラーのタイプは、「認証」する必要があります。
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 <リモートサーバ-見つかりません/> - 部分または存在しないことを意図するレシピエントの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 <リモートサーバタイムアウト/> - 一部又は意図されるレシピエントの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 <リソース制約/> - サーバまたは受信者がリクエストをサービスするために必要なシステム資源を欠いています。関連するエラーのタイプは、「待機」であるべきです。
o <service-unavailable/> -- the server or recipient does not currently provide the requested service; the associated error type SHOULD be "cancel".
O <サービス利用できません/> - サーバーまたは受信者は、現在、要求されたサービスを提供していません。関連するエラーのタイプは、「キャンセル」であるべきです。
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 <サブスクリプションに必要な/> - 要求エンティティは、サブスクリプションが必要とされているため、要求されたサービスにアクセスすることを許可されていません。関連するエラーのタイプは、「認証」する必要があります。
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 <不定状態/> - エラー状態は、このリスト内の他の条件によって定義されたものではありません。エラータイプは、この状態に関連付けられてもよく、それは、アプリケーション固有の条件と一緒に使用されるべきです。
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 <予期しない要求/> - 受信者またはサーバが要求を理解が、この時点でそれを期待していなかった（例えば、リクエストは、順不同でした）。関連するエラーのタイプは、「待機」であるべきです。
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:
述べたように、アプリケーションがエラー要素に適切に名前空間子を含めることによって、アプリケーション固有のスタンザエラー情報を提供することができます。アプリケーション固有の要素を補完またはさらに定義された要素を修飾する必要があります。このように、<誤り/>要素は、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>
<IQタイプ= 'エラー' のid = 'いくつかの-ID'> <エラーの種類は= '変更'> <悪い要求のxmlns = '壷：IETF：のparams：XML：NS：XMPP-スタンザ' /> <あまりにも多くの-parametersのxmlns = 'アプリケーションNS' /> </エラー> </ 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>
<メッセージタイプ= 'エラー' ID = '別の-ID'> <エラータイプ= '変更'> <不定条件のxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-スタンザ' /> <テキストXML： LANG =のxmlns = 'EN' 'のurn：IETF：のparams：XML：NS：XMPP-スタンザ'>いくつかの特別なアプリケーション診断情報... </テキスト> <特殊アプリケーション条件のxmlns = 'アプリケーション-NS' /> </エラー> </メッセージ>
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.
スタンザはNO「に」属性を持っていない場合、サーバはそれを送信したエンティティに代わってそれを処理する必要があります。他のサーバから受信したすべてのスタンザが「と」属性を持っていなければならないので、このルールは、スタンザは、サーバーに接続されている（例えばクライアントなど）に登録したエンティティから受信のみに適用されます。サーバーが属性「に」はでのプレゼンススタンザを受信しない場合、サーバは（該当するインスタントメッセージングとプレゼンスアプリケーションに対するプレゼンス放送のセマンティクスは[XMPPに定義されている場合、送信側エンティティのプレゼンスを購読しているエンティティにそれを放送すべきです-私は]）。サーバーは、属性「に」はで「取得」または「設定」タイプの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:
JIDのドメイン識別子部分のホスト名は、ローカルサービスへ（属性がサーバ自体またはそのサブドメインの設定されたホスト名のいずれかと一致しない、サーバーが外部ドメインへのルートスタンザをSHOULD「」の主題に含まれる場合ドメイン間の通信に関するプロビジョニングおよびセキュリティポリシー）。 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つのドメイン間に存在する：送信者のサーバーのルート権限のあるサーバーへのスタンザを既存のストリームを超える外部ドメインのために
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
二つのドメインの間には、サーバー間のストリームが存在しない：送信者のサーバー（1）外部ドメインのホスト名を解決します（下の定義されているサーバー間通信（14.4節））、（2）サーバ - を交渉します二つのドメイン（TLSの使用（セクション5）で定義したとSASLの使用との間にサーバーストリーム（セクション
6)), and (3) routes the stanza to the authoritative server for the foreign domain over the newly-established stream
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).
属性「」の中に含まれる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 <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.
JIDのドメイン識別子部分のホスト名は、属性は、サーバ自体の構成されたホスト名と一致し、属性「」の中に含まれる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:
JIDのドメイン識別子部分のホスト名は、属性は、サーバ自体の構成されたホスト名と一致し、属性「」の中に含まれるJIDフォーム<ノード@ドメイン>または<ノード@ドメインである「」の中に含まれる場合/リソース>「に」属性に含まれる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.
JIDは、リソース識別子が含まれている場合1.（すなわち、フォーム<ノード@ドメイン/リソース>である）と、受信者のサーバーは、その正確ストリームまたはセッションにスタンザを提供すべきである、完全なJIDに一致する接続リソースが存在しますリソース識別子と一致します。
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と一致するいかなる接続リソースが存在しない場合は、受信者のサーバーが送信者に、<サービス利用できません/>スタンザエラーを返すべきです。
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]).
JIDフォーム<ノード@ドメイン>であり、ノードのための少なくとも1つの接続リソースが存在する場合、受信者のサーバは、アプリケーション固有の規則に従って、接続されたリソースの少なくとも一方にスタンザを送達すべきである。3.（Aインスタントメッセージングとプレゼンスアプリケーションの配信ルールのセットは[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
事前定義されたエンティティ（その中の4.6節）にマップエスケープ文字を含むO文字データや属性値。そのような文字をエスケープしなければなりません
With regard to XML processing, if an XMPP implementation receives such restricted XML data, it MUST ignore the data.
XMPPの実装は、このような制限されたXMLデータを受信した場合、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名前空間[XML-NAMES]は、データの所有権の厳密な境界を作成するために、すべてのXMPPに準拠したXML内で使用されています。名前空間の基本的な機能は、構造的に一緒に混合されるXML要素の異なる語彙を分離することです。 XMPPに準拠したXMLが名前空間を意識していることを保証することは、任意の許容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ストリームのヘッダで必要とされます。ストリームの名前空間の名前は「http://etherx.jabber.org/streams」でなければなりません。 <ストリーム/>要素とその<特長/>の要素名と<エラー/>子供たちは、すべてのインスタンス内のストリームの名前空間接頭辞で修飾する必要があります。接頭辞：これらの要素のために、そして歴史的な理由のための接頭辞のみ「ストリーム」を受け入れることがあります。実装は唯一の「ストリーム」を生成する必要があります。
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).
デフォルトの名前空間宣言が必要とされ、ルートストリーム要素の許容最初のレベルの子を定義するために、すべての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.
デフォルトの名前空間、および歴史的な理由だけで、デフォルトの名前空間をサポートすることがあります。クライアントの実装では、「クライアントジャバー」がサポートしなければなりません。
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'.
「：クライアントおしゃべり」または 'おしゃべり：サーバの実装では、デフォルトの名前空間がある場合は、デフォルトの名前空間内の要素の名前空間接頭辞を生成してはなりません。実装では、コンテンツによって修飾要素の名前空間接頭辞を生成するべきではありません（ストリーミングではなく）「ジャバー：クライアント」以外の名前空間と 'おしゃべり：サーバの。
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：サーバー」 ）。両者の唯一の違いは、「から」と属性が内に送信スタンザにオプションである「から」：「：サーバージャバー」彼らは内に送信スタンザで必要とされているのに対し、「ジャバークライアントの。 「：クライアントおしゃべり」または 'おしゃべり：サーバの準拠した実装がで修飾されたストリーム受け入れた場合、名前空間を、それが（メッセージをすべての3つのコアスタンザの種類の共通の属性（9.1節）と基本的な意味論（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）で使用されるすべての要素のために必要とされます。ダイヤルバックの名前空間の名前は、「：サーバー：ダイヤルバックジャバー」でなければなりません。この名前空間で修飾すべての要素が前に置かなければなりません。実装では、唯一の「デシベル：」を生成すべきであるような要素の接頭辞をし、唯一の「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.
「ジャバー：サーバー」「に」と内スタンザのアドレス「から」に関して述べたものを除いて、名前空間、サーバがクライアントまたは別のサーバーに転送する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])
[NAMEPREP]のO応用、Nodeprep（付録A）、及び[STRINGPREP]（[IDNA]で定義されるように、ドメイン識別子は国際化ドメイン名であることを確実にすることを含む）アドレスへのResourceprep（付録B）プロファイル
o XML streams (Section 4), including Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7)
TLS（セクション5）、SASLの使用（第6節）、および結合リソース（第7節）の使用を含むO XMLストリーム（第4章）
o The basic semantics of the three defined stanza kinds (i.e., <message/>, <presence/>, and <iq/>) as specified in stanza semantics (Section 9.2)
スタンザセマンティクス（セクション9.2）で指定された3つの定義されたスタンザの種類（すなわち、<メッセージ/>、<存在/>、および<IQ />）の基本的な意味論O
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)
TLS（セクション5）、SASLの使用（第6節）、および結合リソース（第7節）の使用を含むO XMLストリーム（第4章）
o The basic semantics of the three defined stanza kinds (i.e., <message/>, <presence/>, and <iq/>) as specified in stanza semantics (Section 9.2)
スタンザセマンティクス（セクション9.2）で指定された3つの定義されたスタンザの種類（すなわち、<メッセージ/>、<存在/>、および<IQ />）の基本的な意味論O
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
[NAMEPREP]にアドレスの生成O、[STRINGPREP]のNodeprep（付録A）、及びResourceprep（付録B）のプロファイルは、失敗することなく適用することができます
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.
文字エンコード（セクション11.5）の下で指定されたXMLストリームは、UTF-8でエンコードされなければなりません。人間のユーザに提示されることを意図しているストリームを介して送信される任意のXML文字データのデフォルト言語として扱われる属性：ストリームは（4.4節）属性の下に指定されているように、XMLストリームは、「LANGのxml」を含むべきです。 XMLの下に指定されているように：スタンザは、人間のユーザに提示されることを意図されたXML文字データが含まれている場合、属性：LANG（9.1.5）は、XMLスタンザは「LANGのxml」を含むべきです。それがルートスタンザに属性または接続されたエンティティに代わって配信し、変更または削除しないようにしてください：サーバは、デフォルトの「LANGのxml」を適用すべきである「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ピアがしっかりと他のピアと通信するとき、それはピアの証明書を検証する必要があります。三つの可能なケースがあります。
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]の規則に従ってピア証明書を確認します。証明書は、次に、タイプ「XMPP」のsubjectAltName拡張が存在する場合にはIDとして使用する必要があることを除いて、[HTTP-TLS]に記載の規則に従ってピアの期待アイデンティティと照合されるべきです。これらのチェックのいずれかが失敗した場合、ユーザー指向のクライアントは、ユーザーに通知しなければなりませんいずれか、または不正な証明書エラーとの接続を終了する（クライアントは、ユーザーが任意の場合の接続を継続する機会を与える場合があります）。自動化されたクライアントは、（悪い証明書エラーで）接続を終了し、適切な監査ログにエラーを記録すべきです。自動化されたクライアントは、このチェックを無効にしますが、それを可能に設定を提供しなければならない構成設定を提供することができます。
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.
（SASLの使用（セクション6）の下に定義）XMLストリームを認証するためのSASLプロトコルは、サーバーに接続しているクライアントは、それがあることを主張する人であることを検証するための信頼できる機構を提供します。
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クライアント」および「TCP」のプロトの[SRV]サービスを使用してホスト名を解決しようとすべきである「_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クライアント」）は、IANA登録と一致しています。 SRVルックアップが失敗した場合、フォールバックは、IANAに登録された5222の「XMPPクライアント」ポートを使用して、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サーバ」および「TCP」のプロトの[SRV]サービスを使用してホスト名を解決しようとしなければならない「_xmpp-server._tcp.example.com。」 （サービス識別子の文字列「XMPPサーバー」の使用は、IANA登録と一致している。以前の使用がなかったので、「XMPPサーバ」サービス識別子が「ジャバー」サービス識別子の以前の使用に取って代わることはよく注意してください[SRV]に準拠していない。下位互換性があることを希望する実装が）探しかだけでなく、「ジャバー」サービス識別子に答えるために継続すべきです。 SRVルックアップが失敗した場合、フォールバックは、IANAに登録された「XMPPサーバ」のポート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
サーバーのダイヤルバックは、このように、それはより困難XMLスタンザを偽装すること、ドメインのなりすましを防ぐことができます。これは、認証の確保、またはSASLとTLSを経由して行われているように、サーバー間のストリームを暗号化するためのメカニズム、およびサーバのみアイデンティティの弱い検証における結果ではありません。また、DNSSEC [DNSSEC]が使用されない限り、DNSポイズニング攻撃を受けやすい、とさえ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.
情報が正確である、ダイヤルバックは、攻撃者がリモートドメインの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暗号を使用して）
for both: TLS plus SASL EXTERNAL(using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side certificates)
両方のために：TLSプラスSASL EXTERNAL（クライアント側の証明書をサポートする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.
IANAに登録さXMPPは、通常、ポート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のセクション3 [BASE64]における定義に従わなければなりません。
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.
リソース識別子のノード識別子のNodeprep（付録A）及びResourceprep（付録B）：また、XMPPは[STRINGPREP]の2つのプロファイルを定義します。
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曲のレパートリーは同じように見える多くの文字を持っています。多くの場合、セキュリティプロトコルのユーザーは、信頼できる第三者の名前を比較するときなどの視覚マッチングを行う可能性があります。それは、このような使用するフォントを知っているとして、コンテキストの多大ない類似した文字を、マッピングすることは不可能であるため、文字列前は、彼らが他の人のように見えるので、一緒に似て見える文字をマップするため、また一部の文字を禁止する何もしません。
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にエンティティのアドレスの一部として使用することができます。一つの一般的な使用法は、インスタント・メッセージング・ユーザのユーザ名の通りです。他には、マルチユーザーチャットルームの名前の通りです。エンティティ他の多くの種類は、そのアドレスの一部としてノード識別子を使用することができます。そのようなサービスのセキュリティは、国際ノード識別子の異なる解釈に基づいて、妥協することができます。例えば、単一の国際化ノード識別子を入力するユーザーが別のユーザーのアカウント情報にアクセスすることができ、またはユーザーがそれ以外の場合は制限されたチャットルームやサービスへのアクセスを得ることができました。
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にエンティティのアドレスの一部として使用することができます。一つの一般的な使用法は、インスタントメッセージングユーザーの接続リソース（アクティブなセッション）の名前の通りです。他には、マルチユーザーチャットルーム内のユーザーのニックネームの通りです。エンティティ他の多くの種類は、そのアドレスの一部として、リソース識別子を使用することができます。このようなサービスのセキュリティは、国際化リソース識別子の異なる解釈に基づいて危険にさらされる可能性があり、例えば、ユーザーは、同じ名前を持つ複数のセッションを開始しようとする可能性があり、またはユーザーがマルチユーザーチャットルームで意図した受信者以外の誰かにメッセージを送信することができます。
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>
URI：URN：IETF：のparams：XML：NS：XMPP-TLS仕様：RFC 3920の説明：RFC 3920登録者の接触によって定義されている。これは、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）でTLS関連データのXML名前空間名です。 ：IETF、XMPPワーキンググループ、<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>
URI：URN：IETF：のparams：XML：NS：XMPP-SASL仕様：RFC 3920の説明：RFC 3920登録者の接触によって定義されている。これは、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）でSASL関連データのXML名前空間名です。 ：IETF、XMPPワーキンググループ、<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>
URI：URN：IETF：paramsは：XML：NS：XMPPストリーム仕様：RFC 3920の説明：RFC 3920登録者によって定義される。これは、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）でストリームに関連するエラーデータのXML名前空間名であります連絡先：IETF、XMPPワーキンググループ、<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>
URI：URN：IETF：のparams：XML：NS：XMPP-バインド仕様：RFC 3920の説明：IETF：これはRFC 3920登録者の接触によって定義されている拡張メッセージングおよびプレゼンスプロトコル（XMPP）に結合リソースのXML名前空間名です。 、XMPPワーキンググループ、<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>
URI：URN：IETF：のparams：XML：NS：XMPP-スタンザ仕様：RFC 3920の説明：RFC 3920登録者によって定義されている。これは、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）でスタンザ関連のエラーデータのXML名前空間名です。連絡先：IETF、XMPPワーキンググループ、<xmppwg@jabber.org>
The Nodeprep profile of stringprep is defined under Nodeprep (Appendix A). The IANA has registered Nodeprep in the stringprep profile registry.
文字列準備のNodeprepプロファイルはNodeprep（付録A）の下に定義されています。 IANAは、文字列準備プロフィールレジストリに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.
文字列準備のResourceprepプロファイルはResourceprep（付録B）の下に定義されています。 IANAは、文字列準備プロフィールレジストリに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).
SASL定義（セクション6.3）の下で定義されるようにIANAは、GSSAPI [GSSAPI]サービス名として「XMPP」が登録されています。
The IANA has registered "xmpp-client" and "xmpp-server" as keywords for [TCP] ports 5222 and 5269 respectively.
IANAは、それぞれ[TCP]ポート5222と5269のためのキーワードとして "XMPPクライアント" および "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]クロッカー、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でデータエンコーディング"、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]リーチ、P.とC.ニューマン、RFC 2831、2000年5月 "SASLメカニズムとしてダイジェスト認証を使用します"。
[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]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[HTTP-TLS]レスコラ、E.、 "HTTPオーバーTLS"、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.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（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.とS.デアリング、 "インターネットプロトコルバージョン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]ホフマン、P.とM.ブランシェ、 "NAMEPREP：国際化ドメイン名のためのstringprepプロフィール（IDN）"、RFC 3491、2003年3月。
[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RANDOM]イーストレーク第3、D.、クロッカー、S.、およびJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（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]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、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.
[用語]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "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.、ポーク、W.、フォード、W.、およびD.ソロ、 "インターネット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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、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]ブレイ、T.、オランダ、D.、およびA.素人、 "XMLで名前空間"、W3C REC-XML-名、1999年1月、<http://www.w3.org/TR/REC -xml-名>。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C.及びJ.マイヤーズ、 "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：抽象構文記法1（ASN.1）の仕様"、1988。
[DNSSEC] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[DNSSEC]イーストレーク第3、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、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日目、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[IRC] Oikarinen、J.とD.リード、 "インターネットリレーチャットプロトコル"、RFC 1459、1993年5月。
[JEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", JSF JEP 0029, October 2003.
[JEP-0029] Kaes、C.、 "Jabberの識別子（たJID）の定義"、JSF JEP 0029、2003年10月。
[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.
[JEP-0078]サンアンドレ、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]ノリス、R.とP.サンアンドレ、 "エラー状態マッピング"、JSF JEP 0086、2004年2月。
[JSF] Jabber Software Foundation, "Jabber Software Foundation", <http://www.jabber.org/>.
[JSF]のJabber Software Foundationが、 "Jabberのソフトウェア財団"、<http://www.jabber.org/>。
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月。
[SIMPLE] SIMPLE Working Group, "SIMPLE WG", <http://www.ietf.org/html.charters/simple-charter.html>.
[SIMPLE] 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.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[USINGTLS]ニューマン、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]サンアンドレ、P.、エド、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"。、RFC 3921、2004年10月。
Appendix A. Nodeprep
付録A. Nodeprep
A.1. Introduction
A.1。前書き
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
ユニコード3.2、使用するマッピングoをこの付録のセクション2で指定された：STRINGPREPする入力と出力される文字レパートリoをXMPP内のノード識別子を国際：使用Unicode正規oをセクション3で指定されたプロファイルの意図された適用O ：出力として禁止されている文字oを第4節で指定：双方向文字処理oをセクション5で指定された：第6節で指定されました
A.2. Character Repertoire
A.2。文字レパートリ
This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both defined in Appendix A of [STRINGPREP].
このプロファイルは、表A.1にある未割り当てコードポイントのリストをユニコード3.2を使用して、両方が[STRINGPREP]の付録Aで定義されます。
A.3. Mapping
A.3。マッピング
This profile specifies mapping using the following tables from [STRINGPREP]:
このプロファイルは、[STRINGPREP]から以下の表を使用してマッピングを指定します。
Table B.1 Table B.2
表B.1表B.2
A.4. Normalization
A.4。正常化
This profile specifies the use of Unicode normalization form KC, as described in [STRINGPREP].
記載されているように、このプロファイルは[STRINGPREP]、KC形態Unicode正規化の使用を指定します。
A.5. Prohibited Output
A.5。出力禁止
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.4表C.5表C.6表C.7表C.8表C.9
In addition, the following Unicode characters are also prohibited:
また、以下のUnicode文字も禁止されています。
#x22 (") #x26 (&) #x27 (') #x2F (/) #x3A (:) #x3C (<) #x3E (>) #x40 (@)
＃服（「）＃KSAT（＆）＃くる病（a）の＃Ksav（/）＃Ksaa（:)＃Ksek（<）＃KSA（>）＃40猫（@）
A.6. Bidirectional Characters
A.6。双方向文字
This profile specifies the checking of bidirectional strings, as described in Section 6 of [STRINGPREP].
【STRINGPREP]のセクション6で説明したように、このプロファイルは、双方向の文字列のチェックを指定します。
Appendix B. Resourceprep
付録B. Resourceprep
B.1. Introduction
B.1。前書き
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]の「Resourceprep」プロファイルを定義します。このように、それは、拡張メッセージングおよびプレゼンスプロトコル（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
ユニコード3.2、この付録の第2節で指定：文字列前に、入力と出力の文字レパートリーO
o The mappings used: specified in Section 3
第3節で指定：使用マッピングO
o The Unicode normalization used: specified in Section 4
セクション4で指定された：使用されるUnicode正規O
o The characters that are prohibited as output: specified in Section 5
第5節で指定：出力として禁止されている文字O
o Bidirectional character handling: specified in Section 6
O双方向文字処理：第6節で指定されました
B.2. Character Repertoire
B.2。文字レパートリ
This profile uses Unicode 3.2 with the list of unassigned code points being Table A.1, both defined in Appendix A of [STRINGPREP].
このプロファイルは、表A.1にある未割り当てコードポイントのリストをユニコード3.2を使用して、両方が[STRINGPREP]の付録Aで定義されます。
B.3. Mapping
B.3。マッピング
This profile specifies mapping using the following tables from [STRINGPREP]:
このプロファイルは、[STRINGPREP]から以下の表を使用してマッピングを指定します。
Table B.1
表B.1
B.4. Normalization
B.4。正常化
This profile specifies using Unicode normalization form KC, as described in [STRINGPREP].
【STRINGPREP]に記載されているように、このプロファイルは、KCフォームのUnicode正規化を使用して指定します。
B.5. Prohibited Output
B.5。出力禁止
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.4表C.5表C.6表C.7表C.8表C.9
B.6. Bidirectional Characters
B.6。双方向文字
This profile specifies checking bidirectional strings as described in Section 6 of [STRINGPREP].
このプロファイルは、[STRINGPREP]のセクション6で説明したように、双方向の文字列をチェックする指定します。
Appendix C. XML Schemas
付録C. XMLスキーマ
The following XML schemas are descriptive, not normative. For schemas defining the 'jabber:client' and 'jabber:server' namespaces, refer to [XMPP-IM].
次のXMLスキーマは規範的、記述的ではありません。 「：クライアントおしゃべり」と 'おしゃべり：サーバの定義スキーマの名前空間を、[XMPP-IM]を参照してください。
C.1. Streams namespace
C.1。ストリームの名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= '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：スキーマのxmlns：XSの= 'のhttp：//www.w3.org/2001/XMLSchema' のtargetNamespace = 'のhttp：//etherx.jabber.org/streams' のxmlns = 'のhttp：//etherx.jabber.org /ストリームのelementFormDefault = '' 修飾されていません>
<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：要素名= '流れ'> <XS：complexTypeの> <XS：シーケンスのxmlns：クライアント= 'おしゃべり：クライアントののxmlns：サーバー='おしゃべり：サーバののxmlns：DB = 'のjabber：サーバー：ダイヤルバック'> < XS：要素REF = '特徴' のminOccurs = '0' のmaxOccurs = '1' /> <XS：のminOccurs = '0' のmaxOccurs = '無限= '：IETF：paramsは：XML：NS XMPP-TLS URN' 名前空間'/> <XS：任意の名前空間=' URN：IETF：のparams：XML：NS：XMPP-SASL」のminOccurs = '0' のmaxOccurs = '無制限' /> <XS：選択肢のminOccurs = '0' のmaxOccurs = '1' > <XS：選択肢のminOccurs = '0' のmaxOccurs = '無制限に'> <XS：要素REF = 'クライアント：メッセージ' /> <XS：要素REF = 'クライアント：存在' /> <XS：要素REF = 'クライアント：IQ '/> </ XS：選択> <XS：選択のminOccurs =' 0' のmaxOccurs属性の= '無制限'> <XS：要素REF = 'サーバー：メッセージ' /> <XS：要素REF = 'サーバー：プレゼンス' /> <XS：要素REF = 'サーバー：IQ' /> <XS：要素REF = 'DB：結果' /> <XS：要素REF = 'DB：検証' /> </ XS：選択> </ XS ：選択> <XS：要素REF = 'エラー' のminOccurs = '0' のmaxOccursの= '1' /> </ XS：シーケンス> <XS：タイプ= 'のxs：文字列' 'から' 属性名=使用= 'オプション'/> <XS：属性名=' ID」タイプ= 'のxs：NMTOKEN' 使用= XS </> 'オプション'：タイプ= 'に' 属性名= 'のxs：文字列' 使用= 'オプション' /> <XS：属性名= 'バージョン' タイプ= 'のxs：小数点以下' 使用= 'オプション' / > <XS：属性REF = 'のxml：langの' 使用= 'オプション' /> </ XS：complexTypeの> </ XS：要素>
<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：要素名= 'の特徴'> <XS：complexTypeの> <XS：すべてのxmlns：TLSの= 'URN：IETF：のparams：XML：NS：XMPP-TLS' のxmlns：SASL = 'URN：IETF：のparams：XML ：NS：XMPP-SASL」のxmlns：バインド= 'URN：IETF：paramsは：XML：NS：XMPPバインド' のxmlns：のSES = 'URN：IETF：paramsは：XML：NS：XMPPセッション'> <XS：要素REF = 'TLS：STARTTLS' のminOccurs = '0' /> <XS：要素REF = 'SASL：メカニズム' のminOccurs = '0' /> <XS：要素REF = 'バインド：バインド' のminOccurs = '0' /> <XS：要素REF = 'のSES：セッション' = '0' のminOccurs /> </ XS：すべて> </ XS：complexTypeの> </ XS：要素>
<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：要素名= 'エラー'> <XS：complexTypeの> <XS：配列のxmlns：=誤る 'URNを：IETF：paramsは：XML：NS：XMPPストリーム'> <XS：グループREF = 'ERR：streamErrorGroup' /> <XS：要素REF = 'ERR：テキスト' のminOccurs = '0' ののmaxOccurs = '1' /> </ XS：配列> </ XS：complexTypeの>
</xs:element>
</ XS：要素>
</xs:schema>
</ XS：スキーマ>
C.2. Stream error namespace
C.2。ストリームエラーの名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= '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：スキーマのxmlns：XS = 'HTTP：//www.w3.org/2001/XMLSchema' のtargetNamespace = 'URN：IETF：paramsは：XML：NS：XMPPストリーム' のxmlns = 'URN：IETF：paramsは：XML ：NS：XMPPストリームのelementFormDefault = '資格'>
<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：要素名= '悪い-フォーマット' タイプ= '空' /> <XS：要素名= '悪い-名前空間接頭辞' タイプ= '空' /> <XS：要素名= '葛藤' タイプ=」空「/> <XS：要素名=」接続タイムアウト「タイプ= 『空』 /> <XS：要素名= 『ホストなくなっ』タイプ= 『空』 /> <XS：要素名=」ホスト不明'TYPE =' 空 '/> <XS：要素名=' 不適切アドレッシング」TYPE = '空' /> <XS：要素名= 'サーバ内蔵エラー' TYPE = '空' /> <XS：要素NAME = '無効から' TYPE = '空' /> <XS：要素名= '無効-ID' TYPE = '空' /> <XS：要素名= '無効な名前空間' TYPE = '空' /> <XS：要素名= '無効-XML' タイプ= '空' /> <XS：要素名= ' - 権限がありません' タイプ= '空' /> <XS：要素名= 'ポリシー違反' タイプ=」空「/> <XS：要素名=」リモート接続に失敗した「タイプ= 『空』 /> <XS：要素名= 『リソース制約』タイプ= 『空』 /> <XS：要素名は=」制限-xml」タイプ= '空' /> <XS：要素名= '参照-他のホスト' タイプ= 'のxs：文字列' /> <XS：要素名= 'システムシャットダウン' タイプ= '/' 空> <XS：要素名=「未定義条件」タイプ= 'EMP TY '/> <XS：要素名=' サポートされていないエンコード 'TYPE = '空'/> <XS：要素名= 'サポートされていない-スタンザ型' TYPE = '空'/> <XS：要素名=' サポートされていません-version」TYPE = '空 ''/> <XS要素名= 'XML-ウェルに形成されていない' TYPE =' 空/>
<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：グループ名= 'streamErrorGroup'> <XS：選択> <XS：要素REF = '悪いフォーマット' /> <XS：要素REF = '悪い名前空間接頭辞' /> <XS：要素REF =」紛争 '/> <XS：要素REF =' 接続タイムアウト '/> <XS：= ref要素'：ホスト - 不明なホスト-なくなっ '= ref要素/> <XS' '/> <XS：要素REF ='不適切なアドレッシング '/>
<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：要素REF = '内部サーバーエラー' /> <XS：要素REF = '無効から' /> <XS：要素REF = '無効-ID' /> <XS：要素REF = 'invalid-名前空間 '/> <XS：要素REF =' 無効なXML '/> <XS：要素REF =' - 権限がありません '/> <XS：要素REF =' ポリシー違反 '/> <XS：要素REF ='リモート接続に失敗した '/> <XS：要素REF =' リソース制約 '/> <XS：要素REF =' 制限-XML '/> <XS：要素REF =' 参照-他のホスト '/> < XS：要素REF = 'システムシャットダウン' /> <XS：要素REF = '不定状態' /> <XS：要素REF = 'サポートされていないエンコード' /> <XS：要素REF = 'サポートされていない-スタンザ型'/> <XS：要素REF =' サポートされていないバージョン '/> <XS：要素REF =' XML-ウェルに形成されていない '/> </ XS：選択> </ XS：グループ>
<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：要素名= 'テキスト'> <XS：complexTypeの> <XS：simpleContentを> <XS：増設ベース= 'のxs：文字列'> <XS：属性REF = 'のxml：langの' 使用= 'オプション' /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素>
<xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType>
<XS：単純名= '空'> <XS：制限基地= 'XS：文字列'> <XS：列挙値= '' /> </ XS：制限> </ XS：simpleTypeの>
</xs:schema>
</ XS：スキーマ>
C.3. TLS namespace
C.3。 TLS名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= '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：スキーマの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 = '資格'>
<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：要素名= 'STARTTLS'> <XS：complexTypeの> <XS：配列> <XS：要素名= '必須' のminOccurs = '0' のmaxOccurs = '1' TYPE = '空' /> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素>
<xs:element name='proceed' type='empty'/> <xs:element name='failure' type='empty'/>
<XS：要素名= '進む' タイプ= '空' /> <XS：要素名= '失敗' タイプ= '空' />
<xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType>
<XS：単純名= '空'> <XS：制限基地= 'XS：文字列'> <XS：列挙値= '' /> </ XS：制限> </ XS：simpleTypeの>
</xs:schema>
</ XS：スキーマ>
C.4. SASL namespace
C.4。 SASLの名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= '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：スキーマの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 = '資格'>
<xs:element name='mechanisms'> <xs:complexType> <xs:sequence> <xs:element name='mechanism' maxOccurs='unbounded' type='xs:string'/> </xs:sequence> </xs:complexType> </xs:element>
<XS：要素名= '機構'> <XS：complexTypeの> <XS：配列> <XS：要素名= '機構' のmaxOccurs = '無限' TYPE = 'XS：文字列' /> </ XS：配列> < / XS：complexTypeの> </ XS：要素>
<xs:element name='auth'> <xs:complexType> <xs:simpleContent> <xs:extension base='empty'> <xs:attribute name='mechanism'
<XS：要素名= 'AUTH'> <XS：complexTypeの> <XS：simpleContentを> <XS：拡張塩基= '空の'> <XS：属性名= '機構'
type='xs:string' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
TYPE = 'のxs：string' は使用= '任意' /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素>
<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：要素名= '挑戦' タイプ= 'のxs：文字列' /> <XS：要素名= '応答' タイプ= 'のxs：文字列' /> <XS：要素名= '中止' タイプ= '空' /> <XS：要素名= '成功' タイプ= '空' />
<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：要素名= '失敗'> <XS：complexTypeの> <XS：選択肢のminOccurs = '0'> <XS：要素名= '中止に' タイプ= '空' /> <XS：要素名= 'incorrect-エンコーディング」TYPE = '空' /> <XS：要素名= '無効authzidは' TYPE = '空' /> <XS：要素名= '無効メカニズム' TYPE = '空' /> <XS：要素名= 'メカニズム - あまりにも弱' タイプ= '空' /> <XS：要素名= ' - 権限がありません' タイプ= '空' /> <XS：要素名= '一時的-AUTH-失敗' タイプ= '空'/> </ XS：選択> </ XS：complexTypeの> </ XS：要素> <XS：単純名=' 空 '> <XS：制限基地=' のxs：string 'は> <XS：列挙値=' 「/> </ XS：制限> </ XS：単純>
</xs:schema>
</ XS：スキーマ>
C.5. Resource binding namespace
C.5。リソースバインディング名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= '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：スキーマのxmlns：XS = 'のhttp：//www.w3.org/2001/XMLSchema' のtargetNamespace = 'URN：IETF：のparams：XML：NS：XMPP-バインド' のxmlns = "壷：IETF：のparams：XML ：NS：XMPP-バインド」のelementFormDefault = '資格'>
<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：要素名= 'バインド'> <XS：complexTypeの> <XS：選択肢のminOccurs = '0' のmaxOccurs = '1'> <XS：要素名= 'リソース' タイプ= 'のxs：文字列' /> <XS ：要素名= 'JID' タイプ= 'のxs：文字列' />
</xs:choice> </xs:complexType> </xs:element>
</ XS：選択> </ XS：complexTypeの> </ XS：要素>
</xs:schema>
</ XS：スキーマ>
C.6. Dialback namespace
C.6。ダイアルバックの名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:server:dialback' xmlns='jabber:server:dialback' elementFormDefault='qualified'>
<XS：スキーマのxmlns：XSの= 'のhttp：//www.w3.org/2001/XMLSchema' のtargetNamespace = 'のjabber：サーバー：ダイヤルバック' のxmlns = 'のjabber：サーバー：ダイヤルバック' のelementFormDefault = '資格'>
<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：要素名= '結果'> <XS：complexTypeの> <XS：simpleContentを> <XS：拡張ベース= 'XS：トークン'> <XS：属性名= 'から' 型= 'XS：string' は使用= '必要な' /> <XS：属性名=タイプ= 'XS：文字列' 'から' 使用= '必要' /> <XS：属性名= 'type' を使用= 'オプション'> <XS：単純> <XS ：制限ベース= 'のxs：NCNameで'> <XS：列挙値= '無効' /> <XS：列挙値= '有効' /> </ XS：制限> </ XS：単純> </ XS：属性> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素>
<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：要素名= '確認'> <XS：complexTypeの> <XS：simpleContentを> <XS：拡張ベース= 'XS：トークン'> <XS：属性名=タイプ= 'XS：文字列' '' から使用= '必要な' /> <XS：属性名= 'ID' タイプ= 'のxs：NMTOKEN' 使用= '必要' /> <XS：タイプ= 'に' 属性名= 'のxs：文字列' 使用= '必要' / > <XS：属性名= 'タイプ' 使用= '任意'> <XS：単純> <XS：制限基地= 'のxs：NCNameで'> <XS：列挙値= '無効' /> <XS：列挙値= '有効' /> </ XS：制限>
</xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
</ XS：単純> </ XS：属性> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素>
</xs:schema>
</ XS：スキーマ>
C.7. Stanza error namespace
C.7。スタンザ・エラーの名前空間
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= '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：スキーマのxmlns：XS = 'HTTP：//www.w3.org/2001/XMLSchema' のtargetNamespace = 'URN：IETF：paramsは：XML：NS：XMPP-スタンザ' のxmlns = 'URN：IETF：paramsは：XML ：NS：XMPP-スタンザのelementFormDefault = '資格'>
<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：要素名= '悪い要求' タイプ= '空' /> <XS：要素名= '葛藤' タイプ= '空' /> <XS：要素名= '機能-実装されていません' タイプ=」空 '/> <XS：要素名=' 禁断の 'タイプ= '空'/> <XS：要素名= '消えて' タイプの= 'XS：文字列'/> <XS：要素名=' サーバ内蔵のエラー'TYPE =' 空 '/> <XS：要素名=' アイテム-見つかりません」TYPE = '空' /> <XS：要素名= 'JID-奇形' TYPE = '空' /> <XS：要素名= '受け入れられない' タイプ= '空' /> <XS：要素名= '許可されていません' タイプ= '空' /> <XS：要素名= '支払い-必要' タイプ= '空' /> <XS：要素名= '受信者利用不可' TYPE = '空' /> <XS：要素名= 'リダイレクト' TYPE = 'XS：文字列' /> <XS：要素名= '登録必要' TYPE =」空「/> <XS：要素名=」リモート・サーバ・見つからない」タイプ= 『空』 /> <XS：要素名= 『リモート・サーバー・タイムアウト』タイプ= 『空』 /> <XS：要素名前=「リソース制約」タイプ=「空」/> <XS：要素名=「サービス利用できません」タイプ=「空」/> <XS：要素名=「サブスクリプション必要」タイプ=「空」/> <XS：要素名= '未定義 - コndition」タイプ= '空' /> <XS：要素名= '予期しない要求' タイプ= '空' />
<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：グループ名= 'stanzaErrorGroup'> <XS：選択> <XS：要素REF = '悪い要求' /> <XS：要素REF = '葛藤' /> <XS：要素REF = '機能-not-実装 '/> <XS：要素REF =' 禁断の '/> <XS：要素REF =' なくなっ '/>
<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：要素REF = '内部サーバーエラー' /> <XS：要素REF = 'アイテム-見つかりません' /> <XS：= ref要素 'JID-奇形' /> <XS：要素REF =」 - 許容できない '/> <XS：要素REF ='、許可されていません '/> <XS：要素REF =' 支払いに必要な '/> <XS：要素REF =' 受信者-使用できません '/> <XS：要素の参照= 'リダイレクト' /> <XS：要素REF = '登録必要' /> <XS：要素REF /> <XS = '-見つからないリモートサーバー'：要素REF = 'リモートサーバタイムアウト' / > <XS：要素REF = 'リソース制約' /> <XS：要素REF = 'サービス利用できません' /> <XS：要素REF = 'サブスクリプションに必要な' /> <XS：要素REF = '未定義条件'/> <XS：要素REF =' 予期しない要求 '/> </ XS：選択> </ XS：グループ>
<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：要素名= 'テキスト'> <XS：complexTypeの> <XS：simpleContentを> <XS：増設ベース= 'のxs：文字列'> <XS：属性REF = 'のxml：langの' 使用= 'オプション' /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素>
<xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType>
<XS：単純名= '空'> <XS：制限基地= 'XS：文字列'> <XS：列挙値= '' /> </ XS：制限> </ XS：simpleTypeの>
</xs:schema>
</ XS：スキーマ>
Appendix D. Differences Between Core Jabber Protocols and XMPP
コアのJabberプロトコルとXMPPの間の付録D.の違い
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の実装と展開の大規模なインストールベースが存在するので、迅速かつXMPPにそれらの実装と展開のアップグレードを促進するために、関連のJabberプロトコルとXMPPの主な違いを指定すると便利かもしれません。 [XMPP-IM]の対応するセクションは、インスタントメッセージングとプレゼンスアプリケーションに特異的に関連する差異を要約しながら、このセクションでは、コアの違いをまとめたものです。
D.1. Channel Encryption
D.1。チャネルの暗号化
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.
これは、（慣例は、ポート5223と5270を使用することです）5222と5269以外のポート上のチャネルの暗号化にSSLを使用するJabberのコミュニティで一般的に行われました。本明細書でTLSの使用（セクション5）で定義したXMPPは、チャネル暗号化のためのIANA登録ポートを介してTLSを使用します。
D.2. Authentication
D.2。認証
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.
「：IQ：AUTHジャバー」のJabber Software Foundationの[JSF]によって公開された名前空間（このプロトコルのドキュメントは[JEP-0078]に含まれている、Jabberのコミュニティで開発されたクライアントサーバ認証プロトコルは、で修飾基本的なIQの相互作用を使用しました）。本明細書でSASLの使用（セクション6）で定義したXMPPは、認証のために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節）プロトコルをサーバー間通信のための認証プロトコルを開発しませんでした。本明細書でSASLの使用（セクション6）で定義したXMPPは、真のサーバ間の認証プロトコルとサーバーダイアルバックに取って代わります。
D.3. Resource Binding
D.3。リソースバインディング
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コミュニティに結合リソースは「：IQ認証ジャバー」を介して処理されていました。 XMPPは、リソースの結合のための専用の名前空間と同様リソース（セクション7）結合の下で定義されるように、クライアントに代わってリソース識別子を生成するサーバーの能力を定義します。
D.4. JID Processing
D.4。 JID処理
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のソフトウェア財団[JSF]が発行し、[JEP-0029]に含まれています）。リソース識別子のノード識別子のNodeprep（付録A）及びResourceprep（付録B）：XMPPは、JIDの処理のための2つの追加[STRINGPREP]プロフィールを有する[NAMEPREP]ドメイン識別子及びサプリメントのためのNAMEPREPの使用を指定します。
D.5. Error Handling
D.5。エラー処理
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とエラー処理機構との間のマッピングのドキュメントは、[JEP-0086]に含まJabberのソフトウェア財団[JSF]により公開されています。）
D.6. Internationalization
D.6。国際化
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の」の使用を指定：langの（セクション9.1.5）本明細書に気流下で定義されるように、そのような状況において、属性（セクション4.4）とXML属性。
D.7. Stream Version Attribute
D.7。ストリームバージョン属性
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年1月の主要中ジャバー・サーバの初期バージョンのソースコードをリリースしたジェレミー・ミラー、によって設立された当初、1999年にJabberのオープンソース・コミュニティ内で開発されました基本プロトコルへの早期貢献もライアンEatmon、ピーター・ミラード、トーマスMuldowney、とデイブ・スミスが含まれています。 XMPPワーキンググループによる研究では、特に安全保障と国際化に集中しています。これらの地域では、TLSとSASLを使用するためのプロトコルは、もともとロブ・ノリスが寄与し、文字列準備プロフィールはもともとジョー・ヒルデブラントによって寄与されました。エラーコードの構文は、リサ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.
おかげで記載された貢献に加えて、個人の数に起因するものです。トーマス・シャロン、リチャード・ドブソン、サム・ハートマン、スカイラー・ヒース、ジョナサン・ホッグ、カレン・ジェニングス、クレイグKaes：それは完全なリストを提供することは困難であるが、以下の個人は、プロトコルを定義してか、このメモでは仕様上のコメントで特に有用でした、ヤツェクKonieczny、アレクセイ・メルニコフ、キースMinkler、ジュリアンMissig、ピート・レズニック、マーシャルローズ、アレクセイShchepin、ジャン=ルイ・Seguineau、イアンShigeoka、グレッグTroxel、そしてデイビット・ウェイト。また、XMPPワーキンググループのメンバーとこのメモの人生を通じて提供コメントやフィードバックのためのIETFコミュニティに感謝します。
Author's Address
著者のアドレス
Peter Saint-Andre (editor) Jabber Software Foundation
ピーター・サン・アンドレ（エディタ）のJabber Software Foundationの
EMail: stpeter@jabber.org
メールアドレス：stpeter@jabber.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。