注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

BCB-DG's Blog

...

 
 
 

日志

 
 

RFC4622(一)  

2011-03-07 10:44:32|  分类: Jabber |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
XMPP中文翻譯計劃
本文的英文原文来自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的使用

基本原理

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"弄混了).

格式

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]:
     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 )
无论如何, 前述的语法不适合包含在xmpp URI规划中的注册项中, 因为IANA只承认URI规划而不承认IRI规划. 所以,ABNF语法用于XMPP URI而不是IRI,定义见本文第三章第三节(见下文"IANA Registration"). 如果有必要把IRI语法转化成URI语法, 一个应用程序必须(MUST)遵守定义于\[IRI\]第三章第一节的映射过程.
以下是一个基本的XMPP IRI/URI例子,用于标识一个和XMPP服务器有关的节点:
      xmpp:node@example.com
以下章节提供各种组件对于XMPP IRI/URI的描述.

授权组件

如本文第二章第八节所述, 在缺乏授权组件的时候, 处理程序将作为一个已配置的XMPP服务器的一个已配置的用户来进行验证. 也就是说, 授权组件章节不是必需的, 并且如果处理程序已经被缺省的证书配置好,授权组件将被忽略.
RFC 3986第 三章第二节一致, 授权组件由一个双斜杠("//")开始,结束于下一个单斜杠("/"), 问号("?"), 或数字符号("#")字符, 或由IRI/URI的结尾结束. 更完整的解释见本文第二章第八节第一小节, 一个授权组件的出席信息通知处理程序在授权组件中验证它是node@domain,而不是作为一个已配置的node@domain. (见本文的 安全性事项章节Security Considerations中关于验证的部分). (虽然授权组件被包含在大部分的XMPP IRIs 或 URIs中是不现实的, 但是如果适当的话规划允许它被包含.) 所以, 以下 XMPP IRI/URI 表明验证为 "guest@example.com":
      xmpp://guest@example.com
严重注意这和接下来的 XMPP IRI/URI是不相同的, 它标识一个节点"guest@example.com"而不是通知处理程序来验证它成为一个节点:
      xmpp:guest@example.com
类似的, 使用可能的查询组件 "?message" 来触发一个接口用于发送一条消息, 以下XMPP IRI/URI通知处理程序来验证为"guest@example.com"并发送一条消息给"support@example.com":
      xmpp://guest@example.com/support@example.com?message
对应的, 以下XMPP IRI/URI通知处理程序验证为它的已配置的缺省帐号并发送一条消息给"support@example.com":
      xmpp:support@example.com?message

路径组件

一个XMPP IRI/URI的路径组件标识一个XMPP地址或指明IRI/URI处理最终要让一个XML节将去到的XMPP地址.
例如, 以下XMPP IRI/URI标识一个和XMPP服务器有关的节点:
      xmpp:example-node@example.com


以下XMPP IRI/URI标识一个和XMPP服务器有关的节点并带上特定的和那个节点相关的XMPP资源标识符:
      xmpp:example-node@example.com/some-resource
在XMPP地址中包含一个节点是可选的, 所以以下XMPP IRI/URI简单的标识了一个XMPP服务器:
      xmpp:example.com

=查询组件

有许多可能的用例用于在一个XMPP IRI/URI的查询组件中封装信息; 包含但不仅限于以下例子:
  • 发送一个XMPP消息节(见XMPP-IM),
  • 添加一个名册条目(见XMPP-IM),
  • 发送一个出席信息订阅项(见XMPP-IM),
  • 调查当前出席信息(见XMPP-IM),
  • 触发一个远程过程调用(见[XEP-0009]),
  • 查询另一个实体的身份或能力(见XEP-0030),
  • 加入一个基于XMPP的文本聊天室(见XEP-0045),
  • 和一个发行-订阅频道交互(见XEP-0060),
  • 提供一个SOAP接口(见[XEP-0072]), 以及
许多这些潜在的用例是应用程序特定的并且这类应用的全貌在XMPP的持续扩张发展中无法预知; 无论如何, Jabber/XMPP开发社区一致同意所有想象中的未来应用可能通过"query type"被封装, 通过一个或多个 "键-值"(key-value)对进行可选的补充(这类似于\[HTML\]中描述的"application/x-www-form- urlencoded" MIME 类型).
作为例子, 一个XMPP IRI/URI企图启动一个接口用于发送一条消息给XMPP实体"example-node@example.com", 可以用以下形式表达:
      xmpp:example-node@example.com?message
