RFC4622 日本語訳
4622 Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and PresenceProtocol (XMPP). P. Saint-Andre. July 2006. (Format: TXT=49968 bytes) (Obsoleted by RFC5122) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Saint-Andre Request for Comments: 4622 JSF Category: Standards Track July 2006
コメントを求めるワーキンググループP.サンアンドレ要求をネットワークでつないでください: 4622年のJSFカテゴリ: 標準化過程2006年7月
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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)の使用を定義します。
Saint-Andre Standards Track [Page 1] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[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 .......................................................4
2.3. Authority Component ........................................6
2.4. Path Component .............................................7
2.5. Query Component ............................................7
2.6. Fragment Identifier Component ..............................9
2.7. Generation of XMPP IRIs/URIs ...............................9
2.7.1. Generation Method ...................................9
2.7.2. Generation Notes ...................................10
2.7.3. Generation Example .................................11
2.8. Processing of XMPP IRIs/URIs ..............................12
2.8.1. Processing Method ..................................12
2.8.2. Processing Notes ...................................13
2.8.3. Processing Example .................................14
2.9. Internationalization ......................................14
3. IANA Registration of xmpp URI Scheme ...........................15
3.1. URI Scheme Name ...........................................15
3.2. Status ....................................................15
3.3. URI Scheme Syntax .........................................15
3.4. URI Scheme Semantics ......................................16
3.5. Encoding Considerations ...................................16
3.6. Applications/protocols That Use This URI Scheme Name ......16
3.7. Interoperability Considerations ...........................16
3.8. Security Considerations ...................................16
3.9. Contact ...................................................17
3.10. Author/Change Controller .................................17
3.11. References ...............................................17
4. IANA Considerations ............................................17
5. Security Considerations ........................................17
5.1. Reliability and Consistency ...............................17
5.2. Malicious Construction ....................................18
5.3. Back-End Transcoding ......................................18
5.4. Sensitive Information .....................................18
5.5. Semantic Attacks ..........................................19
5.6. Spoofing ..................................................19
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................20
1. 序論…3 1.1. 用語…3 2. XMPP虹彩とURIの使用…4 2.1. 原理…4 2.2. 形成してください…4 2.3. 権威コンポーネント…6 2.4. 経路コンポーネント…7 2.5. コンポーネントについて質問してください…7 2.6. 部分識別子コンポーネント…9 2.7. XMPP虹彩/URIの世代…9 2.7.1. 世代メソッド…9 2.7.2. 世代注意…10 2.7.3. 世代の例…11 2.8. XMPP虹彩/URIの処理…12 2.8.1. 処理メソッド…12 2.8.2. 処理注意…13 2.8.3. 処理の例…14 2.9. 国際化…14 3. xmpp URI SchemeのIANA Registration…15 3.1. URI体系名…15 3.2. 状態…15 3.3. URI体系構文…15 3.4. URI体系意味論…16 3.5. 問題をコード化します…16 3.6. このURIを使用するアプリケーション/プロトコルが名前を計画します…16 3.7. 相互運用性問題…16 3.8. セキュリティ問題…16 3.9. 連絡します。17 3.10. コントローラを書くか、または変えてください…17 3.11. 参照…17 4. IANA問題…17 5. セキュリティ問題…17 5.1. 信頼性と一貫性…17 5.2. 悪意がある工事…18 5.3. バックエンドコード変換…18 5.4. 機密の情報…18 5.5. 意味攻撃…19 5.6. だまします…19 6. 参照…20 6.1. 標準の参照…20 6.2. 有益な参照…20
Saint-Andre Standards Track [Page 2] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[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 and must adhere to various profiles of [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]の様々なプロフィールを固く守らなければなりません。 結果は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 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[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. Neither does a generic XMPP entity 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実体はhttpなどのどんな既存のURI体系の意味論も実装しません:、以下をftpするか、または以下をmailtoします。 計画してください。 したがって、IRIかURIとしてどんなXMPP実体(インスタントメッセージングと存在実体であるだけではない)とも特定するか、または対話するのを可能にする新しいURI体系を定義するのは適切です。
XMPP IRIs and URIs are defined for use by non-native interfaces and applications, and primarily for the purpose of identification rather than of interaction (on the latter distinction, see Section 1.2.2 of [URI]). 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は非ネイティブのインタフェースとアプリケーションによる使用、および主として相互作用についてというよりむしろ識別の目的のために定義されます(後者の区別のときに、[URI]についてセクション1.2.2を見てください)。 データが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を参照してください; 「リソース識別子」という用語のこの使用は[ユリ]のセクション1.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] profiles and [IDNA] restrictions, (2) follows a certain set of syntax rules, and (3) is encoded as [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]制限に従わせる一連のユニコード文字です、そして、(2)はあるシンタックス・ルールに従います、そして、(3)は[UTF-8]としてコード化されます。 以下としてAugmented BN記法([ABNF])を使用することでそのようなアドレスの書式を表すことができます。
[ node "@" ] domain [ "/" resource ]
[ノード"@"] ドメイン[「/」リソース]
Saint-Andre Standards Track [Page 4] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[4ページ]。
In this context, the "node" and "resource" rules rely on distinct profiles of [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 into [IDNA] syntax before addressing XML stanzas to the specified entity on an XMPP network.)
このような関係においては、「ノード」と「リソース」規則は[STRINGPREP]の異なったプロフィールを当てにします、そして、「ドメイン」規則は[IDNA]で説明されるように国際化ドメイン名の概念を当てにします。 (以下に注意してください。 IRI構文自体でpunycodeについて言及する必要は全くありません、どんなpunycode表現も国際化ドメイン名を表すためにXMPPアプリケーションだけで起こるでしょう、したがって。 しかしながら、XMPPネットワークの指定された実体へのスタンザをXMLに扱う前に[IRI]構文を[IDNA]構文に変換するのは、処理アプリケーションの責任です。)
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実体とのさらに高度な相互作用を可能にするために望ましいです、権威コンポーネントや、質問コンポーネントや、部分識別子コンポーネントなどのように。
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], the "pct-encoded" rule is defined in [URI], and DQUOTE is defined in [ABNF]:
したがって、XMPP IRIのためのABNF構文は以下に示すように"ifragment"、"ihost"、および"iunreservedする"の規則が[IRI]で定義されて、「pctによってコード化された」規則が[URI]で定義されて、DQUOTEが[ABNF]で定義される[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 = "!" / DQUOTE / "$" / "&" / "'" / "(" / ")" /
"*" / "+" / "," / ":" / ";" / "<" / "=" / ">" /
"[" / "\" / "]" / "^" / "`" / "{" / "|" / "}"
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によってコード化されたか「再-血色の悪」い)「再-サルヤナギ」が“!"と等しい、」、' 「/ DQUOTE /「$」/“&"/、「'」 「/「(「/」)」/「*」/「+」/」、/」:、」、' / ";" 「[「/「\」/」]」という/"<"/「=」/">"//"^"/、「'、「/、「「/、「| 」 /」、iquerytype[*ipair]」 iquerycomp=iquerytypeが*iunreserved ipair=と等しい、」、'、」、。 ikeyはivalue ikey=*iunreserved ivalue=*と「等しいです」。(iunreserved / pctによってコード化された)
Saint-Andre Standards Track [Page 5] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[5ページ]。
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 (see below under "IANA Registration"). 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に示されるように定義されます(「IANA登録」で以下を見てください)。 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セットのデフォルト資格証明書によって構成されたなら、サーバすなわち、権威コンポーネント部は不要であり、無視されるべきです。
In accordance with Section 3.2 of RFC 3986, 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のセクション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
Saint-Andre Standards Track [Page 6] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[6ページ]。
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
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; examples include but are not limited to:
XMPP IRI/URIの質問コンポーネントには可能性が情報をカプセル化しながらケースを使用する多くがあります。 含んでいますが、例は制限されません:
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]を見る)のために、調べます。
Saint-Andre Standards Track [Page 7] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[7ページ]。
o triggering a remote procedure call (see [JEP-0009]),
o 遠隔手続き呼び出し([JEP-0009]を見る)の引き金となります。
o discovering the identity or capabilities of another entity (see
[JEP-0030]),
o アイデンティティを発見するか、別の実体の能力([JEP-0030]を見ます)
o joining an XMPP-based text chat room (see [JEP-0045]),
o XMPPベースのテキストチャットルーム([JEP-0045]を見る)を接合します。
o interacting with publish-subscribe channels (see [JEP-0060]),
o 対話、発行、-申し込んでください、チャンネル([JEP-0060]を見ます)
o providing a SOAP interface (see [JEP-0072]), and
o そしてSOAPインタフェース([JEP-0072]を見る)を提供する。
o registering with another entity (see [JEP-0077]).
o 別の実体([JEP-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開発者社会の中の協定があります。
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 Jabber Registrar function (see [JEP-0053]) of the Jabber Software Foundation maintains a registry of such query types and keys at <http://www.jabber.org/registrar/querytypes.html>. To help ensure
注意されるように、多くの種類のXMPP利用(実際のものと同様に潜在的の)は存在しています、そして、そのようなアプリケーションはXMPP URIの質問コンポーネント部分での使用のための質問タイプとキーを定義するかもしれません。 Jabber Software財団のJabber Registrar機能([JEP-0053]を見る)は<http://www.jabber.org/記録係/querytypes.html>でそのような質問タイプとキーの登録を維持します。 助けは確実にします。
Saint-Andre Standards Track [Page 8] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[8ページ]。
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 [JEP-0147].
相互運用性(手順に従ったその登録のSHOULDが提出するこのドキュメントで定義された書式を使用して、どんな関連質問もタイプするキーが[JEP-0147]で指定したどんなアプリケーションも)。
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 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 IRIs/URIにおける部分識別子コンポーネントの意味論は未知であって事実上、自由であると考えられる」(前掲書)ことです。 特定のXMPPアプリケーションはそれら自身の目的に部分識別子コンポーネントを利用するかもしれません。 しかしながら、処理アプリケーションが、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 application of the relevant [STRINGPREP]; it MUST then concatenate the following:
XMPPノード識別子、ドメイン識別子、およびリソース識別子からXMPP IRIを形成するために、生成するアプリケーションは、最初にXMPPアドレスが[XMPP-CORE]で指定された規則に従うのを確実にしなければなりません、関連[STRINGPREP]のアプリケーションを含んでいて。 次に、それは以下を連結しなければなりません:
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"規則に従わせるユニコード文字の/。
Saint-Andre Standards Track [Page 9] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[9ページ]。
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で指定されたマッピング手順を固く守らなければなりません。
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:
そのアドレスは以下のXMPP IRIに変えられるでしょう:
xmpp:nasty!%23$%25()*+,-.;=%3F[\]^_`{|}~node@example.com
'xmpp: 嫌なもの!%23$%25()*+、-、^_'| =%3F[\] ~node@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 two lines for layout purposes):
そのアドレスは以下のXMPP IRI(レイアウト目的のために2つの系列に分けられる)に変えられるでしょう:
xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
xmpp: node@example.com /よそよそしい%、20!%の23インチの$%25と'()*+、-. %2F:、;、<が>%3F%40[\]^_と等しい '| ~リソース
Furthermore, virtually any character outside the [US-ASCII] range 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
その上、[米国のASCII]の範囲の外の実際にはどんなキャラクタもXMPPアドレスとしたがって、XMPP IRIにも許容されていますが、URI構文は、直接そのようなキャラクタを禁じて、そのようなキャラクタがパーセントでコード化していなければならないと指定します。 URIが関連づけたことを決定します。
Saint-Andre Standards Track [Page 10] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[10ページ]。
with an XMPP IRI, an application MUST adhere to the mapping procedure specified in Section 3.1 of [IRI].
XMPP IRIと共に、アプリケーションは[IRI]のセクション3.1で指定されたマッピング手順を固く守らなければなりません。
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, following the "XML Notation" used in [IRI] to represent characters that cannot be rendered in ASCII-only documents (note also that these characters are represented in their stringprep canonical form). 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 read Czech, this example could be Anglicized as "george@czech-lands.example/In Prague".
以下に注意してください。 「ストリング」 #x159」 「ユニコード文字LATIN SMALL LETTER R WITH CARON、およびストリング」 #x10Dのためのスタンド」 ASCIIだけドキュメント(また、これらのキャラクタが彼らのstringprep標準形で代理をされることに注意する)にすることができないキャラクタの代理をするのに[IRI]で使用される「XML記法」に続いて、ユニコード文字LATIN SMALL LETTER C WITH CARONを表します。 '<'と'>'キャラクタをアドレス自体の一部ではありませんが、読みやすさのためのアドレスを引きたたせるように提供します。 チェク語を読まない人に関しては、「 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 and encoding as a [UTF-8] string.
1. XMPPアドレスが[XMPP-CORE]で指定された規則に従うのを確実にしてください、関連[STRINGPREP]プロフィールのアプリケーションを含んで、[UTF-8]としてストリングをコード化して。
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. アプリケーション(この例では、目立たない)に適切であるなら、「#」キャラクタは「部分識別子コンポーネント」で続きました。
Saint-Andre Standards Track [Page 11] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[11ページ]。
The result is this XMPP IRI:
結果はこの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"体系、」、:、」 キャラクタ。
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]. 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]のアプリケーションを含んでいて。 (2) 次に、(1) 一層の完全なXMPPがそれ自体を扱って、処理アプリケーションがそうするだろうか、または支援アプリケーションを呼び出して、XMPP取り扱いを終了してください。 そのようなXMPP取り扱いはたぶん以下のステップから成るでしょう:
Saint-Andre Standards Track [Page 12] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[12ページ]。
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 [JEP-0030]).
2. 任意に、意図している受取人(例えば、[JEP-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スタンザを意図している受取人に送ってください。
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:
XMPP IRIで以下の不快なノードを考えてください:
xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com
'xmpp: 嫌なもの!%23$%()*+、-、^_'| =%3F[\] ~node@example.com
That IRI would be transformed into the following XMPP address:
そのIRIは以下のXMPPアドレスに変えられるでしょう:
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
'嫌なもの!#$%()*+、-、^_'| =? [\] ~node@example.com
Saint-Andre Standards Track [Page 13] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[13ページ]。
Consider the following repulsive resource in an XMPP IRI (split into two lines for layout purposes):
XMPP IRI(レイアウト目的のために2つの系列に分けられる)で以下のよそよそしいリソースを考えてください:
xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
xmpp: node@example.com /よそよそしい%、20!%の23インチの$%25と'()*+、-. %2F:、;、<が>%3F%40[\]^_と等しい '| ~リソース
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:
前の例から生じたXMPP URIを考えてください:
<xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
<xmpp: ji%C5%99i@%C4%8Dechy.example/v%20Praze 、gt。
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"体系を取り除くだろう、」、:、」 「"inodeid"からどんなパーセントでコード化された八重奏も変換して、XMPPがこのXMPP IRIから扱う抽出、"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 and because octets outside the [US-ASCII] range 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
XMPPアドレスが[UTF-8]ストリングであり、容易にXMPP住所の中の[米国のASCII]の範囲の外での八重奏はパーセントでコード化された八重奏に変換できるので、XMPPアドレスはInternationalized Resource Identifiers([IRI])と共にうまくいくように設計されています。 そして、「それらのキャラクタ同等物(」 例えば、[米国のASCII]の間隔文字への%20インチ)へのstringprep検証の例外、構文関連している[米国-ASCII]キャラクタ(例えば、“?")の変換、および"inodeid"、"ihost"、および"iresid"規則からのパーセントでコード化された八重奏の変換で、特に、直接"xmpp"体系をprependingすることによってXMPPイリを組み立てることができる、」、:、」 XMPPアドレスへのキャラクタ。 その上、付着することによって、URI構文にXMPP IRIを変換できます。
Saint-Andre Standards Track [Page 14] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[14ページ]。
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.
[IRI]のセクション3.1、およびXMPP URIで指定された手順には、[IRI]のセクション3.2で指定された手順を固く守るのによるIRI構文に変換されて、その結果、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
永久的
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] and DQUOTE is defined in [ABNF]:
[ABNF]による指定されるとしてのAugmented BN記法を使用する下でxmpp URIのための構文は定義されます、「断片」、「ホスト」、「pctによってコード化され」て、「無遠慮な」規則が[URI]で定義されて、DQUOTEが[ABNF]で定義されるところで:
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 = "!" / DQUOTE / "$" / "&" / "'" / "(" / ")" /
"*" / "+" / "," / ":" / ";" / "<" / "=" / ">" /
"[" / "\" / "]" / "^" / "`" / "{" / "|" / "}"
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によってコード化されたか「再-血色の悪」い)「再-サルヤナギ」が“!"と等しい、」、' 「/ DQUOTE /「$」/“&"/、「'」 「/「(「/」)」/「*」/「+」/」、/」:、」、' / ";" 「[「/「\」/」]」という/"<"/「=」/">"//"^"/、「'、「/、「「/、「| 」 /」、*(無遠慮であるかpctによってコード化される)のquerytype[*対にする]」 querycomp=querytype=組=、」、'、」、。 主要な「=」値主要な=*(無遠慮であるかpctによってコード化された)価値は*と等しいです。(無遠慮であるかpctによってコード化された)
Saint-Andre Standards Track [Page 15] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[15ページ]。
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 RFC 4622, 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は断片化する)を送ると、RFC4622のセクション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 [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), and the UTF-8 string must then be prepended with the "xmpp" scheme and ":" character. However, because an XMPP URI must contain only [US-ASCII] characters, the UTF-8 string of an XMPP IRI must be transformed into URI syntax by adhering to the procedure specified in RFC 3987.
また、XMPP URIに加えて、XMPP Internationalized Resource Identifiers(IRIs)があるでしょう。 そして、「IRI(そして[XMPP-CORE]に従って)にExtensible MessagingとPresenceプロトコル(XMPP)アドレスを変換する前に次に、"xmpp"体系で生成するアプリケーション(例えば、UTF-16ストリングとしてアプリケーションのアドレスの内部の表現をUTF-8ストリングに変えるのによる)、およびUTF-8ストリングによる[UTF-8]をprependedしなければならないときXMPPアドレスを表さなければならない、」、:、」 キャラクタ。 しかしながら、XMPP URIがキャラクタだけを含まなければならないので、RFC3987で指定された手順を固く守ることによって、XMPP IRIのUTF-8ストリングをURI構文に変えなければなりません。
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 Jabber Registrar function of the Jabber Software 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.jabber.org/registrar/querytypes.html>.
xmpp URI体系の使用に関連する相互運用性関心は知られていません。 相互運用性を確実にするのを助けるために、Jabber Software財団のJabber Registrar機能は質問タイプとXMPP URIの質問コンポーネントに使用できるキーと<http://www.jabber.org/記録係/querytypes.html>に位置するIRIsの登録を維持します。
3.8. Security Considerations
3.8. セキュリティ問題
See Section 5 of RFC 4622, Security Considerations.
RFC4622のセクション5、セキュリティ問題を見てください。
Saint-Andre Standards Track [Page 16] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[16ページ]。
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 registers a URI scheme. The registration template can be found in Section 3 of this document. In order to help ensure interoperability, the Jabber Registrar function of the Jabber Software 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.jabber.org/registrar/querytypes.html>.
このドキュメントはURI体系を登録します。 このドキュメントのセクション3で登録テンプレートを見つけることができます。 相互運用性を確実にするのを助けるために、Jabber Software財団のJabber Registrar機能は質問タイプとXMPP URIの質問コンポーネントに使用できるキーと<http://www.jabber.org/記録係/querytypes.html>に位置する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 be reliably and consistently 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
フォーム node@domain.tld/resource のXMPPアドレスは通常はかなくさえあります(与えられたXMPPリソース識別子がXMPPサーバでXMPPクライアントの特定の、そして、一時的なセッションに通常関連しているので)。 したがって、そのようなXMPPアドレスを特定するXMPP IRI/URIがたぶん確かに一貫してないでしょう。
Saint-Andre Standards Track [Page 17] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[17ページ]。
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.
同じセッションに関連しています。 しかしながら、[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 de-commission 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アドレスを特定するものの間のどこかまで下がるでしょう。
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, as specified in [XMPP-CORE]).
禁止はXMPP IRIs/URIにおけるポートナンバーでそれほどXMPP IRIs/URIの悪意がある工事をありそうにしません([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
ウェブブラウザか他の非固有のアプリケーションでXMPP実体と対話する能力で、機密情報(特定のXMPPアプリケーション・プロトコル拡張子のサポートなどの)を暴露して、その結果、可能でないか、または固有のXMPPネットワークでありそうもない攻撃に着手するのは可能になるかもしれません。 相当な注意を取らなければなりません。
Saint-Andre Standards Track [Page 18] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[18ページ]。
in deciding what information is appropriate for representation in XMPP IRIs or URIs.
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 [SASL] makes it possible to use the SASL ANONYMOUS mechanism, if desired.
機密情報、パスワード、および他のユーザに漏れるのを防ぐのを助けるために、資格証明書はXMPP IRIs/URIの権威コンポーネントで禁じられます。 事実上、それらは必要ではありません、XMPPでの認証が[SASL]を通して起こるという事実でSASL ANONYMOUSメカニズムを使用するのが可能になるので、望まれているなら。
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を参照してください。
Saint-Andre Standards Track [Page 19] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[19ページ]。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[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月。
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-コア] サンアンドレ、P.、「広げることができるメッセージングと存在は以下について議定書の中で述べ(XMPP)」。 「コア」、RFC3920、2004年10月。
6.2. Informative References
6.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月。
[JEP-0009] Adams, D., "Jabber-RPC", JSF JEP 0009, February 2006.
[JEP-0009]アダムス、2006年2月のD.、「おしゃべり-RPC」JSF JEP0009。
Saint-Andre Standards Track [Page 20] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[20ページ]。
[JEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P.
Saint-Andre, "Service Discovery", JSF JEP 0030,
January 2006.
[JEP-0030] ヒルデブラントとJ.とミラードとP.とEatmon、R.とP.サンアンドレ、「サービス発見」、JSF JEP0030、2006年1月。
[JEP-0045] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045,
September 2005.
[JEP-0045] サンアンドレ、P.、「マルチユーザチャット」、JSF JEP0045、2005年9月。
[JEP-0053] Saint-Andre, P., "Jabber Registrar", JSF JEP 0053,
May 2004.
[JEP-0053]サンアンドレ(P.、「おしゃべり記録係」、JSF JEP0053)は2004がそうするかもしれません。
[JEP-0060] Millard, P., Saint-Andre, P., and R. Meijer,
"Publish-Subscribe", JSF JEP 0060, June 2005.
[JEP-0060]ミラード、P.、サンアンドレ、P.、そして、R.Meijer、「発行、-申し込んでください、」、JSF JEP0060、6月2005日
[JEP-0072] Forno, F. and P. Saint-Andre, "SOAP Over XMPP", JSF
JEP 0072, December 2005.
[JEP-0072] FornoとF.とP.サンアンドレ、「XMPPの上のSOAP」、JSF JEP0072、2005年12月。
[JEP-0077] Saint-Andre, P., "In-Band Registration", JSF JEP 0077,
January 2006.
[JEP-0077] サンアンドレ、P.、「バンドにおける登録」、JSF JEP0077、2006年1月。
[JEP-0147] Saint-Andre, P., "XMPP IRI/URI Query Components", JSF
JEP 0147, March 2006.
[JEP-0147] サンアンドレ、P.、「XMPP IRI/URI質問コンポーネント」、JSF JEP0147、2006年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月。
[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/ )。
Saint-Andre Standards Track [Page 21] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[21ページ]。
[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日
[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日
Author's Address
作者のアドレス
Peter Saint-Andre Jabber Software Foundation
ピーターサンアンドレおしゃべりソフトウェア財団
EMail: stpeter@jabber.org URI: xmpp:stpeter@jabber.org
メール: stpeter@jabber.org ユリ: xmpp: stpeter@jabber.org
Saint-Andre Standards Track [Page 22] RFC 4622 XMPP IRIs/URIs July 2006
サンアンドレ規格はXMPP虹彩/URI2006年7月にRFC4622を追跡します[22ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Saint-Andre Standards Track [Page 23]
サンアンドレ標準化過程[23ページ]
一覧
スポンサーリンク
