查看源代码

[[Category:XMPP正式RFC标准]]
[[Category:已翻译]]

'''本文的英文原文来自[http://www.ietf.org/rfc/rfc4622.txt RFC 4622]'''

{|
|网络工作组 || P. Saint-Andre
|-
|申请讨论: 4622  || Jabber软件基金会
|-
|类别: 标准跟踪  || 2006年7月
|}

::::'''用于 Extensible Messaging and Presence Protocol (XMPP) 的国际化资源标识符(IRIs)和统一资源标识符(URIs)'''

'''关于本文的说明'''

:本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD 1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。

'''版权声明'''

:本文版权属于互联网社区 (C) The Internet Society (2006).

'''摘要'''

:本文定义了在XMPP通信的时候,国际化资源标识符(IRIs)和统一资源标识符(URIs)在识别实体或与实体交互中的使用.

==简介==

:可扩展的消息和出席信息协议(XMPP)是一个流式的XML技术,允许任何两个网络上的实体准实时地交换XML元素(称为"XML节").

:如[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]所定义, 在XMPP网络通信中使用的实体地址不能(must not)由一个Uniform Resource Identifier (URI)(定义在[URI])规划预设. 无论如何,一个XMPP网络之外的应用需要通过 URIs 或更时髦的方式,比如国际化资源标识符(IRIs; 见[IRI])来标识XMPP实体. 这些外部应用的例子包括,需要存储XMPP地址的数据库,非本地用户代理例如web浏览器,和提供接口给XMPP服务的日历应用程序.

:XMPP地址的格式定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 这样的一个地址可以包含几乎任何 \[UNICODE\] 字符并且必须(must)遵从很多\[STRINGPREP\]的profiles. 这使得XMPP地址完全国际化并且非常接近于一个没有scheme的IRI. 无论如何, 由于在IRS schemes中没有独立的注册项, 所以需要定义的XMPP标识符主要是作为URIs而不是IRIs, 并且注册一个XMPP URI scheme而不是一个IRI scheme. 所以, 本文做以下事情:

*  说明如何标识 XMPP 实体作为 IRIs 或 URIs.

*  说明如何与作为 IRIs 或 URIs 的 XMPP 实体交互.

*  正式定义 XMPP IRIs and URIs 的语法.

*  说明如何转换 XMPP IRIs 成为 URIs ,反之亦然.

*  注册 xmpp URI scheme.

===术语===

:本文继承来自\[IRI\], \[URI\], 和 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]的术语.

:关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 在本文中的解释描述于 RFC 2119 \[TERMS\].

==XMPP IRIs 和 URIs的使用==

===基本原理===

:如[[RFC3921|XMPP-IM]]所述, XMPP的即时消息和出席信息应用必须处理 im: 和 pres: URIs (由[CPIM] 和[CPP]定义). 无论如何, 有许多XMPP的其他应用(包括网络管理, 工作流系统, 通用 发行-订阅, 远程过程调用, 内容联合,游戏, 和中间件), 而这些应用没有实现即时消息和出席信息语义. 一个通用的XMPP实体不会实现任何已有的 URI规划的语义, 如 http:, ftp:, 或mailto: 规划. 所以, 需要定义一个新的 URI 规划, 以 IRI 或 URI 来标识或和任何XMPP实体交互 (不仅是即时消息和出席信息实体).