类似的, 一个XMPP IRI/URI企图启动一个接口用于发送一个有特定标题的消息给XMPP实体"example-node@example.com", 可以以下形式表达:
      xmpp:example-node@example.com?message;subject=Hello%20World
如果处理程序不理解查询组件或特定的查询类型, 它必须(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)连接以下的东西:
  1. "xmpp"规划和":"符号
  2. 可选的 (如果在节点标识符之前包含了一个授权组件), 符号"//", 一个格式为node@domain的授权组件, 以及符号"/".
  3. 可选的(如果XMPP地址包含了一个 XMPP "节点标识符"), 一个Unicode字符集的字符串并遵守"inodeid"规则, 跟在"@"符号后面.
  4. 一个Unicode字符集的字符串并遵守"ihost"规则.
  5. 可选的(如果XMPP地址包含一个XMPP "资源标识符"), 符号"/"和一个Unicode字符集的字符串并遵守"iresid"规则.
  6. 可选的(如果一个查询组件被包含), 符号"?"和查询组件.
  7. 可选的(如果一个碎片标识组件被包含), "#"符号和碎片标识组件.
为了把一个resulting IRI格式化成一个XMPP URI, 一个应用必须(MUST)遵守\[IRI\]第三章第一节定义的映射过程.

生成备注

某些特定的符号被允许存在于一个原生的XMPP地址的节点标识符, 域标识符, 和资源标识符部分, 但是被XMPP IRI中的"inodeid", "ihost", 和 "iresid"规则禁止. 具体来说, "#"和"?"符号被允许出现在节点标识符, "/", "?", "#", 和"@"符号被允许在资源标识符, 但是这些符号被用作XMPP IRIs的分隔符. 另外, " "([US-ASCII]空格)符号被允许在资源标识符中但是在IRIs中是禁止的. 所以, 当把一个XMPP地址转化为一个XMPP IRI时, 所有前述的符号必须(MUST)被部分编码.
考虑以下的在一个XMPP地址中的nasty节点:
      nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com


