RFC5122 日本語訳
5122 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and PresenceProtocol (XMPP). P. Saint-Andre. February 2008. (Format: TXT=55566 bytes) (Obsoletes RFC4622) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Saint-Andre Request for Comments: 5122 XSF Obsoletes: 4622 February 2008 Category: Standards Track
コメントを求めるワーキンググループP.サンアンドレ要求をネットワークでつないでください: 5122XSFは以下を時代遅れにします。 4622 2008年2月のカテゴリ: 標準化過程
Internationalized Resource Identifiers (IRIs) and
Uniform Resource Identifiers (URIs) for
the Extensible Messaging and Presence Protocol (XMPP)
広げることができるメッセージングと存在プロトコルのための国際化しているリソース識別子(虹彩)とUniform Resource Identifier(URI)(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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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).
このドキュメントはExtensible Messagingを通って交信できる実体とPresenceプロトコル(XMPP)と特定するか、または対話する際にInternationalized Resource Identifiers(IRIs)とUniform Resource Identifier(URI)の使用を定義します。
This document obsoletes RFC 4622.
このドキュメントはRFC4622を時代遅れにします。
Saint-Andre Standards Track [Page 1] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 2。 XMPP虹彩とURI. . . . . . . . . . . . . . . . . . 4 2.1の使用。 原理. . . . . . . . . . . . . . . . . . . . . . . . 4 2.2。 .52.3を形成してください。 権威コンポーネント. . . . . . . . . . . . . . . . . . . 6 2.4。 経路コンポーネント. . . . . . . . . . . . . . . . . . . . . . 7 2.5。 コンポーネント. . . . . . . . . . . . . . . . . . . . . 8 2.6について質問してください。 識別子コンポーネント. . . . . . . . . . . . . . 9 2.7を断片化してください。 XMPP虹彩/URI. . . . . . . . . . . . . . . 10 2.8の世代。 XMPP虹彩/URI. . . . . . . . . . . . . . . 13 2.9の処理。 国際化. . . . . . . . . . . . . . . . . . . 16 3。 xmpp URI Scheme. . . . . . . . . . . . . 16 3.1のIANA Registration。 URI計画名. . . . . . . . . . . . . . . . . . . . . 16 3.2。 状態. . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3。 URI計画構文. . . . . . . . . . . . . . . . . . . . 17 3.4。 URI計画意味論. . . . . . . . . . . . . . . . . . . 17 3.5。 問題. . . . . . . . . . . . . . . . . 17 3.6をコード化します。 このURIを使用するアプリケーション/プロトコルが名前. . . 18 3.7を計画します。 相互運用性問題. . . . . . . . . . . . . 18 3.8。 セキュリティ問題. . . . . . . . . . . . . . . . . 18 3.9。 .18 3.10に連絡してください。 コントローラ. . . . . . . . . . . . . . . . . 18 3.11を書くか、または変えてください。 参照. . . . . . . . . . . . . . . . . . . . . . . . 18 4。 IANA問題. . . . . . . . . . . . . . . . . . . . . 18 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 5.1。 信頼性と一貫性. . . . . . . . . . . . . . . 19 5.2。 悪意がある工事. . . . . . . . . . . . . . . . . . 20 5.3。 バックエンドコード変換. . . . . . . . . . . . . . . . . . . 20 5.4。 機密情報. . . . . . . . . . . . . . . . . . 20 5.5。 意味攻撃. . . . . . . . . . . . . . . . . . . . . 21 5.6。 スプーフィング. . . . . . . . . . . . . . . . . . . . . . . . . 21 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 21 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 21 7.2。 RFC4622.25の付録B.コピー状態. . . . . . . . . . . . . . . . . 25からの有益な参照. . . . . . . . . . . . . . . . . . 22付録A.差
Saint-Andre Standards Track [Page 2] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[2ページ]。
1. Introduction
1. 序論
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.
Extensible MessagingとPresenceプロトコル(XMPP)はネットワークのどんな2つの実体もリアルタイムで近くでレートで明確な、しかし、広げることができるXML要素(「XMLスタンザ」と呼ばれる)を交換するのを可能にするストリーミングの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]で指定されるように、Uniform Resource Identifier(URI)計画でXMPPネットワークの上でコミュニケーションで使用される実体アドレスをprependedしてはいけません([URI]で指定されるように)。 しかしながら、XMPPネットワークへの外部のアプリケーションは、URIとして、または、より現代のファッションによるInternationalized Resource IdentifiersとしてXMPP実体を特定する必要があるかもしれません(IRIs; [IRI]を見てください)。 そのような外部のアプリケーションに関する例は、ウェブブラウザなどのXMPPアドレスを格納する必要があるデータベースと非ネイティブのユーザエージェントとインタフェースを提供するアプリケーションをXMPPサービスにcalendaringするのを含んでいます。
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]で定義されます。 そのようなアドレスは、ほとんどどんなユニコード文字[ユニコード]も含むかもしれなくて、stringprep[STRINGPREP]の様々なプロフィールを固く守らなければなりません。 結果はXMPPアドレスが完全に国際化可能で、計画がなければIRIであることの非常に近くにあるということです。 しかしながら、IRI計画のどんな支柱なしで立っている登録もなければ、主としてIRIsとしてというよりむしろURIとXMPP識別子を定義して、IRI計画の代わりにXMPP URI計画を登録するのが必要です。 したがって、このドキュメントは以下をします:
o Specifies how to identify XMPP entities as IRIs or URIs.
o XMPP実体がIRIsかURIであると認識する方法を指定します。
o Specifies how to interact with XMPP entities as IRIs or URIs.
o IRIsかURIとしてXMPP実体と対話する方法を指定します。
o Formally defines the syntax for XMPP IRIs and URIs.
o 正式に、XMPP IRIsとURIのために構文を定義します。
o Specifies how to transform XMPP IRIs into URIs and vice versa.
o 逆もまた同様にXMPP IRIsをURIに変える方法を指定します。
o Registers the xmpp URI scheme.
o xmpp URI計画を登録します。
1.1. Terminology
1.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[用語]で説明されるように本書では解釈されることであるべきですか?
Saint-Andre Standards Track [Page 3] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[3ページ]。
2. Use of XMPP IRIs and URIs
2. XMPP虹彩とURIの使用
2.1. Rationale
2.1. 原理
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.
XMPPのアプリケーションが処理しなければならない[XMPP-IM]、インスタントメッセージング、および存在で説明される、不-、: pres: URI([CPIM]と[CPP]によって指定されるように)。 しかしながら、XMPPの他の多くの利用がある、(ネットワークマネージメント、ワークフローシステムを含んでいる、一般的である、発行、-申し込んでください、遠隔手続き呼び出し、満足しているシンジケート組織化、ゲーミング、およびミドルウェア)、これらのアプリケーションはインスタントメッセージングと存在意味論を実行しません。 その上、一般的なXMPP実体はどんな既存のURI計画の意味論も実行しません、httpなどのように:、以下をftpするか、または以下をmailtoします。 計画してください。 したがって、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 IRIsとURIは使用のために非ネイティブのインタフェースとアプリケーションで定義されます。 実体がデータがXMPP実体に発送されるか(例えば、XMPPアドレスはいつXMLスタンザの'to'か'from'属性に含まれていますか)、またはXMPP実体が別の方法で標準のXMPPプロトコル要素で特定されるとき、XMPPネットワークで相互運用性を確実にする記述された as <node@domain/resource でなければならない、gt;、(すなわち、prepended計画のない。); 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
XMPP IRIsとURIは主として相互作用についてというよりむしろ識別の目的のために定義されます(この区別に関して、[URI]についてセクション1.2.2を見てください)。 XMPP IRIかURIによって特定された「インターネット資料」はネットワークの上のXMPPを通って交信できる実体です。 XMPP IRIかURIが特定されたリソースを超えて追加情報を含むことができます。 特に、特定されたリソースとの相互作用に提案された意味論を指定するためにセクション2.5の下で説明されるように質問コンポーネントを含むことができます。 またはXMPPアプリケーションであるときに、思い描かれて、それがXMPP IRIを決議するか、またはURI含有が相互作用意味論を示したということであり、アプリケーションが特定されたリソースにXMPPスタンザを発生させて、それを送る。(そこでは、発生しているスタンザがユーザを含むかもしれません)。
Saint-Andre Standards Track [Page 4] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[4ページ]。
application inputs that are consistent with the suggested interaction semantics (for details, see Section 2.8.1).
提案された相互作用意味論(詳細に関して、セクション2.8.1を見る)と一致したアプリケーション入力。
2.2. Form
2.2. フォーム
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[STRINGPREP]プロフィールとあるIDNA制限[IDNA]に従わせる一連のユニコード文字です、そして、(2)はあるシンタックス・ルールに従います、そして、(3)はUTF-8[UTF-8]としてコード化されます。 以下としてAugmented BN記法[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[STRINGPREP]の異なったプロフィールを当てにします、そして、「ドメイン」規則は[IDNA]で説明されるように国際化ドメイン名の概念を当てにします。 (以下に注意してください。 IRI構文自体でpunycodeについて言及する必要は全くありません、どんなpunycode表現も国際化ドメイン名を表すためにXMPPアプリケーションだけで起こるでしょう、したがって。 しかしながら、XMPPネットワークの指定された実体にXMLスタンザを記述する前にIRI構文[IRI]をIDNA構文[IDNA]に変換するのは、処理アプリケーションの責任です。)
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:
確信しているキャラクタは、XMPPノード識別子とXMPPリソース識別子に許容されていますが、IRIかURIの関連部分に許容されるというわけではありません。 キャラクタは以下の通りです:
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.
ノード識別子キャラクタはuserinfoにサブdelims規則で許容されていません、そして、リソース識別子キャラクタはセグメントでpchar規則で許容されていません。 XMPPアドレスをXMPP IRIかURIに変えるとき、これらのキャラクタはパーセントでコード化していなければなりません。
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.
当然、XMPPアドレスは、IRIかURIに変換されるのに計画(明確にxmpp計画)でprependedしなければならなくて、また、[IRI]と[URI]で定義された規則を固く守る変化を受ける必要があるかもしれません。 その上、URI構文と意味論の追加局面を利用するのは簡単な識別よりむしろXMPP実体とのさらに高度な相互作用を可能にするために望ましいです、権威コンポーネントや、質問コンポーネントや、断片識別子の部品などのように。
Saint-Andre Standards Track [Page 5] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[5ページ]。
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]:
したがって、XMPP IRIのためのABNF構文は以下に示すように"ifragment"、"ihost"、および"iunreservedする"の規則が[IRI]で定義されて、「pctによってコード化された」規則が[URI]で定義される[ABNF]によって指定されたAugmented BN記法を使用することで定義されます:
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"と等しい」:、」 inodeid"@"ihost ipathxmpp=[inodeid"@"]ihost[「/」iresid]inodeid=*(iunreserved / pctによってコード化された/nodeallow)」 「ihierxmpp[“?" iquerycomp][「#」ifragment]ihierxmpp=iauthpath / ipathxmpp iauthpath=」//iauthxmpp[「/」ipathxmpp]iauthxmpp=nodeallowは“!"と等しいです。 / "$" / "(" / ")" / "*" / "+" / "," / ";" /「=」iresid=*(iunreserved / pctによってコード化された/「再-サルヤナギ」)「再-サルヤナギ」は“!"と等しいです。 / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ":" / ";" 「/は「」 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].
しかしながら、xmpp URI計画の登録での包含には、以上の構文は適切ではありません、IANAがIRI計画ではなく、URI計画だけを認識するので。 したがって、IRIのためにというよりむしろXMPP URIのためのABNF構文はこのドキュメントのセクション3.3に示されるように定義されます。 IRI構文をURI構文に変換するのが必要であるなら、アプリケーションは[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サーバに関連しているノードを特定する目的に使用される基本的なXMPP IRI/URIに関する例です:
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の様々なコンポーネントの記述を以下のセクションに提供します。
2.3. Authority Component
2.3. 権威コンポーネント
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.
処理アプリケーションが権威コンポーネントがないとき構成されたユーザとして構成されたXMPPで認証するこのドキュメントのセクション2.8で説明されるように、処理アプリケーションが1セットのデフォルト信任状によって構成されたなら、サーバすなわち、権威コンポーネント部分は不要であり、無視されるべきです。
Saint-Andre Standards Track [Page 6] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[6ページ]。
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":
RFC3986[URI]のセクション3.2によると、権威コンポーネントは、二重スラッシュ(「//」)が先行して、次のスラッシュ(「/」)、疑問符(“?")、またはナンバー記号(「#」)キャラクタ、またはイリ/URIの終わりまでに終えられます。 セクションで、より完全に説明されるように、この.1通のドキュメント、権威コンポーネントの存在が node@domain として認証するように処理アプリケーションに示す2.8は構成された node@domain (認証に関するこのドキュメントのSecurity Considerations部を見る)としてというよりむしろ権威コンポーネントで指定しました。 (権威コンポーネントがほとんどのXMPP IRIsか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 "というノードを特定しますが、URIはそのノードとして以下を認証するように処理アプリケーションに示しません)。
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":
通信してください。「使用して、同様に、可能なaがコンポーネントについて質問する、」、--、」 メッセージを送るためのインタフェースの引き金となるように、以下のXMPP IRI/URIはメッセージを" guest@example.com "として認証して、送る処理アプリケーションを" support@example.com "に示します:
xmpp://guest@example.com/support@example.com?message
xmpp://客@example.com/サポート@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":
対照的に、" support@example.com "にメッセージを構成されたデフォルトアカウントとして認証して、送ってください以下のXMPP IRI/URIが、処理アプリケーションに示す:
xmpp:support@example.com?message
xmpp: support@example.com?message
2.4. Path Component
2.4. 経路コンポーネント
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アドレスを特定するか、またはIRI/URI処理の終わりがXMLスタンザがなるかどれに向けられた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
Saint-Andre Standards Track [Page 7] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[7ページ]。
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
2.5. Query Component
2.5. 質問コンポーネント
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]),
o XMPPメッセージスタンザ([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]),
o XMPPベースのテキストチャットルーム([XEP-0045]を見る)を接合します。
o interacting with publish-subscribe channels (see [XEP-0060]),
o 対話、発行、-申し込んでください、チャンネル([XEP-0060]を見ます)
o providing a SOAP interface (see [XEP-0072]), and
o そしてSOAPインタフェース([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「キー値」の組によって任意に補われた「質問タイプ」を通してこれまで思い描かれたすべての用途は要約できるという(これは[HTML]で説明された「x-wwwフォームはアプリケーション/urlencodedしている」MIMEの種類と同様です)Jabber/XMPP開発者社会の中の協定があります。
Saint-Andre Standards Track [Page 8] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[8ページ]。
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実体" example-node@example.com "にメッセージを送るためにインタフェースを始めることを意図するXMPP IRI/URIは以下の通り表されるかもしれません:
xmpp:example-node@example.com?message
xmpp: example-node@example.com?message
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実体" example-node@example.com "にメッセージを送るためにインタフェースを始めることを意図するXMPP IRI/URIは以下の通り表されるかもしれません:
xmpp:example-node@example.com?message;subject=Hello%20World
xmpp: こんにちは、% example-node@example.com?message;subject =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.
処理アプリケーションが質問コンポーネントか指定された質問タイプを理解していないなら、質問コンポーネントを無視して、例えば、<xmpp: example-node@example.com から成るとしてIRI/URIを扱わなければならない、gt;、<xmpp: example-node@example.com?query よりむしろ、gt。 処理アプリケーションが質問コンポーネントの中で特定のキーを理解していないなら、それはその主要な値とその関連値を無視しなければなりません。
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 Standards財団のXMPP Registrar機能([XEP-0053]を見る)は<http://www.xmpp.org/記録係/querytypes.html>でそのような質問タイプとキーの登録を維持します。 相互運用性、どんなアプリケーションも確実にするのを本書では定義された書式を使用することで助けるために、[XEP-0147]で指定された手順によると、SHOULDはその登録のどんな関連質問タイプとキーも提出します。
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アプリケーション。
2.6. Fragment Identifier Component
2.6. 断片識別子の部品
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
[URI]のセクション3.5に述べられているように、「URIの断片識別子の部品は第一のリソースと追加身元が分かる情報の参照による二次リソースの間接的な識別を許します」。 「XMPP IRI/URIによって特定されたリソースで少しのメディアタイプも利用可能にならないで([MIME]を見てください)、またしたがって([URI]の用語で)、表現が全くXMPPリソースで存在していないので、XMPP IRIs/URIにおける断片識別子の部品の意味論は未知であって事実上、自由であると考えられる」(前掲書)ことです。 特定のXMPPアプリケーションはそれら自身の目的に断片識別子の部品を利用するかもしれません。 しかしながら、処理アプリケーションが分からないなら、識別子を断片化してください。
Saint-Andre Standards Track [Page 9] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[9ページ]。
components or the syntax of a particular fragment identifier component included in an XMPP IRI/URI, it MUST ignore the fragment identifier component.
XMPP IRI/URIに特定の断片識別子の部品を含むコンポーネントか構文、それは断片識別子の部品を無視しなければなりません。
2.7. Generation of XMPP IRIs/URIs
2.7. XMPP虹彩/URIの世代
2.7.1. Generation Method
2.7.1. 世代方法
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アドレスが[XMPP-CORE]で指定された規則に従うのを確実にしなければなりません、関連stringprepのUTF-8[UTF-8]ストリングとアプリケーションが[STRINGPREP]の輪郭を描きながらコード化するのを含んでいて。 IRI構文[IRI]が、IRIのキャラクタがオリジナルのユニコード文字自身[ユニコード]であると指定するので、次に発生アプリケーションが解読しなければならないXMPP IRIを発生させるとき、彼らのオリジナルのユニコードへの固有のXMPPアドレスのUTF-8[UTF-8]キャラクタは形成します。 次に、発生アプリケーションは以下を連結しなければなりません:
1. The "xmpp" scheme and the ":" character.
1. そして、「"xmpp"計画、」、:、」 キャラクタ。
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. 「任意に(権威コンポーネントがノード識別子の前に含まれることであるなら)、キャラクタ、」 //、」、フォーム node@domain の権威の部品、およびキャラクタ、」 /、」
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"に従う一連のユニコード文字が判決を下します、"@"キャラクタによって後をつけられて。
4. A string of Unicode characters that conforms to the "ihost" rule.
4. "ihost"に従う一連のユニコード文字が判決を下します。
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. 「任意に(XMPPアドレスがXMPP「リソース識別子」を含んだなら)、キャラクタ、」 」 aが結ぶそれが"iresid"規則に従わせるユニコード文字の/。
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で指定されたマッピング手順を固く守らなければなりません。
Saint-Andre Standards Track [Page 10] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[10ページ]。
2.7.2. Generation Notes
2.7.2. 世代注意
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アドレスのノード識別子、ドメイン識別子、およびリソース識別子部分に許容されていますが、XMPP IRIの"inodeid"、"ihost"、および"iresid"規則で禁止されています。 そして、「明確に、「#」と“?"キャラクタがノード識別子に許容されている、」 /、」、“?"、「#」、および"@"キャラクタはリソース識別子に許容されていますが、これらのキャラクタはデリミタとしてXMPP虹彩で使用されます。 添加で「「([米国のASCII]のスペース)キャラクタは、リソース識別子に許容されていますが、IRIsで禁止されています」。 したがって、XMPPアドレスをXMPP IRIに変えるとき、すべての以上のキャラクタがパーセントでコード化していなければなりません。
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):
そのアドレスは以下のXMPP IRI(レイアウト目的のために2つの系列に分けられる)に変えられるでしょう:
xmpp:nasty!%23$%25()*+,-.;=%3F%5B%5C%5D%5E_%60%7B%7C%7D~node
@example.com
: 嫌なもの!%を23ドルの%25()*+xmppする、-、; =%3Fの%5B%5Cの%5D%5ユーロの_%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):
そのアドレスは以下の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
. %2Fを: node@example.com /よそよそしい%20!%23%22ドルの%25と'()*+xmppする、:、; 5Eの_%%の3C=の%の3ユーロの%の3Fの%の40%の5B%の5Cの%の5D%の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].
その上、米国-ASCII範囲[米国-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
以下のテーブルが本書では議論した識別子のそれぞれのencodingsと「キャリヤー部隊」を理解しているのに作成者を助けるかもしれない、すなわち: (1) 固有のXMPPアドレス、(2)IRIs、および(3)URI。 詳細について、また、このドキュメントのセクション3.5を参照してください。
Saint-Andre Standards Track [Page 11] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[11ページ]。
as Section 3 of [XMPP-CORE], Section 6.4 of [IRI], and Section 2 of [URI].
[XMPP-コア]のセクション3、[IRI]のセクション6.4、および[URI]のセクション2として。
+--------------+-----------+-----------+ | Identifier | Encoding | Units | +--------------+-----------+-----------+ | XMPP address | UTF-8 | Octets | +--------------+-----------+-----------+ | IRI | Unicode | 16/32-bit | | | | values | +--------------+-----------+-----------+ | URI | Percent- | US-ASCII | | | encoded | | | | UTF-8 | | +--------------+-----------+-----------+
+--------------+-----------+-----------+ | 識別子| コード化| ユニット| +--------------+-----------+-----------+ | XMPPアドレス| UTF-8| 八重奏| +--------------+-----------+-----------+ | イリ| ユニコード| 16/32ビットです。| | | | 値| +--------------+-----------+-----------+ | URI| パーセント| 米国-ASCII| | | コード化されます。| | | | UTF-8| | +--------------+-----------+-----------+
2.7.3. Generation Example
2.7.3. 世代の例
Consider the following XMPP address:
以下のXMPPがアドレスであると考えてください:
<jiři@čechy.example/v Praze>
<jiと# x159;i@& #x10D; echy.example/v Praze>。
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」 「ユニコード文字LATIN SMALL LETTER R WITH CARON、およびストリング」 #x10Dのためのスタンド」 ユニコード文字LATIN SMALL LETTER C WITH CARONのためのスタンド。 「」 #x.」 フォームはユニコード文字の代理をするのに本書では記号法のデバイスとして使用されます、ASCIIだけドキュメントにすることができないキャラクタの代理をするのに[IRI]で使用される「XML記法」に続いて。 XMPPイリはXML Notationの表現ではなく、ユニコード文字自身を含まなければなりません(特に、「#」キャラクタがイリ構文で禁じられることに注意してください)。 XMPP URI MUSTは以下で説明されるように適切にそのようなキャラクタから逃げます。 '<'と'>'キャラクタをアドレス自体の一部ではありませんが、読みやすさのためのアドレスを引きたたせるように提供します。 (チェコの言語を理解していない人に関して、「 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アドレスが[XMPP-CORE]で指定された規則に従うのを確実にしてください、関連stringprepプロフィール[STRINGPREP]のアプリケーションを含んで、UTF-8ストリングとして[UTF-8]をコード化して。
Saint-Andre Standards Track [Page 12] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[12ページ]。
2. Concatenate the following:
2. 以下を連結してください:
1. The "xmpp" scheme and the ":" character.
1. そして、「"xmpp"体系、」、:、」 キャラクタ。
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アドレスを表す一連のユニコード文字。
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).
「結果は以下のXMPP IRI(ユニコード文字LATIN SMALL LETTER C WITH CARONに[IRI]、ストリング」 #x159; 」 ユニコード文字LATIN SMALL LETTER R WITH CARONとストリング」 #x10Dのためのスタンド; 」 スタンドで使用される「XML記法」に従って、もう一度それに注意してください; XMPP IRIはユニコード文字自身を含む)です。
<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を生成するために、アプリケーションは[IRI]のセクション3.1で指定された手順を固く守らなければなりません、以下のURIをもたらして:
<xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
<xmpp: ji%C5%99i@%C4%8Dechy.example/v%20Praze 、gt。
2.8. Processing of XMPP IRIs/URIs
2.8. XMPP虹彩/URIの処理
2.8.1. Processing Method
2.8.1. 処理メソッド
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で指定された手順に従うことでURIをIRIに変換しなければなりません。
In order to decompose an XMPP IRI for interaction with the entity it identifies, a processing application MUST separate:
それが特定する実体との相互作用のためにXMPP IRIを分解するために、処理アプリケーションは分離しなければなりません:
1. The "xmpp" scheme and the ":" character.
1. そして、「"xmpp"体系、」、:、」 キャラクタ。
Saint-Andre Standards Track [Page 13] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[13ページ]。
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. 「権威コンポーネントであって、含まれる、(間のユニコード文字のストリング、」 //、」 キャラクタと次、」 /、イリの」 キャラクタ、“?"キャラクタ、「#」キャラクタ、または端)
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アドレスを表す一連のユニコード文字が判決を下します。
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アドレスが[XMPP-CORE]で指定された規則に従うのを確実にしなければなりません、関連stringprepプロフィール[STRINGPREP]のアプリケーションを含んでいて。 (2) 次に、(1) 一層の完全なXMPPがそれ自体を扱って、処理アプリケーションがそうするだろうか、または支援アプリケーションを呼び出して、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-CORE]で定義されたXMPP接続手順を固く守ることによって。 (注意: それが1セットのデフォルト資格証明書によって構成されたなら、処理アプリケーションSHOULDは権威コンポーネントを無視します。)
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スタンザを意図している受取人に送ってください。
Saint-Andre Standards Track [Page 14] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[14ページ]。
2.8.2. Processing Notes
2.8.2. 処理注意
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の終わりで説明される「さらなるXMPP取り扱い」の最初の2ステップがHTTP認証[HTTP-AUTH]と同様であることに注意するのを助けるかもしれません、次の3ステップはmailtoの取り扱いと同様ですが: URI[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通のセクション2.7ドキュメントに述べられるように、確信しているキャラクタは、固有のXMPPアドレスのノード識別子、ドメイン識別子、およびリソース識別子部分に許容されていますが、XMPP IRIの"inodeid"、"ihost"、および"iresid"規則で禁止されています。 XMPP IRIsのこれらのキャラクタにおいて、対応するパーセントコード化された八重奏を表された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
: 嫌なもの!%を23ドルの%25()*+xmppする、-、; =%3Fの%5B%5Cの%5D%5ユーロの_%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
. %2Fを: node@example.com /よそよそしい%20!%23%22ドルの%25と'()*+xmppする、:、; 5Eの_%%の3C=の%の3ユーロの%の3Fの%の40%の5B%の5Cの%の5D%の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 /よそよそしい、!#、」 $%と'()*+、-. /: @^_'| ; <=>--[\]~リソース
2.8.3. Processing Example
2.8.3. 処理の例
Consider the XMPP URI that resulted from the previous example (see Section 2.7.3):
前の例から生じたXMPP URIを考えてください(セクション2.7.3を見てください):
<xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
<xmpp: ji%C5%99i@%C4%8Dechy.example/v%20Praze 、gt。
Saint-Andre Standards Track [Page 15] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[15ページ]。
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]のセクション3.2で指定された手順を固く守らなければなりません、以下のIRIをもたらして:
<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"体系を取り除くだろう、」、:、」 「このXMPP IRIからXMPPアドレスを抜粋するキャラクタ、どんなパーセントも変換すると、八重奏は"inodeid"、"ihost"、および"iresid"規則からそれらのキャラクタ同等物(」 例えば、間隔文字への%20インチ)にコード化されました。
The result is this XMPP address:
結果はこのXMPPアドレスです:
<jiři@čechy.example/v Praze>
<jiと# x159;i@& #x10D; echy.example/v Praze>。
2.9. Internationalization
2.9. 国際化
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住所の中の米国-ASCII範囲[米国-ASCII]の外での八重奏はパーセントでコード化された八重奏に変換できるので、XMPPアドレスはInternationalized Resource Identifiers[IRI]と共にうまくいくように設計されています。 そして、「それらのキャラクタ同等物(」 例えば、米国-ASCII間隔文字への%20インチ)への"inodeid"、"ihost"、および"iresid"規則からのstringprep検証の例外、構文関連している米国-ASCII文字(例えば、“?")の変換、およびパーセントでコード化された八重奏の変換で、特に、直接"xmpp"体系をprependingすることによってXMPPイリを組み立てることができる、」、:、」 XMPPアドレスへのキャラクタ。 その上、[IRI]のセクション3.1で指定された手順を固く守ることによって、URI構文にXMPP IRIを変換できます、そして、[IRI]のセクション3.2で指定された手順を固く守ることによって、IRI構文にXMPP URIを変換できます、その結果、URIを処理できますが、IRIsを処理できないアプリケーションで相互運用性を確実にします。
3. IANA Registration of xmpp URI Scheme
3. xmpp URI SchemeのIANA Registration
In accordance with [URI-SCHEMES], this section provides the information required to register the xmpp URI scheme.
[URI-SCHEMES]に従って、このセクションはxmpp URI体系を登録するのに必要である情報を提供します。
3.1. URI Scheme Name
3.1. URI体系名
xmpp
xmpp
3.2. Status
3.2. 状態
permanent
永久的
Saint-Andre Standards Track [Page 16] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[16ページ]。
3.3. URI Scheme Syntax
3.3. URI体系構文
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]:
Augmentedバッカス指定されるとしての[ABNF]によるナウアFormを使用する下でxmpp URIのための構文は定義されます、「断片」、「ホスト」と「pctはコード化し」て、「無遠慮な」規則が[URI]で定義されるところで:
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"と等しい」:、」 nodeid"@"ホストpathxmpp=[nodeid"@"]ホスト[「/」残油]nodeid=*(無遠慮であるかpctによってコード化された/nodeallow)」 「hierxmpp[“?" querycomp][「#」断片]hierxmpp=authpath / pathxmpp authpath=」//authxmpp[「/」pathxmpp]authxmpp=nodeallowは“!"と等しいです。 / "$" / "(" / ")" / "*" / "+" / "," / ";" /「=」残油=*(無遠慮であるかpctによってコード化された/「再-サルヤナギ」)「再-サルヤナギ」は“!"と等しいです。 / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ":" / ";" 「/は「*(無遠慮であるかpctによってコード化される)のquerytype[*対にする]」 querycomp=querytype=組=と等しいです」」 主要な「=」値主要な=*(無遠慮であるかpctによってコード化された)価値は*と等しいです。(無遠慮であるかpctによってコード化された)
3.4. URI Scheme Semantics
3.4. URI体系意味論
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体系は、Extensible Messagingを使用することでネイティブに交信する実体とPresenceプロトコル(XMPP)を特定して、リソース位置にというよりむしろ識別に主に使用されます。 しかしながら、xmpp URIを処理するアプリケーションがURIによって特定されるXMPPアドレスとの相互作用を可能にするなら、XMPPアドレスにカプセル化されたXMPPアドレスを再建して、適切なXMPPサーバに接続して、適切なXMPP「スタンザ」(XMLは断片化する)を送ると、このドキュメントのセクション2で定義された方法論、XMPP IRIsとURIのUseが続かなければなりません。 (注意: xmpp URI体系に関連しているどんなMIMEの種類もありません。)
3.5. Encoding Considerations
3.5. 問題をコード化します。
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
また、XMPP URIに加えて、XMPP Internationalized Resource Identifiers(IRIs)があるでしょう。 IRI(そして[XMPP-CORE]に従って)にExtensible MessagingとPresenceプロトコル(XMPP)アドレスを変換する前に、生成するアプリケーション(例えば、UTF-16ストリングとしてアプリケーションのアドレスの内部の表現をUTF-8ストリングに変えるのによる)で一連のUTF-8キャラクタ[UTF-8]としてXMPPアドレスを表さなければなりません。 IRI構文[IRI]が、IRIのキャラクタがオリジナルのユニコード文字自身[ユニコード]であると指定するので、XMPP IRIを生成するとき、生成するアプリケーションは固有のXMPPアドレスのUTF-8キャラクタを彼らの元のユニコードフォームに解読しなければなりません。 URI
Saint-Andre Standards Track [Page 17] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[17ページ]。
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.
構文[URI]はそれをspecificesします。URIにおけるキャラクタは米国-ASCII文字専用[米国-ASCII]です。(その時、XMPP URIが生成するアプリケーションであると生成するのがRFC3987で指定された手順を固く守ることによって、米国-ASCII文字にXMPP IRIのユニコード文字から逃げなければなりません)。
3.6. Applications/Protocols That Use This URI Scheme Name
3.6. このURI体系名を使用するアプリケーション/プロトコル
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かIRIsであると認識する必要がある非固有のアプリケーションでXMPPネットワークに使用されることを意図します。
3.7. Interoperability Considerations
3.7. 相互運用性問題
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 Standards財団のXMPP Registrar機能は質問タイプとXMPP URIの質問コンポーネントに使用できるキーと<http://www.xmpp.org/記録係/querytypes.html>に位置するIRIsの登録を維持します。
3.8. Security Considerations
3.8. セキュリティ問題
See Section 5 of this document, Security Considerations.
このドキュメントのセクション5、Security Considerationsを見てください。
3.9. Contact
3.9. 接触
Peter Saint-Andre [mailto:stpeter@jabber.org, xmpp:stpeter@jabber.org]
ピーターサンアンドレ[xmpp: mailto: stpeter@jabber.org 、 stpeter@jabber.org ]
3.10. Author/Change Controller
3.10. 作者/変化コントローラ
This scheme is registered under the IETF tree. As such, the IETF maintains change control.
この体系はIETF木の下に登録されます。 そういうものとして、IETFは変化コントロールを維持します。
3.11. References
3.11. 参照
[XMPP-CORE]
[XMPP-コア]
4. IANA Considerations
4. IANA問題
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
このドキュメントはRFC4622によって作成されたURI体系登録を時代遅れにします。 このドキュメントのセクション3で登録テンプレートを見つけることができます。 相互運用性を確実にするのを助けるために、XMPP Standards財団のXMPP Registrar機能は質問に使用できる質問タイプとキーの登録を維持します。
Saint-Andre Standards Track [Page 18] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[18ページ]。
components of XMPP URIs and IRIs, located at <http://www.xmpp.org/registrar/querytypes.html>.
<http://www.xmpp.org/記録係/querytypes.html>に位置するXMPP URIとIRIsの部品。
5. Security Considerations
5. セキュリティ問題
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 IRIsに適用されます、そして、[URI]と[XMPP-CORE]で議論したセキュリティ問題はXMPP URIに適用されます。 [URI-SCHEMES]のセクション2.7と[URI]のセクション7によると、特定のセキュリティ問題は以下のセクションで指定されます。
5.1. Reliability and Consistency
5.1. 信頼性と一貫性
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サーバか関連サービスです。 サーバかサービス管理者がいつでもサーバかサービスの使用を中止するのが、当然通常可能ですが、そのようなサーバかサービスを特定するIRIs/URIは最も信頼できて一貫したXMPP IRIs/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 IRIs/URIの信頼性と一貫性はおそらくフォームdomain.tldのXMPPアドレスを特定するものとフォーム node@domain.tld のXMPPアドレスを特定するものの間のどこかまで下がるでしょう。
Saint-Andre Standards Track [Page 19] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[19ページ]。
5.2. Malicious Construction
5.2. 悪意がある工事
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]).
禁止はXMPP IRIs/URIにおけるポートナンバーでそれほどXMPP IRIs/URIの悪意がある工事をありそうにしません(DNS SRVを使用すると、[DNS-SRV]はポートナンバーが発見されることであるので、記録されます、[XMPP-CORE]で指定されるように)。
5.3. Back-End Transcoding
5.3. バックエンドコード変換
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 IRIs/URIの使用が有害な「反-参照をつけ」をもたらすだろうというのはありそうもないと考えられます。 しかしながら、XMPPプロトコル拡張子が情報検索のためにメソッドを定義するなら、それはその情報へのアクセスの適切なコントロールを定義しなければなりません。 さらに、XMPPサーバSHOULD NOTはネイティブにXMPP IRIs/URIを分析しますが、代わりに、SHOULDはそれに加えて[XMPP-CORE]とどんな必要な拡大でも指定されたXMLワイヤプロトコルだけを受け入れます。
5.4. Sensitive Information
5.4. 機密情報
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.
ウェブブラウザか他の非固有のアプリケーションでXMPP実体と対話する能力で、機密情報(特定のXMPPアプリケーション・プロトコル拡張子のサポートなどの)を暴露して、その結果、可能でないか、または固有のXMPPネットワークでありそうもない攻撃に着手するのは可能になるかもしれません。 XMPP IRIsか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 IRIs/URIで悪意あるユーザーがXMPP IRIs/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 IRIs/URIの権威コンポーネントで禁じられます。 事実上、それらは必要ではありません、XMPPでの認証がSimple AuthenticationとSecurity Layer[SASL]を通して起こるという事実でSASL ANONYMOUSメカニズムを使用するのが可能になるので、望まれているなら。
Saint-Andre Standards Track [Page 20] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[20ページ]。
5.5. Semantic Attacks
5.5. 意味攻撃
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 IRIs/URIで」 //、」 キャラクタは経路コンポーネントよりむしろ権威コンポーネントに先行します。 その結果、xmpp: //guest@example.com が示す、xmpp: guest@example.com が" guest@example.com "" guest@example.com "というノードを特定しますが、認証するために。 「処理アプリケーションが明確にこれらのフォームを区別しなければならなくて、ユーザエージェントSHOULDが包含からの人間のユーザをがっかりさせる、」 」 XMPP虹彩/URIにおけるキャラクタが以来使用する権威コンポーネントの//は、より一般に、専門化しているシナリオだけで役立たないように思い描かれます。
5.6. Spoofing
5.6. スプーフィング
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に有効に最大限の範囲のユニコード文字を含む能力で、(また、呼ばれた「スプーフィング」)をまねるあるフォームのアドレスを作成するのは、より簡単になるかもしれません。 しかしながら、XMPP IRIsは他のIRIsとこの点で異なっていません、そして、人間のユーザにXMPP IRIsを寄贈するアプリケーションは偽造しているアドレス(例えば「フィッシング詐欺」として知られている現象)から生じる攻撃を防ぐのを助けるためにアドレス物真似に関して最も良い習慣を固く守らなければなりません。 詳細について、[IRI]のSecurity Considerationsを参照してください。
6. Acknowledgements
6. 承認
Thanks to Martin Duerst, Lisa Dusseault, Frank Ellerman, Roy Fielding, Joe Hildebrand, and Ralph Meijer for their comments.
彼らのコメントをマーチンDuerst、リサDusseault、フランクEllerman、ロイFielding、ジョー・ヒルデブラント、およびラルフMeijerをありがとうございます。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2007.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2007年1月。
[IRI] Duerst, M. and M. Suignard, "Internationalized
Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI] DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TERMS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
Saint-Andre Standards Track [Page 21] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[21ページ]。
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-コア] サンアンドレ、P.、「広げることができるメッセージングと存在は以下について議定書の中で述べ(XMPP)」。 「コア」、RFC3920、2004年10月。
7.2. Informative References
7.2. 有益な参照
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPIM] ピーターソン、J.、「インスタントメッセージング(CPIM)のための一般的なプロフィール」、RFC3860、2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)",
RFC 3859, August 2004.
[CPP] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、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 RR(DNS SRV)」、RFC2782(2000年2月)。
[HTML] Raggett, D., "HTML 4.0 Specification", W3C REC REC-
html40-19980424, April 1998.
[HTML] Raggett、D.、「HTML4.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認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、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)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The
mailto URL scheme", RFC 2368, July 1998.
1998年7月の[MAILTO]ホフマンとP.とMasinter、L.とJ.Zawinski、「mailto URL計画」RFC2368。
[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を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("STRINGPREP")", RFC 3454,
December 2002.
[STRINGPREP] ホフマンとP.とM.Blanchet、「国際化しているストリング("STRINGPREP")の準備」、RFC3454、2002年12月。
Saint-Andre Standards Track [Page 22] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[22ページ]。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
3.2.0", 2000.
[ユニコード] ユニコード共同体、「ユニコード規格、バージョン、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/).
ユニコードStandard、バージョン、3.2、.0、ユニコードStandard、バージョン3.0(読書、MA、アディソン・ウエスリー、2000ISBN0-201-61633-5)で、ユニコードStandard Annex#27によって修正されるように、定義されます: ( http://www.unicode.org/reports/tr27/ )とユニコード規格別館#28によるユニコード3.1: ユニコード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.
[ユリ-計画] ハンセン、T.、ハーディー、T.、L.Masinter、および「新しいURI計画のためのガイドラインと登録手順」、RFC4395、2月2006日
[US-ASCII] American National Standards Institute, "Coded
Character Set - 7-bit American Standard Code for
Information Interchange", ANSI X3.4, 1986.
[米国-ASCII] American National Standards Institut、「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、ISO10646の変化形式」STD63、RFC3629、11月2003日
[XEP-0009] Adams, D., "Jabber-RPC", XSF XEP 0009, February 2006.
[XEP-0009]アダムス、2006年2月のD.、「おしゃべり-RPC」XSF XEP0009。
[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.聖者2007年2月のアンドレ、「サービスディスカバリー」XSF XEP0030。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
April 2007.
[XEP-0045] サンアンドレ、P.、「マルチユーザチャット」、XSF XEP0045、2007年4月。
[XEP-0053] Saint-Andre, P., "XMPP Registrar Function", XSF
XEP 0053, December 2006.
[XEP-0053] サンアンドレ、P.、「XMPP記録係機能」、XSF XEP0053、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 XEP0060、9月2006日
[XEP-0072] Forno, F. and P. Saint-Andre, "SOAP Over XMPP", XSF
XEP 0072, December 2005.
[XEP-0072]FornoとF.とP.サンアンドレ、「XMPPの上の石鹸」、XSF XEP0072、2005年12月。
[XEP-0077] Saint-Andre, P., "In-Band Registration", XSF XEP 0077,
January 2006.
[XEP-0077] サンアンドレ、P.、「バンドにおける登録」、XSF XEP0077、2006年1月。
[XEP-0147] Saint-Andre, P., "XMPP URI Scheme Query Components",
XSF XEP 0147, September 2006.
[XEP-0147] サンアンドレ、P.、「XMPP URI計画質問の部品」、XSF XEP0147、2006年9月。
Saint-Andre Standards Track [Page 23] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[23ページ]。
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004.
[XMPP、-、不-、]、サンアンドレ、P.、「広げることができるメッセージングと存在は以下について議定書の中で述べ(XMPP)」。 「インスタントメッセージングと存在」、RFC3921、10月2004日
Saint-Andre Standards Track [Page 24] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[24ページ]。
Appendix A. Differences from RFC 4622
RFC4622からの付録A.差
Several errors were found in RFC 4622. This document corrects those errors. The resulting differences from RFC 4622 are as follows:
いくつかの誤りがRFC4622で見つけられました。 このドキュメントはそれらの誤りを修正します。 RFC4622からの結果として起こる違いは以下の通りです:
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.
o それを指定する、キャラクタ、「[「「\」、」、]、」、"^"、「'、「「「「|、」、」、」 XMPPノード識別子に許容されていますが、サブdelims規則に従って虹彩かURIでは許容されていない、」、'
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 Specified that the characters '"', "<", ">", "[", "\", "]", "^", "`", "{", "|", and "}" are allowed in XMPP resource identifiers but not allowed in IRIs or URIs according to the pchar rule.
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 ユリ: xmpp: stpeter@jabber.org
Saint-Andre Standards Track [Page 25] RFC 5122 XMPP IRIs/URIs February 2008
サンアンドレ規格はXMPP虹彩/URI2008年2月にRFC5122を追跡します[25ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Saint-Andre Standards Track [Page 26]
サンアンドレ標準化過程[26ページ]
一覧
スポンサーリンク
