RFC3920 日本語訳
3920 Extensible Messaging and Presence Protocol (XMPP): Core. P.Saint-Andre, Ed.. October 2004. (Format: TXT=194313 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Saint-Andre, Ed. Request for Comments: 3920 Jabber Software Foundation Category: Standards Track October 2004
エド、ワーキンググループP.サンアンドレをネットワークでつないでください。コメントのために以下を要求してください。 3920年のおしゃべりソフトウェア財団カテゴリ: 標準化過程2004年10月
Extensible Messaging and Presence Protocol (XMPP): Core
広げることができるメッセージングと存在は(XMPP)について議定書の中で述べます: コア
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このメモはExtensible MessagingとPresenceプロトコル(XMPP)のコアの特徴(どんな2つのネットワーク終点の間でもリアルタイムでと閉鎖における構造化された情報を交換するために拡張マークアップ言語(XML)要素を流すためのプロトコル)を定義します。 XMPPが一般化されて、広げることができるフレームワークをXMLデータを交換するのに提供している間、それは主にRFC2779に関する必要条件を満たすインスタントメッセージングと存在アプリケーションを組立てる目的に使用されます。
Saint-Andre, Ed. Standards Track [Page 1] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[1ページ]RFC3920XMPPコア2004年10月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 アーキテクチャ. . . . . . . . . . . . . . . . . . 3 3を広めました。 体系. . . . . . . . . . . . . . . . . . . . . 5 4を扱います。 XMLは.7 5を流します。 TLS. . . . . . . . . . . . . . . . . . . . . . . . . 19 6の使用。 SASL. . . . . . . . . . . . . . . . . . . . . . . . 27 7の使用。 リソース結合. . . . . . . . . . . . . . . . . . . . . . 37 8。 サーバDialback. . . . . . . . . . . . . . . . . . . . . . 41 9。 XMLスタンザ. . . . . . . . . . . . . . . . . . . . . . . . 48 10。 サーバは取り扱いXMLスタンザ. . . . . . . . . . . 58 11のために統治されます。 XMPP. . . . . . . . . . . . . . . . . . . 60 12の中のXML用法。 コア承諾要件. . . . . . . . . . . . . . . . 62 13。 国際化問題. . . . . . . . . . . . 64 14。 セキュリティ問題. . . . . . . . . . . . . . . . . . 64 15。 IANA問題. . . . . . . . . . . . . . . . . . . . 69 16。 コアおしゃべりプロトコルとXMPP.87人の貢献者の参照. . . . . . . . . . . . . . . . . . . . . . . . . 71A.Nodeprep. . . . . . . . . . . . . . . . . . . . . . . . . . 75B.Resourceprep. . . . . . . . . . . . . . . . . . . . . . . . 76C.XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . 78D.差。 . . . . . . . . . . . . . . . . . . . . . . . . . . 89の承認。 . . . . . . . . . . . . . . . . . . . . . . . . 89作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . 89 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 90
1. Introduction
1. 序論
1.1. Overview
1.1. 概要
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].
Extensible MessagingとPresenceプロトコル(XMPP)は近くリアルタイムのメッセージング、存在、および要求応答サービスのための開いている拡張マークアップ言語[XML]プロトコルです。 基本的な構文と意味論は主に1999年に元々、Jabberオープンソース共同体の中で開発されました。 2002年に、XMPP WGはIETFインスタントメッセージング(IM)と存在技術として適当なJabberプロトコルの適合を開発するのにチャーターされました。 XMPP WGによる仕事の結果、現在のメモはXMPP1.0のコアの特徴を定義します。 拡大がRFC2779[IMP-REQS]で定義されたメッセージングと存在の機能性がExtensible MessagingとPresenceプロトコル(XMPP)で指定されるとすぐに、提供するのが必要です: インスタントメッセージングと存在、[XMPP、-、不-、]
Saint-Andre, Ed. Standards Track [Page 2] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[2ページ]RFC3920XMPPコア2004年10月
1.2. Terminology
1.2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14、RFC2119[用語]で説明されるように本書では解釈されることであるべきですか?
2. Generalized Architecture
2. 一般化されたアーキテクチャ
2.1. Overview
2.1. 概要
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
C1----S1---S2---C3| C2----+--G1===FN1===FC1
The symbols are as follows:
シンボルは以下の通りです:
o C1, C2, C3 = XMPP clients
o XMPP C1、C2、C3=クライアント
o S1, S2 = XMPP servers
o XMPP S1、S2=サーバ
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は外国メッセージングネットワークでクライアントと等しいです。
2.2. Server
2.2. サーバ
A server acts as an intelligent abstraction layer for XMPP communications. Its primary responsibilities are:
サーバはXMPPコミュニケーションのための知的な抽象化層として機能します。 責務は以下の通りです。
o to manage connections from or sessions for other entities, in the
form of XML streams (Section 4) to and from authorized clients,
servers, and other entities
o 実体と認可されたクライアントと、サーバと、他の実体からXMLの形の他の実体のための接続かセッションストリームを管理する(セクション4)ために
Saint-Andre, Ed. Standards Track [Page 3] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[3ページ]RFC3920XMPPコア2004年10月
o to route appropriately-addressed XML stanzas (Section 9) among
such entities over XML streams
o XMLストリームの上で適切に扱われたXMLスタンザ(セクション9)をそのような実体に発送するために
Most XMPP-compliant servers also assume responsibility for the storage of data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the XML data is processed directly by the server itself on behalf of the client and is not routed to another entity.
また、ほとんどのXMPP対応することのサーバがクライアント(例えば、XMPPベースのインスタントメッセージングのユーザへのコンタクトリストと存在アプリケーション)によって使用されるデータ記憶への責任を負います。 この場合、XMLデータは、直接サーバ自体によってクライアントを代表して処理されて、別の実体に発送されません。
2.3. Client
2.3. クライアント
Most clients connect directly to a server over a [TCP] connection and use XMPP to take full advantage of the functionality provided by a server and any associated services. Multiple resources (e.g., devices or locations) MAY connect simultaneously to a server on behalf of each authorized client, with each resource differentiated by the resource identifier of an XMPP address (e.g., <node@domain/ home> vs. <node@domain/work>) as defined under Addressing Scheme (Section 3). The RECOMMENDED port for connections between a client and a server is 5222, as registered with the IANA (see Port Numbers (Section 15.9)).
ほとんどのクライアントが、[TCP]接続の上で直接サーバに接続して、サーバによって提供された機能性とどんな関連サービスも最大限に利用するのにXMPPを使用します。 複数のリソース(例えば、デバイスか位置)が同時にそれぞれの認可されたクライアントを代表してサーバに接続するかもしれません、各リソースがXMPPアドレスに関するリソース識別子によって差別化されている状態で(例えば、 <node@domain/ ホーム、gt;、 vs. <node@domain/work 、gt;、)、Addressing Scheme(セクション3)の下で定義されるように。 クライアントとサーバとの関係のためのRECOMMENDEDポートは5222です、IANAに登録されるように(Port民数記(セクション15.9)を見てください)。
2.4. Gateway
2.4. ゲートウェイ
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に翻訳して戻すプライマリ機能がことである専用サーバサイドサービスです。 例は、AIMや、アイシーキューや、MSN Messengerや、Yahoo!インスタントメッセンジャなどのメールするゲートウェイ([SMTP]を見る)と、インターネットRelay Chat([IRC]を見る)と、SIMPLE([SIMPLE]を見る)と、Short Message Service(SMS)と、レガシーインスタントメッセージングサービスです。 ゲートウェイとサーバと、ゲートウェイと外国メッセージシステムとのコミュニケーションは本書では定義されません。
2.5. Network
2.5. ネットワーク
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 、gt;、メッセージ、存在、および他の情報 with <romeo@example.net を交換できる、gt。 このパターンはネットワークアドレシング規格を利用するメッセージング・プロトコル([SMTP]などの)から身近です。 どんな2つのサーバのコミュニケーションもOPTIONALです。 可能にされるなら、そのようなコミュニケーションSHOULDは[TCP]接続に縛られるXMLストリームの上に起こります。 サーバの間の関係のためのRECOMMENDEDポートはIANAに登録されるように5269(Port民数記(セクション15.9)を見る)です。
Saint-Andre, Ed. Standards Track [Page 4] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[4ページ]RFC3920XMPPコア2004年10月
3. Addressing Scheme
3. アドレシング体系
3.1. Overview
3.1. 概要
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を使用することで交信できる何かです。 そのようなすべての実体がRFC2396[URI]と一致したフォームで唯一アドレス可能です。 歴史的な理由で、XMPP実体のアドレスはJabber IdentifierかJIDと呼ばれます。 有効なJIDはドメイン識別子、ノード識別子、およびリソース識別子について形成された1セットの規則正しい要素を含んでいます。
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].)
[ABNF]で定義されるようにAugmented BN記法を使用する下でJIDのための構文は定義されます。 ( IPv4addressとIPv6address規則はIPv6のAppendix Bで定義されます; ノード規則に従う許容できるキャラクタシーケンスはこのメモのAppendix Aの記録されるとしてのSTRINGPREPのNodeprepプロフィールによって定義されます; リソース規則に従う許容できるキャラクタシーケンスはこのメモのAppendix 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*、(「. 」 サブドメイン) サブドメイン=(ドメインラベルを国際的にします)アドレスリテラル=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).
すべてのJIDsが以上の構造に基づいています。 この構造の最も一般の使用がフォーム of <user@host/resource でインスタントメッセージングユーザ、ユーザが接続するサーバ、およびユーザの接続リソース(例えば、特定のクライアント)を特定することである、gt。 しかしながら、クライアント以外のノード種別は可能です。 例えば、 as <room@service であるとマルチユーザチャットサービスで提供された特定のチャットルームを扱うことができた、gt;、(「余地」がチャットルームの名前であり、「サービス」がマルチユーザチャットサービスのホスト名であるところ)、 as <room@service/nick であることをそのような部屋の特定の占有者を宛てることができた、gt;、(「刻み目」が占有者の余地のあだ名であるところ。) 他の多くの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(ノード識別子、ドメイン識別子、およびリソース識別子)のそれぞれの許容できる部分は長さが1023バイト以上であるはずがありません、最大3071バイトの総サイズ('@'と'/'分離符を含んでいる)をもたらして。
Saint-Andre, Ed. Standards Track [Page 5] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[5ページ]RFC3920XMPPコア2004年10月
3.2. Domain Identifier
3.2. ドメイン識別子
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の唯一のREQUIRED要素(単なるドメイン識別子は有効な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.
aが完全修飾ドメイン名であったなら、ネットワークの上で伝えるあらゆるサーバかサービスのためのドメイン識別子は、IPアドレスにもかかわらず、SHOULDであるかもしれません([DNS]を見てください)。 ドメイン識別子は[IDNA](失敗しないで、stringprep[STRINGPREP]のNameprep[NAMEPREP]プロフィールを適用できる)で定義されるように「国際化ドメイン名」であるに違いありません。 2つのドメイン識別子を比較する前に、サーバは最初に、各識別子を作るラベル([IDNA]で定義されるように)へのNameprepプロフィールを当てはまらなければなりません(そして、クライアントSHOULD)。
3.3. Node Identifier
3.3. ノード識別子
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」と呼ばれて、 form <node@domain のものである、gt。
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プロフィールを当てはまらなければなりません(そして、クライアントSHOULD)。
3.4. Resource Identifier
3.4. リソース識別子
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
'リソース識別子はドメイン識別子の後に置かれて、'/'キャラクタによって後者と切り離された任意の第三の識別子です。 リソース識別子が a <node@domain を変更するかもしれない、gt;、または、単なる<ドメイン>アドレス。 通常、それは、ノード識別子に関連している実体に属しながら、特定のセッション、接続(例えば、デバイスか位置)、またはオブジェクト(例えば、マルチユーザチャットルームの関係者)の代理をします。 リソース識別子は不明瞭です。
Saint-Andre, Ed. Standards Track [Page 6] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[6ページ]RFC3920XMPPコア2004年10月
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.
サーバと他のクライアントの両方、それが「接続リソース」と呼ばれるResource Binding(セクション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つのリソース識別子を比較する前に、サーバは最初に、各識別子へのResourceprepプロフィールを当てはまらなければなりません(そして、クライアントSHOULD)。
3.5. Determination of Addresses
3.5. アドレスの決断
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)と適切でありResource Binding(セクション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).
サーバからサーバへのコミュニケーションとして、開始実体のJID SHOULDが承認のアイデンティティであって、認証のアイデンティティから派生されていて、アイデンティティは承認でないならSASL交渉(セクション6)の間、Simple AuthenticationとSecurity Layer(SASL)仕様[SASL]で定義されるように指定されました。
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).
クライアントからサーバへのコミュニケーション、「むき出しのJID」 (<node@domain 、gt;、)、承認のアイデンティティであって、承認のアイデンティティが全くSASL交渉の間、指定されなかったなら[SASL]で定義されるように認証のアイデンティティから派生しているSHOULD(セクション6)。 「完全なJID」 (<node@domain/resource のリソース識別子一部、gt;、)、SHOULD、Resource Binding(セクション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(ノード識別子、ドメイン識別子、リソース識別子、および分離符キャラクタを含んでいる)が、より早くこのセクションで定義された規則と書式に従うのを確実にしなければなりません。 この制限を満たすために、受信実体は、canonicalized JIDが受信実体で断固としていた状態で開始実体によって送られたJIDを取り替える必要があるかもしれません。
4. XML Streams
4. XMLストリーム
4.1. Overview
4.1. 概要
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:
2つの基本概念で、構造化された情報の比較的わずかなペイロードの急速で、非同期な交換は存在意識している実体の間で可能になります: XMLストリームとXMLスタンザ。 これらの用語は以下の通り定義されます:
Saint-Andre, Ed. Standards Track [Page 7] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[7ページ]RFC3920XMPPコア2004年10月
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</ストリーム>タグによって指示されますが。 ストリームの寿命の間、それを開始した実体は限りない数のXML要素をストリームの上に送ることができます、ストリームを交渉するのに使用される(例えばTLSのUse(セクション5)かSASLの使用(セクション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ストリームの上で1つの実体から別のものに送られる構造化された情報の離散的な意味ユニットです。 XMLスタンザは、根の<ストリーム/>要素のダイレクト子供レベルで存在していて、[XML]の生産[43]内容を合わせるなら、バランスが良いと言われます。 どんなXMLスタンザの始まりも明白にXMLストリーム(例えば、<存在>)の深さ=1つにおける要素開始タグによって指示されます、そして、どんなXMLスタンザの終わりも明白に対応する近いタグによって深さ=1(例えば、</存在>)で指示されます。 XMLスタンザは、必要な情報を伝えるために、必要に応じて、子供要素(付随の属性、要素、およびXMLキャラクタデータがある)を含むかもしれません。 ここに定義された唯一のXMLスタンザが、要素がデフォルト名前空間でストリームの資格を与えた<メッセージ/>と、<存在/>と、<iq/>です、XML Stanzas(セクション9)の下で説明されるように。 XML要素はTransport Layer Security(TLS)交渉(セクション5)、Simple Authentication、およびSecurity Layer(SASL)交渉(セクション6)、または(セクション8)がXMLスタンザであることは考えられないサーバdialbackの目的のために発信しました。
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
サーバとのクライアントのセッションに関する例を考えてください。サーバに接続するために、クライアントはXMLバージョンを指定して、文字符号化がサポートしたテキスト宣言で任意に先行されたサーバに初めの<ストリーム>タグを送ることによって、XMLストリームを開始しなければなりません(Text Declaration(セクション11.4)のInclusionを見てください; また、キャラクターEncoding(セクション11.5)を見てください)。 次にSHOULDが返答するローカルの方針とサービスの食糧を供給するサーバを条件として
Saint-Andre, Ed. Standards Track [Page 8] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[8ページ]RFC3920XMPPコア2004年10月
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.
テキスト宣言で再び任意に先行されたクライアントへの2番目のXMLストリーム。 クライアントがいったん、SASL交渉(セクション6)を終了すると、クライアントはネットワークで限りない数のXMLスタンザをどんな受取人へのストリームの上にも送るかもしれません。 クライアントが、ストリームを閉じることを望んでいるとき、それは単にサーバ(あるいはまた、ストリームはサーバによって閉じられるかもしれない)に終わりの</ストリーム>タグを送ります。(その時、クライアントとサーバSHOULDの両方がまた、基本的な接続(通常TCP接続)を終えました後)。
Those who are accustomed to thinking of XML in a document-centric manner may wish to view a client's session with a server as consisting of two open-ended XML documents: one from the client to the server and one from the server to the client. From this perspective, the root <stream/> element can be considered the document entity for each "document", and the two "documents" are built up through the accumulation of XML stanzas sent over the two XML streams. However, this perspective is a convenience only; XMPP does not deal in documents but in XML streams and XML stanzas.
ドキュメント中心の方法でXMLを考えるのに慣れている人は2通の制限のないXMLドキュメントから成るとサーバとのクライアントのセッションをみなしたがっているかもしれません: クライアントからサーバまでの1とサーバからクライアントまでの1。 この見解から、各「ドキュメント」のためのドキュメント実体であると根の<ストリーム/>要素を考えることができます、そして、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> | |--------------------|
|--------------------| | <ストリーム>。| |--------------------| | <存在>。| | <ショー/>。| | </存在>。| |--------------------| | 'foo'>'と等しい<メッセージ| | <ボディー/>。| | </メッセージ>。| |--------------------| | 'バー'>'と等しい<iq| | <質問/>。| | </iq>。| |--------------------| | ... | |--------------------| | </ストリーム>。| |--------------------|
Saint-Andre, Ed. Standards Track [Page 9] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[9ページ]RFC3920XMPPコア2004年10月
4.2. Binding to TCP
4.2. TCPに付きます。
Although there is no necessary coupling of an XML stream to a [TCP] connection (e.g., two entities could connect to each other via another mechanism such as polling over [HTTP]), this specification defines a binding of XMPP to TCP only. In the context of client-to-server communications, a server MUST allow a client to share a single TCP connection for XML stanzas sent from client to server and from server to client. In the context of server-to-server communications, a server MUST use one TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections.
[TCP]接続へのXMLストリームのどんな必要なカップリングもありませんが([HTTP]の上の世論調査などの別のメカニズムで例えば2つの実体が互いに接できるでしょう)、この仕様はXMPPの結合をTCPだけと定義します。 クライアントからサーバへのコミュニケーションの文脈では、サーバで、クライアントはクライアントからサーバまでサーバからクライアントに送られたXMLスタンザのための単独のTCP接続を共有できなければなりません。 サーバからサーバへのコミュニケーションの文脈では、サーバはスタンザのために同輩と別のサーバからTCP接続に送られた(同輩によって開始されます)XMLスタンザに同輩からサーバまで1つのTCP接続を使用しなければなりません、合計2つのTCP接続のために。
4.3. Stream Security
4.3. ストリームセキュリティ
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)).
定義されるとして使用されてください。交渉するとき、XMLはXMPP1.0を流れます、TLS SHOULD、TLS(セクション5)のUseとSASL MUSTの下では、SASL(セクション6)のUseの下で定義されるように使用されてください。 別々に、「初期のストリーム」(すなわち、開始実体から受信実体までのストリーム)と「応答ストリーム」(すなわち、受信実体から開始実体までのストリーム)を機密保護しなければなりません、両方の方向におけるセキュリティは互いの認証を提供するメカニズムで確立されるかもしれませんが。 ストリームの前にXML Stanzas(セクション9)をストリームの上に送る実体SHOULD NOT試みが認証されましたが、次に、そうするなら、もう片方の実体がそのようなスタンザを受け入れてはいけなくて、SHOULDは認可されなかった</>ストリーム誤りを返して、次に、XMLストリームと基本的なTCP接続の両方を終えます。 これがストリーム交渉に使用されるXML要素ではなく、XMLスタンザ(すなわち、デフォルト名前空間によって見られた<メッセージ/>、<存在/>、および<iq/>要素)だけに適用されることによく注意してください(例えば、要素は以前は、よくTLSのUse(セクション5)かSASLのUse(セクション6)を交渉していました)。
4.4. Stream Attributes
4.4. ストリーム属性
The attributes of the stream element are as follows:
ストリーム要素の属性は以下の通りです:
o to -- The 'to' attribute SHOULD be used only in the XML stream
header from the initiating entity to the receiving entity, and
MUST be set to a hostname serviced by the receiving entity. There
SHOULD NOT be a 'to' attribute set in the XML stream header by
which the receiving entity replies to the initiating entity;
however, if a 'to' attribute is included, it SHOULD be silently
ignored by the initiating entity.
o --'to'属性SHOULDはXMLストリームヘッダーだけで開始実体から受信実体まで使用されて、受信実体によって修理されたホスト名に用意ができなければなりません。 そこ、SHOULD NOT、受信実体が開始実体に答えるXMLストリームヘッダーに設定された'to'属性になってください。 しかしながら、'to'であるなら、属性は含まれていて、それはSHOULDです。開始実体によって静かに無視されます。
Saint-Andre, Ed. Standards Track [Page 10] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[10ページ]RFC3920XMPPコア2004年10月
o from -- The 'from' attribute SHOULD be used only in the XML stream
header from the receiving entity to the initiating entity, and
MUST be set to a hostname serviced by the receiving entity that is
granting access to the initiating entity. There SHOULD NOT be a
'from' attribute on the XML stream header sent from the initiating
entity to the receiving entity; however, if a 'from' attribute is
included, it SHOULD be silently ignored by the receiving entity.
o --'from'属性SHOULDはXMLストリームヘッダーだけで受信実体から開始実体まで使用されて、開始実体へのアクセスを承諾している受信実体によって修理されたホスト名に用意ができなければなりません。 そこ、SHOULD NOT、開始実体から受信実体に送られたXMLストリームヘッダーの'from'属性になってください。 しかしながら、'from'であるなら、属性は含まれていて、それはSHOULDです。受信実体によって静かに無視されます。
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 'イド'はSHOULDを結果と考えます。イド--、XMLストリームヘッダーだけで受信実体から開始実体まで使用されてください。 この属性は開始実体のものに、主要なセッションが受信実体であふれて、受信アプリケーションの中でユニークであるに違いないので受信実体によって作成された、機能したユニークな識別子(通常サーバ)です。 ストリームIDがセキュリティ重要であるかもしれなく、したがって、ともに予測できるはずがなくて、非反復されていることによく注意してください(セキュリティ目的のために推薦に関して偶発性に関して[RANDOM]を見てください)。 そこ、SHOULD NOT、開始実体から受信実体に送られたXMLストリームヘッダーの'イド'属性になってください。 しかしながら、'イド'であるなら、属性は含まれていて、それはSHOULDです。受信実体によって静かに無視されます。
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キャラクタデータのデフォルト言語も指定するヘッダーの上の開始実体でSHOULDを結果と考えます([XML]のセクション2.12で定義されるように)。 属性が含まれているなら、受信実体SHOULDは初期のストリームと応答ストリームの両方のためのデフォルトとしてその値を覚えています。 属性が含まれていないなら、受信実体SHOULDは両方のストリームに構成可能なデフォルト値を使用します。(それは応答ストリームのためにヘッダーでストリームを伝えなければなりません)。 開始実体が'xml: lang'属性を含んでいないなら初期のストリームの上に送られたすべてのスタンザのために、受信実体SHOULDはデフォルト値を適用します。 開始実体が'xml: lang'属性を含んでいるなら、受信実体は、それを変更してはいけませんし、また削除してはいけません(xmlも: lang(セクション9.1.5)を見てください)。 'xml: lang'属性の値は、NMTOKENでなければならなく([XML]のセクション2.3で定義されるように)、RFC3066[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インチの信号サポート」の値にセットしました。 この属性の世代と取り扱いに関する細則は以下で定義されます。
Saint-Andre, Ed. Standards Track [Page 11] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[11ページ]RFC3920XMPPコア2004年10月
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
| 受信への開始| 開始に、受信します。---------+---------------------------+----------------------- to| 受信機に関するホスト名| 静かに無視されます。| 静かに無視されます。| 受信機イドに関するホスト名| 静かに無視されます。| セッションの主要なxml: lang| デフォルト言語| デフォルト言語バージョン| XMPP1.0が支える信号| XMPP1.0が支える信号
4.4.1. Version Support
4.4.1. バージョンサポート
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インチ」です。 特に、これは(TLS(セクション5)、SASLのUse(セクション6)、およびStream Errors(セクション4.7)の使用)、および3つのものの意味論が定義したストリーム関連のプロトコルにXMLスタンザタイプ(<メッセージ/>、<存在/>、および<iq/>)をカプセル化します。 XMPPバージョンのためのナンバリングスキームはそうです。「<の主要な><の小さい方の>。」 主要で小さい方の数を別々の整数として扱わなければなりません、そして、各数は一桁より高く増加されるかもしれません。 このようにして、「XMPP、2.4インチが低いバージョンであるだろう、「XMPP、どれが順番に何2.13インチも、低いだろうか、「XMPP、12.3インチ」 先行ゼロ、(例えば、「XMPP、6.01インチ) 必須を受取人が無視して、送ってはいけない、」
The major version number should be incremented only if the stream and stanza formats or required actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions specified in the older specification. The minor version number indicates new capabilities, and MUST be ignored by an entity with a smaller minor version number, but used for informational purposes by the entity with the larger minor version number. For example, a minor version number might indicate the ability to process a newly defined value of the 'type' attribute for message, presence, or IQ stanzas; the entity with the larger minor version number would simply note that its correspondent would not be able to understand that value of the 'type' attribute and therefore would not send it.
ストリームとスタンザ形式か必要な動作が、それが単に要素と属性を無視したかどうかを旧式のバージョン実体が、より新しいバージョン実体で共同利用できないくらいの劇的に変えたので、分からないで、より古い仕様で指定された行動を取る場合にだけ、メジャーバージョン番号は増加されるでしょうに。 マイナーバージョン番号を新しい能力を示して、よりわずかなマイナーバージョン番号がある実体によって無視されますが、情報の目的により大きいマイナーバージョン番号がある実体で使用しなければなりません。 例えば、マイナーバージョン番号はメッセージ、存在、またはIQスタンザのために'タイプ'属性の新たに定義された値を処理する能力を示すかもしれません。 より大きいマイナーバージョン番号がある実体は、通信員が'タイプ'属性のその値を理解できないことに単に注意して、したがって、それを送らないでしょう。
The following rules apply to the generation and handling of the 'version' attribute within stream headers by implementations:
以下の規則はストリームヘッダーの中に実装によって'バージョン'属性の世代と取り扱いに適用されます:
1. The initiating entity MUST set the value of the 'version'
attribute on the initial stream header to the highest version
number it supports (e.g., if the highest version number it
supports is that defined in this specification, it MUST set the
value to "1.0").
1. 開始実体は初期のストリームヘッダーの'バージョン'属性の値をサポートする中で最も大きいバージョン番号に設定しなければなりません。(それが例えば、サポートする中で最も大きいバージョン番号がそうなら中でこの仕様を定義した、値を設定しなければならない、「1インチ)」
Saint-Andre, Ed. Standards Track [Page 12] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[12ページ]RFC3920XMPPコア2004年10月
2. The receiving entity MUST set the value of the 'version'
attribute on the response stream header to either the value
supplied by the initiating entity or the highest version number
supported by the receiving entity, whichever is lower. The
receiving entity MUST perform a numeric comparison on the major
and minor version numbers, not a string match on
"<major>.<minor>".
2. 受信実体は開始実体によって供給された値か受信実体によってサポートされる中で最も大きいバージョン番号のどちらかに応答ストリームヘッダーの'バージョン'属性の値を設定しなければなりません、どれが低くても。 受信実体は「<の主要な><の小さい方の>」のストリングマッチではなく、主要で小さい方のバージョン番号における数値比較を実行しなければなりません。
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つの主要なバージョンであるなら、開始実体SHOULDは<のサポートされないバージョン/>がストリーム誤りであると生成して、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インチ、'中では、それが回答で送るストリームヘッダーを結果と考える」というNOTインクルードa'バージョンはそうするべきです。
4.5. Namespace Declarations
4.5. 名前空間宣言
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]に基づき定義されるとき)。 ストリーム名前空間とデフォルト名前空間の詳細な情報に関しては、Namespace NamesとPrefixes(セクション11.2)を見てください。
4.6. Stream Features
4.6. ストリーム機能
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インチ、受信実体は交渉できるどんなストリームレベル機能(または、そうでなければ広告を出す必要がある能力)も発表するために、<特徴/>子供要素(ストリーム名前空間接頭語で、前に置かれている)を開始実体に送らなければならない」値にセットしてください。 現在、これはここに、そして、および[XMPP-IM]で定義されるSession特権階級のために定義されるように使用されますが、TLSのUse(セクション5)、SASLのUse(セクション6)、およびResource Binding(セクション7)の広告を出します。 しかしながら、将来他の交渉可能な特徴の広告を出すのにストリーム特徴の機能性を使用できました。 実体は、いくつかの特徴を理解もしていませんし、サポートもしないで、それはSHOULDです。静かにそれらを無視してください。 非セキュリティ関連の特徴(例えば、Resource Binding)を提供できる前の(例えば、TLSとSASL)が首尾よく交渉されるために必要とする1つ以上のセキュリティ機能、非セキュリティ関連の特徴SHOULD NOTが含まれているなら、以前広告に掲載されるストリーム機能では、関連セキュリティ機能は交渉されました。
Saint-Andre, Ed. Standards Track [Page 13] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[13ページ]RFC3920XMPPコア2004年10月
4.7. Stream Errors
4.7. ストリーム誤り
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.
根のストリーム要素はストリーム名前空間接頭語によって前に置かれている<誤り/>子供要素を含むかもしれません。 それが、ストリームレベル誤りが発生したと知覚するなら、対応する実体(通常クライアントよりむしろサーバ)で誤り子供を送らなければなりません。
4.7.1. Rules
4.7.1. 規則
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接続を終えなければなりません。 この場合、開始実体が'to'属性(または、'to'属性を全く提供しない)に未知のホストを提供するなら、サーバSHOULDは終了の前に送られたストリームヘッダーの'from'属性にサーバの正式のホスト名を提供します。
4.7.2. Syntax
4.7.2. 構文
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は'つぼ:ietf:params:xml:ナノ秒: xmpp-ストリーム'/><テキストxmlns='つぼ:ietf:params:xml:ナノ秒: xmpp-ストリーム'xml: langは'langcode'>OPTIONAL説明文</テキスト>[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:ナノ秒: xmpp-ストリーム'名前空間でこの要素に資格がなければなりません。
Saint-Andre, Ed. Standards Track [Page 14] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[14ページ]RFC3920XMPPコア2004年10月
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:ナノ秒: xmpp-ストリーム'名前空間でこの要素に資格がなければなりません、そして、SHOULDには、XMLキャラクタデータの自然言語を指定する'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).
<テキスト/>要素はOPTIONALです。 含まれているならそれ、SHOULD、使用されて、単に定義された状態かアプリケーション特有の状態の意味をそれが補う描写的であるか診断している情報に提供してください。 それ、SHOULD NOT、アプリケーションでプログラムに基づいて解釈されてください。 それ、SHOULD NOTはユーザに提示されたエラーメッセージとして使用されますが、含まれている状態要素(または、要素)に関連しているエラーメッセージに加えて見せられるかもしれません。
4.7.3. Defined Conditions
4.7.3. 定義された状態
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整形式でない/>、より特定の誤りは好まれますが。
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 Namespace NamesとPrefixes(セクション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 <ホストが過ぎ去った/>--ストリームヘッダーの開始実体によって提供された'to'属性の値はもうサーバによってホスティングされないホスト名に対応しています。
Saint-Andre, Ed. Standards Track [Page 15] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[15ページ]RFC3920XMPPコア2004年10月
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 未知の<ホスト/>--ストリームヘッダーの開始実体によって提供された'to'属性の値はサーバによってホスティングされるホスト名と食い違っています。
o <improper-addressing/> -- a stanza sent between two servers lacks
a 'to' or 'from' attribute (or the attribute has no value).
o <の不適当なアドレシング/>--2つのサーバの間に送られたスタンザは'to'か'from'属性を欠いています(属性に、値が全くありません)。
o <internal-server-error/> -- the server has experienced a
misconfiguration or an otherwise-undefined internal error that
prevents it from servicing the stream.
o <内部サーバーエラー/>--サーバはmisconfigurationかそれがストリームを修理するのを防ぐそうでなければ、未定義の内部エラーになりました。
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 <病人、-、/>--'from'アドレスに提供されたJIDかホスト名がSASLを通したサーバの間、または、dialbackか認証とリソース結合を通したクライアントとサーバの間で交渉された認可されたJIDか有効にされたドメインに合っていません。
o <invalid-id/> -- the stream ID or dialback ID is invalid or does
not match an ID previously provided.
o <の無効のイド/>--ストリームIDかdialback 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 "を除いて、ストリーム名前空間名は何かであるか「おしゃべり:サーバ:dialback」を除いて、dialback名前空間名は何か(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を送りました(Validation(セクション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 <リソース規制/>--サーバはストリームを修理するのに必要なシステム資源を欠いています。
Saint-Andre, Ed. Standards Track [Page 16] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[16ページ]RFC3920XMPPコア2004年10月
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、実体参照、または非エスケープしているキャラクタなどの制限されたXMLの特徴を送るのを試みました(Restrictions(セクション11.1)を見てください)。
o <see-other-host/> -- the server will not provide service to the
initiating entity but is redirecting traffic to another host; the
server SHOULD specify the alternate hostname or IP address (which
MUST be a valid domain identifier) as the XML character data of
the <see-other-host/> element.
o <が他のホストを見ている/>--サーバは、開始実体に対するサービスを提供しませんが、別のホストにトラフィックを向け直しています。 サーバSHOULDは<が他のホストを見ている/>要素に関する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 <の未定義の状態/>--エラー条件はこのリストの他の状態によって定義されたものの1つではありません。 このエラー条件SHOULD、単にアプリケーション特有の状態に関連して、使用されてください。
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 <のサポートされないコード化/>--開始実体はサーバによってサポートされないコード化におけるストリームをコード化しました(キャラクターEncoding(セクション11.5)を見てください)。
o <unsupported-stanza-type/> -- the initiating entity has sent a
first-level child of the stream that is not supported by the
server.
o <のサポートされないスタンザタイプ/>--開始実体はサーバによってサポートされないストリームの最初に、レベル子供を送りました。
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を送りました。
4.7.4. Application-Specific Conditions
4.7.4. アプリケーション一定の条件
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:
注意されるように、アプリケーションは誤り要素に適切にnamespacedされた子供を含んでいることによって、アプリケーション特有のストリームエラー情報を提供するかもしれません。 アプリケーション特有の要素SHOULDは定義された要素に補うか、またはさらに、資格を与えます。 したがって、<誤り/>要素は2か3つの子供要素を含むでしょう:
Saint-Andre, Ed. Standards Track [Page 17] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[17ページ]RFC3920XMPPコア2004年10月
<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はつぼ:ietf:params: 'つぼ:ietf:params:xml:ナノ秒: xmpp-ストリーム'/><テキストxml: langは'アンと等しく'xmlns='xmlと等しいです: ナノ秒: xmpp-ストリーム'>のSomeの特別なアプリケーション診断情報!' 'アプリケーションナノ秒'<があなたのデータから逃げている</テキスト>xmlns=/></ストリーム: 誤り></ストリーム: ストリーム>。
4.8. Simplified Stream Examples
4.8. 簡易型のストリームの例
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」系列をサーバからクライアントに送るところ)のクライアントのストリームベースの「セッション」に関する2つの簡単な例を含みます。 これらの例はこれまでのところ紹介された概念を例証する目的のために含まれています。
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'?><ストリーム: 'example.com'xmlns='おしゃべり: クライアント'xmlnsと等しいには、流れてください: ストリーム=' http://etherx.jabber.org/streams 'バージョンは'1.0'>Sと等しいです'。 <?xmlバージョン= '1.0'?><ストリーム: ='example.com'イド='someid'xmlns='おしゃべりからのストリーム: クライアント'xmlns: ストリーム=' http://etherx.jabber.org/streams 'バージョン='1.0 '>…暗号化、認証、およびリソース結合' C: =' juliet@example.com からの<メッセージ('=' romeo@example.net 'xmlに: langは'アン'>Cと等しいです') <は>Artをロメオではなく、なんじ、およびモンターグ?</ボディー>Cで具体化させます: </メッセージ>S: =' romeo@example.net からの<メッセージ('=' juliet@example.com 'xmlに: langは'アン'>Sと等しいです') <ボディー>Neither、公正な聖者は. </ボディー>Sが嫌であってください: </メッセージ>C: </ストリーム: >Sを流してください: </ストリーム: ストリーム>。
Saint-Andre, Ed. Standards Track [Page 18] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[18ページ]RFC3920XMPPコア2004年10月
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'?><ストリーム: 'example.com'xmlns='おしゃべり: クライアント'xmlnsと等しいには、流れてください: ストリーム=' http://etherx.jabber.org/streams 'バージョンは'1.0'>Sと等しいです'。 <?xmlバージョン= '1.0'?><ストリーム: ='example.com'イド='someid'xmlns='おしゃべりからのストリーム: クライアント'xmlns: ストリーム=' http://etherx.jabber.org/streams 'バージョン='1.0 '>…暗号化、認証、およびリソース結合' C: <メッセージxml: lang='アン'><ボディー>Bad XML、終わりのボディータグがありません!' </メッセージ>S: <ストリーム: 誤り><xml整形式でないxmlns'=つぼ:ietf:params:xml:ナノ秒: xmpp-ストリーム'/></ストリーム: 誤り>S: </ストリーム: ストリーム>。
5. Use of TLS
5. TLSの使用
5.1. Overview
5.1. 概要
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は改ざんと盗聴からのストリームを保証するためのメソッドを含んでいます。 このチャンネル暗号化メソッドはTransport Layer Security(TLS)プロトコル[TLS]を利用します、RFC2595[USINGTLS]で説明されるようにIMAP[IMAP]、POP3[POP3]、およびACAP[ACAP]プロトコルのための同様の拡大に倣われる「STARTTLS」拡大と共に。 STARTTLS拡張子のための名前空間名はそうです。'つぼ:ietf:params:xml:ナノ秒: 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のクライアントからサーバへのコミュニケーション、サーバからサーバへのコミュニケーション、または両方の使用を必要とするかもしれません。 クライアントSHOULDはSASL交渉(セクション6)の完成を試みる前にストリームを保証するのにTLSを使用します、そして、サーバSHOULDはサーバからサーバへのコミュニケーションを保証する目的に2つのドメインの間のTLSを使用します。
Saint-Andre, Ed. Standards Track [Page 19] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[19ページ]RFC3920XMPPコア2004年10月
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インチ」の値に'バージョン'属性セットを含まなければなりません。
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)ホスト名が決議されるまで(ServerからサーバへのCommunications(セクション14.4)を見てください)、コミュニケーションは続いてはいけません。
3. When a receiving entity that complies with this specification
receives an initial stream header that includes the 'version'
attribute set to a value of at least "1.0", after sending a
stream header in reply (including the version flag), it MUST
include a <starttls/> element (qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list
of other stream features it supports.
3. この仕様に従う受信実体が受信されるとき、'バージョン'属性を含んでいる初期のストリームヘッダーは少なくとも「1インチ、回答(バージョン旗を含んでいる)でストリームヘッダーを送った後に、それがサポートする他のストリーム機能のリストに伴う<starttls/>要素('つぼ:ietf:params:xml:ナノ秒: xmpp-tls'名前空間で、資格がある)を含まなければならない」値にセットしました。
4. If the initiating entity chooses to use TLS, TLS negotiation MUST
be completed before proceeding to SASL negotiation; this order of
negotiation is required to help safeguard authentication
information sent during SASL negotiation, as well as to make it
possible to base the use of the SASL EXTERNAL mechanism on a
certificate provided during prior TLS negotiation.
4. 開始実体が、TLSを使用するのを選ぶなら、SASL交渉に続く前に、TLS交渉を終了しなければなりません。 SASL交渉の間に送られた認証情報を保護しているのを助けて、SASL EXTERNALメカニズムの使用を先のTLS交渉の間に提供された証明書に基礎づけるのを可能にするように交渉のこの注文を必要とします。
5. During TLS negotiation, an entity MUST NOT send any white space
characters (matching production [3] content of [XML]) within the
root stream element as separators between elements (any white
space characters shown in the TLS examples below are included for
the sake of readability only); this prohibition helps to ensure
proper security layer byte precision.
5. TLS交渉の間、実体は分離符として根のストリーム要素の中で少しの余白キャラクタ([XML]の合っている生産[3]内容)も要素の間に送ってはいけません(以下のTLSの例に示されたどんな余白キャラクタも読み易さだけのために含まれています)。 この禁止は、適切なセキュリティ層のバイト精度を確実にするのを助けます。
6. The receiving entity MUST consider the TLS negotiation to have
begun immediately after sending the closing ">" character of the
<proceed/> element. The initiating entity MUST consider the TLS
negotiation to have begun immediately after receiving the closing
">" character of the <proceed/> element from the receiving
entity.
6. 受信実体は、TLSが<のキャラクタが続かせる終わりの">"/>要素を送る直後始めた交渉であると考えなければなりません。 開始実体は、TLSが受信実体から<のキャラクタが続かせる終わりの">"/>要素を受け取る直後始めた交渉であると考えなければなりません。
7. The initiating entity MUST validate the certificate presented by
the receiving entity; see Certificate Validation (Section 14.2)
regarding certificate validation procedures.
7. 開始実体は受信実体によって提示された証明書を有効にしなければなりません。 証明書合法化手順に関してCertificate Validation(セクション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]ルックアップは戻りました。
Saint-Andre, Ed. Standards Track [Page 20] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[20ページ]RFC3920XMPPコア2004年10月
"im.example.com", the certificate MUST be checked as
"example.com". If a JID for any kind of XMPP entity (e.g.,
client or server) is represented in a certificate, it MUST be
represented as a UTF8String within an otherName entity inside the
subjectAltName, using the [ASN.1] Object Identifier
"id-on-xmppAddr" specified in Section 5.1.1 of this document.
"im.example.com"、"example.com"として証明書をチェックしなければなりません。 どんな種類のXMPP実体(例えば、クライアントかサーバ)のためのJIDも証明書に表されるなら、UTF8StringとしてsubjectAltNameの中のotherName実体の中にそれを表さなければなりません、この.1通のセクション5.1ドキュメントで指定された[ASN.1]オブジェクトIdentifier「xmppAddrの上のイド」を使用して。
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. サポートしなければならないメカニズムに関してMandatoryから道具へのTechnologies(セクション14.7)を見てください。
5.1.1. ASN.1 Object Identifier for XMPP Address
5.1.1. XMPPアドレスのためのASN.1オブジェクト識別子
The [ASN.1] Object Identifier "id-on-xmppAddr" described above is defined as follows:
上で説明された[ASN.1]オブジェクトIdentifier「xmppAddrの上のイド」は以下の通り定義されます:
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms
イドオンなOBJECT IDENTIFIER:、:= イド-pkix8--他の名前フォーム
id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }
xmppAddrの上のイドオブジェクト識別子:、:= イドオンな5
XmppAddr ::= UTF8String
XmppAddr:、:= UTF8String
This Object Identifier MAY also be represented in the dotted display format as "1.3.6.1.5.5.7.8.5".
また、このObject Identifierが点を打つのが書式を表示する表されたコネであるかもしれない、「1.3 .6 .1 .5 .5 .7 .8 0.5インチ」
Saint-Andre, Ed. Standards Track [Page 21] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[21ページ]RFC3920XMPPコア2004年10月
5.2. Narrative
5.2. 物語
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. 開始実体は、初めのXMLストリームヘッダーを受信実体に送ることによって、TCP接続を開いて、ストリームを開始します、少なくとも属性が値にセットした'バージョン'「1インチ」を含んでいて。
2. The receiving entity responds by opening a TCP connection and
sending an XML stream header to the initiating entity, including
the 'version' attribute set to a value of at least "1.0".
2. 受信実体は開始実体にTCP接続を開いて、XMLストリームヘッダーを送ることによって、応じます、少なくとも属性が値にセットした'バージョン'「1インチ」を含んでいて。
3. The receiving entity offers the STARTTLS extension to the
initiating entity by including it with the list of other
supported stream features (if TLS is required for interaction
with the receiving entity, it SHOULD signal that fact by
including a <required/> element as a child of the <starttls/>
element).
3. 受信実体が他のサポートしているストリーム機能のリストでそれを含んでいることによってSTARTTLS拡張子を開始実体に提供する、(TLSが受信実体との相互作用に必要であり、それが<を含んでいるのによる事実が<starttls/>要素の子供として/>要素を必要としたというSHOULD信号である、)
4. The initiating entity issues the STARTTLS command (i.e., a
<starttls/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the
receiving entity that it wishes to begin a TLS negotiation to
secure the stream.
4. 開始実体はストリームを保証するためにTLS交渉を始めたがっているよう受信実体に命令するSTARTTLSコマンド(すなわち、<starttls/>要素は'つぼ:ietf:params:xml:ナノ秒: xmpp-tls'名前空間で資格を得た)を発行します。
5. The receiving entity MUST reply with either a <proceed/> element
or a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case
occurs, the receiving entity MUST terminate both the XML stream
and the underlying TCP connection. If the proceed case occurs,
the entities MUST attempt to complete the TLS negotiation over
the TCP connection and MUST NOT send any further XML data until
the TLS negotiation is complete.
5. 受信実体は続かなければなりません。<との回答は'つぼ:ietf:params:xml:ナノ秒: xmpp-tls'名前空間によって資格があった/>要素か<失敗/>要素を続かせます。 失敗事件が起こるなら、受信実体は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ストリームヘッダーを受信実体に送ることによって、新しいストリームを開始しなければなりません(最初に終わりの</ストリーム>タグを送るのが必要でない、受信以来、存在と実体を開始するのはオリジナルのストリームがうまくいっているTLS交渉のときに閉じられると考えなければなりません)。
Saint-Andre, Ed. Standards Track [Page 22] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[22ページ]RFC3920XMPPコア2004年10月
8. Upon receiving the new stream header from the initiating entity,
the receiving entity MUST respond by sending a new XML stream
header to the initiating entity along with the available features
(but not including the STARTTLS feature).
8. 開始実体から新しいストリームヘッダーを受けると、受信実体は、新しいXMLストリームヘッダーを利用可能な特徴に伴う開始実体に送ることによって、応じなければなりません(STARTTLSの特徴を含んでいませんが)。
5.3. Client-to-Server Example
5.3. クライアントからサーバへの例
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: 'example.com'バージョン='1.0'>と等しいように=' http://etherx.jabber.org/streams 'を流してください'と等しいです。
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 'イド='c2s_123'='example.com'バージョンは'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='つぼ:ietf:params: xml:ナノ秒:xmpp-tls'><は/></starttls><メカニズムxmlns='つぼ:ietf:params:xml:ナノ秒: 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='つぼ:ietf:params:xml:ナノ秒: xmpp-tls'/>。
Saint-Andre, Ed. Standards Track [Page 23] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[23ページ]RFC3920XMPPコア2004年10月
Step 5: Server informs client that it is allowed to proceed:
ステップ5: サーバは、続くことができることをクライアントに知らせます:
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<はxmlns='つぼ:ietf:params:xml:ナノ秒: 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='つぼ:ietf:params:xml:ナノ秒: 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: 'example.com'バージョン='1.0'>と等しいように=' http://etherx.jabber.org/streams 'を流してください'と等しいです。
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>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='c2s_234' version='1.0'> <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> <mechanism>EXTERNAL</mechanism> </mechanisms> </stream:features>
Step 9: Client continues with SASL negotiation (Section 6).
ステップ9: クライアントはSASL交渉(セクション6)を続行します。
Saint-Andre, Ed. Standards Track [Page 24] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[24ページ]RFC3920XMPPコア2004年10月
5.4. Server-to-Server Example
5.4. サーバからサーバへの例
The following example shows the data flow for two servers securing a stream using STARTTLS (note: the alternate steps shown below are provided to illustrate the protocol for failure cases; they are not exhaustive and would not necessarily be triggered by the data sent in the example).
以下の例はSTARTTLSを使用することでストリームを保証する2つのサーバのためのデータフローを示しています(失敗事件のためにプロトコルを例証するために注意: 以下に示された代替のステップを提供します; それらは、徹底的でなく、必ず例で送られたデータによって引き起こされるというわけではないでしょう)。
Step 1: Server1 initiates stream to Server2:
ステップ1: Server1開始はServer2に流れます:
<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: Server2はストリームタグをServer1に送ることによって、応じます:
<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'イド='s2s_123'バージョンは'1.0'>と等しいこと'と等しいです。
Step 3: Server2 sends the STARTTLS extension to Server1 along with authentication mechanisms and any other stream features:
ステップ3: Server2は認証機構といかなる他のストリーム機能に伴うServer1にも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='つぼ:ietf:params: xml:ナノ秒:xmpp-tls'><は/></starttls><メカニズムxmlns='つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'><メカニズム>DIGEST-MD5</メカニズム><メカニズム>ケルベロス_V4</メカニズム></メカニズム></ストリームを必要としました: >を特集すること'を特集します。
Step 4: Server1 sends the STARTTLS command to Server2:
ステップ4: Server1はSTARTTLSコマンドをServer2に送ります:
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<starttls xmlns='つぼ:ietf:params:xml:ナノ秒: xmpp-tls'/>。
Step 5: Server2 informs Server1 that it is allowed to proceed:
ステップ5: Server2は、続くことができることをServer1に知らせます:
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
<はxmlns='つぼ:ietf:params:xml:ナノ秒: xmpp-tls'/>を続かせます。
Saint-Andre, Ed. Standards Track [Page 25] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[25ページ]RFC3920XMPPコア2004年10月
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='つぼ:ietf:params:xml:ナノ秒: xmpp-tls'/></ストリーム: ストリーム>。
Step 6: Server1 and Server2 attempt to complete TLS negotiation via TCP.
ステップ6: Server1とServer2は、TCPを通してTLS交渉を終了するのを試みます。
Step 7: If TLS negotiation is successful, Server1 initiates a new stream to Server2:
ステップ7: TLS交渉がうまくいくなら、Server1は新しいストリームをServer2に開始します:
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<ストリーム: ストリーム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: Server2はどんな利用可能なストリーム機能に伴うServer1にもストリームヘッダーを送ることによって、応じます:
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'> <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>KERBEROS_V4</mechanism> <mechanism>EXTERNAL</mechanism> </mechanisms> </stream:features>
Step 9: Server1 continues with SASL negotiation (Section 6).
ステップ9: Server1はSASL交渉(セクション6)を続行します。
Saint-Andre, Ed. Standards Track [Page 26] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[26ページ]RFC3920XMPPコア2004年10月
6. Use of SASL
6. SASLの使用
6.1. Overview
6.1. 概要
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はSimple AuthenticationとSecurity Layer(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)ホスト名が決議されるまで(ServerからサーバへのCommunications(セクション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インチは初期にヘッダーを流す」値に'バージョン'属性セットを含めなければなりません。
3. If the receiving entity is capable of SASL negotiation, it MUST
advertise one or more authentication mechanisms within a
<mechanisms/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace in reply to the
opening stream tag received from the initiating entity (if the
opening stream tag included the 'version' attribute set to a
value of at least "1.0").
3. 受信実体はSASL交渉ができるなら、'つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'名前空間によって開始実体から受け取られた初めのストリームタグに対して資格があった<メカニズム/>要素の中の1台以上の認証機構の広告を出さなければならない、(初めのストリームタグが少なくとも属性が値にセットした'バージョン'を含んでいた、「1インチ)」
4. During SASL negotiation, an entity MUST NOT send any white space
characters (matching production [3] content of [XML]) within the
root stream element as separators between elements (any white
space characters shown in the SASL examples below are included
for the sake of readability only); this prohibition helps to
ensure proper security layer byte precision.
4. SASL交渉の間、実体は分離符として根のストリーム要素の中で少しの余白キャラクタ([XML]の合っている生産[3]内容)も要素の間に送ってはいけません(以下のSASLの例に示されたどんな余白キャラクタも読み易さだけのために含まれています)。 この禁止は、適切なセキュリティ層のバイト精度を確実にするのを助けます。
5. Any XML character data contained within the XML elements used
during SASL negotiation MUST be encoded using base64, where the
encoding adheres to the definition in Section 3 of RFC 3548
[BASE64].
5. base64(コード化はRFC3548[BASE64]のセクション3との定義を固く守る)を使用して、SASL交渉の間に使用されるXML要素の中に含まれたどんなXMLキャラクタデータもコード化しなければなりません。
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)
6. 「簡単なユーザ名」の支給が選択されたSASLメカニズムで後押しされているなら(例えば、これは、DIGEST-MD5とCRAM-MD5メカニズムによってサポートされますが、EXTERNALとGSSAPIメカニズムによってサポートされるというわけではありません)、認証の間、開始実体SHOULDは簡単なユーザ名として送付ドメインを提供します。(ドメイン識別子に含まれているIPアドレスか完全修飾ドメイン名)
Saint-Andre, Ed. Standards Track [Page 27] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[27ページ]RFC3920XMPPコア2004年10月
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.
サーバからサーバへのコミュニケーションかその登録されたアカウントの場合では、クライアントからサーバへのコミュニケーションの場合で(XMPPノード識別子に含まれているユーザかノード名)を命名してください。
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]で説明されるように認証のアイデンティティから得られたデフォルト承認のアイデンティティと異なっていない場合、開始実体は承認のアイデンティティを提供してはいけません。 提供するなら、承認のアイデンティティの値がサーバのためのフォーム<ドメイン>(すなわち、ドメイン識別子専用)と form <node@domain のものであるに違いない、gt;、クライアントへの(すなわち、ノード識別子とドメイン識別子。)
8. Upon successful SASL negotiation that involves negotiation of a
security layer, the receiving entity MUST discard any knowledge
obtained from the initiating entity which was not obtained from
the SASL negotiation itself.
8. セキュリティ層の交渉にかかわるうまくいっているSASL交渉のときに、受信実体はSASL交渉自体から得られなかった開始実体から得られたどんな知識も捨てなければなりません。
9. Upon successful SASL negotiation that involves negotiation of a
security layer, the initiating entity MUST discard any knowledge
obtained from the receiving entity which was not obtained from
the SASL negotiation itself.
9. セキュリティ層の交渉にかかわるうまくいっているSASL交渉のときに、開始実体はSASL交渉自体から得られなかった受信実体から得られたどんな知識も捨てなければなりません。
10. See Mandatory-to-Implement Technologies (Section 14.7) regarding
mechanisms that MUST be supported.
10. サポートしなければならないメカニズムに関してMandatoryから道具へのTechnologies(セクション14.7)を見てください。
6.2. Narrative
6.2. 物語
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. 開始実体は受信実体に送られた初めのXMLストリームヘッダーに'バージョン'属性を含んでいることによって、SASL認証を要求します、「1インチ」への選択値群で。
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:ナノ秒: xmpp-sasl'名前空間で資格を得たので含まれていた<メカニズム/>要素です。 TLS(セクション5)のUseが、事項の前に設立される必要があるなら
Saint-Andre, Ed. Standards Track [Page 28] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[28ページ]RFC3920XMPPコア2004年10月
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.
認証機構は使用されるかもしれません、と受信実体がTLS交渉の前に利用可能なSASL認証機構のリストにそのメカニズムを前提としてはいけません。 開始実体が先のTLS交渉の間、有効な証明書を提示するなら、受信実体SHOULDはSASL交渉の間、SASL EXTERNALメカニズムを開始実体に提供します([SASL]を参照してください)、また、他の状況でEXTERNALメカニズムを提供するかもしれませんが。
3. The initiating entity selects a mechanism by sending an <auth/>
element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity and including an appropriate
value for the 'mechanism' attribute. This element MAY contain
XML character data (in SASL terminology, the "initial response")
if the mechanism supports or requires it; if the initiating
entity needs to send a zero-length initial response, it MUST
transmit the response as a single equals sign ("="), which
indicates that the response is present but contains no data.
3. 開始実体は、'メカニズム'属性のために'つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'名前空間によって受信実体に資格があった<auth/>要素を送って、適切な値を含んでいることによって、メカニズムを選択します。 メカニズムがそれをサポートするか、または必要とするなら、この要素はXMLキャラクタデータ(SASL用語における「初期の応答」)を含むかもしれません。 開始実体が、ゼロ・レングスの初期の応答を送る必要があるなら、それはただ一つの等号(「=」)として応答を伝えなければなりません。(応答が存在しているのを示しますが、それは、データを全く含みません)。
4. If necessary, the receiving entity challenges the initiating
entity by sending a <challenge/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity; this element MAY contain XML character data (which MUST
be computed in accordance with the definition of the SASL
mechanism chosen by the initiating entity).
4. 必要なら、'つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'名前空間によって開始実体に資格があった<挑戦/>要素を送ることによって、受信実体は開始実体に挑戦します。 この要素はXMLキャラクタデータ(開始実体によって選ばれたSASLメカニズムの定義に従って、計算しなければならない)を含むかもしれません。
5. The initiating entity responds to the challenge by sending a
<response/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving
entity; this element MAY contain XML character data (which MUST
be computed in accordance with the definition of the SASL
mechanism chosen by the initiating entity).
5. 開始実体は'つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'名前空間によって受信実体に資格があった<応答/>要素を送ることによって、挑戦に応じます。 この要素はXMLキャラクタデータ(開始実体によって選ばれたSASLメカニズムの定義に従って、計算しなければならない)を含むかもしれません。
6. If necessary, the receiving entity sends more challenges and the
initiating entity sends more responses.
6. 必要なら、受信実体は実体が送るより多くの挑戦と開始により多くの応答を送ります。
This series of challenge/response pairs continues until one of three things happens:
3つのものの1つが起こるまで、このシリーズの挑戦/応答組は続けています:
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. 開始実体は、'つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'名前空間によって受信実体に資格があった<アボート/>要素を送ることによって、握手を中止します。 <アボート/>要素を受け取ると、受信実体SHOULDは構成可能な、しかし、妥当な数の再試行(少なくとも2)を許します。(その時TCP接続を終えなければなりませんでした)後。 これは、再接続させられないで不当に提供された資格証明書(例えば、mistypedパスワード)を許容するために開始実体を可能にします(例えば、エンドユーザクライアント)。
Saint-Andre, Ed. Standards Track [Page 29] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[29ページ]RFC3920XMPPコア2004年10月
2. The receiving entity reports failure of the handshake by sending
a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity (the particular cause of failure SHOULD be communicated in
an appropriate child element of the <failure/> element as defined
under SASL Errors (Section 6.4)). If the failure case occurs,
the receiving entity SHOULD allow a configurable but reasonable
number of retries (at least 2), after which it MUST terminate the
TCP connection; this enables the initiating entity (e.g., an
end-user client) to tolerate incorrectly-provided credentials
(e.g., a mistyped password) without being forced to reconnect.
2. <失敗/>要素を送るのによる握手の受信実体レポート失敗は'つぼ:ietf:params:xml:ナノ秒: xmpp-sasl'名前空間で開始実体への資格を得ました。(SHOULDは事項がコミュニケートしているコネが<失敗/>要素の適切な子供要素であったならSASL Errors(セクション6.4)の下で定義されるように失敗を引き起こします。 失敗事件が起こるなら、受信実体SHOULDは構成可能な、しかし、妥当な数の再試行(少なくとも2)を許します。(その時TCP接続を終えなければなりませんでした)後。 これは、再接続させられないで不当に提供された資格証明書(例えば、mistypedパスワード)を許容するために開始実体を可能にします(例えば、エンドユーザクライアント)。
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:ナノ秒: xmpp-sasl'名前空間で開始実体への資格を得ました。 この要素は必要なら選ばれたSASLメカニズムで、XMLキャラクタデータ(SASL用語における「成功がある追加データ」)を含むかもしれません。 <成功/>要素を受け取ると、開始実体は、初めのXMLストリームヘッダーを受信実体に送ることによって、新しいストリームを開始しなければなりません(最初に終わりの</ストリーム>タグを送るのが必要でない、受信以来、存在と実体を開始すると、オリジナルのストリームは<成功/>要素を送るか、または受け取りながら迫られるために考えられなければなりません)。 開始実体から新しいストリームヘッダーを受けると、受信実体は新しいXMLストリームヘッダーを開始実体に送ることによって、応じなければなりません、どんな利用可能な特徴(STARTTLSとSASLの特徴を含んでいませんが)か空の<特徴/>要素(どんな付加的な機能も利用可能でないことを意味する)と共にも。 XMPPへの関連拡大でここに定義されなかった少しのそのような付加的な機能も定義しなければなりません。
6.3. SASL Definition
6.3. SASL定義
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ストリームヘッダーと受信に実体回答を供給した後に、受信実体は許容できる認証方法のリストを提供します。 開始実体は、<auth/>要素によって持たれていた'メカニズム'属性の値としてリストから1つのメソッドを選んで、受信実体にそれを送ります、周遊旅行を避けるために任意に初期の応答を含んでいて。
Saint-Andre, Ed. Standards Track [Page 30] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[30ページ]RFC3920XMPPコア2004年10月
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.
承認のアイデンティティの使用: 承認のアイデンティティが non-default <node@domain を指示するのにxmppによって使用されるかもしれない、gt;、クライアントかサーバの送付<ドメイン>について。
6.4. SASL Errors
6.4. SASL誤り
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 <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 <invalid-authzid/> -- The authzid provided by the initiating
entity is invalid, either because it is incorrectly formatted or
because the initiating entity does not have permissions to
authorize that ID; sent in reply to a <response/> element or an
<auth/> element with initial response data.
o <invalid-authzid/> -- The authzid provided by the initiating entity is invalid, either because it is incorrectly formatted or because the initiating entity does not have permissions to authorize that ID; sent in reply to a <response/> element or an <auth/> element with initial response data.
o <invalid-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 <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.
Saint-Andre, Ed. Standards Track [Page 31] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 31] RFC 3920 XMPP Core October 2004
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 <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 <not-authorized/> -- The authentication failed because the
initiating entity did not provide valid credentials (this includes
but is not limited to the case of an unknown username); sent in
reply to a <response/> element or an <auth/> element with initial
response data.
o <not-authorized/> -- 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 <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 <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.
6.5. Client-to-Server Example
6.5. Client-to-Server Example
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).
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).
Step 1: Client initiates stream to server:
Step 1: Client initiates stream to server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
Step 2: Server responds with a stream tag sent to client:
Step 2: Server responds with a stream tag sent to client:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_234'
from='example.com'
version='1.0'>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_234' from='example.com' version='1.0'>
Step 3: Server informs client of available authentication mechanisms:
Step 3: Server informs client of available authentication mechanisms:
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
<stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> </stream:features>
Saint-Andre, Ed. Standards Track [Page 32] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 32] RFC 3920 XMPP Core October 2004
Step 4: Client selects an authentication mechanism:
Step 4: Client selects an authentication mechanism:
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
Step 5: Server sends a [BASE64] encoded challenge to client:
Step 5: Server sends a [BASE64] encoded challenge to client:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== </challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== </challenge>
The decoded challenge is:
The decoded challenge is:
realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess
realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server returns error to client:
Step 5 (alt): Server returns error to client:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <incorrect-encoding/> </failure> </stream:stream>
Step 6: Client sends a [BASE64] encoded response to the challenge:
Step 6: Client sends a [BASE64] encoded response to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo YXJzZXQ9dXRmLTgK </response>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo YXJzZXQ9dXRmLTgK </response>
The decoded response is:
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
username="somenode",realm="somerealm",\ nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ nc=00000001,qop=auth,digest-uri="xmpp/example.com",\ response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server sends another [BASE64] encoded challenge to client:
Step 7: Server sends another [BASE64] encoded challenge to client:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </challenge>
Saint-Andre, Ed. Standards Track [Page 33] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 33] RFC 3920 XMPP Core October 2004
The decoded challenge is:
The decoded challenge is:
rspauth=ea40f60335c427b5527b84dbabcdfffd
rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server returns error to client:
Step 7 (alt): Server returns error to client:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <temporary-auth-failure/> </failure> </stream:stream>
Step 8: Client responds to the challenge:
Step 8: Client responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server informs client of successful authentication:
Step 9: Server informs client of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server informs client of failed authentication:
Step 9 (alt): Server informs client of failed authentication:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <temporary-auth-failure/> </failure> </stream:stream>
Step 10: Client initiates a new stream to server:
Step 10: Client initiates a new stream to server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):
Step 11: Server responds by sending a stream header to client along with any additional features (or an empty features element):
<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>
<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>
Saint-Andre, Ed. Standards Track [Page 34] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 34] RFC 3920 XMPP Core October 2004
6.6. Server-to-Server Example
6.6. Server-to-Server Example
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).
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).
Step 1: Server1 initiates stream to Server2:
Step 1: Server1 initiates stream to Server2:
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
Step 2: Server2 responds with a stream tag sent to Server1:
Step 2: Server2 responds with a stream tag sent to Server1:
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_234'
version='1.0'>
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'>
Step 3: Server2 informs Server1 of available authentication mechanisms:
Step 3: Server2 informs Server1 of available authentication mechanisms:
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
<stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>KERBEROS_V4</mechanism> </mechanisms> </stream:features>
Step 4: Server1 selects an authentication mechanism:
Step 4: Server1 selects an authentication mechanism:
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
Step 5: Server2 sends a [BASE64] encoded challenge to Server1:
Step 5: Server2 sends a [BASE64] encoded challenge to Server1:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz </challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9 ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz </challenge>
Saint-Andre, Ed. Standards Track [Page 35] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 35] RFC 3920 XMPP Core October 2004
The decoded challenge is:
The decoded challenge is:
realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess
realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess
Step 5 (alt): Server2 returns error to Server1:
Step 5 (alt): Server2 returns error to Server1:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <incorrect-encoding/> </failure> </stream:stream>
Step 6: Server1 sends a [BASE64] encoded response to the challenge:
Step 6: Server1 sends a [BASE64] encoded response to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3 LGNoYXJzZXQ9dXRmLTgK </response>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3 LGNoYXJzZXQ9dXRmLTgK </response>
The decoded response is:
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
username="example.org",realm="somerealm",\ nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ nc=00000001,qop=auth,digest-uri="xmpp/example.org",\ response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
Step 7: Server2 sends another [BASE64] encoded challenge to Server1:
Step 7: Server2 sends another [BASE64] encoded challenge to Server1:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </challenge>
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </challenge>
The decoded challenge is:
The decoded challenge is:
rspauth=ea40f60335c427b5527b84dbabcdfffd
rspauth=ea40f60335c427b5527b84dbabcdfffd
Step 7 (alt): Server2 returns error to Server1:
Step 7 (alt): Server2 returns error to Server1:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <invalid-authzid/> </failure> </stream:stream>
Saint-Andre, Ed. Standards Track [Page 36] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 36] RFC 3920 XMPP Core October 2004
Step 8: Server1 responds to the challenge:
Step 8: Server1 responds to the challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 8 (alt): Server1 aborts negotiation:
Step 8 (alt): Server1 aborts negotiation:
<abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9: Server2 informs Server1 of successful authentication:
Step 9: Server2 informs Server1 of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server2 informs Server1 of failed authentication:
Step 9 (alt): Server2 informs Server1 of failed authentication:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<aborted/>
</failure>
</stream:stream>
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <aborted/> </failure> </stream:stream>
Step 10: Server1 initiates a new stream to Server2:
Step 10: Server1 initiates a new stream to Server2:
<stream:stream
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
Step 11: Server2 responds by sending a stream header to Server1 along with any additional features (or an empty features element):
Step 11: Server2 responds by sending a stream header to Server1 along with any additional features (or an empty features element):
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='example.com'
id='s2s_345'
version='1.0'>
<stream:features/>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_345' version='1.0'> <stream:features/>
7. Resource Binding
7. Resource Binding
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
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
Saint-Andre, Ed. Standards Track [Page 37] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 37] RFC 3920 XMPP Core October 2004
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>.
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>.
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):
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):
Server advertises resource binding feature to client:
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>
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_345' from='example.com' version='1.0'> <stream:features> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> </stream:features>
Upon being so informed that resource binding is required, the client MUST bind a resource to the stream by sending to the server an IQ stanza of type "set" (see IQ Semantics (Section 9.2.3)) containing data qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace.
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.
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:
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:
Client asks server to bind a resource:
Client asks server to bind a resource:
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>
<iq type='set' id='bind_1'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> </iq>
A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>.
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>.
Saint-Andre, Ed. Standards Track [Page 38] RFC 3920 XMPP Core October 2004
Saint-Andre, Ed. Standards Track [Page 38] RFC 3920 XMPP Core October 2004
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:
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:
Client binds a resource:
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 type='set' id='bind_2'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <resource>someresource</resource> </bind> </iq>
Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server:
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:
Server informs client of successful resource binding:
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タイプが'ひも_2'><ひものxmlns='つぼ:ietf:params:xml:ナノ秒'結果'イド=: xmpp-bind'> <jid>somenode@example.com/someresource と等しい、lt;、/jid、gt;、lt;、/ひもの></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.
サーバSHOULDはクライアントによって提供されたリソース識別子を受け入れますが、サーバが生成するリソース識別子でそれをくつがえすかもしれません。 この場合、サーバSHOULD NOTはスタンザ誤り(例えば、/>が禁じられた<)をクライアントに返しますが、代わりに、SHOULDは上に示されるようにIQ結果で発生しているリソース識別子をクライアントに伝えます。
When a client supplies a resource identifier, the following stanza error conditions are possible (see Stanza Errors (Section 9.3)):
クライアントがリソース識別子を提供するとき、以下のスタンザエラー条件は可能です(Stanza Errors(セクション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 提供されたリソース識別子は既に使用中ですが、サーバで、同じ識別子で複数の接続リソースを縛りません。
Saint-Andre, Ed. Standards Track [Page 39] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[39ページ]RFC3920XMPPコア2004年10月
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 type='error' id='bind_2'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <resource>someresource</resource> </bind> <error type='modify'> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
Client is not allowed to bind a resource:
クライアントはリソースを縛ることができません:
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq type='error' id='bind_2'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <resource>someresource</resource> </bind> <error type='cancel'> <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
Resource identifier is in use:
リソース識別子は使用中です:
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq type='error' id='bind_2'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <resource>someresource</resource> </bind> <error type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
If, before completing the resource binding step, the client attempts to send an XML stanza other than an IQ stanza with a <bind/> child qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace, the server MUST NOT process the stanza and SHOULD return a <not-authorized/> stanza error to the client.
リソースの拘束力があるステップを終了する前にクライアントが、<ひも/>子供は'つぼ:ietf:params:xml:ナノ秒: xmpp-ひもの'名前空間によって資格がある状態でIQスタンザ以外のXMLスタンザを送るのを試みるなら、サーバはスタンザを処理してはいけません、そして、SHOULDは認可されなかった</>スタンザ誤りをクライアントに返します。
Saint-Andre, Ed. Standards Track [Page 40] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[40ページ]RFC3920XMPPコア2004年10月
8. Server Dialback
8. サーバDialback
8.1. Overview
8.1. 概要
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プロトコルはドメインスプーフィングから守るための「サーバdialback」メソッドを含んでいます、その結果、XMLにスタンザを偽造するのをより難しくします。 サーバdialbackはセキュリティー対策でなくて、サーバのアイデンティティの弱い検証で結果(このメソッドのセキュリティの特性に関してServerからサーバへのCommunications(セクション14.4)を見る)専用です。 強健なセキュリティSHOULDを必要とするドメインがTLSとSASLを使用します。 詳細に関してServerからサーバへのCommunications(セクション14.4)を見てください。 dialback SHOULD、SASLはサーバからサーバ証明に使用されます。それが不要であるので、使用されません。 dialbackのドキュメンテーションは主に存在するとの後方の互換性の実装と展開のために含まれています。
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)の存在でサーバdialbackメソッドを可能にします、1つのサーバが(通常)正式のサーバを与えられたドメインに発見できるので。 dialbackがDNSによるので、サーバによって断言されたドメインネームシステム(DNS)ホスト名が決議されるまで(ServerからサーバへのCommunications(セクション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.
サーバdialbackはuni方向上です、そして、アイデンティティの(弱い)の検証における結果は個人的には一方向に流れます。 サーバdialbackが認証機構でないので、互いの認証はdialbackを通して可能ではありません。 したがって、2つのドメインの双方向のコミュニケーションを可能にするために各方向にサーバdialbackを完成しなければなりません。
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).
サーバdialbackで使用されるキーについて生成して、確かめるためのメソッドは使用されるホスト名を考慮に入れなければなりません、IDが受信サーバ、および正式のサーバのネットワークによって知られていた秘密で生成したストリーム。 したがって、ストリームIDがともにサーバdialbackでセキュリティ重要であり、予測できないで非反復でなければならない(セキュリティ目的のために推薦に関して偶発性に関して[RANDOM]を見てください)。
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.
ストリーム誤りであるとdialback交渉の間に発生するどんな誤りも考えなければなりません、ストリームと基本的なTCP接続の終了をもたらして。 可能なエラー条件は以下でのプロトコル記述で指定されます。
The following terminology applies:
以下の用語は適用されます:
o Originating Server -- the server that is attempting to establish a
connection between two domains.
o Serverを溯源します--2つのドメインの間に取引関係を築くのを試みているサーバ。
Saint-Andre, Ed. Standards Track [Page 41] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[41ページ]RFC3920XMPPコア2004年10月
o Receiving Server -- the server that is trying to authenticate that
the Originating Server represents the domain which it claims to
be.
o Serverを受けます--Originating Serverがそれが要求するドメインを表す認証するトライであるサーバ。
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 正式のServer--Originating Serverによって断言されたDNSホスト名に対応するサーバ。 基本的な環境のために、これはOriginating Serverになるでしょうが、それはOriginating Serverのネットワークで別々のマシンであるかもしれません。
8.2. Order of Events
8.2. イベントの注文
The following is a brief summary of the order of events in dialback:
↓これはdialbackでのイベントの注文の簡潔な概要です:
1. The Originating Server establishes a connection to the Receiving
Server.
1. Originating ServerはReceiving Serverに取引関係を築きます。
2. The Originating Server sends a 'key' value over the connection to
the Receiving Server.
2. Originating Serverは'主要な'値をReceiving Serverとの接続の上に送ります。
3. The Receiving Server establishes a connection to the
Authoritative Server.
3. Receiving ServerはAuthoritative Serverに取引関係を築きます。
4. The Receiving Server sends the same 'key' value to the
Authoritative Server.
4. Receiving Serverは同じ'主要な'値をAuthoritative Serverに送ります。
5. The Authoritative Server replies that key is valid or invalid.
5. Authoritative Serverは、キーが有効であるか、または無効であると返答します。
6. The Receiving Server informs the Originating Server whether it is
authenticated or not.
6. Receiving Serverは、それが認証されるかどうかをOriginating Serverに知らせます。
Saint-Andre, Ed. Standards Track [Page 42] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[42ページ]RFC3920XMPPコア2004年10月
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 |
| <---------------------- |
| |
サーバサーバを受け取りながら、起因します。----------- --------- | | | 接続を確立してください。| | ---------------------->|、|、|、| ストリームヘッダーを送ってください。| | ---------------------->|、|、|、| ストリームヘッダーを送ってください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 正式| dialbackキーを送ってください。| サーバ| ---------------------->| ------------- | | | | 接続を確立してください。| | ---------------------->|、|、|、| ストリームヘッダーを送ってください。| | ---------------------->|、|、|、| ストリームヘッダーを送ってください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 発信、要求について確かめてください。| | ---------------------->|、|、|、| 発信、応答について確かめてください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| レポートdialback結果| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
8.3. Protocol
8.3. プロトコル
The detailed protocol interaction between the servers is as follows:
サーバの間の詳細なプロトコル相互作用は以下の通りです:
1. The Originating Server establishes TCP connection to the
Receiving Server.
1. Originating ServerはTCP接続をReceiving Serverに確立します。
Saint-Andre, Ed. Standards Track [Page 43] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[43ページ]RFC3920XMPPコア2004年10月
2. The Originating Server sends a stream header to the Receiving
Server:
2. Originating ServerはストリームヘッダーをReceiving Serverに送ります:
<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は'おしゃべり:サーバ:dialback'>'と等しいです。
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. The inclusion of the xmlns:db namespace declaration with the name shown indicates to the Receiving Server that the Originating Server supports dialback. If the namespace name is incorrect, then the Receiving Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.
以下に注意してください。 'to'と'from'属性は根のストリーム要素の上のOPTIONALです。 xmlnsの包含: 示される名前でのdb名前空間宣言は、Originating ServerがdialbackをサポートするのをReceiving Serverに示します。 名前空間名が不正確であるなら、Receiving Serverは<の無効の名前空間/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。
3. The Receiving Server SHOULD send a stream header back to the
Originating Server, including a unique ID for this interaction:
3. Receiving Server SHOULDはこの相互作用のための固有のIDを含むOriginating Serverにストリームヘッダーを送り返します:
<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は'おしゃべり:サーバ:dialback'イド='457F9224A0'と等しいです…'>'
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Originating Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection. Note well that the Receiving Server SHOULD reply but MAY silently terminate the XML stream and underlying TCP connection depending on security policies in place; however, if the Receiving Server desires to proceed, it MUST send a stream header back to the Originating Server.
以下に注意してください。 'to'と'from'属性は根のストリーム要素の上のOPTIONALです。 名前空間名が不正確であるなら、Originating Serverは<の無効の名前空間/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。 Receiving Server SHOULD回答にもかかわらず、5月が静かに適所にある安全保障政策を当てにするXMLストリームと基本的なTCP接続を終えることによく注意してください。 しかしながら、Receiving Serverが、続くことを望んでいるなら、それはストリームヘッダーをOriginating Serverに送り返さなければなりません。
4. The Originating Server sends a dialback key to the Receiving
Server:
4. Originating ServerはReceiving Serverに主要なdialbackを送ります:
<db:result
to='Receiving Server'
from='Originating Server'>
98AF014EDC0...
</db:result>
<db: ''='からサーバを受け取りながら等しいサーバ'>98AF014EDC0'を溯源する結果 </db: 結果>。
Note: This key is not examined by the Receiving Server, since the Receiving Server does not keep information about the Originating Server between sessions. The key generated by the Originating Server MUST be based in part on the value of the ID provided by the
以下に注意してください。 このキーはReceiving Serverによって調べられません、Receiving ServerがOriginating Serverの情報をセッションの間に置かないので。 Originating Serverによって生成されたキーを提供されたIDの値に一部基礎づけなければなりません。
Saint-Andre, Ed. Standards Track [Page 44] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[44ページ]RFC3920XMPPコア2004年10月
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.
前のステップと、一部秘密でServerを受けるのはOriginating ServerとAuthoritative Serverによって共有されました。'to'アドレスの値がReceiving Serverによって認識されたホスト名に合っていないなら、Receiving Serverは未知の<ホスト/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。 'from'アドレスの値がReceiving Serverには確立した接続が既にあるドメインに合っているなら、新しい接続が正統であるか否かに関係なく、Receiving Serverは、既存のそれまでの接続が有効にすると主張しなければなりません。 さらに、Receiving Serverは新しい接続のために認可されなかった</>ストリームエラー条件を生成して、次に、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. Receiving ServerはOriginating Serverによって断言されたドメイン名にTCP接続を確立して戻します、その結果、それがAuthoritative Serverに接続します。(注意: 最適化として、実装はここで既存の接続を再利用するかもしれません。)
6. The Receiving Server sends the Authoritative Server a stream
header:
6. Receiving ServerはストリームヘッダーをAuthoritative Serverに送ります:
<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は'おしゃべり:サーバ:dialback'>'と等しいです。
Note: The 'to' and 'from' attributes are OPTIONAL on the root stream element. If the namespace name is incorrect, then the Authoritative Server MUST generate an <invalid-namespace/> stream error condition and terminate both the XML stream and the underlying TCP connection.
以下に注意してください。 'to'と'from'属性は根のストリーム要素の上のOPTIONALです。 名前空間名が不正確であるなら、Authoritative Serverは<の無効の名前空間/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。
7. The Authoritative Server sends the Receiving Server a stream
header:
7. Authoritative ServerはストリームヘッダーをReceiving Serverに送ります:
<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は'おしゃべり:サーバ:dialback'イド='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
以下に注意してください。 名前空間名が不正確であるなら、Receiving Serverは<の無効の名前空間/>ストリームエラー条件を生成して、それとAuthoritative Serverの間のXMLストリームと基本的なTCP接続の両方を終えなければなりません。ストリーム誤りがReceiving ServerとAuthoritative Serverの間に発生するなら、Receiving Serverは<のリモート接続失敗/>ストリームを生成しなければなりません。
Saint-Andre, Ed. Standards Track [Page 45] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[45ページ]RFC3920XMPPコア2004年10月
error condition and terminate both the XML stream and the underlying TCP connection between it and the Originating Server.
そして、エラー条件、それとOriginating Serverの間のXMLストリームと基本的なTCP接続の両方を終えてください。
8. The Receiving Server sends the Authoritative Server a request for
verification of a key:
8. Receiving Serverはキーの検証を求める要求をAuthoritative Serverに送ります:
<db:verify
from='Receiving Server'
to='Originating Server'
id='457F9224A0...'>
98AF014EDC0...
</db:verify>
<db: =等しい'サーバを受け取ります''起因するサーバ'イド=から、'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.
以下に注意してください。 ここに通過されているのは、ホスト名(オリジナルのReceiving ServerのストリームヘッダーからStep3のOriginating Serverと、Originating Serverが送ったキーからStep4のReceiving Serverまでの識別子)です。 この情報、およびAuthoritative Serverのネットワークの中の共有された秘密の情報に基づいて、キーは確かめられます。 どんな証明可能なメソッドも、キーを生成するのに使用されるかもしれません。 'to'アドレスの値がAuthoritative Serverによって認識されたホスト名に合っていないなら、Authoritative Serverは未知の<ホスト/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。 'from'アドレスの値がそうしないなら、TCP接続(または、それのReceiving Serverのホスト名の有効にされたサブドメインかReceiving Serverによってホスティングされた別の有効にされたドメインなどのどんな有効にされたドメインも)を開くときReceiving Serverによって表されたホスト名を合わせてください、Authoritative Serverが生成しなければならないその時、<病人、-、/>はエラー条件を流して、XMLストリームと基本的なTCP接続の両方を終えます。
9. The Authoritative Server verifies whether the key was valid or
invalid:
9. Authoritative Serverは、キーが有効であるか、または無効であったかを確かめます:
<db:verify
from='Originating Server'
to='Receiving Server'
type='valid'
id='457F9224A0...'/>
<db: =から、'Server'タイプ='有効な'イド='457F9224A0を受けます'と等しいように'起因するServer'について確かめてください…'/>'
or
または
<db:verify
from='Originating Server'
to='Receiving Server'
type='invalid'
id='457F9224A0...'/>
<db: =から、'Server'タイプ='無効の'イド='457F9224A0を受けます'と等しいように'起因するServer'について確かめてください…'/>'
Saint-Andre, Ed. Standards Track [Page 46] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[46ページ]RFC3920XMPPコア2004年10月
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がReceiving ServerによってStep3に提供されたそれに合っていないなら、Receiving Serverは<の無効のイド/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。 'to'アドレスの値がReceiving Serverによって認識されたホスト名に合っていないなら、Receiving Serverは未知の<ホスト/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。 'from'アドレスの値がそうしないなら、TCP接続(または、それのOriginating Serverのホスト名の有効にされたサブドメインかOriginating Serverによってホスティングされた別の有効にされたドメインなどのどんな有効にされたドメインも)を開くときOriginating Serverによって表されたホスト名を合わせてください、Receiving Serverが生成しなければならないその時、<病人、-、/>はエラー条件を流して、XMLストリームと基本的なTCP接続の両方を終えます。 検証をReceiving Serverに返した後に、Authoritative Server SHOULDはそれらの間のストリームを終えます。
10. The Receiving Server informs the Originating Server of the
result:
10. Receiving Serverは結果についてOriginating Serverに知らせます:
<db:result
from='Receiving Server'
to='Originating Server'
type='valid'/>
<db: ='Serverを溯源します'と等しいためには'Serverを受けます'タイプ='有効'/>からの結果
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.
以下に注意してください。 ここに、接続は、タイプ=で'有効な'状態で有効にされるか、または無効であると報告されました。 接続が無効であるなら、Receiving ServerはXMLストリームと基本的なTCP接続の両方を終えなければなりません。 接続が有効にされるなら、データは、Originating Serverによって送られて、Receiving Serverで読むことができます。 その前に、下げられて、Receiving Server SHOULDに送られたすべての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.
上記の結果はReceiving ServerがOriginating Serverのアイデンティティについて確かめたということです、Originating Serverが発信できて、Receiving Serverが受け入れることができるように、「初期のストリーム」(すなわち、Originating ServerからReceiving Serverまでのストリーム)の上のXMLスタンザ。 「応答ストリーム」(すなわち、Receiving ServerからOriginating Serverまでのストリーム)を使用することで実体のアイデンティティについて確かめるために、また、逆方向にdialbackを完成しなければなりません。
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.
うまくいっているdialback交渉の後に、Receiving Server SHOULDはその後の<dbを受け入れます: 存在の上のOriginating Serverからの結果/>パケット(例えばサブドメインに送られた合法化要求かReceiving Serverによって修理された他のホスト名)は接続を有効にしました。 これはオリジナルの有効にされた接続の一方向への「便乗」を可能にします。
Saint-Andre, Ed. Standards Track [Page 47] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[47ページ]RFC3920XMPPコア2004年10月
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.
dialback交渉がうまくいっても、サーバは、もう片方のサーバから受け取られたすべてのXMLスタンザが'from'属性と'to'属性を含んでいることを確かめなければなりません。 スタンザがこの制限を満たさないなら、スタンザを受け取るサーバは、<の不適当なアドレシング/>ストリームエラー条件を生成して、XMLストリームと基本的なTCP接続の両方を終えなければなりません。 その上、サーバは、もう片方のサーバから受け取られたスタンザの'from'属性がストリームのための有効にされたドメインを含んでいることを確かめなければなりません。 スタンザがこの制限を満たさないなら、スタンザを受け取るサーバが生成しなければならない、<病人、-、/>はエラー条件を流して、XMLストリームと基本的なTCP接続の両方を終えます。 ともに、これらのチェックでは、だますのを防ぐ助けは特定のスタンザに関連しました。
9. XML Stanzas
9. XMLスタンザ
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].
必要なら、XMLスタンザをストリームの上に送ることができます。TLS交渉の後、(セクション5) 3種類のXMLスタンザが'おしゃべり: クライアントのために定義されて、'': サーバについてペチャクチャしゃべってください'という必要なSASL交渉(セクション6)、およびResource Binding(セクション7)名前空間であるなら: <メッセージ/>、<存在/>、および<iq/>さらに、これらの種類のスタンザのための5つの一般的な属性があります。 これらの一般的な属性、および3スタンザ種類の基本的な意味論はここに定義されます。 インスタントメッセージングと関連したXMLスタンザと存在アプリケーションの構文の、より詳細な情報を[XMPP-IM]に提供します。
9.1. Common Attributes
9.1. 一般的な属性
The following five attributes are common to message, presence, and IQ stanzas:
以下の5つの属性がメッセージ、存在、およびIQスタンザに共通です:
9.1.1. to
9.1.1.
The 'to' attribute specifies the JID of the intended recipient for the stanza.
'to'属性は意図している受取人のJIDをスタンザに指定します。
In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' attribute, although a stanza sent from a client to a server for handling by that server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute.
'おしゃべり: クライアントでは、'名前空間、スタンザSHOULDは'to'属性を持って、スタンザはそのサーバによる取り扱いのためにクライアントからサーバまで発信しましたが(例えば、存在は他の実体に放送するためのサーバに発信しました)、SHOULD NOTには'to'属性があります。
In the 'jabber:server' namespace, a stanza MUST possess a 'to' attribute; if a server receives a stanza that does not meet this restriction, it MUST generate an <improper-addressing/> stream error condition and terminate both the XML stream and the underlying TCP connection with the offending server.
'おしゃべり: サーバ'名前空間では、スタンザは'to'属性を持たなければなりません。 サーバがこの制限を満たさないスタンザを受け取るなら、それは、<の不適当なアドレシング/>ストリームエラー条件を生成して、怒っているサーバがあるXMLストリームと基本的なTCP接続の両方を終えなければなりません。
Saint-Andre, Ed. Standards Track [Page 48] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[48ページ]RFC3920XMPPコア2004年10月
If the value of the 'to' attribute is invalid or cannot be contacted, the entity discovering that fact (usually the sender's or recipient's server) MUST return an appropriate error to the sender, setting the 'from' attribute of the error stanza to the value provided in the 'to' attribute of the offending stanza.
'to'属性の値に無効であるか、または連絡できないなら、その事実(通常送付者か受取人のサーバ)を発見する実体は適切な誤りを送付者に返さなければなりません、怒っているスタンザの'to'属性に提供された値に誤りスタンザの'from'属性を設定して。
9.1.2. from
9.1.2.
The 'from' attribute specifies the JID of the sender.
'from'属性は送付者のJIDを指定します。
When a server receives an XML stanza within the context of an authenticated stream qualified by the 'jabber:client' namespace, it MUST do one of the following:
サーバが'おしゃべり: クライアント'名前空間によって資格があった認証されたストリームの文脈の中にXMLスタンザを受け取るとき、以下の1つをしなければなりません:
1. validate that the value of the 'from' attribute provided by the
client is that of a connected resource for the associated entity
1.、有効にする、クライアントによって提供された'from'属性の値は関連実体のための接続リソースのものです。
2. add a 'from' address to the stanza whose value is the bare JID
(<node@domain>) or the full JID (<node@domain/resource>)
determined by the server for the connected resource that
generated the stanza (see Determination of Addresses (Section
3.5))
2. 値がむき出しのJID (<node@domain であるスタンザに'from'アドレスを追加してください、gt;、)、完全なJID (<node@domain/resource 、gt;、)、サーバで、スタンザを生成した接続リソースのために決定します。(アドレス(セクション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.
クライアントが、'from'属性の値がその実体のための接続リソースの1つに合っていないXMLスタンザを送るのを試みるなら、サーバSHOULDが戻る、<病人、-、クライアントへの/>ストリーム誤り。 クライアントが、まだ認証されていないストリームの上にXMLスタンザを送るのを試みるなら、サーバSHOULDは認可されなかった</>ストリーム誤りをクライアントに返します。 生成されるなら、これらの状態の両方がストリームの閉鎖と基本的な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)が値がアカウントのむき出しのJID (<node@domain である'from'属性か(2)インクルードa'from'属性を含んでいない、gt;、)、クライアントの完全なJID (<node@domain/resource 、gt;、) スタンザがサーバ自体によって生成されなかったなら、サーバは'from'属性なしでスタンザをクライアントに送ってはいけません。 クライアントが'from'属性を含んでいないスタンザを受け取るとき、それは、スタンザがクライアントが関連しているサーバから来ていると仮定しなければなりません。
In the 'jabber:server' namespace, a stanza MUST possess a 'from' attribute; if a server receives a stanza that does not meet this restriction, it MUST generate an <improper-addressing/> stream error condition. Furthermore, the domain identifier portion of the JID
'おしゃべり: サーバ'名前空間では、スタンザは'from'属性を持たなければなりません。 サーバがこの制限を満たさないスタンザを受け取るなら、それは<の不適当なアドレシング/>ストリームエラー条件を生成しなければなりません。 その上、ドメイン識別子はJIDを分配します。
Saint-Andre, Ed. Standards Track [Page 49] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[49ページ]RFC3920XMPPコア2004年10月
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.
含まれて、'from'属性では、SASL交渉かdialback交渉における、コミュニケートするとしての送付サーバ(または、それの送付サーバのホスト名の有効にされたサブドメインか送付サーバによってホスティングされた別の有効にされたドメインなどのどんな有効にされたドメインも)に関するホスト名は合っていなければなりません。 サーバがこの制限を満たさないスタンザを受け取るなら、生成しなければならない、<病人、-、/>ストリームエラー条件。 最後になりましたが、これらの状態の両方が基本的なTCP接続のストリームと終了を結果として生じさせなければなりません。 これは、凶暴なサーバから進水するサービス不能攻撃を防ぐのを助けます。
9.1.3. id
9.1.3. イド
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).
任意の'イド'属性はそれが送って、受け取る(特にIQスタンザの意味論に固有の要求応答相互作用を追跡するために)スタンザの内部の追跡に送付実体によって使用されるかもしれません。 それは'イド'属性の値がドメインか、ストリームの中でグローバルに特有であるOPTIONALです。 IQスタンザの意味論は追加制限を課します。 IQ Semantics(セクション9.2.3)を見てください。
9.1.4. type
9.1.4. タイプ
The 'type' attribute specifies detailed information about the purpose or context of the message, presence, or IQ stanza. The particular allowable values for the 'type' attribute vary depending on whether the stanza is a message, presence, or IQ; the values for message and presence stanzas are specific to instant messaging and presence applications and therefore are defined in [XMPP-IM], whereas the values for IQ stanzas specify the role of an IQ stanza in a structured request-response "conversation" and thus are defined under IQ Semantics (Section 9.2.3) below. The only 'type' value common to all three stanzas is "error"; see Stanza Errors (Section 9.3).
'タイプ'属性はメッセージ、存在、またはIQスタンザの目的か文脈の詳細な情報を指定します。 スタンザがメッセージ、存在、またはIQであるかによって、'タイプ'属性のための特定の許容量は異なります。 メッセージと存在スタンザのための値は、インスタントメッセージングと存在アプリケーションに特定であり、したがって、[XMPP-IM]で定義されます、IQスタンザのための値は、構造化された要求応答「会話」でIQスタンザの役割を指定して、その結果、以下のIQ Semantics(セクション9.2.3)の下で定義されます。 すべての3つのスタンザに共通の唯一の'タイプ'値が「誤り」です。 Stanza Errors(セクション9.3)を見てください。
9.1.5. xml:lang
9.1.5. xml: lang
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].
スタンザSHOULDには、スタンザが人間のユーザに提示されることを意図するXMLキャラクタデータを含んでいるなら(RFC2277[CHARSET]で説明されるように、「国際化は人間のためのものである」)、'xml: lang'属性([XML]のセクション2.12で定義されるように)があります。 'xml: lang'属性の値はそのようなどんな人間読み込み可能なXMLキャラクタデータのデフォルト言語も指定します。(データは特定の子供要素の'xml: lang'属性によって優越されます)。 スタンザに'xml: lang'属性がないなら、実装は、デフォルト言語がStream Attributes(セクション4.4)の下の定義されるとしての上のストリームにそんなに指定されていると仮定しなければなりません。 'xml: lang'属性の値は、NMTOKENでなければならなく、RFC3066[LANGTAGS]で定義された書式に従わなければなりません。
Saint-Andre, Ed. Standards Track [Page 50] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[50ページ]RFC3920XMPPコア2004年10月
9.2. Basic Semantics
9.2. 基本的な意味論
9.2.1. Message Semantics
9.2.1. メッセージ意味論
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).
スタンザ種類を「プッシュ」メカニズムと考えることができるという1つの実体がメールなどのシステムに現れるコミュニケーションと同様の別の実体に情報を押す<メッセージ/>。 すべてのメッセージスタンザSHOULDには、メッセージの意図している受取人を指定する'to'属性があります。 そのようなスタンザ、SHOULDがそれを発送するか、または提供するサーバを受け取るときの意図している受取人(Handling XML Stanzas(セクション10)に関してXMLスタンザに関連する一般的なルーティングと配送規則に関してServer Rulesを見ます)。
9.2.2. Presence Semantics
9.2.2. 存在意味論
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が'to'なしで存在スタンザを送る出版実体は、どの場合に実体が接続SHOULD放送であるサーバを結果と考えるか、そして、または実体を申し込みながら、そのスタンザをすべてに多重送信します。 しかしながら、出版実体は、また、その場合、'to'属性、サーバSHOULDルートで存在スタンザを送るか、またはそのスタンザを意図している受取人に提供するかもしれません。 XMLスタンザに関連する一般的なルーティングと配送規則のためのHandling XML Stanzas(セクション10)に関してServer Rulesを見て、インスタントメッセージングと存在アプリケーションの文脈の存在特有の規則のために[XMPP-IM]を見てください。
9.2.3. IQ Semantics
9.2.3. IQ意味論
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要素のダイレクト子供要素の名前空間宣言で定義されます、そして、相互作用は要求実体によって'イド'属性の使用で追跡されます。 したがって、IQ相互作用は/結果かセット/結果を得るような構造化されたデータ交換の共通パターンに続いて起こります(適切であるなら、誤りが要求に対して返されるかもしれませんが):
Saint-Andre, Ed. Standards Track [Page 51] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[51ページ]RFC3920XMPPコア2004年10月
Requesting Responding
Entity Entity
---------- ----------
| |
| <iq type='get' id='1'> |
| ------------------------> |
| |
| <iq type='result' id='1'> |
| <------------------------ |
| |
| <iq type='set' id='2'> |
| ------------------------> |
| |
| <iq type='error' id='2'> |
| <------------------------ |
| |
実体実体を反応させる要求---------- ---------- | | | <iqタイプは''1'イド='>を手に入れてください'と等しいです。| | ------------------------>|、|、|、| <iqタイプは'結果'イド='1'>'と等しいです。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| <iqタイプ=は''イド='2'>を設定します'。| | ------------------------>|、|、|、| <iqタイプは'誤り'イド='2'>'と等しいです。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
In order to enforce these semantics, the following rules apply:
これらを実施するために、意味論、以下の規則は申し込まれます:
1. The 'id' attribute is REQUIRED for IQ stanzas.
1. 'イド'属性はIQスタンザのためのREQUIREDです。
2. The 'type' attribute is REQUIRED for IQ stanzas. The value MUST
be one of the following:
2. 'タイプ'属性はIQスタンザのためのREQUIREDです。 値は以下の1つでなければなりません:
* 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.
* 結果--スタンザはaに成功している応答が要求を得るか、または設定するということです。
* error -- An error has occurred regarding processing or
delivery of a previously-sent get or set (see Stanza Errors
(Section 9.3)).
* 誤り--誤りが処理に関して発生したか、または得るか、または設定されて、aの配送は以前に、発信しました(Stanza Errors(セクション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. 「得てください」か「セット」というタイプのIQ要求を受け取る実体はタイプ「結果」か「誤り」の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応答を送ることによって、スタンザに応じてはいけません。 しかしながら、上に示されるように、要求実体は別の要求を送るかもしれません(例えば、必須情報を提供するために「設定された」タイプのIQは、aを通して/結果組を手に入れるように発見しました)。
Saint-Andre, Ed. Standards Track [Page 52] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[52ページ]RFC3920XMPPコア2004年10月
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. タイプ「誤り」SHOULDのIQスタンザは、関連「得てください」か「セット」に含まれた子供要素を含んでいて、<誤り/>子供を含まなければなりません。 詳細に関しては、Stanza Errors(セクション9.3)を見てください。
9.3. Stanza Errors
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)を流すために同様の方法で扱われます。 しかしながら、ストリーム誤りと異なって、スタンザ誤りは回復可能です。 したがって、スタンザが含む誤りは、動作に関して元の送り主が誤りを改善するために取ることができると暗示します。
9.3.1. Rules
9.3.1. 規則
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 SHOULDが含む誤りスタンザにオリジナルの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 誤りスタンザを受け取る実体はさらなる誤りスタンザでスタンザに応じてはいけません。 これは、輪にするのを防ぐのを助けます。
Saint-Andre, Ed. Standards Track [Page 53] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[53ページ]RFC3920XMPPコア2004年10月
9.3.2. Syntax
9.3.2. 構文
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>
<stanza-kind to='sender' type='error'> [RECOMMENDED to include sender XML here] <error type='error-type'> <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='langcode'> OPTIONAL descriptive text </text> [OPTIONAL application-specific condition element] </error> </stanza-kind>
The stanza-kind is one of message, presence, or iq.
スタンザ種類はメッセージ、存在、またはiqの1つです。
The value of the <error/> element's 'type' attribute MUST be one of the following:
<誤り/>要素の'タイプ'属性の値は以下の1つでなければなりません:
o cancel -- do not retry (the error is unrecoverable) o continue -- proceed (the condition was only a warning) o modify -- retry after changing the data sent o auth -- retry after providing credentials o wait -- retry after waiting (the error is temporary)
o 取り消してください--oが続けている再試行(誤りは復しません)--oを続かせるのは(状態は警告にすぎませんでした)待った後に、再試行を変更しませんか?--データの送られた○authを変えた後の再試行(提供資格証明書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:ナノ秒でこの要素に資格がなければなりません: 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:ナノ秒: xmpp-スタンザ'名前空間でこの要素に資格がなければなりません、そして、SHOULDには、'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
<テキスト/>要素はOPTIONALです。 含まれているならそれ、SHOULD、使用されて、単に定義された状態かアプリケーション特有の状態の意味をそれが補う描写的であるか診断している情報に提供してください。 それ、SHOULD NOT、アプリケーションでプログラムに基づいて解釈されてください。 それ
Saint-Andre, Ed. Standards Track [Page 54] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[54ページ]RFC3920XMPPコア2004年10月
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).
SHOULD NOTはユーザに提示されたエラーメッセージとして使用されますが、含まれている状態要素(または、要素)に関連しているエラーメッセージに加えて見せられるかもしれません。
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]では、指定される)は<誤り/>要素における'コード'属性の任意の包含を許容します。
9.3.3. Defined Conditions
9.3.3. 定義された状態
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スタンザ)を送りました。 関連誤りタイプSHOULDは「変更」です。
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 <闘争/>--既存のリソースかセッションが同じ名前かアドレスで存在しているので、アクセスを承諾できません。 関連誤りタイプSHOULDは「取り消し」です。
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 実装されなかった<の特徴/>--要求された特徴は、受取人かサーバで実装しないで、したがって、処理できません。 関連誤りタイプSHOULDは「取り消し」です。
o <forbidden/> -- the requesting entity does not possess the
required permissions to perform the action; the associated error
type SHOULD be "auth".
o />が禁じられた<--要求実体には、動作を実行するために、必要な許容がありません。 関連誤りタイプSHOULDは「authに」そうです。
o <gone/> -- the recipient or server can no longer be contacted at
this address (the error stanza MAY contain a new address in the
XML character data of the <gone/> element); the associated error
type SHOULD be "modify".
o <過ぎ去る、/>、--、もうこのアドレスで受取人かサーバに連絡できない(誤りスタンザが<に関するXMLキャラクタデータの新しいアドレスを含むかもしれない、過ぎ去る、/>要素)、。 関連誤りタイプSHOULDは「変更」です。
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 <内部サーバーエラー/>--サーバはmisconfigurationかそうでなければ、未定義の内部サーバーエラーのためにスタンザを処理できませんでした。 関連誤りタイプSHOULDは「待ち」です。
o <item-not-found/> -- the addressed JID or item requested cannot be
found; the associated error type SHOULD be "cancel".
o 見つけられなかった<の品目/>--要求された扱われたJIDか項目は見つけることができません。 関連誤りタイプSHOULDは「取り消し」です。
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奇形の/>--送付実体は、それのAddressing Scheme(セクション3)で定義された構文を固く守らないXMPPアドレス(例えば、'to'属性の値)か局面(例えば、リソース識別子)を、提供するか、または伝えました。 関連誤りタイプSHOULDは「変更」です。
Saint-Andre, Ed. Standards Track [Page 55] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[55ページ]RFC3920XMPPコア2004年10月
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 許容できない</>--受取人かサーバ(例えば、メッセージの許容できる単語に関するローカルの方針)によって定義された評価基準を満たさないので、受取人かサーバが、要求を理解していますが、それを処理するのを拒否しています。 関連誤りタイプSHOULDは「変更」です。
o <not-allowed/> -- the recipient or server does not allow any
entity to perform the action; the associated error type SHOULD be
"cancel".
o 許容されなかった</>--受取人かサーバで、どんな実体も動作を実行できません。 関連誤りタイプSHOULDは「取り消し」です。
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 認可されなかった</>--動作を実行するのが許容される前に適切な資格証明書を提供しなければならない、さもなければ、送付者は不適当な資格証明書を提供しました。 関連誤りタイプSHOULDは「authに」そうです。
o <payment-required/> -- the requesting entity is not authorized to
access the requested service because payment is required; the
associated error type SHOULD be "auth".
o <支払いで必要な/>--支払いが必要であるので要求実体が要求されたサービスにアクセスするのが認可されません。 関連誤りタイプSHOULDは「authに」そうです。
o <recipient-unavailable/> -- the intended recipient is temporarily
unavailable; the associated error type SHOULD be "wait" (note: an
application MUST NOT return this error if doing so would provide
information about the intended recipient's network availability to
an entity that is not authorized to know such information).
o 受取人入手できない</>--意図している受取人は一時入手できません。 関連誤りタイプSHOULDは「待ち」(そうするなら: アプリケーションがこの誤りを返してはいけない注意は意図している受取人のネットワークの有用性の情報をそのような情報を知るのは認可されない実体に提供する)です。
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 <の再直接の/>--受取人かサーバが通常一時この情報に関する要求を別の実体に向け直しています(誤りスタンザSHOULDは有効なJIDであるに違いない代替アドレスを含んでいます、<再直接の/>要素に関するXMLキャラクタデータで)。 関連誤りタイプSHOULDは「変更」です。
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 <登録で必要な/>--登録が必要であるので要求実体が要求されたサービスにアクセスするのが認可されません。 関連誤りタイプSHOULDは「authに」そうです。
o <remote-server-not-found/> -- a remote server or service specified
as part or all of the JID of the intended recipient does not
exist; the associated error type SHOULD be "cancel".
o リモートサーバが見つけなかった</>--意図している受取人のJIDの部分かすべてが存在していないので、リモートサーバかサービスが指定しました。 関連誤りタイプSHOULDは「取り消し」です。
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の部分かすべてに連絡できなかったので、指定しました。 関連誤りタイプSHOULDは「待ち」です。
o <resource-constraint/> -- the server or recipient lacks the system
resources necessary to service the request; the associated error
type SHOULD be "wait".
o <リソース規制/>--サーバか受取人が要求を修理するのに必要なシステム資源を欠いています。 関連誤りタイプSHOULDは「待ち」です。
Saint-Andre, Ed. Standards Track [Page 56] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[56ページ]RFC3920XMPPコア2004年10月
o <service-unavailable/> -- the server or recipient does not
currently provide the requested service; the associated error type
SHOULD be "cancel".
o サービス入手できない</>--サーバか受取人が現在、要求されたサービスを提供しません。 関連誤りタイプSHOULDは「取り消し」です。
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 <購読で必要な/>--購読が必要であるので要求実体が要求されたサービスにアクセスするのが認可されません。 関連誤りタイプSHOULDは「authに」そうです。
o <undefined-condition/> -- the error condition is not one of those
defined by the other conditions in this list; any error type may
be associated with this condition, and it SHOULD be used only in
conjunction with an application-specific condition.
o <の未定義の状態/>--エラー条件はこのリストの他の状態によって定義されたものの1つではありません。 どんな誤りタイプもこの状態、およびそれに関連しているかもしれない、SHOULD、単にアプリケーション特有の状態に関連して、使用されてください。
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 <の予期していなかった要求/>--受取人かサーバが、要求を理解していましたが、このとき、それを予想していませんでした(例えば、要求は不適切でした)。 関連誤りタイプSHOULDは「待ち」です。
9.3.4. Application-Specific Conditions
9.3.4. アプリケーション一定の条件
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:
注意されるように、アプリケーションは誤り要素に適切にnamespacedされた子供を含んでいることによって、アプリケーション特有のスタンザエラー情報を提供するかもしれません。 アプリケーション特有の要素SHOULDは定義された要素に補うか、またはさらに、資格を与えます。 したがって、<誤り/>要素は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タイプが'誤り'イド='と等しい、いくつか、-、イド、'><誤りタイプが''><の悪い要求xmlns='つぼ:ietf:params:xml:ナノ秒: xmppスタンザを変更してください'/>と等しい、<、あまりに多くのパラメタ、xmlnsは'アプリケーションナノ秒'/></誤り></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>
<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... テキストの>の<の特別なアプリケーション</状態xmlnsは'アプリケーションナノ秒'/></誤り></メッセージ>と等しいです。
Saint-Andre, Ed. Standards Track [Page 57] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[57ページ]RFC3920XMPPコア2004年10月
10. Server Rules for Handling XML Stanzas
10. 取り扱いXMLスタンザのためのサーバ規則
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:
オーダーにおける処理のための要件を超えて、それぞれのサーバ実装はそれが受け取る取り扱いスタンザのためのそれ自身の「配送木」を含むでしょう。 そのような木は、スタンザが、接続ノードに関連しているリソースに別のドメインに発送されるか、内部的に処理されるか、または提供される必要であるかどうか決定します。 以下の規則は適用されます:
10.1. No 'to' Address
10.1. 'to'アドレスがありません。
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.
スタンザに'to'属性が全くないなら、サーバSHOULDはそれを送った実体を代表してそれを処理します。 他のサーバから受け取られたすべてのスタンザが'to'属性を持たなければならないので、この規則はサーバに接続される登録された実体(クライアントなどの)から受け取られたスタンザだけに適用されます。サーバが'to'属性なしで存在スタンザを受け取るなら、サーバSHOULDは送付実体の存在に申し込まれて、適切な実体にそれを放送します(存在の意味論はインスタントメッセージングのために放送されました、そして、存在アプリケーションは[XMPP-IM]で定義されます)。 サーバが受信されるなら、タイプのIQスタンザがどんな'to'属性でも「得もしません」し、「セットもしない」で、スタンザの内容に資格を与える名前空間を理解していて、それは、送付実体(「プロセス」の意味が資格を得る名前空間の意味論で決定するところ)を代表してスタンザを処理しなければならないか、または送付実体に誤りを返さなければなりません。
10.2. Foreign Domain
10.2. 外国ドメイン
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute does not match one of the configured hostnames of the server itself or a subdomain thereof, the server SHOULD route the stanza to the foreign domain (subject to local service provisioning and security policies regarding inter-domain communication). There are two possible cases:
'to'属性に含まれたJIDのドメイン識別子一部に関するホスト名がそれのサーバ自体かサブドメインの構成されたホスト名の1つに合っていないなら、サーバ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
サーバからサーバへのストリームは全く2つのドメインの間に存在していません: 送付者のサーバ(1)が外国ドメインに関するホスト名を決議して(ServerからサーバへのCommunications(セクション14.4)の下で定義されるように)、(2)が2つのドメインの間のサーバからサーバへのストリームを交渉する、(TLS(セクション5)のUseとSASLのUseの下で定義される、(セクション
Saint-Andre, Ed. Standards Track [Page 58] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[58ページ]RFC3920XMPPコア2004年10月
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.
受取人のサーバへのルーティングが失敗しているなら、送付者のサーバは誤りを送付者に返さなければなりません。 受取人のサーバに連絡できますが、受取人への受取人のサーバによる配送が失敗しているなら、受取人のサーバは送付者のサーバを通して誤りを送付者に返さなければなりません。
10.3. Subdomain
10.3. サブドメイン
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のドメイン識別子一部に関するホスト名が'to'属性マッチにサーバ自体の構成されたホスト名の1つに関するサブドメインを含んだなら、サーバは、そのサブドメイン(サブドメインが構成されるなら)に原因となる専門化しているサービスにスタンザ自体を処理しなければならないか、スタンザを発送しなければならない、または誤りを送付者に返さなければなりません(サブドメインが構成されないなら)。
10.4. Mere Domain or Specific Resource
10.4. 単なるドメインか特定のリソース
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の構成されたホスト名が'to'属性に含んだ'to'属性マッチに含まれたJIDのドメイン識別子一部に関するホスト名がフォーム<ドメインの>か<ドメイン/リソース>のものであるなら、サーバ(または、それの定義されたリソース)は、スタンザ種類のために適宜スタンザを処理しなければならないか、または誤りスタンザを送付者に返さなければなりません。
10.5. Node in Same Domain
10.5. 同じドメインのノード
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の構成されたホスト名が'to'属性に含んだ'to'属性マッチに含まれたJIDのドメイン識別子一部に関するホスト名が form <node@domain のものである、gt;、<ノード@domain/リソース>('to'属性に含まれたJIDによって表されるようにSHOULDがスタンザの意図している受取人へのスタンザを提供するサーバ) 以下の規則は適用されます:
1. If the JID contains a resource identifier (i.e., is of the form
<node@domain/resource>) and there exists a connected resource
that matches the full JID, the recipient's server SHOULD deliver
the stanza to the stream or session that exactly matches the
resource identifier.
1. すなわち、JIDがリソース識別子を含んでいる、( form <node@domain/resource がある、gt;、)、完全なJID(SHOULDがまさにリソース識別子に合っているストリームかセッションまでスタンザを提供する受取人のサーバ)に合っている接続リソースは存在しています。
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に合っているどんな接続リソースも存在していないなら、受取人のサーバSHOULDはサービス入手できない</>スタンザ誤りを送付者に返します。
Saint-Andre, Ed. Standards Track [Page 59] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[59ページ]RFC3920XMPPコア2004年10月
3. If the JID is of the form <node@domain> and there exists at least
one connected resource for the node, the recipient's server
SHOULD deliver the stanza to at least one of the connected
resources, according to application-specific rules (a set of
delivery rules for instant messaging and presence applications is
defined in [XMPP-IM]).
3. JIDが form <node@domain のものである、gt;、ノード(アプリケーション特有の規則(1セットのインスタントメッセージングのための配送規則と存在アプリケーションは[XMPP-IM]で定義される)に従ってSHOULDが少なくとも接続リソースの1つへのスタンザを提供する受取人のサーバ)のための少なくともある接続リソースが存在しています。
11. XML Usage within XMPP
11. XMPPの中のXML用法
11.1. Restrictions
11.1. 制限
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.2)(そこにセクション4.6)
o character data or attribute values containing unescaped characters
that map to the predefined entities (Section 4.6 therein); such
characters MUST be escaped
o (そこにセクション4.6)を定義済み実体に写像する非エスケープしているキャラクタを含むキャラクタデータか属性値。 そのようなキャラクタから逃げなければなりません。
With regard to XML processing, if an XMPP implementation receives such restricted XML data, it MUST ignore the data.
XML処理に関して、XMPP実装がそのような制限されたXMLデータを受け取るなら、それはデータを無視しなければなりません。
11.2. XML Namespace Names and Prefixes
11.2. XML名前空間名と接頭語
XML Namespaces [XML-NAMES] are used within all XMPP-compliant XML to create strict boundaries of data ownership. The basic function of namespaces is to separate different vocabularies of XML elements that are structurally mixed together. Ensuring that XMPP-compliant XML is namespace-aware enables any allowable XML to be structurally mixed with any data element within XMPP. Rules for XML namespace names and prefixes are defined in the following subsections.
XML Namespaces[XML-NAMES]は、データ所有権の厳しい境界を作成するのにすべてのXMPP対応することのXMLの中で使用されます。 名前空間の基本機能は構造的に一緒に複雑であるXML要素の異なったボキャブラリーを切り離すことです。 XMPP対応することのXMLが名前空間意識しているのを確実にするのがどんな許容できるXMLも構造的にXMPPの中のどんなデータ要素にも混ぜられるのを可能にします。 XML名前空間名のための規則と接頭語は以下の小区分で定義されます。
Saint-Andre, Ed. Standards Track [Page 60] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[60ページ]RFC3920XMPPコア2004年10月
11.2.1. Streams Namespace
11.2.1. 名前空間を流します。
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ストリームヘッダーのREQUIREDです。 ストリーム名前空間の名前は' http://etherx.jabber.org/streams 'であるに違いありません。 ストリーム名前空間接頭語ですべての場合に<ストリーム/>要素の要素名とその<特徴/>と<誤り/>子供に資格がなければなりません。 SHOULDがこれらの要素、および歴史的な理由で'流れてください'という接頭語だけを生成する実装は'ストリームだけを受け入れるかもしれません: '接頭語。
11.2.2. Default Namespace
11.2.2. デフォルト名前空間
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).
デフォルト名前空間宣言は、REQUIREDであり、根のストリーム要素の許容できる最初に、レベル子供を定義するのにすべてのXMLストリームに使用されます。 初期のストリームと応答ストリームに、この名前空間宣言が同じであるに違いないので、両方の小川は一貫して資格があります。 デフォルト名前空間宣言はストリームの中で送られたストリームとすべてのスタンザに適用されます(別の名前空間、またはストリーム名前空間かdialback名前空間の接頭語によって明らかに資格がない場合)。
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 : クライアントについてペチャクチャしゃべってください--ストリームがクライアントとサーバとのコミュニケーションに使用されるとき、このデフォルト名前空間は宣言されます。
o jabber:server -- this default namespace is declared when the
stream is used for communications between two servers
o : サーバについてペチャクチャしゃべってください--ストリームが2つのサーバのコミュニケーションに使用されるとき、このデフォルト名前空間は宣言されます。
A client implementation MUST support the 'jabber:client' default namespace, and for historical reasons MAY support only that default namespace.
クライアント実装は、'おしゃべり: クライアント'デフォルトが名前空間であるとサポートしなければなりません、そして、歴史的な理由で、5月はそのデフォルト名前空間だけをサポートします。
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'.
実装はデフォルト名前空間は'おしゃべりです: クライアント''おしゃべり: サーバ'なら要素のためにデフォルト名前空間で名前空間接頭語を生成してはいけません。 'おしゃべり: クライアント'を除いた名前空間と'おしゃべり: サーバ'という内容(ストリームと対照的に)でSHOULD NOTが要素のために名前空間接頭語を生成する実装は資格を得ました。
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
以下に注意してください。 'おしゃべり: クライアント'と'おしゃべり: サーバ'名前空間は、ほとんど同じですが、異なった文脈(クライアントからサーバへの'おしゃべり: クライアント'へのコミュニケーションと'おしゃべり: サーバ'のためのサーバからサーバへのコミュニケーション)で使用されます。 2の唯一の違いは'to'と'from'属性が'おしゃべり: クライアント'の中で送られたスタンザのOPTIONALであるのにもかかわらずの、それらがスタンザのREQUIREDであるということです。
Saint-Andre, Ed. Standards Track [Page 61] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[61ページ]RFC3920XMPPコア2004年10月
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).
'おしゃべり: サーバ'の中で発信しました。 対応する実装が'おしゃべり: クライアント'か'おしゃべり: サーバ'名前空間によって資格がある小川を受け入れるなら、それは、一般的な属性(セクション9.1)と基本的な意味論がすべての3コアスタンザ種類(メッセージ、存在、およびIQ)の(セクション9.2)であるとサポートしなければなりません。
11.2.3. Dialback Namespace
11.2.3. Dialback名前空間
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.
dialback名前空間宣言はサーバdialback(セクション8)で使用されるすべての要素のためのREQUIREDです。 dialback名前空間の名前は'おしゃべり:サーバ:dialback'であるに違いありません。 この名前空間によって資格があったすべての要素を前に置かなければなりません。 SHOULDが'dbだけを生成する実装: 'そのような要素のための接頭語と5月は'dbだけを受け入れます: '接頭語。
11.3. Validation
11.3. 合法化
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.
'おしゃべりの中にスタンザのための'to'と'from'アドレスに関して述べられるのを除いて: サーバ'名前空間、サーバはクライアントか別のサーバに送られたXML要素を有効にするのに原因となりません。 実装は、有効にされたデータ要素だけを提供するのを選ぶかもしれませんが、これはOPTIONAL(実装は整形式でないXMLを受け入れてはいけませんが)です。 クライアントSHOULD NOTはschemasに従わないデータを送る能力を当てにします、そして、SHOULDは入って来るXMLストリームのどんな非conformant要素や属性も無視します。 XMLストリームとスタンザの合法化はOPTIONALです、そして、schemasは描写的である目的だけのためにここに含まれています。
11.4. Inclusion of Text Declaration
11.4. テキスト宣言の包含
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.
ストリームヘッダーを送る前に、実装SHOULDはテキスト宣言を送ります。 アプリケーションは[XML]でテキスト宣言が含まれている事情に関して約束を守らなければなりません。
11.5. Character Encoding
11.5. 文字符号化
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.
RFC2277[CHARSET]で実装は必要に応じてUniversal文字コード(ISO/IEC10646-1[UCS2])キャラクタのUTF-8(RFC3629[UTF-8])変換をサポートしなければなりません。 実装は、いかなる他のコード化も使用するのを試みてはいけません。
12. Core Compliance Requirements
12. コア承諾要件
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
このセクションはサポートされた状態でExtensible Messagingの特定の局面と追加議定書局面と同様にサーバとクライアントが対応する実装であると考えられるためにサポートしなければならないSHOULDがあるPresenceプロトコルをまとめます。 承諾目的のために、私たちはコアプロトコルの間で区別をつけます。
Saint-Andre, Ed. Standards Track [Page 62] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[62ページ]RFC3920XMPPコア2004年10月
(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]の該当箇所で指定されます。
12.1. Servers
12.1. サーバ
In addition to all defined requirements with regard to security, XML usage, and internationalization, a server MUST support the following core protocols in order to be considered compliant:
セキュリティ、XML用法、および国際化に関するすべての定義された要件に加えて、サーバは、言いなりになると考えられるために以下のコアがプロトコルであるとサポートしなければなりません:
o Application of the [NAMEPREP], Nodeprep (Appendix A), and
Resourceprep (Appendix B) profiles of [STRINGPREP] to addresses
(including ensuring that domain identifiers are internationalized
domain names as defined in [IDNA])
o アドレスへの[STRINGPREP]の[NAMEPREP]、Nodeprep(付録A)、およびResourceprep(付録B)プロフィールのアプリケーション(ドメイン識別子が[IDNA]で定義されるように国際化ドメイン名であることを確実にするのを含んでいます)
o XML streams (Section 4), including Use of TLS (Section 5), Use of
SASL (Section 6), and Resource Binding (Section 7)
o TLSのUse(セクション5)、SASLのUse(セクション6)、およびResource Bindingを含んでいて、XMLは流れます(セクション4)。(セクション7)
o The basic semantics of the three defined stanza kinds (i.e.,
<message/>, <presence/>, and <iq/>) as specified in stanza
semantics (Section 9.2)
o 3つのものの基本的な意味論はスタンザ意味論における指定されるとしてのスタンザ種類(すなわち、<メッセージ/>、<存在/>、および<iq/>)を定義しました。(セクション9.2)
o Generation (and, where appropriate, handling) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas
o ストリーム、TLS、SASL、およびXMLスタンザに関連する誤り構文と意味論の世代(適切であるところの取り扱い)
In addition, a server MAY support the following core protocol:
さらに、サーバは以下のコアプロトコルをサポートするかもしれません:
o Server dialback (Section 8)
o サーバdialback(セクション8)
12.2. Clients
12.2. クライアント
A client MUST support the following core protocols in order to be considered compliant:
クライアントは、言いなりになると考えられるために以下のコアがプロトコルであるとサポートしなければなりません:
o XML streams (Section 4), including Use of TLS (Section 5), Use of
SASL (Section 6), and Resource Binding (Section 7)
o TLSのUse(セクション5)、SASLのUse(セクション6)、およびResource Bindingを含んでいて、XMLは流れます(セクション4)。(セクション7)
o The basic semantics of the three defined stanza kinds (i.e.,
<message/>, <presence/>, and <iq/>) as specified in stanza
semantics (Section 9.2)
o 3つのものの基本的な意味論はスタンザ意味論における指定されるとしてのスタンザ種類(すなわち、<メッセージ/>、<存在/>、および<iq/>)を定義しました。(セクション9.2)
o Handling (and, where appropriate, generation) of error syntax and
semantics related to streams, TLS, SASL, and XML stanzas
o 誤り構文の取り扱い(適切であるところの世代)とストリーム、TLS、SASL、およびXMLスタンザに関連する意味論
Saint-Andre, Ed. Standards Track [Page 63] RFC 3920 XMPP Core October 2004
エドサンアンドレ、標準化過程[63ページ]RFC3920XMPPコア2004年10月
In addition, a client SHOULD support the following core protocols:
追加、SHOULDが以下のコアプロトコルをサポートするクライアントで:
o Generation of addresses to which the [NAMEPREP], Nodeprep
(Appendix A), and Resourceprep (Appendix B) profiles of
[STRINGPREP] can be applied without failing
o 失敗しないで[STRINGPREP]の[NAMEPREP]、Nodeprep(付録A)、およびResourceprep(付録B)プロフィールを適用できるアドレスの世代
13. Internationalization Considerations
13. 国際化問題
一覧
スポンサーリンク