那个地址将被转化成以下的XMPP IRI:
      xmpp:nasty!%23$%25()*+,-.;=%3F[\]^_`{|}~node@example.com


考虑以下的在一个XMPP地址中的repulsive资源(为了看起来方便分成两行):
      node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource
那个地址将被转化成以下的XMPP IRI(为了看起来方便分成两行):
      xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource
而且, 事实上被允许在一个XMPP地址中出现的任何[US-ASCII]范围之外的符号, 也在XMPP IRI中出现, 但是URI语法禁止这些符号直接显示并指出这样的符号必须(MUST)被部分编码. 为了确定和一个XMPP IRI相关的URI, 一个应用必须(MUST)遵守定义在\[IRI\]第三章第一节的映射过程.

生成例子

考虑以下XMPP地址:
         <ji?i@?echy.example/v Praze>
注意: 字符串"?" 代表Unicode符号LATIN SMALL LETTER R WITH CARON, 并且字符串"?" 代表Unicode符号LATIN SMALL LETTER C WITH CARON, 以下用于[IRI]"XML Notation"来表现无法在ASCII-only中表示的字符串(注意这些字符串也被展现在它们的字符准备规范表单中stringprep canonical form). '<'和'>'符号不是地址本身的一部分但为了易于理解而用来设定地址的结束. 对于那些不能读捷克语的人,这个例子可能被英语化为"george@czech-lands.example/In Prague".
和以上指定的过程一致, 生成程序将按以下步骤从这个地址生成一个合法的XMPP IRI:
  1. 确保XMPP地址符合XMPP-CORE定义的规则, 包括应用相应的[STRINGPREP] profiles和编码成[UTF-8]字符串.
  2. 连接以下:
    1. "xmpp"规划和":"符号.
    2. 一个"授权组件",如果有的话(本例没有展现).
    3. 一个Unicode字符串展示XMPP地址, 被以"inodeid","ihost",和"iresid"规则转换.
    4. "?"符号被一个"查询组件"跟随, 如果有适当的应用(本例没有展现).
    5. "#"符号被一个"碎片标识组件"跟随, 如果有适当的应用(本例没有展现).
结果是这个XMPP IRI:
       <xmpp:ji?i@?echy.example/v%20Praze>
为了从前述的IRI生成一个合法的XMPP URI, 应用必须(MUST)遵守定义在\[IRI\]第三章第一节的过程, 结果是以下的URI:
       <xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>

XMPP IRIs/URIs的处理

处理方法

如果一个处理程序被显示为一个XMPP URI而不是一个XMPP IRI, 它必须(MUST)首先按以下定义在\[IRI\]第三章第二节的过程把这个URI转换成为IRI.
为了分解一个XMPP IRI用于和它所标识的实体交互, 一个处理程序必须(MUST)分解为:
  1. "xmpp"规划和":"符号.
  2. 授权组件, 如果有的话(在"//"符号和下一个"/"符号 "?"符号,"#"符号,或IRI的结尾之间的Unicode字符串,).
  3. 一个展示为XMPP地址的根据"inodeid", "ihost", "iresid"规则转换的Unicode字符串.
  4. 可选的查询组件, 如果有的话, 使用"?"符号作为分隔符.
  5. 可选的碎片标识组件, 如果有的话, 使用"#"符号作为分隔符.
在这一点上, 处理程序必须(MUST)确保结果的XMPP地址遵守XMPP-CORE定义的规则, 包括应用相应的[STRINGPREP]. 然后处理程序将 (1) 自行完成更多的XMPP处理, 或(2) 调用一个帮助程序来完成XMPP处理; 这样的XMPP处理很可能包括如下的步骤:
  1. 如果还未连接到一个XMPP服务器, 作为授权组件中指明的用户连接或作为已配置的XMPP服务器的已配置用户连接, 通常遵守[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的XMPP连接过程.(注意: 处理程序应该(SHOULD)忽略授权组件,如果它已经用缺省的证书设置所配置.)
  2. 可选的, 决定预定接收者的种类(换言之,通过\[XEP-0030\]).
  3. 可选的, 根据预定接收者的种类展示一个适当的界面以及/或查询组件的内容给用户.
  4. 生成一个XMPP节把任何用户或应用的输入转换成它们相应的XMPP数据.
  5. 通过验证过的服务器连接发送XMPP节用于递送给预定接收者.

处理备注

实施者可能注意到, 在第二章第八节第一小节结尾中描述的"更多的XMPP处理", 前两步类似HTTP 验证([HTTP-AUTH]), 后三步类似处理 mailto: URIs ([MAILTO]).
本文的第二章第七节第二小节说过, 特定的字符被允许出现在原生的XMPP地址的节点标识符, 域标识符, 和资源标识符部分, 但被XMPP IRI的"inodeid", "ihost", 和"iresid"规则禁止. 当处理一个XMPP IRI用来和XMPP实体交互的时候, 这些部分编码的符合XMPP IRIs的字节必须(MUST)被转化成在XMPP地址中允许的字符串.
考虑以下一个XMPP IRI中的nasty节点:
      xmpp:nasty!%23$%()*+,-.;=%3F[\]^_`{|}~node@example.com
那个IRI将被转化成以下的XMPP address:
      nasty!#$%()*+,-.;=?[\]^_`{|}~node@example.com
考虑以下一个XMPP IRI中的repulsive资源(为便于阅读分成两行):
      xmpp:node@example.com
/repulsive%20!%23"$%25&'()*+,-.%2F:;<=>%3F%40[\]^_`{|}~resource


那个IRI将被转化成以下的XMPP地址(为便于阅读分成两行):
      node@example.com
/repulsive !#"$%&'()*+,-./:;<=>?@[\]^_`{|}~resource

处理例子

考虑从前一个例子中得到的XMPP URI:
       <xmpp:ji%C5%99i@%C4%8Dechy.example/v%20Praze>
为了从那个URI生成一个合法的XMPP IRI, 应用程序必须(MUST)遵守\[IRI\]第三章第二节定义的过程, 结果得到以下IRI:
       <xmpp:ji?i@?echy.example/v%20Praze>
和以上指明的处理一致, 处理程序将移除"xmpp"规划和":"符号以从XMPP IRI中揭解开XMPP地址, 转换任何按照"inodeid", "ihost", 和"iresid"规则部分编码的字节成为相应的字符串(例如, "%20" 转化成空格符号).
结果是这个XMPP地址:
       <ji?i@?echy.example/v Praze>

国际化

因为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\]:
    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 )

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维护变更控制.
  评论这张
 
阅读(1051)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017