:XMPP IRIs 和 URIs 定义由非本地接口和应用所使用, 主要目的是为了标识而非交互后者的区别,见 [URI]第一章第二节第二小节).  为了确保在XMPP网络中的互操作性, 当数据被路由到一个 XMPP 实体(例如, 当一个 XMPP 地址包含于一个XML节的'to' 或 'from' 属性中)或一个 XMPP 实体以别的方式为标准XMPP协议元素所标识, 这个实体必须(MUST)被赋予的地址格式为<[node@]domain[/resource]>(换言之, 没有一个预先的规划),这里一个XMPP地址的 "node identifier"部分,"domain identifier"部分, 和 "resource identifier"部分都遵守[XMPP-CORE第三章|XMPP文档列表/XMPP正式RFC标准/RFC3920#地址空间]所定义的规范.

:(注意: 由于历史原因, XMPP中的术语"resource identifier"表示XMPP地址的可选部分,跟在域名后面并用"/"符号隔开(详细情况, 参照[XMPP-CORE第三章第四节|XMPP文档列表/XMPP正式RFC标准/RFC3920#地址空间]; 术语"resource identifier"的使用不要和\[URI\]的第一章第一节提供的"resource"和"identifier"弄混了).

===格式===

:如[[RFC3920|XMPP-CORE]]所述, 一个生来用于一个XMPP网络的XMPP地址是一个Unicode字符串, (1) 遵循一个特定系列的[STRINGPREP] profiles 和[IDNA] 约束, (2) 允许特定系列的语法规则, 并且 (3) 编码为[UTF-8]. 这样一个地址的格式可以被表示为扩张的巴斯科范式([ABNF])如下:

      [ node "@" ] domain [ "/" resource ]

:在这个上下文中, "node" 和 "resource" 规则依赖于于独特的profiles of [STRINGPREP],而"domain" 规则依赖于[IDNA]说描述的国家化域名概念. (注意: 不需要参考IRI语法本身的punycode, 因为为了展示国际化域名任何punycode表述仅发生在XMPP应用内部. 无论如何, 在为XML节指明XMPP网络实体地址之前, 转换[IRI]语法到[IDNA]语法的工作是应用程序的责任.)

:很自然, 为了被转化成 IRI 或 URI, 一个XMPP地址必须以一个规划进行预处理(特别的, xmpp规划)并且也可能需要要先进行转化以满足[IRI]和[URI]定义的规则. 更远一点, 为了和一个XMPP实体能有更多高级的交互能力而不只是简单地标识, 可能需要获得附加的URI语法和语义, 例如授权组件,查询组件, 以及碎片标识组件.

:所以, 以下使用显示了用[ABNF]定义的巴斯科范式格式来用作XMPP IRI 的ABNF语法, 这里"ifragment", "ihost", 和 "iunreserved" 规则定义于[IRI], "pct-encoded"规则定义于[URI], 而 DQUOTE 定义于 [ABNF]:

<pre>
     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 )
</pre>

:无论如何, 前述的语法不适合包含在xmpp URI规划中的注册项中, 因为IANA只承认URI规划而不承认IRI规划. 所以,ABNF语法用于XMPP URI而不是IRI,定义见本文第三章第三节(见下文"IANA Registration"). 如果有必要把IRI语法转化成URI语法, 一个应用程序必须(MUST)遵守定义于\[IRI\]第三章第一节的映射过程.

:以下是一个基本的XMPP IRI/URI例子,用于标识一个和XMPP服务器有关的节点:

<pre>
      xmpp:node@example.com
</pre>

:以下章节提供各种组件对于XMPP IRI/URI的描述.

===授权组件===

:如本文第二章第八节所述, 在缺乏授权组件的时候, 处理程序将作为一个已配置的XMPP服务器的一个已配置的用户来进行验证. 也就是说, 授权组件章节不是必需的, 并且如果处理程序已经被缺省的证书配置好，授权组件将被忽略.

:和RFC 3986第三章第二节一致, 授权组件由一个双斜杠("//")开始,结束于下一个单斜杠("/"), 问号("?"), 或数字符号("#")字符, 或由IRI/URI的结尾结束. 更完整的解释见本文第二章第八节第一小节, 一个授权组件的出席信息通知处理程序在授权组件中验证它是node@domain,而不是作为一个已配置的node@domain. (见本文的 安全性事项章节Security Considerations中关于验证的部分). (虽然授权组件被包含在大部分的XMPP IRIs 或 URIs中是不现实的, 但是如果适当的话规划允许它被包含.) 所以, 以下 XMPP IRI/URI 表明验证为 "guest@example.com":

<pre>
      xmpp://guest@example.com
</pre>

:严重注意这和接下来的 XMPP IRI/URI是不相同的, 它标识一个节点"guest@example.com"而不是通知处理程序来验证它成为一个节点:

<pre>
      xmpp:guest@example.com
</pre>

:类似的, 使用可能的查询组件 "?message" 来触发一个接口用于发送一条消息, 以下XMPP IRI/URI通知处理程序来验证为"guest@example.com"并发送一条消息给"support@example.com":

<pre>
      xmpp://guest@example.com/support@example.com?message
</pre>

:对应的, 以下XMPP IRI/URI通知处理程序验证为它的已配置的缺省帐号并发送一条消息给"support@example.com":

<pre>
      xmpp:support@example.com?message
</pre>

===路径组件===

:一个XMPP IRI/URI的路径组件标识一个XMPP地址或指明IRI/URI处理最终要让一个XML节将去到的XMPP地址.

:例如, 以下XMPP IRI/URI标识一个和XMPP服务器有关的节点:

<pre>
      xmpp:example-node@example.com
</pre>


:以下XMPP IRI/URI标识一个和XMPP服务器有关的节点并带上特定的和那个节点相关的XMPP资源标识符:

<pre>
      xmpp:example-node@example.com/some-resource
</pre>

:在XMPP地址中包含一个节点是可选的, 所以以下XMPP IRI/URI简单的标识了一个XMPP服务器:

<pre>
      xmpp:example.com
</pre>

===查询组件==

:有许多可能的用例用于在一个XMPP IRI/URI的查询组件中封装信息; 包含但不仅限于以下例子:

*  发送一个XMPP消息节(见[[RFC3921|XMPP-IM]]),

*  添加一个名册条目(见[[RFC3921|XMPP-IM]]),

*  发送一个出席信息订阅项(见[[RFC3921|XMPP-IM]]),

*  调查当前出席信息(见[[RFC3921|XMPP-IM]]),

*  触发一个远程过程调用(见[XEP-0009]),

*  查询另一个实体的身份或能力(见[[XEP-0030]]),

*  加入一个基于XMPP的文本聊天室(见[[XEP-0045]]),

*  和一个发行-订阅频道交互(见[[XEP-0060]]),

*  提供一个SOAP接口(见[XEP-0072]), 以及

*  注册另一个实体(见[[XEP-0077]]).

:许多这些潜在的用例是应用程序特定的并且这类应用的全貌在XMPP的持续扩张发展中无法预知; 无论如何, Jabber/XMPP开发社区一致同意所有想象中的未来应用可能通过"query type"被封装, 通过一个或多个 "键-值"(key-value)对进行可选的补充(这类似于\[HTML\]中描述的"application/x-www-form-urlencoded" MIME 类型).

:作为例子, 一个XMPP IRI/URI企图启动一个接口用于发送一条消息给XMPP实体"example-node@example.com", 可以用以下形式表达:

<pre>
      xmpp:example-node@example.com?message
</pre>

:类似的, 一个XMPP IRI/URI企图启动一个接口用于发送一个有特定标题的消息给XMPP实体"example-node@example.com", 可以以下形式表达:

<pre>
      xmpp:example-node@example.com?message;subject=Hello%20World
</pre>

:如果处理程序不理解查询组件或特定的查询类型, 它必须(MUST)忽略查询组件并把它当成它的IRI/URI部分, 例如,当成<xmpp:example-node@example.com>而不是   <xmpp:example-node@example.com?query>. 如果处理程序不理解查询组件的一个特定键, 它必须(MUST)忽略那个键以及与它相关的值.

:大家知道, 存在许多种类的XMPP应用(包括现有的和潜在的), 而这些应用可以定义查询类型和键用于XMPP URIs的查询组件部分. XSF(XMPP Software Foundation)的XMPP Registrar 功能(见\[XEP-0053\])维护了这些查询类型的一个注册表和键, 网址在<http://www.xmpp.org/registrar/querytypes.html>.  为了帮助确保互操作性,任何定义在本文中的应用正在使用的格式应该(SHOULD)按照\[XEP-0147\]所定义的流程来提交任何相关的查询类型和键到那个注册表.

===碎片标识组件===

:如[URI]第三章第五节指出, "URI的碎片标识组件允许通过参考主要资源和附加标识信息来做二级资源的间接标识". 因为这个被XMPP IRI/URI标识的资源不产生任何可用的媒体类型(见[MIME]),所以(在[URI]术语中)一个XMPP资源不存在任何表述, 在XMPP IRIs/URIs中碎片标识组件的语义是"可能未知的considered unknown 和, 有效地,非强制性的" (ibid.). 典型的XMPP应用可以(MAY)为它们自己的目的来使用碎片标识组件. 无论如何,如果一个处理程序不理解碎片标识组件或XMPP IRI/URI中特定的碎片标识组件的语法, 它必须(MUST)忽略这个碎片标识组件.

===XMPP IRIs/URIs的生成===

====生成方法====

:为了把一个XMPP节点标识符,域标识符,和资源标识符格式化成为一个XMPP IRI, 生成程序必须(MUST)首先确保XMPP地址符合[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的规则, 包括相应的\[STRINGPREP\]的应用; 然后它必须(MUST)连接以下的东西:

:# "xmpp"规划和":"符号
:# 可选的 (如果在节点标识符之前包含了一个授权组件), 符号"//", 一个格式为node@domain的授权组件, 以及符号"/".
:# 可选的(如果XMPP地址包含了一个 XMPP "节点标识符"), 一个Unicode字符集的字符串并遵守"inodeid"规则, 跟在"@"符号后面.
:# 一个Unicode字符集的字符串并遵守"ihost"规则.
:# 可选的(如果XMPP地址包含一个XMPP "资源标识符"), 符号"/"和一个Unicode字符集的字符串并遵守"iresid"规则.
:# 可选的(如果一个查询组件被包含), 符号"?"和查询组件.
:# 可选的(如果一个碎片标识组件被包含), "#"符号和碎片标识组件.

:为了把一个resulting IRI格式化成一个XMPP URI, 一个应用必须(MUST)遵守\[IRI\]第三章第一节定义的映射过程.

====生成备注====

:某些特定的符号被允许存在于一个原生的XMPP地址的节点标识符, 域标识符, 和资源标识符部分, 但是被XMPP IRI中的"inodeid", "ihost", 和 "iresid"规则禁止. 具体来说, "#"和"?"符号被允许出现在节点标识符, "/", "?", "#", 和"@"符号被允许在资源标识符, 但是这些符号被用作XMPP IRIs的分隔符. 另外, " "([US-ASCII]空格)符号被允许在资源标识符中但是在IRIs中是禁止的. 所以, 当把一个XMPP地址转化为一个XMPP IRI时, 所有前述的符号必须(MUST)被部分编码.

:考虑以下的在一个XMPP地址中的nasty节点:

<pre>
      nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
</pre>


:那个地址将被转化成以下的XMPP IRI:

<pre>
      xmpp:nasty!%23$%25()*+,-.;=%3F[\]^_`{|}~node@example.com
</pre>


:考虑以下的在一个XMPP地址中的repulsive资源(为了看起来方便分成两行):

<pre>
      node@example.com
      /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
</pre>

:那个地址将被转化成以下的XMPP IRI(为了看起来方便分成两行):

<pre>
      xmpp:node@example.com
      /repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
</pre>

:而且, 事实上被允许在一个XMPP地址中出现的任何[US-ASCII]范围之外的符号, 也在XMPP IRI中出现, 但是URI语法禁止这些符号直接显示并指出这样的符号必须(MUST)被部分编码. 为了确定和一个XMPP IRI相关的URI, 一个应用必须(MUST)遵守定义在\[IRI\]第三章第一节的映射过程.

====生成例子====

:考虑以下XMPP地址:

<pre>
         <ji&#x159;i@&#x10D;echy.example/v Praze>
</pre>

:注意: 字符串"&#x159;" 代表Unicode符号LATIN SMALL LETTER R WITH CARON, 并且字符串"&#x10D;" 代表Unicode符号LATIN SMALL LETTER C WITH CARON, 以下用于[IRI]"XML Notation"来表现无法在ASCII-only中表示的字符串(注意这些字符串也被展现在它们的字符准备规范表单中stringprep canonical form). '<'和'>'符号不是地址本身的一部分但为了易于理解而用来设定地址的结束. 对于那些不能读捷克语的人,这个例子可能被英语化为"george@czech-lands.example/In Prague".

:和以上指定的过程一致, 生成程序将按以下步骤从这个地址生成一个合法的XMPP IRI:

:# 确保XMPP地址符合[[RFC3920|XMPP-CORE]]定义的规则, 包括应用相应的[STRINGPREP] profiles和编码成[UTF-8]字符串.
:# 连接以下:
:## "xmpp"规划和":"符号.
:## 一个"授权组件",如果有的话(本例没有展现).
:## 一个Unicode字符串展示XMPP地址, 被以"inodeid","ihost",和"iresid"规则转换.
:## "?"符号被一个"查询组件"跟随, 如果有适当的应用(本例没有展现).
:## "#"符号被一个"碎片标识组件"跟随, 如果有适当的应用(本例没有展现).

:结果是这个XMPP IRI:

<pre>
       <xmpp:ji&#x159;i@&#x10D;echy.example/v%20Praze>
</pre>

:为了从前述的IRI生成一个合法的XMPP URI, 应用必须(MUST)遵守定义在\[IRI\]第三章第一节的过程, 结果是以下的URI:

<pre>
       <xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
</pre>

===XMPP IRIs/URIs的处理===

====处理方法====

:如果一个处理程序被显示为一个XMPP URI而不是一个XMPP IRI, 它必须(MUST)首先按以下定义在\[IRI\]第三章第二节的过程把这个URI转换成为IRI.

:为了分解一个XMPP IRI用于和它所标识的实体交互, 一个处理程序必须(MUST)分解为:

:# "xmpp"规划和":"符号.
:# 授权组件, 如果有的话(在"//"符号和下一个"/"符号 "?"符号,"#"符号,或IRI的结尾之间的Unicode字符串,).
:# 一个展示为XMPP地址的根据"inodeid", "ihost", "iresid"规则转换的Unicode字符串.
:# 可选的查询组件, 如果有的话, 使用"?"符号作为分隔符.
:# 可选的碎片标识组件, 如果有的话, 使用"#"符号作为分隔符.

:在这一点上, 处理程序必须(MUST)确保结果的XMPP地址遵守[[RFC3920|XMPP-CORE]]定义的规则, 包括应用相应的[STRINGPREP]. 然后处理程序将 (1) 自行完成更多的XMPP处理, 或(2) 调用一个帮助程序来完成XMPP处理; 这样的XMPP处理很可能包括如下的步骤:

:# 如果还未连接到一个XMPP服务器, 作为授权组件中指明的用户连接或作为已配置的XMPP服务器的已配置用户连接, 通常遵守[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的XMPP连接过程.(注意: 处理程序应该(SHOULD)忽略授权组件,如果它已经用缺省的证书设置所配置.)
:# 可选的, 决定预定接收者的种类(换言之,通过\[XEP-0030\]).
:# 可选的, 根据预定接收者的种类展示一个适当的界面以及/或查询组件的内容给用户.
:# 生成一个XMPP节把任何用户或应用的输入转换成它们相应的XMPP数据.
:# 通过验证过的服务器连接发送XMPP节用于递送给预定接收者.

====处理备注====

:实施者可能注意到, 在第二章第八节第一小节结尾中描述的"更多的XMPP处理", 前两步类似HTTP 验证([HTTP-AUTH]), 后三步类似处理 mailto: URIs ([MAILTO]).

:本文的第二章第七节第二小节说过, 特定的字符被允许出现在原生的XMPP地址的节点标识符, 域标识符, 和资源标识符部分, 但被XMPP IRI的"inodeid", "ihost", 和"iresid"规则禁止. 当处理一个XMPP IRI用来和XMPP实体交互的时候, 这些部分编码的符合XMPP IRIs的字节必须(MUST)被转化成在XMPP地址中允许的字符串.

:考虑以下一个XMPP IRI中的nasty节点:

<pre>
      xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com
</pre>

:那个IRI将被转化成以下的XMPP address:

<pre>
      nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
</pre>

:考虑以下一个XMPP IRI中的repulsive资源(为便于阅读分成两行):

<pre>
      xmpp:node@example.com
      /repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
</pre>


:那个IRI将被转化成以下的XMPP地址(为便于阅读分成两行):

<pre>
      node@example.com
      /repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
</pre>

====处理例子====

:考虑从前一个例子中得到的XMPP URI:

<pre>
       <xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
</pre>

:为了从那个URI生成一个合法的XMPP IRI, 应用程序必须(MUST)遵守\[IRI\]第三章第二节定义的过程, 结果得到以下IRI:

<pre>
       <xmpp:ji&#x159;i@&#x10D;echy.example/v%20Praze>
</pre>

:和以上指明的处理一致, 处理程序将移除"xmpp"规划和":"符号以从XMPP IRI中揭解开XMPP地址, 转换任何按照"inodeid", "ihost", 和"iresid"规则部分编码的字节成为相应的字符串(例如, "%20" 转化成空格符号).

:结果是这个XMPP地址:

<pre>
       <ji&#x159;i@&#x10D;echy.example/v Praze>
</pre>

===国际化===

:因为XMPP地址是[UTF-8]字符串并且因为在XMPP地址中[US-ASCII]范围之外的字节很容易被转化成部分编码的字节, XMPP地址被设计成能够很好地和Internationalized Resource Identifiers ([IRI])配合工作. 某些情况下, 除了stringprep检查, 语法相关的[US-ASCII]符号(例如, "?")转化, 以及根据"inodeid", "ihost", 和"iresid"规则把部分编码的字节转化为相应字符(例如, "%20"转成[US-ASCII]空格符), 一个XMPP IRI能通过加上"xmpp"规划和":"符号的前缀, 直接被构造成一个XMPP地址. 而且, 一个XMPP IRI遵照[IRI]第三章第一节定义的过程可以被转化成URI语法, 一个XMPP URI遵照[IRI]第三章第二节定义的过程可以被转化成IRI, 因而确保应用的互操作性的是能处理URIs但不能处理IRIs.

==xmpp URI规划的IANA注册项==

:和[URI-SCHEMES]一致, 本章提供注册xmpp URI规划需要的信息.

===URI规划名===

   xmpp

===状态===

   permanent

===URI规划语法===

:一个xmpp URI的语法使用\[ABNF\]定义的巴斯科范式定义在下文, 这里"fragment","host","pct-encoded",以及"unreserved"规则定义在\[URI\]而DQUOTE定义在\[ABNF\]:

<pre>
    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 )
</pre>

===URI规划语义===

:xmpp URI规划标识了使用XMPP进行本地通信的实体, 并且主要用于标识而非资源定位. 无论如何, 如果一个处理xmpp URI的应用能够用URI标识的XMPP地址进行交互, 它必须(MUST)遵从定义在[RFC4622第二章|XMPP文档列表/XMPP正式RFC标准/RFC4622#XMPP_IRIs_和_URIs的使用]的方法论, 来重构被封装的XMPP地址, 连接到适当的XMPP服务器, 并发送一个适当的XMPP"节"(XML碎片)给XMPP地址. (注意: 没有和xmpp URI规划关联的MIME类型.)

===编码事项===

:除了XMPP URIs, 还将有XMPP国际化资源标识符(IRIs).  在转换一个XMPP地址成为一个IRI之前(并且遵守[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]), XMPP地址必须由生成程序展现为\[UTF-8\](例如, 把应用内部的UTF-16字符串的地址转换为UTF-8字符串), 并且UTF-8字符串必须加上前缀"xmpp"规划和":"符号. 无论如何, 因为一个XMPP URI必须仅包含\[US-ASCII\]字符, 一个XMPP IRI的UTF-8字符串必须遵照RFC 3987定义的过程被转化成URI语法.

===使用本URI规划名的应用/协议===

:xmpp URI规划被设计用于从一个非原生的用户代理和一个XMPP网络之间的接口, 例如web浏览器, 以及其他需要标识XMPP实体成为全URIs或IRIs的非原生的应用.

===互操作性事项===

:已知还没有和使用xmpp URI规划有关的互操作性问题. 为了帮助确保互操作性, XSF的XMPP Registrar功能维护了一个query类型的注册表,用于那些可能的查询组件和XMPP URIs以及IRIs, 网址在<http://www.jabber.org/registrar/querytypes.html>.

===安全性事项===

:见[RFC4622第五章安全事项|XMPP文档列表/XMPP正式RFC标准/RFC4622#安全事项].

===联系人===

:Peter Saint-Andre {link:mailto:stpeter@jabber.org|mailto:stpeter@jabber.org},

:[xmpp:stpeter@jabber.org xmpp:stpeter@jabber.org]

===作者/变更管理者===

:这个规划被注册在IETF树下. 同样的, IETF维护变更控制.

===参考===

[[RFC3920|XMPP-CORE]]

==IANA事项==

:本文注册了一个URI规划. 注册项模版能在本文第三章找到. 为了帮助确保互操作性, XSF(XMPP Software Foundation)的XMPP注册功能维护了一个查询组件和健的注册项, 用于XMPP URIs和IRIs的查询组件, 网址在<http://www.jabber.org/registrar/querytypes.html>.

==安全事项==

:从非原生的应用提供一个接口到XMPP服务器产生了新的安全隐患. 在\[IRI\], \[URI\],和[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中讨论的安全事项适用于XMPP IRIs, 而在[URI],和[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中讨论的安全事项适用于XMPP URIs. 遵循\[URI-SCHEMES\]第二章第七节和\[URI\]第七章, 以下章节定义了具体的安全事项.

===可靠性和一致性===

:假设格式为node@domain.tld的XMPP地址是通过向XMPP服务器注册创建的或由服务器的管理员提供, 这样的地址也可以被取消注册或取消供应. 所以, 标识这样的一个XMPP地址的XMPP IRI/URI可能是不可靠的并且其负责人,帐号拥有者,应用,或递送者是不一致的.

:格式为node@domain.tld/resource的XMPP地址甚至可能更短暂(因为一个特定的XMPP资源标识符典型地关联于在一个XMPP服务器上的一个XMPP客户端的一个特定的,临时的会话); 所以标识这样一个XMPP地址的XMPP IRI/URI可能将是不可靠的以及和相关的同一会话不一致的. 无论如何, 定义于[XMPP-CORE第十章|XMPP文档列表/XMPP正式RFC标准/RFC3920#服务器处理XML节的规则]的过程有效地排除了任何潜在的由标识XMPP地址的XMPP IRI/URI缺少可靠性和一致性造成的混淆.

:典型的格式为domain.tld的XMPP地址是长寿命的XMPP服务器或相关的服务; 当然尽管任何时候服务器或服务的管理员都可能让服务器或服务退役, 一般来讲标识这样的服务或服务器的IRIs/URIs是最可靠的以及和XMPP IRIs/URIs最一致的.

:格式为domain.tld/resource的XMPP地址在XMPP网络还不常见; 无论如何, 标识这样的服务或服务器的IRIs/URIs的可靠性和一致性可能处于格式为domain.tld的XMPP地址和格式为node@domain.tld的XMPP 地址之间.

===恶意的语句===

:通过在XMPP IRIs/URIs中对端口号的禁止减少了XMPP IRIs/URIs的恶意的构造(因为端口号是用\[DNS-SRV\]查询的, 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中).

===后台转换===

:因为基本的XMPP协议被定义用来实现消息和出席信息的交换而不是接收文件或类似的系统功能, 据不可靠消息XMPP IRIs/URIs的使用将导致有害的废弃品. 无论如何, 如果一个XMPP协议扩展定义了方法用于信息接收, 它必须(MUST)定义通过访问那个信息进行适当的控制. 另外, XMPP服务器不应该(SHOULD NOT)在本地解析XMPP IRIs/URIs而应该(SHOULD)只接受定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中的XML电信协议和任何期望往那里的扩展.

===敏感信息===

:通过web浏览器或其他非原生应用来和XMPP实体交互可能会暴露敏感信息(例如特定XMPP应用协议扩展支持)并且因此使得在原生XMPP网络中不可能发生的攻击在这里成为可能. 在决定XMPP IRIs or URIs中应当展示什么信息的时候必须非常小心.

:具体来说, 在公众场合(例如,在网站)声明XMPP IRIs/URIs可能使恶意用户能够从XMPP IRIs/URIs的授权和路径组件收集XMPP地址并且从而发送未经请求的大量通信给那些地址所展示的用户或应用. 应该非常小心地平衡公开信息的好处和非自愿通信的潜在成本.

:为了帮助纺织敏感信息泄露, 密码和其他用户证书被禁止出现在XMPP IRIs/URIs的授权组件中; 实际上它们不需要, 因为在XMPP中的\[SASL\]验证使得可以用SASL ANONYMOUS机制, 如果想要的话.

===语义攻击===

:尽管存在无等级的URI规划如\[MAILTO\], 通过联合人类用户可能预期所有URIs在规划名和":"符号之后包含"//"符号. 无论如何, 在XMPP IRIs/URIs中, "//"符号处于授权组件之前而不是路径组件之前. 因此,

xmpp://guest@example.com 表示验证为"guest@example.com", 反之xmpp:guest@example.com 标识节点"guest@example.com". 处理程序必须(MUST)清晰地区分这两种格式, 而用户代理应该(SHOULD)不鼓励人类用户在XMPP IRIs/URIs中包含"//"符号, 因为使用授权组件被认为只在特定的情景中出现, 不是通常的情景.

===欺骗===

:在一个XMPP IRI中有效包含全范围的Unicode字符的能力可能使得进行特定格式的地址模拟(也成为"欺骗")更为容易. 无论如何, 关于这一点XMPP IRIs和其他IRIs没有不同, 为了帮助防止来自欺骗地址的攻击, 显示XMPP IRIs给人类用户的应用必须遵守关于地址模拟的最佳实践(例如, phenomenon被当成"phishing"). 具体的信息, 参考\[IRI\]的安全性事项.

==参考==

===标准参考===

:[ABNF]         Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

:[IRI]          Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.

:[TERMS]        Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

:[URI]          Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

:[[RFC3920|XMPP-CORE]]    Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.

===信息参考===

:[CPIM]         Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.

:[CPP]          Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.

:[DNS-SRV]      Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

:[HTML]         Raggett, D., "HTML 4.0 Specification", W3C REC REC-html40-19980424, April 1998.

:[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.

:[IDNA]         Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

:[XEP-0009]     Adams, D., "Jabber-RPC", JSF JEP 0009, February 2006.

:[[XEP-0030]]     Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-Andre, "Service Discovery", JSF JEP 0030, January 2006.

:[[XEP-0045]]     Saint-Andre, P., "Multi-User Chat", JSF JEP 0045, September 2005.

:[[XEP-0053]]     Saint-Andre, P., "Jabber Registrar", JSF JEP 0053, May 2004.

:[[XEP-0060]]     Millard, P., Saint-Andre, P., and R. Meijer, "Publish-Subscribe", JSF JEP 0060, June 2005.

:[XEP-0072]     Forno, F. and P. Saint-Andre, "SOAP Over XMPP", JSF JEP 0072, December 2005.

:[[XEP-0077]]     Saint-Andre, P., "In-Band Registration", JSF JEP 0077, January 2006.

:[XEP-0147]     Saint-Andre, P., "XMPP IRI/URI Query Components", JSF JEP 0147, March 2006.

:[MAILTO]       Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.

:[MIME]         Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

:[SASL]         Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

:[STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("STRINGPREP")", RFC 3454, December 2002.

:[UNICODE]      The Unicode Consortium, "The Unicode Standard, Version 3.2.0", 2000. The Unicode Standard, Version 3.2.0 is defined by The Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-61633-5), as amended by the Unicode Standard Annex #27: Unicode 3.1(http://www.unicode.org/reports/tr27/) and by the Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/reports/tr28/).

:[URI-SCHEMES]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", RFC 4395, February 2006.

:[US-ASCII]     American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.

:[UTF-8]        Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

:[[RFC3921|XMPP-IM]]      Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.

'''作者地址'''

:Peter Saint-Andre

:XMPP Software Foundation

:EMail: [mailto:stpeter@jabber.org stpeter@jabber.org]

:URI:   [xmpp:stpeter@jabber.org xmpp:stpeter@jabber.org]

'''完整版权声明'''

<pre>
   Copyright (C) The Internet Society (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.

   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.
</pre>

'''知识产权'''

<pre>
   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.

   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.

   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.
</pre>

'''感谢'''

<pre>
   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).
</pre>