XEP-0147
本文的英文原文来自XEP-0147
XEP-0147: XMPP URI Scheme查询组件
摘要: | 本文定义了一个查询组件的注册项用于XMPP IRIs/URIs的上下文,也指定了注册项的值的首次提交步骤. |
---|---|
作者: | Peter Saint-Andre |
版权: | © 1999 - 2012 XMPP标准化基金会(XSF). 参见法律通告. |
状态: | 活跃 |
类型: | 信息 |
版本: | 1.2 |
最后更新日期: | 2006-09-13 |
注意: 这个信息性的协议定义了一个已经被XMPP评议会 和/或 XSF董事会批准的最佳实践或协议范本. 该协议被鼓励实现并且这一最佳实践或或协议范本适于部署到生产环境.
目录 |
简介
RFC 5122 1 定义了一个统一资源标识符(URI)方案用于把用可扩展的消息和出席信息协议(参见 XMPP核心 3)来通讯的实体的地址格式化成 URIs 和互联网资源标识符(IRIs) 2. 这些标识符使得非类似数据库和web浏览器的本地应用能对XMPP实体进行鉴定和与之交互.
无论如何, RFC 5122 故意在查询组件留下开放式的潜在值, 未对查询提供一个常用"操作"列表(例如, 发送小西或加入聊天室), 并且未指定推荐的"键-值" 对来用于这类操作作的上下文. 所以, 本文定义了这类操作的注册项和 键-值 对(由 XMPP注册项 4) 维护并为那个注册项指定一组初始值.
本文组织如下:
- 注册项定义于 XMPP IRI/URI查询类型注册项 章节.
- 操作和 键-值 对一组初始值在 查询操作 章节中描述.
- 该注册项相应的初始提交定义于初始注册项章节.
- 提交额外值到注册项的过程定义于注册过程章节.
注意: XMPP URI scheme 的格式, 包括查询组件的格式, 完全被指定并正式地被定义是在 RFC 5122 ; 本文未以任何方式修改 xmpp URI scheme 并假定读者对 RFC 5122 各方面很熟悉.
术语
本文从 RFC 3986 5, RFC 3987 6, 和 RFC 5122 继承术语.
查询操作
通过XMPP IRI/URI和XMPP实体的交互来触发的操作的范围,接本上和XMPP扩展的范围一样广泛. 本文不专注于详尽地定义所有这类潜在的操作. 然而, 以下操作可能一般人都会感兴趣的:
对于每个这类操作, XMPP注册项维护一个推荐的(RECOMMENDED) "查询类型" (这可以被认为是操作的名称或 "动词"; 语法和语义参见 RFC 5122) 以及如果必要的话,可选的(OPTIONAL)用于 键-值 对的键列表.
和RFC 3920及RFC 3921相关的查询类型和 键-值 对定义于此; 和XMPP标准基金会的XEP系列定义的协议相关的查询类型和 键-值 对定义于相应的XMPP扩展协议规范中.
消息操作
对于XMPP IRI/URI来说触发特定的接口用来发送一个XMPP消息节可能是最受欢迎的. 对于这个操作,建议的查询类型是"message". 如果没有提供 键-值 对, 和包含了查询类型"message"的 XMPP IRI/URI交互应该触发一个接口允许用户输入一个XMPP消息文本和其他相关的参数(例如, 一个消息标题或 XHTML-IM [[XEP-0147#附录G:备注|14] 加成).
示例1. 基本消息操作
xmpp:romeo@montague.net?message
一个查询类型为"message"的查询组件可以指定各种 键-值 对. 以下三个键和XMPP IM 15 中的'jabber:client'命名空间的XML schema定义的<message/>节的子元素相关:
- subject
- body
- thread
另外, 以下三个键和'jabber:client'命名空间的XML schema定义的<message/>节的属性相关('to'属性是不必要的, 因为它由 IRI/URI中包含的XMPP Address提供):
- from
- id
- type
其他键可以在XMPP注册处去注册但是没有在这里定义.
示例2. 带键的消息操作: IRI/URI
xmpp:romeo@montague.net?message;subject=Test%20Message;body=Here%27s%20a%20test%20message
示例3. M带键的操作: 结果节
<message to='romeo@montague.net'> <subject>Test Message</subject> <body>Here's a test message.</body> </message>
名册管理操作
'jabber:iq:roster' 命名空间提供一个机制来管理XMPP名册(也称为"联系人列表"). 这个命名空间定义于RFC3921. 定义了以下操作.
添加名册条目
用于添加条目到名册或在名册里修改条目的已注册的查询类型是 "roster" (实际上添加和修改是没区别的). 一个包含了 "roster" 查询类型的 XMPP IRI/URI 可以也包含至少一个 "name" 键,它的值映射到'jabber:iq:roster'命名空间的<item/>元素的 'name' 属性, 而且可以包含一个 "group" 键,它的值映射为<item/>元素的<group/>子元素的字符串数据.
示例4. 名册操作: IRI/URI
xmpp:romeo@montague.net?roster
示例5. 名册操作: 结果节
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='romeo@montague.net'/> </query> </iq>
示例6. 对名册的Name操作: IRI/URI
xmpp:romeo@montague.net?roster;name=Romeo%20Montague
示例7. 对名册的Name操作: 结果节’‘’
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='romeo@montague.net' name='Romeo Montague'/> </query> </iq>
示例8. 对名册的Name和Group操作: IRI/URI
xmpp:romeo@montague.net?roster;name=Romeo%20Montague;group=Friends
示例9. 对名册的Name和Group操作: 结果节
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='romeo@montague.net' name='Romeo Montague'> <group>Friends</group> </item> </query> </iq>
注意: 还未确定包含多个group的方法(如果有的话).
删除名册条目
'jabber:iq:roster'命名空间包含了一个机制用来移除XMPP名册条目. 用来从名册中移除一个条目的已注册查询类型是"remove".
示例10. 名册移除操作: IRI/URI
xmpp:romeo@montague.net?remove
示例11. 名册移除操作: 结果节
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='romeo@montague.net' subscription='remove'/> </query> </iq>
订阅管理操作
和名册管理紧密相关的是出席信息订阅管理. 在XMPP中, 订阅管理是通过<presence/>节的特定值来处理的, 如RFC3921所述. 定义了以下操作
订阅
当一个实体通过一个XMPP IRI/URI订阅了另一个实体的出席信息, 被调用的XMPP应用应该首先发送一个下面展示的添加名册的节(这和RFC3921中的建议是一致的).
示例12. 订阅操作: IRI/URI
xmpp:romeo@montague.net?subscribe
示例13. 订阅操作: 结果节
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='romeo@montague.net'/> </query> </iq> <presence to='romeo@montague.net' type='subscribe'/>
取消订阅
XMPP包含了一个机制用于从一个实体取消订阅. 这种行为的已注册查询类型是"unsubscribe".
示例14. 取消订阅操作: IRI/URI
xmpp:romeo@montague.net?unsubscribe
示例15. 取消订阅操作: 结果节
<presence to='romeo@montague.net' type='unsubscribe'/>
国际化事项
对于XMPP IRIs/URIs的国际化事项定义于 RFC 5122 ; 读者可以参考那个文档来了解相关问题的全部讨论.
展示给自然人用户的应用程序特有的数据的本地化(例如, 封装在 键-值 对中的) 是"使用协议"的责任.
安全事项
对于XMPP IRIs/URIs的安全事项定义于 RFC 5122 .
完成一些定义于此的操作将导致对一个实体的帐户的修改, 对信息的订阅, 注册到服务, 和其他实体通讯, 完成特定的命令, 类似的等等. 自然的, 这些修改, 信息, 服务, 以及通讯是潜在的不受欢迎的(例如, 加入一个你对其主题没兴趣或甚至有冒犯加入的用户的行为的聊天室). 被调用的应用应该适当地对一个自然人用户警告该操作完成后的潜在后果.
IANA事项
本文不要求和 互联网号码分配机构(IANA) 16交互. 如果将来 IANA 应该希望维护一个XMPP URI/IRI 查询组件的注册项, 那么XMPP注册处将努力协作把注册项从XMPP注册处中迁移到IANA.