Network Working Group P. Saint-Andre
Request for Comments: 4622 JSF
Category: Standards Track July 2006
Network Working Group P. Saint-Andre
Request for Comments: 4622 JSF
Category: Standards Track July 2006
Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)
可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（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).
本文档定义了国际化资源标识符（IRI）和统一资源标识符（URI）在识别可通过可扩展消息和状态协议（XMPP）进行通信的实体或与之交互时的使用。
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. 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
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 and Presence Protocol，XMPP）是一种流式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]中所述，XMPP网络通信中使用的实体地址不得以统一资源标识符（URI）方案（如[URI]中所述）作为前缀。但是，XMPP网络外部的应用程序可能需要将XMPP实体标识为URI，或者以更现代的方式标识为国际化资源标识符（IRI；请参见[IRI]）。此类外部应用程序的示例包括需要存储XMPP地址的数据库和非本机用户代理，如web浏览器和日历应用程序，它们为XMPP服务提供接口。
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]中定义。这样的地址几乎可以包含任何[UNICODE]字符，并且必须符合[STRINGPREP]的各种配置文件。结果是XMPP地址是完全国际化的，并且非常接近于没有方案的IRI。然而，鉴于没有独立的IRI方案注册中心，有必要将XMPP标识符主要定义为URI而不是IRI，并注册XMPP URI方案而不是IRI方案。因此，本文件具有以下功能：
o Specifies how to identify XMPP entities as IRIs or URIs.
o 指定如何将XMPP实体标识为IRI或URI。
o Specifies how to interact with XMPP entities as IRIs or URIs.
o 指定如何与作为IRI或URI的XMPP实体交互。
o Formally defines the syntax for XMPP IRIs and URIs.
o 正式定义xmppiris和uri的语法。
o Specifies how to transform XMPP IRIs into URIs and vice-versa.
o 指定如何将XMPP IRI转换为URI，反之亦然。
o Registers the xmpp URI scheme.
o 注册xmppuri方案。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[术语]中的说明进行解释。
As described in [XMPP-IM], instant messaging and presence applications of XMPP must handle im: and pres: URIs (as specified by [CPIM] and [CPP]). However, there are many other applications of XMPP (including network management, workflow systems, generic publish-subscribe, remote procedure calls, content syndication, gaming, and middleware), and these applications do not implement instant messaging and presence semantics. 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-IM]中所述，XMPP的即时消息和状态应用程序必须处理IM:和pres:URI（由[CPIM]和[CPP]指定）。但是，XMPP还有许多其他应用程序（包括网络管理、工作流系统、通用发布-订阅、远程过程调用、内容联合、游戏和中间件），这些应用程序不实现即时消息和状态语义。通用XMPP实体也没有实现任何现有URI方案的语义，例如http:、ftp:、或mailto:方案。因此，定义一个新的URI方案是合适的，它可以将任何XMPP实体（不仅仅是即时消息和状态实体）识别为IRI或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 IRI和URI定义为供非本机接口和应用程序使用，主要用于识别而不是交互（关于后一个区别，请参见[URI]第1.2.2节）。为了确保XMPP网络上的互操作性，当数据路由到XMPP实体（例如，当XML节的“to”或“from”属性中包含XMPP地址时）或在标准XMPP协议元素中以其他方式标识XMPP实体时，该实体必须被寻址为<[node@]domain[/resource]>（即，没有预设方案），其中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-CORE]第3.4节）；术语“资源标识符”的使用不应与“资源”和“/”的含义混淆。）[URI]第1.1节中提供的“标识符”。
As described in [XMPP-CORE], an XMPP address used natively on an XMPP network is a string of Unicode characters that (1) conforms to a certain set of [STRINGPREP] 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地址是一个Unicode字符字符串，该字符串（1）符合某一组[STRINGPREP]配置文件和[IDNA]限制，（2）遵循某一组语法规则，（3）编码为[UTF-8]。这种地址的形式可以使用扩展的Backus-Naur形式（[ABNF]）表示为：
[ node "@" ] domain [ "/" resource ]
[节点“@”]域[“/”资源]
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应用程序中，以表示国际化域名。但是，处理应用程序负责将[IRI]语法转换为[IDNA]将XML节寻址到XMPP网络上的指定实体之前的语法。）
Naturally, in order to be converted into an IRI or URI, an XMPP address must be prepended with a scheme (specifically, the xmpp scheme) and may also need to undergo transformations that adhere to the rules defined in [IRI] and [URI]. Furthermore, in order to enable more advanced interaction with an XMPP entity rather than simple identification, it is desirable to take advantage of additional aspects of URI syntax and semantics, such as authority components, query components, and fragment identifier components.
当然，为了转换为IRI或URI，XMPP地址必须在方案（特别是XMPP方案）的前面，并且可能还需要进行符合[IRI]和[URI]中定义的规则的转换。此外，为了能够与XMPP实体进行更高级的交互，而不是简单的标识，需要利用URI语法和语义的其他方面，例如权限组件、查询组件和片段标识符组件。
Therefore, the ABNF syntax for an XMPP IRI is defined as shown below using Augmented Backus-Naur Form specified by [ABNF], where the "ifragment", "ihost", and "iunreserved" rules are defined in [IRI], the "pct-encoded" rule is defined in [URI], and DQUOTE is defined in [ABNF]:
因此，XMPP IRI的ABNF语法如下所示，使用[ABNF]指定的增广的Backus-Naur形式定义，其中[IRI]中定义了“ifragment”、“ihost”和“iunreserved”规则，“pct编码”规则在[URI]中定义，DQUOTE在[ABNF]中定义：
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" ":" 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 )
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只识别URI方案而不识别IRI方案。因此，XMPP URI而非IRI的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的各种组件的描述。
As explained in Section 2.8 of this document, in the absence of an authority component, the processing application would authenticate as a configured user at a configured XMPP server. That is, the authority component section is unnecessary and should be ignored if the processing application has been configured with a set of default credentials.
如本文档第2.8节所述，在没有授权组件的情况下，处理应用程序将作为配置的XMPP服务器上的配置用户进行身份验证。也就是说，如果处理应用程序配置了一组默认凭据，那么authority组件部分是不必要的，应该忽略它。
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":
第二个字符（“；/”）或第二个字符（“；/”）以斜杠结尾（“；/”），或第二个字符（“；/”）以斜杠结尾。如本文件第2.8.1节所述，授权组件的存在向处理应用程序发出信号，要求其作为node@domain在授权组件中指定，而不是作为配置的node@domain（请参阅本文档中有关身份验证的安全注意事项部分）。（虽然授权组件不太可能包含在大多数XMPP IRI或URI中，但如果合适的话，该方案允许将其包含在内。）因此，以下XMPP IRI/URI指示身份验证为“guest@example.com":
xmpp://guest@example.com
xmpp://guest@example.com
Note well that this is quite different from the following XMPP IRI/URI, which identifies a node "guest@example.com" but does not signal the processing application to authenticate as that node:
请注意，这与下面的XMPP IRI/URI非常不同，后者标识一个节点“guest@example.com“但不向处理应用程序发出信号，要求其作为该节点进行身份验证：
xmpp:guest@example.com
xmpp：guest@example.com
Similarly, using a possible query component of "?message" to trigger an interface for sending a message, the following XMPP IRI/URI signals the processing application to authenticate as "guest@example.com" and to send a message to "support@example.com":
类似地，使用一个可能的查询组件“？message”来触发一个发送消息的接口，下面的XMPP IRI/URI向处理应用程序发出信号，以验证为”guest@example.com“并向发送消息”support@example.com":
xmpp://guest@example.com/support@example.com?message
xmpp://guest@example.com/support@example.com?message
By contrast, the following XMPP IRI/URI signals the processing application to authenticate as its configured default account and to send a message to "support@example.com":
相比之下，以下XMPP IRI/URI向处理应用程序发出信号，以作为其配置的默认帐户进行身份验证，并将消息发送到“support@example.com":
xmpp:support@example.com?message
xmpp：support@example.com消息
The path component of an XMPP IRI/URI identifies an XMPP address or specifies the XMPP address to which an XML stanza shall be directed at the end of IRI/URI processing.
XMPP IRI/URI的路径组件标识XMPP地址或指定在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：示例-node@example.com
The following XMPP IRI/URI identifies a node associated with an XMPP server along with a particular XMPP resource identifier associated with that node:
以下XMPP IRI/URI标识与XMPP服务器关联的节点以及与该节点关联的特定XMPP资源标识符：
xmpp:example-node@example.com/some-resource
xmpp:example-node@example.com/some-resource
Inclusion of a node is optional in XMPP addresses, so the following XMPP IRI/URI simply identifies an XMPP server:
在XMPP地址中包含节点是可选的，因此以下XMPP IRI/URI仅用于标识XMPP服务器：
xmpp:example.com
xmpp:example.com
There are many potential use cases for encapsulating information in the query component of an XMPP IRI/URI; 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]），
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开发的持续扩展，这些应用程序的完整范围无法提前预见；然而，Jabber/XMPP开发者社区内部达成一致意见，迄今为止设想的所有用途都可以通过“查询类型”进行封装，可选地由一个或多个“键值”对进行补充（这类似于[HTML]中描述的“application/x-www-form-urlencoded”MIME类型）。
As an example, an XMPP IRI/URI intended to launch an interface for sending a message to the XMPP entity "example-node@example.com" might be represented as follows:
例如，XMPP IRI/URI旨在启动一个接口，用于向XMPP实体发送消息-node@example.com“可代表如下：
xmpp:example-node@example.com?message
xmpp：示例-node@example.com消息
Similarly, an XMPP IRI/URI intended to launch an interface for sending a message to the XMPP entity "example-node@example.com" with a particular subject might be represented as follows:
类似地，XMPP IRI/URI旨在启动一个接口，用于向XMPP实体发送消息-node@example.com“关于某一特定主题，可表述如下：
xmpp:example-node@example.com?message;subject=Hello%20World
xmpp:example-node@example.com?message;subject=Hello%20World
If the processing application does not understand query components or the specified query type, it MUST ignore the query component and treat the IRI/URI as consisting of, for example, <xmpp:example-node@example.com> rather than <xmpp:example-node@example.com?query>. If the processing application does not understand a particular key within the query component, it MUST ignore that key and its associated value.
如果处理应用程序不理解查询组件或指定的查询类型，则必须忽略该查询组件，并将IRI/URI视为包含，例如，<xmpp:example-node@example.com>而不是<xmpp:示例-node@example.com？查询>。如果处理应用程序不理解查询组件中的特定键，则必须忽略该键及其关联值。
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软件基金会的JabbRealver函数（参见[JPE-053]）维护了这样的查询类型和密钥的注册表。http://www.jabber.org/registrar/querytypes.html>. 帮助确保
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].
互操作性，使用本文件中定义的格式的任何应用程序应按照[JEP-0147]中规定的程序向该注册表提交任何关联查询类型和键。
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中包含的特定片段标识符组件的语法，则必须忽略片段标识符组件。
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”规则的Unicode字符字符串，后跟“@”字符。
4. A string of Unicode characters that conforms to the "ihost" rule.
4. 符合“ihost”规则的Unicode字符字符串。
5. Optionally (if the XMPP address contained an XMPP "resource identifier"), the character "/" and a string of Unicode characters that conforms to the "iresid" rule.
5. 可选（如果XMPP地址包含XMPP“资源标识符”），字符“/”和符合“iresid”规则的Unicode字符字符串。
6. Optionally (if a query component is to be included), the "?" character and query component.
6. 可选地（如果要包括查询组件），“？”字符和查询组件。
7. Optionally (if a fragment identifier component is to be included), the "#" character and fragment identifier component.
7. （如果要包括片段标识符组件），“#”字符和片段标识符组件。
In order to form an XMPP URI from the resulting IRI, an application MUST adhere to the mapping procedure specified in Section 3.1 of [IRI].
为了从生成的IRI中形成XMPP URI，应用程序必须遵循[IRI]第3.1节中指定的映射过程。
Certain characters are allowed in the node identifier, domain identifier, and resource identifier portions of a native XMPP address but prohibited by the "inodeid", "ihost", and "iresid" rules of an XMPP IRI. Specifically, the "#" and "?" characters are allowed in node identifiers, and the "/", "?", "#", and "@" characters are allowed in resource identifiers, but these characters are used as delimiters in XMPP IRIs. In addition, the " " ([US-ASCII] space) character is allowed in resource identifiers but prohibited in IRIs. Therefore, all the foregoing characters MUST be percent-encoded when transforming an XMPP address into an XMPP IRI.
本机XMPP地址的节点标识符、域标识符和资源标识符部分允许使用某些字符，但XMPP IRI的“inodeid”、“ihost”和“iresid”规则禁止使用这些字符。具体来说，节点标识符中允许使用“#”和“？”字符，资源标识符中允许使用“/”、“？”、“#”和“@”字符，但这些字符在XMPP IRIs中用作分隔符。此外，资源标识符中允许使用“（[US-ASCII]空格）字符，但在IRIs中禁止使用。因此，在将XMPP地址转换为XMPP IRI时，必须对上述所有字符进行百分比编码。
Consider the following nasty node in an XMPP address:
在XMPP地址中考虑下面的讨厌节点：
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
That address would be transformed into the following XMPP IRI:
该地址将转换为以下XMPP IRI：
xmpp:nasty!%23$%25()*+,-.;=%3F[\]^_`{|}~node@example.com
xmpp:nasty!%23$%25()*+,-.;=%3F[\]^_`{|}~node@example.com
Consider the following repulsive resource in an XMPP address (split into two lines for layout purposes):
考虑XMPP地址中的下列排斥资源（为了布局目的分成两行）：
node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
That address would be transformed into the following XMPP IRI (split into two lines for layout purposes):
该地址将转换为以下XMPP IRI（为便于布局，分为两行）：
xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
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
此外，XMPP地址中允许[US-ASCII]范围之外的任何字符，因此XMPP IRI中也允许使用[US-ASCII]范围之外的任何字符，但URI语法禁止直接使用此类字符，并规定此类字符必须进行百分比编码。以确定关联的URI
with an XMPP IRI, an application MUST adhere to the mapping procedure specified in Section 3.1 of [IRI].
对于XMPP IRI，应用程序必须遵守[IRI]第3.1节中规定的映射过程。
Consider the following XMPP address:
考虑下面的XMPP地址：
<jiři@čechy.example/v Praze>
<jiři@č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".
注：字符串“ř；”表示带CARON的Unicode字符拉丁小写字母R，字符串“č；”表示带CARON的Unicode字符拉丁小写字母C，在[IRI]中使用的“XML表示法”之后表示不能在仅ASCII文档中呈现的字符（还请注意，这些字符以stringprep标准格式表示。）“<”和“>”字符不是地址本身的一部分，而是用来抵消地址的易读性。对于不懂捷克语的人，此示例可以英语化为“george@czech-lands.example/In Prague”。
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. 表示XMPP地址的Unicode字符字符串，根据“inodeid”、“ihost”和“iresid”规则进行转换。
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 this XMPP IRI:
结果是这个XMPP IRI：
<xmpp:jiři@čechy.example/v%20Praze>
<xmpp:jiři@č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>
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 URI而不是XMPP IRI，则它必须首先按照[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. 权限组件（如果包括）（介于“/”字符和下一个“/”字符、“？”字符、“#”字符或IRI结尾之间的Unicode字符字符串）。
3. A string of Unicode characters that represents an XMPP address as transformed in accordance with the "inodeid", "ihost", and "iresid" rules.
3. 一个Unicode字符字符串，表示按照“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]的应用程序。然后，处理应用程序将（1）自行完成进一步的XMPP处理，或（2）调用帮助程序来完成XMPP处理；此类XMPP处理很可能包括以下步骤：
1. If not already connected to an XMPP server, connect either as the user specified in the authority component or as the configured user at the configured XMPP server, normally by adhering to the XMPP connection procedures defined in [XMPP-CORE]. (Note: The processing application SHOULD ignore the authority component if it has been configured with a set of default credentials.)
1. 如果尚未连接到XMPP服务器，则通常通过遵循[XMPP-CORE]中定义的XMPP连接过程，以授权组件中指定的用户或配置的XMPP服务器上的配置用户的身份进行连接。（注意：如果已使用一组默认凭据配置了权限组件，则处理应用程序应忽略该组件。）
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节发送给预期的收件人。
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处理”的前两个步骤类似于HTTP身份验证（[HTTP-AUTH]），而接下来的三个步骤类似于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.7.2节所述，本机XMPP地址的节点标识符、域标识符和资源标识符部分允许使用某些字符，但XMPP IRI的“inodeid”、“ihost”和“iresid”规则禁止使用这些字符。在处理XMPP IRI以与表示的XMPP实体交互时，必须将与XMPP IRI中的这些字符相对应的编码八位字节百分比转换为XMPP地址中允许的字符。
Consider the following nasty node in an XMPP IRI:
在XMPP IRI中考虑下面的讨厌节点：
xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com
xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com
That IRI would be transformed into the following XMPP address:
该IRI将转换为以下XMPP地址：
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
Consider the following repulsive resource in an XMPP IRI (split into two lines for layout purposes):
考虑XMPP IRI中的下列排斥性资源（为了布局目的分成两行）：
xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
That IRI would be transformed into the following XMPP address (split into two lines for layout purposes):
该IRI将转换为以下XMPP地址（分成两行用于布局）：
node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
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>
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ři@č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ři@čechy.example/v Praze>
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地址中[US-ASCII]范围之外的八位字节可以轻松转换为百分比编码的八位字节，因此XMPP地址设计为与国际化资源标识符（[IRI]）配合使用。特别是，除stringprep验证外，语法相关[US-ASCII]字符（例如“？”）的转换，以及百分比编码八位字节从“inodeid”、“ihost”和“iresid”规则转换为其等效字符（例如“%20”转换为[US-ASCII]空格字符），XMPP IRI可以通过将“XMPP”方案和“：”字符前置到XMPP地址直接构造。此外，XMPP IRI可以通过以下方式转换为URI语法：
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但无法处理IRI的应用程序的互操作性。
In accordance with [URI-SCHEMES], this section provides the information required to register the xmpp URI scheme.
根据[URI-SCHEMES]，本节提供注册xmpp URI方案所需的信息。
xmpp
xmpp
permanent
永久的
The syntax for an xmpp URI is defined below using Augmented Backus-Naur Form as specified by [ABNF], where the "fragment", "host", "pct-encoded", and "unreserved" rules are defined in [URI] and DQUOTE is defined in [ABNF]:
xmpp URI的语法在下面使用[ABNF]指定的增广Backus Naur形式定义，其中“片段”、“主机”、“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" ":" 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 )
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 and Presence Protocol，xmpp）进行本机通信的实体，主要用于标识，而不是用于资源位置。但是，如果处理xmpp URI的应用程序能够与URI标识的xmpp地址进行交互，则必须遵循RFC 4622第2节“xmpp IRIs和URI的使用”中定义的方法，以重构封装的xmpp地址，连接到适当的xmpp服务器，并发送适当的xmpp“节”（XML片段）到XMPP地址。（注意：没有与xmpp URI方案关联的MIME类型。）
In addition to XMPP URIs, there will also be XMPP Internationalized Resource Identifiers (IRIs). Prior to converting an Extensible Messaging and Presence Protocol (XMPP) address into an IRI (and in accordance with [XMPP-CORE]), the XMPP address must be represented as [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国际化资源标识符（IRI）。在将可扩展消息和状态协议（XMPP）地址转换为IRI（并根据[XMPP-CORE]）之前，生成应用程序必须将XMPP地址表示为[UTF-8]（例如，通过将应用程序的内部地址表示为UTF-16字符串转换为UTF-8字符串），然后，UTF-8字符串必须以“xmpp”方案和“：”字符作为前缀。但是，由于XMPP URI必须仅包含[US-ASCII]字符，因此必须遵循RFC 3987中指定的过程，将XMPP IRI的UTF-8字符串转换为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方案旨在由来自非本机用户代理（如web浏览器）的xmpp网络接口以及需要将xmpp实体标识为完整URI或IRI的非本机应用程序使用。
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软件基金会的JabbRealver函数维护了一个查询类型和密钥的注册表，这些键值可以在XMPP URI和IRIS的查询组件中使用，位于http://www.jabber.org/registrar/querytypes.html>.
See Section 5 of RFC 4622, Security Considerations.
见RFC 4622第5节，安全注意事项。
Peter Saint-Andre [mailto:stpeter@jabber.org,
xmpp:stpeter@jabber.org]
Peter Saint-Andre [mailto:stpeter@jabber.org,
xmpp:stpeter@jabber.org]
This scheme is registered under the IETF tree. As such, the IETF maintains change control.
该方案在IETF树下注册。因此，IETF保持变更控制。
[XMPP-CORE]
[XMPP-CORE]
This document 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软件基金会的JabbRealver函数维护了一个查询类型和密钥的注册表，这些键值可以在XMPP URI和IRIS的查询组件中使用，位于http://www.jabber.org/registrar/querytypes.html>.
Providing an interface to XMPP services from non-native applications introduces new security concerns. The security considerations discussed in [IRI], [URI], and [XMPP-CORE] apply to XMPP IRIs, and the security considerations discussed in [URI] and [XMPP-CORE] apply to XMPP URIs. In accordance with Section 2.7 of [URI-SCHEMES] and Section 7 of [URI], particular security considerations are specified in the following sections.
从非本机应用程序向XMPP服务提供接口引入了新的安全问题。[IRI]、[URI]和[XMPP-CORE]中讨论的安全注意事项适用于XMPP IRI，[URI]和[XMPP-CORE]中讨论的安全注意事项适用于XMPP URI。根据[URI-SCHEMES]的第2.7节和[URI-SCHEMES]的第7节，以下各节规定了特定的安全注意事项。
Given that XMPP addresses of the form node@domain.tld are typically created via registration at an XMPP server or provisioned by an administrator of such a server, it is possible that such addresses may also be unregistered or deprovisioned. Therefore, the XMPP IRI/URI that identifies such an XMPP address may not be reliably and consistently associated with the same principal, account owner, application, or device.
给定表单的XMPP地址node@domain.tld通常通过在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
表单的XMPP地址node@domain.tld/资源通常更短暂（因为给定的XMPP资源标识符通常与XMPP服务器上的XMPP客户机的特定临时会话相关联）；因此，标识这样一个XMPP地址的XMPP IRI/URI可能不会可靠且一致地被使用
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服务器或相关服务；虽然服务器或服务管理员自然可以随时解除服务器或服务的委托，但通常标识此类服务器或服务的IRI/URI是XMPP IRI/URI中最可靠和一致的。
XMPP addresses of the form domain.tld/resource are not yet common on XMPP networks; however, the reliability and consistency of XMPP IRIs/URIs that identify such XMPP addresses would likely fall somewhere between those that identify XMPP addresses of the form domain.tld and those that identify XMPP addresses of the form node@domain.tld.
表单domain.tld/resource的XMPP地址在XMPP网络上还不常见；但是，标识此类XMPP地址的XMPP IRI/URI的可靠性和一致性可能介于标识表单domain.tld的XMPP地址和标识表单的XMPP地址之间node@domain.tld.
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的可能性（因为按照[XMPP-CORE]中的规定，端口号是使用[DNS-SRV]记录发现的）。
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服务器不应以本机方式解析XMPP IRIs/URI，而应仅接受[XMPP-CORE]中指定的XML wire协议及其任何所需扩展。
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
通过web浏览器或其他非本机应用程序与XMPP实体交互的能力可能会暴露敏感信息（例如对特定XMPP应用程序协议扩展的支持），从而可能在本机XMPP网络上发起不可能或不太可能发起的攻击。必须谨慎行事
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匿名机制。
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指示以“身份验证”guest@example.com“，而xmpp：guest@example.com标识节点“guest@example.com". 处理应用程序必须明确区分这些表单，并且用户代理应该阻止人类用户在XMPP IRIs/URI中包含“/”字符，因为权限组件的使用被认为仅在特定场景中有用，而不是在更一般的情况下。
The ability to include effectively the full range of Unicode characters in an XMPP IRI may make it easier to execute certain forms of address mimicking (also called "spoofing"). However, XMPP IRIs are no different from other IRIs in this regard, and applications that will present XMPP IRIs to human users must adhere to best practices regarding address mimicking in order to help prevent attacks that result from spoofed addresses (e.g., the phenomenon known as "phishing"). For details, refer to the Security Considerations of [IRI].
在XMPP IRI中有效地包含全部Unicode字符的能力可能使执行某些形式的地址模拟（也称为“欺骗”）变得更容易。然而，XMPP IRIs在这方面与其他IRIs没有什么不同，向人类用户展示XMPP IRIs的应用程序必须遵循地址模拟方面的最佳实践，以帮助防止因伪造地址而导致的攻击（例如，被称为“钓鱼”的现象）。有关详细信息，请参阅[IRI]的安全注意事项。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[术语]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-CORE]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：CORE”，RFC 3920，2004年10月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC3860，2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[CPP]Peterson，J.，“存在的共同特征（CPP）”，RFC 38592004年8月。
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[DNS-SRV]Gulbrandsen，A.，Vixie，P.，和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[HTML] Raggett, D., "HTML 4.0 Specification", W3C REC REC-html40-19980424, April 1998.
[HTML]Raggett，D.，“HTML4.0规范”，W3C 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]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[JEP-0009] Adams, D., "Jabber-RPC", JSF JEP 0009, February 2006.
[JEP-0009]Adams，D.，“Jabber RPC”，JSF JEP 0009，2006年2月。
[JEP-0030] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", JSF JEP 0030, January 2006.
[JEP-0030]Hildebrand，J.，Millard，P.，Eatmon，R.，和P.Saint Andre，“服务发现”，JSF JEP 0030，2006年1月。
[JEP-0045] Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, September 2005.
[JEP-0045]圣安德烈，P.，“多用户聊天”，JSF JEP 00452005年9月。
[JEP-0053] Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, May 2004.
[JEP-0053]圣安德烈，P.，“Jabber登记员”，JSF JEP 0053，2004年5月。
[JEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", JSF JEP 0060, June 2005.
[JEP-0060]Millard，P.，Saint Andre，P.，和R.Meijer，“发布-订阅”，JSF JEP 0060，2005年6月。
[JEP-0072] Forno, F. and P. Saint-Andre, "SOAP Over XMPP", JSF JEP 0072, December 2005.
[JEP-0072]Forno，F.和P.Saint Andre，“XMPP上的肥皂”，JSF JEP 0072，2005年12月。
[JEP-0077] Saint-Andre, P., "In-Band Registration", JSF JEP 0077, January 2006.
[JEP-0077]圣安德烈，P.，“带内注册”，JSF JEP 0077，2006年1月。
[JEP-0147] Saint-Andre, P., "XMPP IRI/URI Query Components", JSF JEP 0147, March 2006.
[JEP-0147]Saint Andre，P.，“XMPP IRI/URI查询组件”，JSF JEP 0147，2006年3月。
[MAILTO] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[MAILTO]Hoffman，P.，Masinter，L.，和J.Zawinski，“MAILTO URL方案”，RFC 2368，1998年7月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("STRINGPREP")", RFC 3454, December 2002.
[STRINGPREP]Hoffman，P.和M.Blanchet，“国际化弦的准备（“STRINGPREP”）”，RFC 3454，2002年12月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000.
[UNICODE]UNICODE联盟，“UNICODE标准，3.2.0版”，2000年。
The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).
Unicode标准3.2.0版由Unicode标准3.0版（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由Unicode标准附录27:Unicode 3.1修订(http://www.unicode.org/reports/tr27/)根据Unicode标准附录#28:Unicode 3.2(http://www.unicode.org/reports/tr28/).
[URI-SCHEMES] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006.
[URI-SCHEMES]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，RFC 4395，2006年2月。
[US-ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[US-ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3.41986。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[XMPP-IM]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 39212004年10月。
Author's Address
作者地址
Peter Saint-Andre Jabber Software Foundation
Peter Saint Andre Jabbe软件基金会
EMail: stpeter@jabber.org
URI: xmpp:stpeter@jabber.org
EMail: stpeter@jabber.org
URI: xmpp:stpeter@jabber.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。