XEP-0128
本文的英文原文来自XEP-0128
XEP-0128: 发现服务扩展协议
摘要: 这个文件规定了发现服务的扩展信息的最佳做法。
作者: Peter Saint-Andre
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.
现状: 活跃
类型: 信息
版本: 1.0
最后更新: 2004-10-20
注意：注意：此信息规范定义了一个最佳实践或协议配置文件已被批准的XMPP理事会和/或董事XSF局。实现是鼓励和最佳做法或协议配置文件是在生产系统中部署适当的。
目录 |
简介
开发人员觉得发现服务不能包含更多的信息. 例如, <identity/> 元素不包含'description'属性, 我们可以增加这个属性吗? 答案是可以,但现在不行,太迟了(因为XEP-0030是最终版). 因此,最好的办法是制定一个扩充机制.
让我们参考一个示例. 一个多用户聊天室[2] 可能想要获取更多的信息, 包括房间描述信息,房间主题,房间在线人数和房间所有者的JID.
增加一个新属性的服务发现架构(即使真的是一个选项)不能解决的问题,因为一MUC的服务可能需要提供某些信息，而发布，订阅 [3]服务可能需要提供其信息。
一个更好的解决办法是通过一个扩展的信息包括命名空间，提供了一种灵活的结构化数据格式定义合格。 谢天谢地，我们已经拥有了这样一个协议： 数据表格 [4]。 此外，我们拥有一个共同的方式来定义字段形式用于数据： 数据表格现场标准化 [5]。 使用这些构建模块，我们可以定义为扩展服务发现结果的一些最佳做法。
建议
如果一个实体的希望提供服务发现协议的扩展信息,出现在回复信息内,它应该这样做:每个独立的<field/>元素包含<value/>点数据信息子节点,所有<field/>元素包含在一个类型为"result"命名空间值为'jabber:x:data'的<x/>元素里.
<iq type="result">
<query xmlns="http://jabber.org/protocol/disco#info"> ... <x type='result' xmlns='jabber:x:data'> <field var='[var-name]' label='[optional]'> <value>[var-value]</value> </field> ... </x> </query>
</iq>
<iq type='result'> <query xmlns='http://jabber.org/protocol/disco#info'>
...
<x type='result' xmlns='jabber:x:data'>
<field var='[var-name]' label='[optional]'>
<value>[var-value]</value>
</field>
..
</x>
</query> </iq>
<node> <name>the name of the node</name> <desc>a natural-language description of the node</desc> <doc>the document (e.g., XEP) in which this node is specified</doc> </node>
如果数据字段被用来在由XMPP标准基金会核准的议定书时，他们应该符合相关的XMPP扩展协议规范并按照XEP - 0068定义的规则注册，返回信息中包含一个<field/>元素,其'var'属性为"FORM_TYPE"，其'type'属性的值为"hidden"。
一个实体不能提供'http://jabber.org/protocol/disco#items' 命名空间相关子信息,因为服务发现的核心原则是：一个实体必须确定其身份,不界定的身份与子节点的实体.
示例
IM服务器
以下是即时消息服务器返回一个标准的服务查询的例子.
例1. 实体查询信息服务器
<iq type='get'
from='capulet.com' to='shakespeare.lit' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result' from='shakespeare.lit'
to='capulet.com' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='server' type='im' name='shakespeare.lit jabber server'/> <feature var='jabber:iq:register'/> <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/network/serverinfo</value> </field> <field var='c2s_port'> <value>5222</value> </field> <field var='c2s_port_ssl'> <value>5223</value> </field> <field var='http_access'> <value>http://shakespeare.lit/jabber</value> </field> <field var='ip_version'> <value>ipv4</value> <value>ipv6</value> </field> <field var='info_url'> <value>http://shakespeare.lit/support.php</value> </field> </x> </query>
</iq>
群
下面是在多用户房间里查询服务的例子.
例2. 用户查询房间信息
<iq type='get'
from='hag66@shakespeare.lit/pda' to='darkcave@macbeth.shakespeare.lit' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result'
from='darkcave@macbeth.shakespeare.lit' to='hag66@shakespeare.lit/pda' id='disco1'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' type='text' name='A Dark Cave'/> <feature var='http://jabber.org/protocol/muc'/> <feature var='jabber:iq:register'/> <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/muc#roominfo</value> </field> <field var='muc#roominfo_description' label='Description'> <value>The place for all good witches!</value> </field> <field var='muc#roominfo_subject' label='Subject'> <value>Spells</value> </field> <field var='muc#roominfo_occupants' label='Number of occupants'> <value>3</value> </field> <field var='muc#roominfo_lang' label='Language of discussion'> <value>en</value> </field> </x> </query>
</iq>
实现说明
一般来说，XMPP标准基金会给每一个发现服务在注册登记时指定一个FORM_TYPE.此外，特定的应用可以定义应用程序以及具体FORM_TYPEs，一个实体可以有多个服务发现的身份（例如，一个XMPP服务器也可能作为一个发布，订阅服务）。因此，它是可能的（允许一个单一的服务发现的结果，发现含有多种服务扩展元素（可能高达2为每个标识元素））。然而，在实践中是不可能发现任何特定服务的结果将包含多个服务扩展元素的发现。
安全注意事项
应用程序应确网络上任何实体都能发现服务扩展信息.
IANA注意事项
这份文件并不需要与互联网分配编码机构(IANA) [6]互动.
XMPP协议注册事项
本文件并不需要的相互作用的XMPP注册 [ 7 ]，但是，最佳做法是在XMPP的登记FORM_TYPEs和field值.
附录
附录A:文档信息
系列：XEP
序号：0128
发布者：XMPP标准基金会
状态：终结版
类型：标准跟踪
版本：1.0
最后更新：2004-10-20
批准机构：XMPP理事会
依赖标准：XEP-0030|XEP-0068|XMPP Core
取代: 无
被替代标准：无
缩略名：N/A
附录B:作者信息
Peter Saint-Andre Email: stpeter@jabber.org JabberID: stpeter@jabber.org URI: https://stpeter.im/
附录C:法律通告
版权
XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.
权限
特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。
免责声明'
## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##
责任限制
在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。
知识产权的一致性
XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).
附录D:和XMPP的关系
可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.
附录E:讨论地点
主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.
在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .
勘误表可以发送邮件到 <editor@xmpp.org>.
附录F:需求一致性
以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
附录G:备注
1. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.
2. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.
3. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.
4. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.
5. XEP-0068: Field Data Standardization for Data Forms <http://xmpp.org/extensions/xep-0068.html>.
6. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
7. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.
附录H:修订历史
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Version 1.0 (2004-10-20) Per a vote of the Jabber Council, advanced status to Active; also added implementation notes. (psa) Version 0.2 (2004-03-15) Clarified syntax and corrected several errors; added IM server example. (psa) Version 0.1 (2004-03-05) Initial version. (psa)
结束
