Network Working Group P. Saint-Andre
Request for Comments: 5122 XSF
Obsoletes: 4622 February 2008
Category: Standards Track
Internationalized Resource Identifiers (IRIs) and
Uniform Resource Identifiers (URIs) for
the Extensible Messaging and Presence Protocol (XMPP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP).
この文書では、同定または拡張メッセージングおよびプレゼンスプロトコル（XMPP）を介して通信することができるエンティティと相互作用における国際化リソース識別子（のIRI）とURI（Uniform Resource Identifier）の使用を定義します。
This document obsoletes RFC 4622.
この文書はRFC 4622を廃止します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use of XMPP IRIs and URIs . . . . . . . . . . . . . . . . . . 4
2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Form . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Authority Component . . . . . . . . . . . . . . . . . . . 6
2.4. Path Component . . . . . . . . . . . . . . . . . . . . . . 7
2.5. Query Component . . . . . . . . . . . . . . . . . . . . . 8
2.6. Fragment Identifier Component . . . . . . . . . . . . . . 9
2.7. Generation of XMPP IRIs/URIs . . . . . . . . . . . . . . . 10
2.8. Processing of XMPP IRIs/URIs . . . . . . . . . . . . . . . 13
2.9. Internationalization . . . . . . . . . . . . . . . . . . . 16
3. IANA Registration of xmpp URI Scheme . . . . . . . . . . . . . 16
3.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 16
3.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 17
3.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 17
3.5. Encoding Considerations . . . . . . . . . . . . . . . . . 17
3.6. Applications/Protocols That Use This URI Scheme Name . . . 18
3.7. Interoperability Considerations . . . . . . . . . . . . . 18
3.8. Security Considerations . . . . . . . . . . . . . . . . . 18
3.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.10. Author/Change Controller . . . . . . . . . . . . . . . . . 18
3.11. References . . . . . . . . . . . . . . . . . . . . . . . . 18
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5.1. Reliability and Consistency . . . . . . . . . . . . . . . 19
5.2. Malicious Construction . . . . . . . . . . . . . . . . . . 20
5.3. Back-End Transcoding . . . . . . . . . . . . . . . . . . . 20
5.4. Sensitive Information . . . . . . . . . . . . . . . . . . 20
5.5. Semantic Attacks . . . . . . . . . . . . . . . . . . . . . 21
5.6. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Differences from RFC 4622 . . . . . . . . . . . . . . 25
Appendix B. Copying Conditions . . . . . . . . . . . . . . . . . 25
The Extensible Messaging and Presence Protocol (XMPP) is a streaming XML technology that enables any two entities on a network to exchange well-defined but extensible XML elements (called "XML stanzas") at a rate close to real time.
拡張メッセージングおよびプレゼンスプロトコル（XMPP）は、リアルタイムに近い割合で（「XMLスタンザ」と呼ばれる）、明確に定義されたが、拡張可能なXML要素を交換するネットワーク上の任意の2つのエンティティを可能にストリーミングXML技術です。
As specified in [XMPP-CORE], entity addresses as used in communications over an XMPP network must not be prepended with a Uniform Resource Identifier (URI) scheme (as specified in [URI]). However, applications external to an XMPP network may need to identify XMPP entities either as URIs or, in a more modern fashion, as Internationalized Resource Identifiers (IRIs; see [IRI]). Examples of such external applications include databases that need to store XMPP addresses and non-native user agents such as web browsers and calendaring applications that provide interfaces to XMPP services.
[XMPP-CORE]で指定されるように、XMPPネットワークを介した通信に使用されるエンティティのアドレスは、（[URI]で指定されるように）ユニフォームリソース識別子（URI）方式で付加してはなりません。しかしながら、XMPPネットワークの外部アプリケーションは、URIのように、または、より現代的な方法で、国際化リソース識別子（[IRI]を参照のIRI）のいずれかとXMPPエンティティを識別する必要があるかもしれません。そのような外部アプリケーションの例としては、XMPPサービスへのインタフェースを提供するWebブラウザやカレンダーアプリケーションとしてXMPPアドレスおよび非ネイティブのユーザーエージェントを格納する必要があるデータベースを含みます。
The format for an XMPP address is defined in [XMPP-CORE]. Such an address may contain nearly any Unicode character [UNICODE] and must adhere to various profiles of stringprep [STRINGPREP]. The result is that an XMPP address is fully internationalizable and is very close to being an IRI without a scheme. However, given that there is no freestanding registry of IRI schemes, it is necessary to define XMPP identifiers primarily as URIs rather than as IRIs, and to register an XMPP URI scheme instead of an IRI scheme. Therefore, this document does the following:
XMPPアドレスのフォーマットは、[XMPP-CORE]で定義されています。このようなアドレスは、ほぼすべてのUnicode文字[UNICODE]を含むことができ、[STRINGPREP]文字列前の様々なプロファイルに準拠する必要があります。結果は、XMPPアドレスは完全に国際化され、スキームなしIRIであることに非常に近いということです。しかし、IRIスキームのいかなる自立レジストリが存在しないことを考えると、主なURIとしてよりもむしろのIRIとしてXMPP識別子を定義すること、およびIRIスキームの代わりに、XMPP URIスキームを登録することが必要です。したがって、この文書は次の処理を行います。
o Specifies how to identify XMPP entities as IRIs or URIs.
OアイリスかのURIとしてXMPPエンティティを識別する方法を指定します。
o Specifies how to interact with XMPP entities as IRIs or URIs.
OアイリスかのURIとしてXMPPエンティティと対話する方法を指定します。
o Formally defines the syntax for XMPP IRIs and URIs.
O正式XMPP虹彩とURIの構文を定義します。
o Specifies how to transform XMPP IRIs into URIs and vice versa.
oはURIとその逆にXMPPアイリスを変換する方法を指定します。
o Registers the xmpp URI scheme.
O XMPP URIスキームを登録します。
This document inherits terminology from [IRI], [URI], and [XMPP-CORE].
この文書では、[IRI]、[URI]、および[XMPP-CORE]から用語を継承します。
The 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 RFC 2119 [TERMS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [用語]で説明されるように解釈されます。
As described in [XMPP-IM], instant messaging and presence applications of XMPP must handle im: and pres: URIs (as specified by [CPIM] and [CPP]). However, there are many other applications of XMPP (including network management, workflow systems, generic publish-subscribe, remote procedure calls, content syndication, gaming, and middleware), and these applications do not implement instant messaging and presence semantics. Furthermore, a generic XMPP entity does not implement the semantics of any existing URI scheme, such as the http:, ftp:, or mailto: scheme. Therefore, it is appropriate to define a new URI scheme that makes it possible to identify or interact with any XMPP entity (not just instant messaging and presence entities) as an IRI or URI.
そしてPRES：[XMPP-IM]に記載されているように、XMPPのインスタントメッセージングおよびプレゼンスアプリケーションは、IMを処理しなければならないURIを（[CPIM]と[CPP]によって指定されるように）。しかし、そこに（ネットワーク管理、ワークフローシステム、汎用のパブリッシュ・サブスクライブ、リモート・プロシージャ・コール、コンテンツ配信、ゲーム、およびミドルウェアを含む）XMPPの他の多くの用途があり、これらのアプリケーションは、インスタントメッセージングとプレゼンスのセマンティクスを実装していません。さらに、一般的なXMPPエンティティは、HTTP :, ftpの:,またはmailtoのように、既存のURIスキームのセマンティクスを実装していません：スキーム。したがって、IRIやURIとして任意のXMPPエンティティ（インスタントメッセージングとプレゼンスエンティティだけではなく）を識別したりと対話することが可能となり、新たなURIスキームを定義することが適切です。
XMPP IRIs and URIs are defined for use by non-native interfaces and applications. In order to ensure interoperability on XMPP networks, when data is routed to an XMPP entity (e.g., when an XMPP address is contained in the 'to' or 'from' attribute of an XML stanza) or an XMPP entity is otherwise identified in standard XMPP protocol elements, the entity MUST be addressed as <[node@]domain[/resource]> (i.e., without a prepended scheme), where the "node identifier", "domain identifier", and "resource identifier" portions of an XMPP address conform to the definitions provided in Section 3 of [XMPP-CORE].
XMPP虹彩とURIは、非ネイティブインターフェースとアプリケーションで使用するために定義されています。データはXMPP実体にルーティングされたときに、XMPPネットワーク上で相互運用性を確保するために（例えば、XMPPアドレスはXMLスタンザの属性「から」「に」またはに含まれている場合）またはXMPP実体は、そうでない場合は、標準で識別されますXMPPプロトコル要素、エンティティは<ノード@]ドメイン[/リソース]>のように対処しなければならない（すなわち、プリペンドスキームなし）、「ノード識別子」、「ドメイン識別子」、およびANの「リソース識別子」部分XMPPアドレスは[XMPP-CORE]のセクション3に設けられた定義に従います。
Note: For historical reasons, the term "resource identifier" is used in XMPP to refer to the optional portion of an XMPP address that follows the domain identifier and the "/" separator character (for details, refer to Section 3.4 of [XMPP-CORE]); this use of the term "resource identifier" is not to be confused with the meanings of "resource" and "identifier" provided in Section 1.1 of [URI].
注：歴史的な理由のために、用語「リソース識別子」は、ドメイン識別子を以下のXMPPアドレスの任意の部分を指すためにXMPPに使用されており、詳細は「/」区切り文字（[XMPP-のセクション3.4を参照コア]）;用語「リソース識別子」の使用は[URI]のセクション1.1に提供される「リソース」と「識別子」の意味と混同されるべきではありません。
XMPP IRIs and URIs are defined primarily for the purpose of identification rather than of interaction (regarding this distinction, see Section 1.2.2 of [URI]). The "Internet resource" identified by an XMPP IRI or URI is an entity that can communicate via XMPP over a network. An XMPP IRI or URI can contain additional information above and beyond the identified resource; in particular, as described under Section 2.5 a query component can be included to specify suggested semantics for an interaction with the identified resource. It is envisioned that when an XMPP application resolves an XMPP IRI or URI containing suggested interaction semantics, the application will generate an XMPP stanza and send it to the identified resource, where the generated stanza may include user or application inputs that are consistent with the suggested interaction semantics (for details, see Section 2.8.1).
XMPP虹彩とURIは主にむしろ相互作用のより特定の目的のために定義されている（この区別について、[URI]のセクション1.2.2を参照）。 XMPP IRIまたはURIによって識別される「インターネットリソース」は、ネットワークを介してXMPPを介して通信することができるエンティティです。 XMPP IRIやURIは、上記と識別されるリソース以外の追加情報を含めることができます。具体的には、2.5節で説明したようにクエリコンポーネントは、識別されたリソースとの相互作用のために提案さセマンティクスを指定するために含めることができます。なお、XMPPアプリケーションが提案対話セマンティクスを含むXMPP IRIやURIを解決するとき、アプリケーションはXMPPスタンザを生成し、生成されたスタンザが示唆と一致しているユーザーまたはアプリケーション入力を含むことが識別されたリソースにそれを送信することが想定されます対話のセマンティクス（詳細については、2.8.1項を参照してください）。
As described in [XMPP-CORE], an XMPP address used natively on an XMPP network is a string of Unicode characters that (1) conforms to a certain set of stringprep [STRINGPREP] profiles and IDNA restrictions [IDNA], (2) follows a certain set of syntax rules, and (3) is encoded as UTF-8 [UTF-8]. The form of such an address can be represented using Augmented Backus-Naur Form [ABNF] as:
[XMPP-CORE]で説明されるように、XMPPネットワーク上でネイティブに使用XMPPアドレスは、（1）文字列準備[STRINGPREP]プロファイルとIDNA制限の特定の組[IDNA]に準拠したUnicode文字の文字列である（2）以下の特定の構文規則のセット、および（3）UTF-8 [UTF-8]として符号化されます。そのようなアドレスの形式を用いて表現することができた拡張バッカスナウア記法[ABNF]のように：
[ node "@" ] domain [ "/" resource ]
[ノード "@"]、ドメイン[ "/" リソース]
In this context, the "node" and "resource" rules rely on distinct profiles of stringprep [STRINGPREP], and the "domain" rule relies on the concept of an internationalized domain name as described in [IDNA]. (Note: There is no need to refer to punycode in the IRI syntax itself, since any punycode representation would occur only inside an XMPP application in order to represent internationalized domain names. However, it is the responsibility of the processing application to convert IRI syntax [IRI] into IDNA syntax [IDNA] before addressing XML stanzas to the specified entity on an XMPP network.)
この文脈において、「ノード」と「リソース」のルールは、文字列準備の異なるプロファイル[STRINGPREP]に依存し、そして[IDNA]に記載されているように、「ドメイン」ルールは、国際化ドメイン名の概念に依存しています。 （注意：IRI構文自体にPunycodeで参照する必要はありません、任意のPunycodeでの表現は、国際化ドメイン名を表現するために、唯一のXMPPアプリケーション内に発生するので、しかし、IRI構文を変換するための処理アプリケーションの責任です。 [IRI] IDNA構文[IDNA]にXMPPネットワーク上の指定されたエンティティにXMLスタンザに対処する前に）。
Certain characters are allowed in XMPP node identifiers and XMPP resource identifiers but not in the relevant portion of an IRI or URI. The characters are as follows:
特定の文字はなく、IRIやURIの関連部分におけるXMPPノード識別子とXMPPリソース識別子に許可されています。次のような文字は、次のとおりです。
In node identifiers: [ \ ] ^ ` { | }
ノード識別子で：[\] ^ `{| }
In resource identifiers: " < > [ \ ] ^ ` { | }
リソース識別子で： "<> [\] ^` {|}
The node identifier characters are not allowed in userinfo by the sub-delims rule and the resource identifier characters are not allowed in segment by the pchar rule. These characters MUST be percent-encoded when transforming an XMPP address into an XMPP IRI or URI.
ノード識別子の文字は、サブdelims規則によってユーザー情報で許可されていないと、リソース識別子文字はPChar型ルールによってセグメントに許されません。 XMPP IRIまたはURIにXMPPアドレスを変換する際にこれらの文字は、パーセントエンコードする必要があります。
Naturally, in order to be converted into an IRI or URI, an XMPP address must be prepended with a scheme (specifically, the xmpp scheme) and may also need to undergo transformations that adhere to the rules defined in [IRI] and [URI]. Furthermore, in order to enable more advanced interaction with an XMPP entity rather than simple identification, it is desirable to take advantage of additional aspects of URI syntax and semantics, such as authority components, query components, and fragment identifier components.
当然のことながら、IRI又はURIに変換するために、XMPPアドレススキーム（具体的には、XMPP方式）を用いて付加する必要があり、また、[IRI]および[URI]定義された規則に準拠変換を受ける必要があるかもしれません。また、XMPPエンティティではなく、単純な識別と、より高度な相互作用を可能にするために、このような権限コンポーネント、クエリコンポーネント、およびフラグメント識別子成分としてURIの構文およびセマンティクスの追加の態様を活用することが望ましいです。
Therefore, the ABNF syntax for an XMPP IRI is defined as shown below using Augmented Backus-Naur Form specified by [ABNF], where the "ifragment", "ihost", and "iunreserved" rules are defined in [IRI] and the "pct-encoded" rule is defined in [URI]:
「ifragment」、「ihost」、および「iunreserved」規則は[IRI]および「定義されている[ABNF]で指定された拡張バッカスナウア記法を用いて以下に示すようしたがって、XMPP IRIのためのABNF構文が定義されていますPCTエンコード規則は、[URI]で定義されています」：
xmppiri = "xmpp" ":" ihierxmpp [ "?" iquerycomp ] [ "#" ifragment ] ihierxmpp = iauthpath / ipathxmpp iauthpath = "//" iauthxmpp [ "/" ipathxmpp ] iauthxmpp = inodeid "@" ihost ipathxmpp = [ inodeid "@" ] ihost [ "/" iresid ] inodeid = *( iunreserved / pct-encoded / nodeallow ) nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" / "=" iresid = *( iunreserved / pct-encoded / resallow ) resallow = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ":" / ";" / "=" iquerycomp = iquerytype [ *ipair ] iquerytype = *iunreserved ipair = ";" ikey "=" ivalue ikey = *iunreserved ivalue = *( iunreserved / pct-encoded )
xmppiri = "XMPP" "：" ihierxmppの[ ""？ iquerycomp] [ "＃" ifragment] ihierxmpp = iauthpath / ipathxmpp iauthpath = "//" iauthxmppの[ "/" ipathxmpp] iauthxmpp = inodeid "@" ihost ipathxmpp = [inodeid "@"] ihost [ "/" iresid] inodeid = *（iunreserved / / nodeallow PCT-エンコード）nodeallow = "！" / "$" / "（" / "）" / "*" / "+" / "" / ";" / "=" iresid = *（iunreserved / / resallow PCT-エンコード）resallow = "！" / "$" / "＆" / "'" / "（" / "）" / "*" / "+" / "、" / "：" / ";" / "=" iquerycomp = iquerytype [* ipair] iquerytype = * iunreserved ipair = ";" iKey "=" ivalue用のiKey = * iunreserved ivalue = *（iunreserved / PCTエンコード）
However, the foregoing syntax is not appropriate for inclusion in the registration of the xmpp URI scheme, since the IANA recognizes only URI schemes and not IRI schemes. Therefore, the ABNF syntax for an XMPP URI rather than for IRI is defined as shown in Section 3.3 of this document. If it is necessary to convert the IRI syntax into URI syntax, an application MUST adhere to the mapping procedure specified in Section 3.1 of [IRI].
IANAのみURIスキームはなくIRIスキームを認識するので、上記の構文は、XMPP URIスキームの登録に含めるには適していません。したがって、XMPP URIのためではなく、IRIのためのABNF構文は、このドキュメントのセクション3.3に示すように定義されます。それは、URIの構文にIRI構文を変換する必要がある場合、アプリケーションは[IRI]のセクション3.1で指定されたマッピング手順に従わなければなりません。
The following is an example of a basic XMPP IRI/URI used for purposes of identifying a node associated with an XMPP server:
基本的なXMPP IRI / URIの例は、XMPPサーバに関連付けられているノードを特定の目的のために使用される次
xmpp:node@example.com
XMPP：node@example.com
Descriptions of the various components of an XMPP IRI/URI are provided in the following sections.
XMPP IRI / URIの様々な構成要素の説明は以下のセクションで提供されます。
As explained in Section 2.8 of this document, in the absence of an authority component, the processing application would authenticate as a configured user at a configured XMPP server. That is, the authority component section is unnecessary and should be ignored if the processing application has been configured with a set of default credentials.
このドキュメントのセクション2.8で説明したように、権限の成分の非存在下で、処理アプリケーションは、設定XMPPサーバで構成されたユーザーとして認証することになります。これは、権限コンポーネントセクションが不要であり、処理アプリケーションは既定の資格情報のセットで構成されている場合は無視されるべきです。
In accordance with Section 3.2 of RFC 3986 [URI], the authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the IRI/URI. As explained more fully in Section 2.8.1 of this document, the presence of an authority component signals the processing application to authenticate as the node@domain specified in the authority component rather than as a configured node@domain (see the Security Considerations section of this document regarding authentication). (While it is unlikely that the authority component will be included in most XMPP IRIs or URIs, the scheme allows for its inclusion, if appropriate.) Thus, the following XMPP IRI/URI indicates to authenticate as "guest@example.com":
RFC 3986 [URI]の3.2節に従い、権限コンポーネントは、ダブルスラッシュ（「//」）が先行して、次のスラッシュ（「/」）、疑問符（「？」）、または番号で終了されます記号（「＃」）文字、またはIRI / URIの終わりまでに。このドキュメントのセクション2.8.1でより完全に説明するように、権限の成分の存在は、権限コンポーネントではなく、構成されたノード@ドメインとして指定されたノード@ドメインとして認証する処理アプリケーションを信号（のセキュリティ考慮事項を参照してくださいこの文書に関する認証）。 （それは権限コンポーネントが最もXMPPのIRIやURIの中に含まれる可能性は低いものの、適切な場合、スキームは、その包含を可能にする。）このように、以下のXMPP IRI / URIは「guest@example.com」として認証することを示しています。
xmpp://guest@example.com
XMPP：//guest@example.com
Note well that this is quite different from the following XMPP IRI/ URI, which identifies a node "guest@example.com" but does not signal the processing application to authenticate as that node:
これは以下のXMPP IRI / URIは全く異なることはよく注意し、ノードを識別する「guest@example.com」が、そのノードとして認証する処理アプリケーションを通知しません。
xmpp:guest@example.com
XMPP：guest@example.com
Similarly, using a possible query component of "?message" to trigger an interface for sending a message, the following XMPP IRI/URI signals the processing application to authenticate as "guest@example.com" and to send a message to "support@example.com":
同様の「？メッセージ」メッセージを送信するためのインタフェースをトリガすることが可能とクエリコンポーネントを使用して、以下のXMPP IRI / URIは「guest@example.com」として認証し、サポート」にメッセージを送信するために処理アプリケーションに信号を送ります@ example.com」：
xmpp://guest@example.com/support@example.com?message
XMPP：//guest@example.com/support@example.comメッセージ？
By contrast, the following XMPP IRI/URI signals the processing application to authenticate as its configured default account and to send a message to "support@example.com":
これとは対照的に、以下のXMPP IRI / URIは、処理アプリケーションは、その設定されたデフォルトのアカウントとして認証し、「support@example.com」にメッセージを送信する信号：
xmpp:support@example.com?message
XMPP：support@example.comメッセージ？
The path component of an XMPP IRI/URI identifies an XMPP address or specifies the XMPP address to which an XML stanza shall be directed at the end of IRI/URI processing.
XMPP IRI / URIのパスコンポーネントは、XMPPアドレスを特定するか、XMLスタンザがIRI / URI処理の終了に向けなければならないためXMPPアドレスを指定します。
For example, the following XMPP IRI/URI identifies a node associated with an XMPP server:
例えば、以下のXMPP IRI / URIは、XMPPサーバに関連付けられているノードを識別する。
xmpp:example-node@example.com
XMPP：example-node@example.com
The following XMPP IRI/URI identifies a node associated with an XMPP server along with a particular XMPP resource identifier associated with that node:
以下のXMPP IRI / URIは、そのノードに関連付けられた特定のXMPPリソース識別子とともにXMPPサーバに関連付けられているノードを識別する。
xmpp:example-node@example.com/some-resource
XMPP：example-node@example.com/some-resource
Inclusion of a node is optional in XMPP addresses, so the following XMPP IRI/URI simply identifies an XMPP server:
ノードの包含は、XMPPアドレスにオプションであるので、以下のXMPP IRI / URIは単にXMPPサーバを識別する。
xmpp:example.com
XMPP：example.com
There are many potential use cases for encapsulating information in the query component of an XMPP IRI/URI for the purpose of specifying suggested interaction semantics (see Section 2.1); examples include, but are not limited to:
提案対話セマンティクスを指定するために、XMPP IRI / URIのクエリコンポーネントに情報をカプセル化するための多くの潜在的なユースケースは、（セクション2.1を参照）があります。例としては、これらに限定されません：
o sending an XMPP message stanza (see [XMPP-IM]),
、XMPPメッセージスタンザを送信O（[XMPP-IM]を参照）
o adding a roster item (see [XMPP-IM]),
名簿項目を追加O（[XMPP-IM]を参照）、
o sending a presence subscription (see [XMPP-IM]),
プレゼンス購読を送信O（[XMPP-IM]を参照）、
o probing for current presence information (see [XMPP-IM]),
現在のプレゼンス情報をプロービングO（[XMPP-IM]を参照）、
o triggering a remote procedure call (see [XEP-0009]),
リモート・プロシージャ・コールをトリガO（[XEP-0009]を参照）、
o discovering the identity or capabilities of another entity (see [XEP-0030]),
、別のエンティティの同一性または機能を発見O（[XEP-0030]を参照）
o joining an XMPP-based text chat room (see [XEP-0045]),
、XMPPベースのテキストチャットルームに参加O（[XEP-0045]を参照）
o interacting with publish-subscribe channels (see [XEP-0060]),
、パブリッシュ・サブスクライブチャネルと相互作用O（[XEP-0060]を参照）
o providing a SOAP interface (see [XEP-0072]), and
SOAPインターフェイスを提供O（[XEP-0072]を参照）、および
o registering with another entity (see [XEP-0077]).
別のエンティティに登録O（[XEP-0077]を参照）。
Many of these potential use cases are application specific, and the full range of such applications cannot be foreseen in advance given the continued expansion in XMPP development. However, there is agreement within the Jabber/XMPP developer community that all the uses envisioned to date can be encapsulated via a "query type", optionally supplemented by one or more "key-value" pairs (this is similar to the "application/x-www-form-urlencoded" MIME type described in [HTML]).
これらの潜在的なユースケースの多くは、アプリケーション固有であり、そのようなアプリケーションの完全な範囲は、XMPPの開発の継続的な拡大与え、事前に予見することはできません。しかし、これまでに想定されるすべての使用は、必要に応じて1つまたは複数の「キーと値」のペアによって補わ、「クエリタイプ」を介してカプセル化することができるのJabber / XMPP開発者コミュニティ内の合意がある（これは/「アプリケーションと同様ですx-www-form-urlencodedで[HTML]に記載の」MIMEタイプ）。
As an example, an XMPP IRI/URI intended to launch an interface for sending a message to the XMPP entity "example-node@example.com" might be represented as follows:
次のように、一例として、XMPP IRI / URIは、XMPPエンティティ「example-node@example.com」にメッセージを送信するためのインタフェースを起動することを意図するもので表されるかもしれません。
xmpp:example-node@example.com?message
XMPP：example-node@example.comメッセージ？
Similarly, an XMPP IRI/URI intended to launch an interface for sending a message to the XMPP entity "example-node@example.com" with a particular subject might be represented as follows:
同様に、XMPP IRI / URIは、次のように表現されるかもしれない特定の対象とXMPPエンティティ「example-node@example.com」にメッセージを送信するためのインタフェースを起動することを意図するもの：
xmpp:example-node@example.com?message;subject=Hello%20World
XMPP：example-node@example.comメッセージ、件名=こんにちは％の20World？
If the processing application does not understand query components or the specified query type, it MUST ignore the query component and treat the IRI/URI as consisting of, for example, <xmpp:example-node@example.com> rather than <xmpp:example-node@example.com?query>. If the processing application does not understand a particular key within the query component, it MUST ignore that key and its associated value.
処理アプリケーションは、クエリコンポーネントまたは指定されたクエリのタイプを理解しない場合は、クエリコンポーネントを無視しなければならなくて、例えば、から成るようIRI / URIを治療する、<XMPP：example-node@example.com>なく<XMPP。 example-node@example.com?query>。処理アプリケーションは、クエリコンポーネント内の特定のキーを理解していない場合は、そのキーとその値を無視しなければなりません。
As noted, there exist many kinds of XMPP applications (both actual and potential), and such applications may define query types and keys for use in the query component portion of XMPP URIs. The XMPP Registrar function (see [XEP-0053]) of the XMPP Standards Foundation maintains a registry of such query types and keys at <http://www.xmpp.org/registrar/querytypes.html>. To help ensure interoperability, any application using the formats defined in this document SHOULD submit any associated query types and keys to that registry in accordance with the procedures specified in [XEP-0147].
述べたように、そこに（実際の及び潜在的な両方）XMPPのアプリケーションの多くの種類が存在し、そのようなアプリケーションは、XMPP URIのクエリコンポーネントの部分で使用するためにクエリの種類とキーを定義することができます。 XMPP規格財団のXMPP Registrarの機能は、（[XEP-0053]を参照）<http://www.xmpp.org/registrar/querytypes.html>で、このようなクエリの種類とキーのレジストリを維持します。相互運用性を確保するために、このドキュメントで定義されたフォーマットを使用して任意のアプリケーションは、[XEP-0147]で指定された手順に従って、そのレジストリに関連するクエリの種類とキーを提出しなければなりません。
Note: The delimiter between key-value pairs is the ";" character instead of the "&" character used in many other URI schemes. This delimiter was chosen in order to avoid problems with escaping of the & character in HTML and XML applications.
注：キーと値のペア間の区切り文字は「;」代わりに、他の多くのURIスキームで使用される「＆」の文字の文字。この区切り文字は、HTMLやXMLアプリケーションにおける＆文字のエスケープの問題を回避するために選ばれました。
As stated in Section 3.5 of [URI], "The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information." Because the resource identified by an XMPP IRI/URI does not make available any media type (see [MIME]) and therefore (in the terminology of [URI]) no representation exists at an XMPP resource, the semantics of the fragment identifier component in XMPP IRIs/URIs are to be "considered unknown and, effectively, unconstrained" (ibid.). Particular XMPP applications MAY make use of the fragment identifier component for their own purposes. However, if a processing application does not understand fragment identifier components or the syntax of a particular fragment identifier component included in an XMPP IRI/URI, it MUST ignore the fragment identifier component.
[URI]のセクション3.5で述べたように、「URIの断片識別子コンポーネントは、一次リソースと追加の識別情報を参照することにより、二次リソースの間接的な同定を可能にします」。 XMPP IRI / URIによって識別されたリソースが利用可能な任意のメディアタイプを作成していないため（参照[MIME]）したがって（[URI]の用語では）全く表現はXMPPリソースに存在しない、フラグメント識別子コンポーネントの意味論にXMPP IRIを/ URIは（同上）「制約のない、効果的に、不明とみなされ、」すべきです。特定のXMPPアプリケーションは、独自の目的のためにフラグメント識別子コンポーネントを利用することができます。処理アプリケーションは、フラグメント識別子コンポーネントまたはXMPP IRI / URIに含まれる特定のフラグメント識別子コンポーネントの構文を理解していない場合は、それは断片識別子コンポーネントを無視しなければなりません。
In order to form an XMPP IRI from an XMPP node identifier, domain identifier, and resource identifier, the generating application MUST first ensure that the XMPP address conforms to the rules specified in [XMPP-CORE], including encoding as a UTF-8 [UTF-8] string and application of the relevant stringprep profiles [STRINGPREP]. Because IRI syntax [IRI] specifies that the characters in an IRI are the original Unicode characters themselves [UNICODE], when generating an XMPP IRI the generating application MUST then decode the UTF-8 [UTF-8] characters of a native XMPP address to their original Unicode form. The generating application then MUST concatenate the following:
XMPPノード識別子、ドメイン識別子、およびリソース識別子からXMPP IRIを形成するために、生成アプリケーションは、最初の[XMPPアドレスがUTF-8のような符号化を含む[XMPP-CORE]で指定された規則に準拠していることを確認しなければなりませんUTF-8]文字列と関連する文字列準備プロフィール[STRINGPREP]のアプリケーション。 IRI構文[IRI]はIRIの文字が元のUnicode文字そのもの[UNICODE]があることを指定するので、次に、UTF-8を復号しなければならないXMPP IRIを生成アプリケーションを生成するときに[UTF-8]ネイティブXMPPアドレスの文字それらの元のUnicode形式。生成アプリケーションは、以下を連結しなければなりません。
2. Optionally (if an authority component is to be included before the node identifier), the characters "//", an authority component of the form node@domain, and the character "/".
2.オプション（権限コンポーネントは、ノード識別子の前に含まれている場合）、文字「//」、フォームのノード@ドメインの権限コンポーネント、および文字「/」。
3. Optionally (if the XMPP address contained an XMPP "node identifier"), a string of Unicode characters that conforms to the "inodeid" rule, followed by the "@" character.
3.オプション（XMPPアドレスがXMPP「ノード識別子」を含む場合）、「@」文字が続く「inodeid」ルールに準拠Unicode文字のストリング。
5. Optionally (if the XMPP address contained an XMPP "resource identifier"), the character "/" and a string of Unicode characters that conforms to the "iresid" rule.
5.必要に応じて、文字「/」と「iresid」ルールに準拠Unicode文字の文字列（XMPPアドレスがXMPP「リソース識別子」を含む場合）。
6. Optionally (if a query component is to be included), the "?" character and query component.
6.オプション（クエリコンポーネントが含まれるべきである場合）、「？」文字やクエリコンポーネント。
7. Optionally (if a fragment identifier component is to be included), the "#" character and fragment identifier component.
7.オプション（断片識別子コンポーネントが含まれるべきである場合）、「＃」文字とフラグメント識別子コンポーネント。
In order to form an XMPP URI from the resulting IRI, an application MUST adhere to the mapping procedure specified in Section 3.1 of [IRI].
得られたIRIからXMPP URIを形成するために、アプリケーションは[IRI]のセクション3.1で指定されたマッピング手順に従わなければなりません。
Certain characters are allowed in the node identifier, domain identifier, and resource identifier portions of a native XMPP address but prohibited by the "inodeid", "ihost", and "iresid" rules of an XMPP IRI. Specifically, the "#" and "?" characters are allowed in node identifiers, and the "/", "?", "#", and "@" characters are allowed in resource identifiers, but these characters are used as delimiters in XMPP IRIs. In addition, the " " ([US-ASCII] space) character is allowed in resource identifiers but prohibited in IRIs. Therefore, all the foregoing characters MUST be percent-encoded when transforming an XMPP address into an XMPP IRI.
特定の文字は、ノード識別子、ドメイン識別子、及び天然XMPPアドレスのリソース識別子部分で許可が、「inodeid」、「ihost」、およびXMPP IRIの「iresid」規則によって禁止されています。具体的には、「＃」と「？」文字は、ノード識別子で許可されており、「/」、「？」、「＃」、および「@」の文字がリソース識別子に許可されているが、これらの文字はXMPP虹彩区切り文字として使用されています。また、「」（[US-ASCII]空白）文字がリソース識別子に許可されているが、虹彩禁止します。 XMPP IRIにXMPPアドレスを変換する場合したがって、すべての前述の文字はパーセントエンコードする必要があります。
Consider the following nasty node in an XMPP address:
XMPPアドレスに以下の厄介なノードを考慮してください。
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
厄介なの＃$％（）* +、 - 、！。？= [\] ^ _ `{|}~node@example.com
That address would be transformed into the following XMPP IRI (split into two lines for layout purposes):
そのアドレスは、（レイアウト目的のために2行に分割）は、以下のXMPP IRIに変換されるであろう。
xmpp:nasty!%23$%25()*+,-.;=%3F%5B%5C%5D%5E_%60%7B%7C%7D~node @example.com
XMPP：厄介％23 $の25％（）* +、 - 、=％3F％5B％5C％5D％5E_％60％7B％7C％7D〜ノード@ example.com！。
Consider the following repulsive resource in an XMPP address (split into two lines for layout purposes):
XMPPアドレス（レイアウト目的のための2つの行に分割）で次の反発リソースを考慮してください。
node@example.com /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
！node@example.com /反発＃ "$の％＆ '（）* +、 - / :; <=> @ [\] ^ _`。？{|}〜資源
That address would be transformed into the following XMPP IRI (split into three lines for layout purposes):
そのアドレスは、（レイアウト目的のための3つの行に分割）は、以下のXMPP IRIに変換されるであろう。
xmpp:node@example.com /repulsive%20!%23%22$%25&'()*+,-.%2F:;%3C= %3E%3F%40%5B%5C%5D%5E_%60%7B%7C%7D~resource
XMPP：node@example.com /repulsive%20!%23%22$%25&'()*+,-.%2F:;%3C=％3E％3F％の40％5B％5C％の5Dの％5E_％60 ％7B％7C％7D〜資源
Furthermore, virtually any character outside the US-ASCII range [US-ASCII] is allowed in an XMPP address and therefore also in an XMPP IRI, but URI syntax forbids such characters directly and specifies that such characters MUST be percent-encoded. In order to determine the URI associated with an XMPP IRI, an application MUST adhere to the mapping procedure specified in Section 3.1 of [IRI].
また、US-ASCIIの範囲外の実質的に任意の文字[US-ASCII]はXMPPアドレスで許可されており、したがって、XMPP IRIではなく、URIの構文は、直接そのような文字を禁止し、そのような文字がパーセント符号化しなければならないことを指定します。 XMPP IRIに関連付けられたURIを決定するために、アプリケーションは[IRI]のセクション3.1で指定されたマッピング手順に従わなければなりません。
The following table may assist implementors in understanding the respective encodings and "carrier units" of the identifiers discussed in this document, namely: (1) native XMPP addresses, (2) IRIs, and (3) URIs. For details, refer to Section 3.5 of this document as well
（1）ネイティブXMPPアドレス、（2）アイリス、及び（3）のURI：以下の表は、それぞれのエンコーディングと、すなわち、この文書で説明した識別子の「キャリア単位」を、理解する上で実装を支援することができます。詳細については、同様にこのドキュメントのセクション3.5を参照してください。
as Section 3 of [XMPP-CORE], Section 6.4 of [IRI], and Section 2 of [URI].
[XMPP-CORE]、[IRI]のセクション6.4、及び[URI]の第2のセクション3として。
+--------------+-----------+-----------+
| Identifier | Encoding | Units |
+--------------+-----------+-----------+
| XMPP address | UTF-8 | Octets |
+--------------+-----------+-----------+
| IRI | Unicode | 16/32-bit |
| | | values |
+--------------+-----------+-----------+
| URI | Percent- | US-ASCII |
| | encoded | |
| | UTF-8 | |
+--------------+-----------+-----------+
Consider the following XMPP address:
以下のXMPPアドレスを考えてみましょう：
<jiři@čechy.example/v Praze>
<それ＆＃のx159; I＆@＃X10D; echy.example /プラハ>
Note: The string "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON, and the string "č" stands for the Unicode character LATIN SMALL LETTER C WITH CARON. The "&#x..." form is used in this document as a notational device to represent Unicode characters, following the "XML Notation" used in [IRI] to represent characters that cannot be rendered in ASCII-only documents. An XMPP IRI MUST contain the Unicode characters themselves, not the representation in XML Notation (in particular, note that the "#" character is forbidden in IRI syntax). An XMPP URI MUST properly escape such characters, as described below. The '<' and '>' characters are not part of the address itself but are provided to set off the address for legibility. (For those who do not understand the Czech language, this example could be Anglicized as "george@czech-lands.example/In Prague".)
注意：文字列「＆＃x159のを、」 Unicodeの文字LATIN SMALL LETTER CARON WITH R、および文字列を意味し、 "＆＃X10D;" CARON WITH Unicode文字LATIN SMALL LETTERのCの略です。 「＆＃xは...」形式はASCIIのみの文書にレンダリングできない文字を表すために、[IRI]で使用される「XML表記」以下、Unicode文字を表すために表記デバイスとしてこの文書で使用されています。 XMPP IRIは、（特に、「＃」の文字がIRI構文で禁止されていることに注意してください）Unicode文字そのもの、XML表記のない表現が含まれていなければなりません。後述のようにXMPP URIは適切に、そのような文字をエスケープする必要があります。 「<」と「>」の文字はアドレス自体の一部ではないが、読みやすくするためのアドレスをオフに設定するために設けられています。 （チェコ語を理解していない人のために、この例では、「george@czech-lands.example/Inプラハ」として英国化することができます。）
In accordance with the process specified above, the generating application would do the following to generate a valid XMPP IRI from this address:
上記の方法によれば、生成アプリケーションは、このアドレスから有効なXMPP IRIを生成するには、次の操作を行います。
1. Ensure that the XMPP address conforms to the rules specified in [XMPP-CORE], including application of the relevant stringprep profiles [STRINGPREP] and encoding as a UTF-8 string [UTF-8].
1. XMPPアドレスがUTF-8文字列[UTF-8]などの関連文字列準備プロファイルの適用[STRINGPREP]及び符号化を含む[XMPP-CORE]で指定された規則に準拠していることを確認してください。
2. An "authority component" if included (not shown in this example).
2.アン「権限コンポーネント」含まれている場合（この例では示されていません）。
3. A string of Unicode characters that represents the XMPP address, transformed in accordance with the "inodeid", "ihost", and "iresid" rules.
3.「inodeid」、「ihost」、および「iresid」ルールに従って変換XMPPアドレスを表すUnicode文字のストリング。
4. The "?" character followed by a "query component" if appropriate to the application (not shown in this example).
4. "？" 「クエリコンポーネント」（この例では示されていない）アプリケーションに適切であれば続く文字。
5. The "#" character followed by a "fragment identifier component" if appropriate to the application (not shown in this example).
5.アプリケーションに適切な場合、「断片識別子コンポーネント」に続いて「＃」文字（この例では示されていません）。
The result is the following XMPP IRI (note again that, in accordance with the "XML Notation" used in [IRI], the string "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON and the string "č" stands for the Unicode character LATIN SMALL LETTER C WITH CARON; an XMPP IRI would contain the Unicode characters themselves).
CARON WITH Unicode文字LATIN SMALL LETTERのRと文字列「＆を表し、「＆＃x159の」結果は、[IRI]、文字列で使用される「XML表記」に基づいて、再びその次XMPP IRI（ノートです＃X10D;」CARON WITH Unicode文字LATIN SMALL LETTERのCを表し、XMPP IRIは、Unicode文字そのもの）が含まれています。
<xmpp:jiři@čechy.example/v%20Praze>
<XMPP：JI＆＃のx159; I @＆＃X10D; echy.example / v％の20Praze>
In order to generate a valid XMPP URI from the foregoing IRI, the application MUST adhere to the procedure specified in Section 3.1 of [IRI], resulting in the following URI:
上記IRIから有効なXMPP URIを生成するために、アプリケーションは、次のURIをもたらす、[IRI]のセクション3.1で指定された手順に従わなければなりません。
<xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
<XMPP：ji%C5%99i@%C4%8Dechy.example/v%20Praze>
If a processing application is presented with an XMPP URI and not with an XMPP IRI, it MUST first convert the URI into an IRI by following the procedure specified in Section 3.2 of [IRI].
処理アプリケーションはXMPP IRIとXMPP URIとしないで提示されている場合、それは最初の[IRI]のセクション3.2で指定された手順に従うことによりIRIにURIを変換しなければなりません。
In order to decompose an XMPP IRI for interaction with the entity it identifies, a processing application MUST separate:
それは識別エンティティとの相互作用のためのXMPP IRIを分解するために、処理アプリケーションを分離しなければなりません。
2. The authority component, if included (the string of Unicode characters between the "//" characters and the next "/" character, the "?" character, the "#" character, or the end of the IRI).
2.権限コンポーネント、含まれている場合（「//」の文字と、次の「/」文字の間にUnicode文字の文字列、「？」の文字、「＃」の文字、またはIRIの終わり）。
3. A string of Unicode characters that represents an XMPP address as transformed in accordance with the "inodeid", "ihost", and "iresid" rules.
3.「inodeid」、「ihost」、および「iresid」規則に従って形質としてXMPPアドレスを表すUnicode文字のストリング。
4. Optionally the query component, if included, using the "?" character as a separator.
4.必要に応じてクエリコンポーネント、含まれている場合、使用して「？」セパレータとして文字。
5. Optionally the fragment identifier component, if included, using the "#" character as a separator.
5.オプション断片識別子コンポーネント、含まれている場合、セパレータとして「＃」文字を使用して。
At this point, the processing application MUST ensure that the resulting XMPP address conforms to the rules specified in [XMPP-CORE], including application of the relevant stringprep profiles [STRINGPREP]. The processing application then would either (1) complete further XMPP handling itself or (2) invoke a helper application to complete XMPP handling; such XMPP handling would most likely consist of the following steps:
この時点で、処理アプリケーションは、得られたXMPPアドレスが[STRINGPREP]関連する文字列準備プロフィールのアプリケーションを含む、[XMPP-CORE]で指定された規則に準拠することを保証しなければなりません。処理アプリケーション、次いで（1）完全さらにXMPP自体を取り扱うまたは（2）XMPP処理を完了するために、ヘルパーアプリケーションを起動することになるのいずれか;このようXMPP処理は最も可能性の高い次のステップで構成されます：
1. If not already connected to an XMPP server, connect either as the user specified in the authority component or as the configured user at the configured XMPP server, normally by adhering to the XMPP connection procedures defined in [XMPP-CORE]. (Note: The processing application SHOULD ignore the authority component if it has been configured with a set of default credentials.)
1.既にXMPPサーバに接続されていない場合、通常で定義されたXMPP接続手順に付着することにより、権限コンポーネントで指定されたユーザーとして、または構成XMPPサーバで構成されたユーザーのいずれかと接続[XMPP-CORE]。 （注：これは既定の資格情報のセットで構成されている場合、処理アプリケーションは、権限コンポーネントを無視すべきです。）
2. Optionally, determine the nature of the intended recipient (e.g., via [XEP-0030]).
2.必要に応じて、（[XEP-0030]を介して、例えば、）意図されるレシピエントの性質を決定します。
3. Optionally, present an appropriate interface to a user based on the nature of the intended recipient and/or the contents of the query component.
3.必要に応じて、意図されるレシピエント及び/又はクエリコンポーネントの内容の性質に基づいて、ユーザに適切なインタフェースを提示します。
4. Generate an XMPP stanza that translates any user or application inputs into their corresponding XMPP equivalents.
4.それらの対応するXMPP同等物に任意のユーザまたはアプリケーション入力を変換XMPPスタンザを生成します。
5. Send the XMPP stanza via the authenticated server connection for delivery to the intended recipient.
5.目的の受信者に配信するために、認証サーバー接続を介してXMPPスタンザを送信します。
It may help implementors to note that the first two steps of "further XMPP handling", as described at the end of Section 2.8.1, are similar to HTTP authentication [HTTP-AUTH], while the next three steps are similar to the handling of mailto: URIs [MAILTO].
これは、実装者は、セクション2.8.1の最後で説明したように次の3つのステップは取り扱いと同様であるが、「さらにXMPP処理」の最初の2つのステップは、、、HTTP認証[HTTP-AUTH]に類似していることに注意するのを助けることができますURIの[MAILTO]：のmailtoの。
As noted in Section 2.7.2 of this document, certain characters are allowed in the node identifier, domain identifier, and resource identifier portions of a native XMPP address but prohibited by the "inodeid", "ihost", and "iresid" rules of an XMPP IRI. The percent-encoded octets corresponding to these characters in XMPP IRIs MUST be transformed into the characters allowed in XMPP addresses when processing an XMPP IRI for interaction with the represented XMPP entity.
このドキュメントのセクション2.7.2で述べたように、特定の文字は、ノード識別子、ドメイン識別子、及び天然XMPPアドレスのリソース識別子部分で許可が、「inodeid」、「ihost」、および「iresid」規則によって禁止されていますXMPP IRI。 XMPP虹彩これらの文字に対応するパーセントエンコードされたオクテットが示さXMPPエンティティと対話するためのXMPP IRIを処理するときXMPPアドレスに使用できる文字に変換されなければなりません。
Consider the following nasty node in an XMPP IRI (split into two lines for layout purposes):
XMPP IRI（レイアウト目的のための2つの行に分割）で次の厄介なノードを考慮してください。
xmpp:nasty!%23$%25()*+,-.;=%3F%5B%5C%5D%5E_%60%7B%7C%7D~node @example.com
XMPP：厄介％23 $の25％（）* +、 - 、=％3F％5B％5C％5D％5E_％60％7B％7C％7D〜ノード@ example.com！。
That IRI would be transformed into the following XMPP address:
IRIは、以下のXMPPアドレスに変換されること：
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
厄介なの＃$％（）* +、 - 、！。？= [\] ^ _ `{|}~node@example.com
Consider the following repulsive resource in an XMPP IRI (split into three lines for layout purposes):
XMPP IRI（レイアウト目的のための3つの行に分割）で次の反発リソースを考慮してください。
xmpp:node@example.com /repulsive%20!%23%22$%25&'()*+,-.%2F:;%3C =%3E%3F%40%5B%5C%5D%5E_%60%7B%7C%7D~resource
XMPP：node@example.com /repulsive%20!%23%22$%25&'()*+,-.%2F:;%3C =％3E％3F％の40％5B％5C％の5Dの％5E_％60 ％7B％7C％7D〜資源
That IRI would be transformed into the following XMPP address (split into two lines for layout purposes):
IRIは、以下のXMPPアドレスに変換されること（レイアウト目的のための2つの行に分割）。
node@example.com /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
！node@example.com /反発＃ "$の％＆ '（）* +、 - / :; <=> @ [\] ^ _`。？{|}〜資源
Consider the XMPP URI that resulted from the previous example (see Section 2.7.3):
前の例（セクション2.7.3を参照）に起因XMPP URIを考えてみます。
<xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
<XMPP：ji%C5%99i@%C4%8Dechy.example/v%20Praze>
In order to generate a valid XMPP IRI from that URI, the application MUST adhere to the procedure specified in Section 3.2 of [IRI], resulting in the following IRI:
そのURIから有効なXMPP IRIを生成するために、アプリケーションは、次のIRIをもたらす、[IRI]のセクション3.2で指定された手順に従わなければなりません。
<xmpp:jiři@čechy.example/v%20Praze>
<XMPP：JI＆＃のx159; I @＆＃X10D; echy.example / v％の20Praze>
In accordance with the process specified above, the processing application would remove the "xmpp" scheme and ":" character to extract the XMPP address from this XMPP IRI, converting any percent-encoded octets from the "inodeid", "ihost", and "iresid" rules into their character equivalents (e.g., "%20" into the space character).
上記指定されたプロセスによれば、「XMPP」方式とを除去するであろう処理アプリケーション「：」文字は、「ihost」、「inodeid」から任意のパーセントエンコードオクテットを変換し、このXMPP IRIからXMPPアドレスを抽出し、その文字同等物への「iresid」のルール（例えば、スペース文字に「％20」）。
The result is this XMPP address:
その結果、このXMPPアドレスです。
<jiři@čechy.example/v Praze>
<それ＆＃のx159; I＆@＃X10D; echy.example /プラハ>
Because XMPP addresses are UTF-8 strings [UTF-8] and because octets outside the US-ASCII range [US-ASCII] within XMPP addresses can be easily converted to percent-encoded octets, XMPP addresses are designed to work well with Internationalized Resource Identifiers [IRI]. In particular, with the exceptions of stringprep verification, the conversion of syntax-relevant US-ASCII characters (e.g., "?"), and the conversion of percent-encoded octets from the "inodeid", "ihost", and "iresid" rules into their character equivalents (e.g., "%20" into the US-ASCII space character), an XMPP IRI can be constructed directly by prepending the "xmpp" scheme and ":" character to an XMPP address. Furthermore, an XMPP IRI can be converted into URI syntax by adhering to the procedure specified in Section 3.1 of [IRI], and an XMPP URI can be converted into IRI syntax by adhering to the procedure specified in Section 3.2 of [IRI], thus ensuring interoperability with applications that are able to process URIs but unable to process IRIs.
XMPPアドレスはUTF-8文字列を[UTF-8]であり、XMPPアドレス内のUS-ASCIIの範囲外のオクテット[US-ASCII]が簡単にパーセントエンコードオクテットに変換できるので、XMPPアドレスが国際化リソースでうまく動作するように設計されているので、識別子[IRI]。具体的には、文字列準備検証の例外は、構文関連のUS-ASCII文字（例えば、「？」）の変換、および「inodeid」からパーセントエンコードオクテットの変換、「ihost」、および持つ「iresid」 XMPPアドレスに文字：「」自分のキャラクター同等物への規則は（例えば、US-ASCIIのスペース文字に「％20」）、XMPP IRIは、「XMPP」スキームとを付加することで直接作成することができます。また、XMPP IRIは、[IRI]のセクション3.1で指定された手順に付着することによってURIシンタックスに変換することができ、及びXMPP URIは、このように、[IRI]のセクション3.2で指定された手順に付着することによりIRI構文に変換することができます。 URIを処理できるが、アイリスを処理できませんアプリケーションとの相互運用性を確保します。
In accordance with [URI-SCHEMES], this section provides the information required to register the xmpp URI scheme.
[URI-スキーム]によれば、このセクションでは、XMPP URIスキームを登録するために必要な情報を提供します。
xmpp
XMPP
permanent
恒久
The syntax for an xmpp URI is defined below using Augmented Backus-Naur Form as specified by [ABNF], where the "fragment", "host", "pct-encoded", and "unreserved" rules are defined in [URI]:
「フラグメント」、「宿主」、「PCTエンコード」、及び「予約されていない」ルールは[URI]で定義されている[ABNF]で指定されたURIが増補バッカスナウア記法を用いて以下に定義されるXMPPの構文、
xmppuri = "xmpp" ":" hierxmpp [ "?" querycomp ] [ "#" fragment ] hierxmpp = authpath / pathxmpp authpath = "//" authxmpp [ "/" pathxmpp ] authxmpp = nodeid "@" host pathxmpp = [ nodeid "@" ] host [ "/" resid ] nodeid = *( unreserved / pct-encoded / nodeallow ) nodeallow = "!" / "$" / "(" / ")" / "*" / "+" / "," / ";" / "=" resid = *( unreserved / pct-encoded / resallow ) resallow = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ":" / ";" / "=" querycomp = querytype [ *pair ] querytype = *( unreserved / pct-encoded ) pair = ";" key "=" value key = *( unreserved / pct-encoded ) value = *( unreserved / pct-encoded )
xmppuri = "XMPP" "：" hierxmppの[ ""？ querycomp] [ "＃" フラグメント] hierxmpp = authpath / pathxmpp authpath = "//" authxmppの[ "/" pathxmpp] authxmpp = NODEIDホストpathxmpp = [NODEID "@"]ホスト[ "/" 残油]ノードid = "@" *（予約されていない/ PCT-エンコード/ nodeallow）nodeallow = "！" / "$" / "（" / "）" / "*" / "+" / "" / ";" / "=" 残油= *（予約されていない/ PCT-エンコード/ resallow）resallow = "！" / "$" / "＆" / "'" / "（" / "）" / "*" / "+" / "、" / "：" / ";" / "=" querycomp =のquerytype [*ペア]のquerytype = *（予約されていない/ PCTエンコード）対= ";"キー "=" 値キー= *（予約されていない/ PCT-符号化された）値= *（予約されていない/ PCTエンコード）
The xmpp URI scheme identifies entities that natively communicate using the Extensible Messaging and Presence Protocol (XMPP), and is mainly used for identification rather than for resource location. However, if an application that processes an xmpp URI enables interaction with the XMPP address identified by the URI, it MUST follow the methodology defined in Section 2 of this document, Use of XMPP IRIs and URIs, to reconstruct the encapsulated XMPP address, connect to an appropriate XMPP server, and send an appropriate XMPP "stanza" (XML fragment) to the XMPP address. (Note: There is no MIME type associated with the xmpp URI scheme.)
XMPP URIスキームは、ネイティブ拡張メッセージングおよびプレゼンスプロトコル（XMPP）を使用して通信エンティティを識別し、識別のためではなく、リソースの場所のために主に使用されます。しかし、URIは、URIで識別されるXMPPアドレスとの相互作用を可能にXMPPを処理するアプリケーションならば、それは、このドキュメントのセクション2で定義された方法論に従わなければならないXMPP虹彩とURIの使用、カプセル化されたXMPPアドレスを再構築するために、への接続します適切なXMPPサーバー、およびXMPPアドレスに適切なXMPP「スタンザ」（XMLフラグメント）を送ります。 （注：XMPP URIスキームに関連付けられたMIMEタイプはありません。）
In addition to XMPP URIs, there will also be XMPP Internationalized Resource Identifiers (IRIs). Prior to converting an Extensible Messaging and Presence Protocol (XMPP) address into an IRI (and in accordance with [XMPP-CORE]), the XMPP address must be represented as a string of UTF-8 characters [UTF-8] by the generating application (e.g., by transforming an application's internal representation of the address as a UTF-16 string into a UTF-8 string). Because IRI syntax [IRI] specifies that the characters in an IRI are the original Unicode characters themselves [UNICODE], when generating an XMPP IRI the generating application MUST decode the UTF-8 characters of a native XMPP address to their original Unicode form. Because URI syntax [URI] specifices that the characters in a URI are US-ASCII characters [US-ASCII] only, when generating an XMPP URI the generating application MUST escape the Unicode characters of an XMPP IRI to US-ASCII characters by adhering to the procedure specified in RFC 3987.
XMPPのURIに加えて、XMPP国際化資源識別子（IRIは）存在します。拡張メッセージングおよびプレゼンスプロトコル（XMPP）を変換する前に（および[XMPP-CORE]に従って）IRIに対処する、XMPPアドレスを生成することにより、[UTF-8] UTF-8文字の文字列として表現されなければなりません（例えば、UTF-8文字列にUTF-16文字列としてアドレスのアプリケーションの内部表現に変換することによって）アプリケーション。 IRI構文[IRI]はIRIの文字が元のUnicode文字そのもの[UNICODE]であることを指定するためのXMPP IRIを生成する場合、生成アプリケーションは元のユニコード形式にネイティブXMPPアドレスのUTF-8文字を復号しなければなりません。 URI構文[URI]はURIの文字がUS-ASCII文字であることをspecificesので[US-ASCII] XMPP URIを生成する場合にのみ、生成アプリケーションは、に付着したことにより、US-ASCII文字にXMPP IRIのUnicode文字をエスケープする必要がありますRFC 3987で指定された手順。
The xmpp URI scheme is intended to be used by interfaces to an XMPP network from non-native user agents, such as web browsers, as well as by non-native applications that need to identify XMPP entities as full URIs or IRIs.
XMPP URIスキームは、ウェブブラウザのような非ネイティブユーザエージェントからXMPPネットワークへのインターフェースによって、ならびに完全なURI虹彩としてXMPPエンティティを識別する必要があり、非ネイティブアプリケーションで使用されることが意図されます。
There are no known interoperability concerns related to use of the xmpp URI scheme. In order to help ensure interoperability, the XMPP Registrar function of the XMPP Standards Foundation maintains a registry of query types and keys that can be used in the query components of XMPP URIs and IRIs, located at <http://www.xmpp.org/registrar/querytypes.html>.
XMPP URIスキームの使用に関連する一切の既知の相互運用性の懸念はありません。相互運用性を確保するためには、XMPP標準財団のXMPP Registrarの機能は、<http://www.xmpp.orgに位置、XMPP URIと虹彩のクエリコンポーネントで使用可能なクエリの種類とキーのレジストリを維持します/registrar/querytypes.html>。
See Section 5 of this document, Security Considerations.
このドキュメントのセクション5、セキュリティに関する考慮事項を参照してください。
Peter Saint-Andre [mailto:stpeter@jabber.org, xmpp:stpeter@jabber.org]
ピーターサンタンドレ[MAILTO：stpeter@jabber.org、XMPP：stpeter@jabber.org]
This scheme is registered under the IETF tree. As such, the IETF maintains change control.
この方式は、IETFツリーの下に登録されています。そのため、IETFは、コントロールを変更維持しています。
[XMPP-CORE]
[XMPP-CORE]
This document obsoletes the URI scheme registration created by RFC 4622. The registration template can be found in Section 3 of this document. In order to help ensure interoperability, the XMPP Registrar function of the XMPP Standards Foundation maintains a registry of query types and keys that can be used in the query components of XMPP URIs and IRIs, located at <http://www.xmpp.org/registrar/querytypes.html>.
この文書は、RFC 4622.登録テンプレートによって作成されたURIスキームの登録はこのドキュメントのセクション3で見つけることができ廃止します。相互運用性を確保するためには、XMPP標準財団のXMPP Registrarの機能は、<http://www.xmpp.orgに位置、XMPP URIと虹彩のクエリコンポーネントで使用可能なクエリの種類とキーのレジストリを維持します/registrar/querytypes.html>。
Providing an interface to XMPP services from non-native applications introduces new security concerns. The security considerations discussed in [IRI], [URI], and [XMPP-CORE] apply to XMPP IRIs, and the security considerations discussed in [URI] and [XMPP-CORE] apply to XMPP URIs. In accordance with Section 2.7 of [URI-SCHEMES] and Section 7 of [URI], particular security considerations are specified in the following sections.
非ネイティブアプリケーションからXMPPサービスへのインタフェースを提供することは、新たな安全保障上の懸念を紹介します。 [IRI]、[URI]で説明したセキュリティ上の考慮事項、および[XMPP-CORE] XMPP虹彩適用され、[URI]と[XMPP-CORE]で議論したセキュリティ問題XMPP URIに適用します。 [URI-スキーム]のセクション2.7と[URI]のセクション7によれば、特定のセキュリティ上の考慮事項は、次のセクションで指定されています。
Given that XMPP addresses of the form node@domain.tld are typically created via registration at an XMPP server or provisioned by an administrator of such a server, it is possible that such addresses may also be unregistered or deprovisioned. Therefore, the XMPP IRI/ URI that identifies such an XMPP address may not reliably and consistently be associated with the same principal, account owner, application, or device.
フォームnode@domain.tldのXMPPアドレスは、典型的には、サーバの管理者がXMPPサーバに登録を介して作成またはプロビジョニングされていることを考えると、そのようなアドレスも登録されていない、またはプロビジョニング解除することができる可能性があります。したがって、このようなXMPPアドレスを特定するXMPP IRI / URIを確実かつ一貫して同じ主、アカウント所有者、アプリケーション、または装置に関連しなくてもよいです。
XMPP addresses of the form node@domain.tld/resource are typically even more ephemeral (since a given XMPP resource identifier is typically associated with a particular, temporary session of an XMPP client at an XMPP server). Therefore, the XMPP IRI/URI that identifies such an XMPP address probably will not reliably and consistently be associated with the same session. However, the procedures specified in Section 10 of [XMPP-CORE] effectively eliminate any potential confusion that might be introduced by the lack of reliability and consistency for the XMPP IRI/URI that identifies such an XMPP address.
フォームnode@domain.tld/resourceのXMPPアドレスは、典型的には、より一層短命である（所定のXMPPリソース識別子は、典型的にはXMPPサーバでXMPPクライアントの特定の、一時的なセッションと関連付けられているため）。したがって、このようなXMPPアドレスを特定するXMPP IRI / URIは、おそらく確実にかつ一貫して同じセッションに関連付けされることはありません。しかし、[XMPP-CORE]のセクション10で指定された手順を効果的にこのようなXMPPアドレスを特定するXMPP IRI / URIのための信頼性と一貫性の欠如によって導入される可能性のある潜在的な混乱を避けます。
XMPP addresses of the form domain.tld are typically long-lived XMPP servers or associated services. Although naturally it is possible for server or service administrators to decommission the server or service at any time, typically the IRIs/URIs that identify such servers or services are the most reliable and consistent of XMPP IRIs/URIs.
フォームdomain.tldにのXMPPアドレスは、一般的に長寿命のXMPPサーバーや関連するサービスです。当然、それはいつでもサーバーまたはサービスを廃止するサーバーまたはサービス管理者のため可能ですが、一般的なサーバやサービスを特定のIRI / URIは、最も信頼性の高い、XMPPのIRI / URIの一致しています。
XMPP addresses of the form domain.tld/resource are not yet common on XMPP networks; however, the reliability and consistency of XMPP IRIs/ URIs that identify such XMPP addresses would likely fall somewhere between those that identify XMPP addresses of the form domain.tld and those that identify XMPP addresses of the form node@domain.tld.
フォームdomain.tldに/リソースのXMPPアドレスがXMPPネットワークではまだ一般的ではありません。しかし、信頼性と、このようなXMPPアドレスを特定するXMPP IRIを/ URIの一貫性は、おそらくXMPPフォームdomain.tldにのアドレスとフォームnode@domain.tldのXMPPアドレスを特定するものを同定するものの間に収まるでしょう。
Malicious construction of XMPP IRIs/URIs is made less likely by the prohibition on port numbers in XMPP IRIs/URIs (since port numbers are to be discovered using DNS SRV records [DNS-SRV], as specified in [XMPP-CORE]).
（ポート番号が、DNS SRVレコードを使用して検出されるので、[XMPP-CORE]で指定されるように、[DNS-SRV]）XMPPのIRI / URIの悪質な構成は、XMPPのIRI / URIの中のポート番号の禁止によってにくくなります。
Because the base XMPP protocol is designed to implement the exchange of messages and presence information and not the retrieval of files or invocation of similar system functions, it is deemed unlikely that the use of XMPP IRIs/URIs would result in harmful dereferencing. However, if an XMPP protocol extension defines methods for information retrieval, it MUST define appropriate controls over access to that information. In addition, XMPP servers SHOULD NOT natively parse XMPP IRIs/URIs but instead SHOULD accept only the XML wire protocol specified in [XMPP-CORE] and any desired extensions thereto.
ベースXMPPプロトコルがメッセージおよびプレゼンス情報の交換としないファイルの検索や類似のシステム機能の呼び出しを実装するように設計されているので、XMPPのIRI / URIの使用は有害参照解除をもたらす可能性は低いと考えられます。 XMPPプロトコル拡張は情報検索のためのメソッドを定義する場合は、その情報へのアクセスを適切なコントロールを定義しなければなりません。また、XMPPサーバは、ネイティブXMPPのIRI / URIを解析するべきではなく、代わりに、唯一[XMPP-CORE]で指定されたXMLワイヤプロトコルおよび任意の所望の拡張それを受け入れる必要があります。
The ability to interact with XMPP entities via a web browser or other non-native application may expose sensitive information (such as support for particular XMPP application protocol extensions) and thereby make it possible to launch attacks that are not possible or that are unlikely on a native XMPP network. Due care must be taken in deciding what information is appropriate for representation in XMPP IRIs or URIs.
Webブラウザや他の非ネイティブアプリケーションを介してXMPP実体と相互作用する能力は、（例えば、特定のXMPPアプリケーションプロトコルの拡張機能のサポートなど）の機密情報を公開することにより、それが可能できませんか、上の可能性は低いという攻撃を開始することがありネイティブXMPPネットワーク。ケアは、XMPP IRIをまたはURIの中の表現に適しているどのような情報を決定する際に注意する必要があります。
In particular, advertising XMPP IRIs/URIs in publicly accessible locations (e.g., on websites) may make it easier for malicious users to harvest XMPP addresses from the authority and path components of XMPP IRIs/URIs and therefore to send unsolicited bulk communications to the users or applications represented by those addresses. Due care should be taken in balancing the benefits of open information exchange against the potential costs of unwanted communications.
具体的には、（ウェブサイト上など）公的にアクセス可能な場所での広告XMPPのIRI / URIは、それが簡単に悪意のあるユーザーがXMPPのIRI / URIの権限とパスのコンポーネントからのXMPPアドレスを収集するため、ユーザーに迷惑通信を送信するために作ることまたはアプリケーションは、これらのアドレスによって表されます。ケアが不要な通信の潜在的なコストに対するオープンな情報交換のメリットのバランスに注意する必要があります。
To help prevent leaking of sensitive information, passwords and other user credentials are forbidden in the authority component of XMPP IRIs/URIs; in fact they are not needed, since the fact that authentication in XMPP occurs via the Simple Authentication and Security Layer [SASL] makes it possible to use the SASL ANONYMOUS mechanism, if desired.
機密情報の漏洩を防ぐために、パスワードや他のユーザーの資格情報は、XMPPのIRI / URIの権限コンポーネントで禁止されています。必要に応じて、XMPPでの認証は簡易認証セキュリティー層を介して起こるという事実[SASL]は、SASL ANONYMOUSメカニズムを使用することが可能になるからです。実際には、彼らは、必要とされていません
Despite the existence of non-hierarchical URI schemes such as [MAILTO], by association human users may expect all URIs to include the "//" characters after the scheme name and ":" character. However, in XMPP IRIs/URIs, the "//" characters precede the authority component rather than the path component. Thus, xmpp://guest@example.com indicates to authenticate as "guest@example.com", whereas xmpp:guest@example.com identifies the node "guest@example.com". Processing applications MUST clearly differentiate between these forms, and user agents SHOULD discourage human users from including the "//" characters in XMPP IRIs/URIs since use of the authority component is envisioned to be helpful only in specialized scenarios, not more generally.
「：」の文字など[MAILTO]などの非階層的なURIスキームが存在するにもかかわらず、協会が人間のユーザは、すべてのURIスキーム名と、後に「//」の文字を含めることを期待することがあります。しかし、XMPPのIRI / URIの中で、「//」の文字は権限コンポーネントではなく、パスコンポーネントの前に。したがって、XMPP：//guest@example.comはXMPPのに対し、 "guest@example.com" として認証することを示す：guest@example.com "はguest@example.com" ノードを識別する。処理アプリケーションは明らかにこれらのフォームを区別しなければならない、とユーザーエージェントは権限コンポーネントの使用以来、XMPP IRIを/のURIで「//」の文字を含むから、人間のユーザーを落胆すべきではない、より一般的に、唯一の専門のシナリオで役立つことが想定されます。
The ability to include effectively the full range of Unicode characters in an XMPP IRI may make it easier to execute certain forms of address mimicking (also called "spoofing"). However, XMPP IRIs are no different from other IRIs in this regard, and applications that will present XMPP IRIs to human users must adhere to best practices regarding address mimicking in order to help prevent attacks that result from spoofed addresses (e.g., the phenomenon known as "phishing"). For details, refer to the Security Considerations of [IRI].
効果的XMPP IRIにUnicode文字の全範囲を含める機能は、簡単に（また、「なりすまし」と呼ばれる）を模倣アドレスの特定の形態を実行することがあります。しかし、として知られている現象、XMPP虹彩が、この点で他のIRIから違いはありません、そして人間のユーザにXMPPアイリスを提示するアプリケーションは、偽装されたアドレス（例えばに起因する攻撃を防ぐのを助けるために模倣したアドレスに関するベストプラクティスに従っている必要があります"フィッシング"）。詳細については、[IRI]のセキュリティの考慮事項を参照してください。
Thanks to Martin Duerst, Lisa Dusseault, Frank Ellerman, Roy Fielding, Joe Hildebrand, and Ralph Meijer for their comments.
彼らのコメントのためのマーティンDuerst、リサDusseault、フランクEllerman、ロイ・フィールディング、ジョー・ヒルデブラント、およびラルフ・マイヤーに感謝します。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2007.
、STD 68、RFC 5234、2007年1月： "ABNF構文仕様のための増大しているBNF" [ABNF]クロッカー、D.、およびP. Overell、。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[用語]ブラドナーの、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-CORE]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 3920、2004年10月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]ピーターソン、J.、 "インスタントメッセージングのための共通プロファイル（CPIM）"、RFC 3860、2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[CPP]ピーターソン、J.、 "プレゼンスのための共通プロファイル（CPP）"、RFC 3859、2004年8月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV] Gulbrandsenの、A.、いるVixie、P.、およびL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
[HTML] Raggett, D., "HTML 4.0 Specification", W3C REC REC-html40-19980424, April 1998.
[HTML] Raggett、D.、 "HTML 4.0仕様書"、W3C REC REC-html40-19980424、1998年4月。
[HTTP-AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[HTTP-AUTH]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証：基本とダイジェストアクセス認証」、RFC 2617、1999年6月。
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA] Faltstrom、P.、ホフマン、P.、およびA.コステロ、 "アプリケーションにおける国際化ドメイン名（IDNA）"、RFC 3490、2003年3月。
[MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[MAILTO]ホフマン、P.、Masinter、L.、およびJ. Zawinski、 "mailtoのURLスキーム"、RFC 2368、1998年7月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("STRINGPREP")", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、 "（STRINGPREP "）"、RFC 3454、2002年12月国際化された文字列の準備"。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000.
[UNICODE]のUnicodeコンソーシアム、 "Unicode標準、バージョン3.2.0"、2000年。
The Unicode Standard, Version 3.2.0 is defined by The
Unicode Standard, Version 3.0 (Reading, MA, Addison-
Wesley, 2000. ISBN 0-201-61633-5), as amended by the
Unicode Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the
Unicode Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/).
[URI-SCHEMES] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006.
[URI-スキーム]ハンセン、T.、ハーディ、T.、およびL. Masinter、 "新しいURIスキームのためのガイドラインと登録手順"、RFC 4395、2006年2月。
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]米国規格協会、 "コード化文字セット - 情報交換のための7ビットの米国標準コード"、ANSI X3.4、1986。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[XEP-0009] Adams, D., "Jabber-RPC", XSF XEP 0009, February 2006.
[XEP-0009]アダムス、D.、 "Jabberの-RPC"、XSF XEP 0009、2006年2月。
[XEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", XSF XEP 0030, February 2007.
[XEP-0030]ヒルデブラント、J.、ミラード、P.、Eatmon、R.、およびP.サンアンドレ、 "サービス・ディスカバリー"、XSF XEP 0030、2007年2月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, April 2007.
[XEP-0045]サンアンドレ、P.、 "マルチユーザーチャット"、XSF XEP 0045、2007年4月。
[XEP-0053] Saint-Andre, P., "XMPP Registrar Function", XSF XEP 0053, December 2006.
[XEP-0053]サンアンドレ、P.、 "XMPP Registrarの機能"、XSF XEP 0053、2006年12月。
[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", XSF XEP 0060, September 2006.
[XEP-0060]ミラード、P.、サン・アンドレ、P.、およびR. Meijer氏、 "パブリッシュ・サブスクライブ"、XSF XEP 0060、2006年9月。
[XEP-0072] Forno, F. and P. Saint-Andre, "SOAP Over XMPP", XSF XEP 0072, December 2005.
[XEP-0072] Fornoの、F.およびP.サンアンドレ、 "XMPPオーバーSOAP"、XSF XEP 0072、2005年12月。
[XEP-0077] Saint-Andre, P., "In-Band Registration", XSF XEP 0077, January 2006.
[XEP-0077]サンアンドレ、P.、 "インバンド登録"、XSFのXEP 0077、2006年1月。
[XEP-0147] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF XEP 0147, September 2006.
[XEP-0147]サンアンドレ、P.、 "XMPP URIスキームクエリコンポーネント"、XSF XEP 0147、2006年9月。
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"、RFC 3921、2004年10月。
Appendix A. Differences from
からの付録A.の違い
Several errors were found in RFC 4622. This document corrects those errors. The resulting differences from RFC 4622 are as follows:
いくつかのエラーは、RFC 4622.この文書では、これらのエラーを修正するに発見されました。次のようにRFC 4622からの結果の違いは以下のとおりです。
o Specified that the characters "[", "\", "]", "^", "`", "{", "|", and "}" are allowed in XMPP node identifiers but not allowed in IRIs or URIs according to the sub-delims rule.
XMPPノード識別子に許容しかしのIRIやURIの中に許可されていない| O文字は「[」、「\」、「]」、「^」、「'」、「{」、「」、および、「}」と指定サブdelims規則に従って。
o Specified that the characters '"', "<", ">", "[", "\", "]", "^", "`", "{", "|", and "}" are allowed in XMPP resource identifiers but not allowed in IRIs or URIs according to the pchar rule.
{| "および " ""}" されているOその文字 '"'、 "<"、 ">"、 "["、 "\"、 "]"、 "^"、 "`"、" 指定されましたXMPPリソース識別子で許可されますがPChar型の規則に従ってのIRIやURIの中で許可されていません。
o Specified that the foregoing characters must be percent-encoded when constructing an XMPP URI.
O XMPP URIを構築する際に、前述の文字はパーセントエンコードされなければならないことを指定。
o Corrected the ABNF accordingly.
O ABNFはそれに応じて修正しました。
o Updated the examples accordingly.
O応じ例を更新しました。
Appendix B. Copying Conditions
付録B.のコピー条件
Regarding this entire document or any portion of it, the author makes no guarantees and is not responsible for any damage resulting from its use. The author grants irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.
この文書全体またはその一部については、作者は保証しませんし、その使用に起因するいかなる損害についても責任を負いません。派生作品を再配布提供し、それを使用、変更、および、使用変更する他の誰の権利を損なわない任意の方法でそれを配布し、配布するための誰にも著者の補助金取消不能の許可は、著作者またはバージョンの情報が誤解を招く含まれていません。派生作品は、同様の条件の下でライセンスされる必要はありません。
Author's Address
著者のアドレス
Peter Saint-Andre XMPP Standards Foundation
ピーターサンアンドレXMPP規格財団
EMail: stpeter@jabber.org URI: xmpp:stpeter@jabber.org
電子メール：stpeter@jabber.org URI：XMPP：stpeter@jabber.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。