XEP0030服务发现.docx
《XEP0030服务发现.docx》由会员分享，可在线阅读，更多相关《XEP0030服务发现.docx（44页珍藏版）》请在冰豆网上搜索。
XEP0030服务发现
XEP-0030
来自Jabber/XMPP中文翻译计划
跳转到：
导航,搜索
本文的英文原文来自XEP-0030
XEP-0030:
服务发现
摘要:
本文定义了一个XMPP协议扩展用于发现其他XMPP实体的信息.有两种信息可以被发现：
（1）一个实体的身份和能力,包括它支持的协议和特性;
（2）和一个实体相关的条目,例如一个多用户聊天服务的房间列表.
作者:
JoeHildebrand,PeterMillard,RyanEatmon,PeterSaint-Andre
版权:
©1999-2010XMPP标准化基金会（XSF）.参见法律通告.
状态:
最终
类型:
标准跟踪
版本:
2.4
最后更新日期:
2008-06-06
注意:
这里定义的协议是XMPP标准化基金会的一个最终标准,对于实现和布署来说可以被认为是一个稳定技术.
目录
∙1绪论
∙2需求
∙3发现Jabber实体的信息
3.1基本协议
3.2信息节点
∙4发现与Jabber实体相关的条目
4.1基本协议
4.2条目节点
4.3节点层次结构
4.4实体和其条目的关系
∙5发布可用的条目
∙6实现注意事项
6.1信息请求数
6.2请求的条目数
6.3响应一致性
∙7错误条件
∙8安全事项
∙9IANA事项
∙10XMPP登记事项
10.1协议名字空间
10.2登记处
▪10.2.1身份种类及类型登记
▪10.2.1.1过程
▪10.2.1.2初始提交
▪10.2.2特性注册
▪10.2.2.1过程
▪10.2.3知名节点
▪10.2.3.1过程
10.3URI查询类型
∙11XML架构
11.1disco#info
11.2disco#items
∙12作者备注
∙13附录
13.1附录A:
文档信息
13.2附录B:
作者信息
13.3附录C:
法律通告
13.4附录D:
和XMPP的关系
13.5附录E:
讨论地点
13.6附录F:
需求一致性
13.7附录G:
备注
13.8附录H:
修订历史
绪论
在Jabber网络中发现实体相关信息的能力是极有价值的。
这些信息包括实体支持的特性或支持的协议、实体的类型或身份、同原实体以某种方式相联系的另外一些实体等（这些实体通常当作“父”实体的“子”实体）。
虽然XMPPCore1并没有定义怎样做的机制，但在Jabber社区内，过去已经有几个协议用在了服务发现上,特别是JabberBrowsing2和AgentInformation3上。
然而，这些协议总使人感觉不那么合适，其原因如下：
1.JabberBrowsing和AgentInformation都不容易扩展。
例如，在XEP－0011中列出JID类型的种类及子类都明确地定义为唯一的正式种类，向列表加入新的JID类型都要修改XEP－0011。
而JabberBrowsing规范允许用非正式种类和以‘x-’打头的类型，这会产生移植问题。
这种适应性的缺乏违反了Jabber社区的核心XMPP协议设计原则4之一。
2.在AgentInformation协议中，没有声明所支持的特性的方法。
虽然JabberBrowsing包含了这样的机制，但表达一个特性的有效性的唯一方法是声明一个所支持的名字空间。
然而，有些特性也许并非唯一地对应一个协议名字空间，它只是特性的一个实现，但并是唯一的一个。
3.一个JabberBrowsing结果返回一个组合，由
（1）Jabber实体支持的名字空间，
（2）与Jabber实体相关联的条目，（3）相关条目支持的名字空间组成。
这种方法混淆了信息级别，要求父节点知晓子节点的一切，也就引入了极大的混乱。
4.在JabberBrowsing和AgentInformation中，要求条目们（items）必须可寻址为JIDs；然而，这在有些应用中是做不到的。
本文档旨在克服JabberBrowsing和AgentInformation这两个协议的弱点。
其结果就是一个用于服务发现的标准追踪协议（通常缩写为“disco”，就和一些熟悉的协议，如SOAP5一样）。
需求
在作者的头脑中构思的服务发现协议要满足下面的需求：
∙协议必须支持它所取代的协议（JabberBrowsing和AgentInformation）之全部功能
∙有三种关于一个实体的信息需要发现：
1.它的基本身份（类型和/或目录）
2.它提供的特性和支持的协议
3.与实体相关联的任何附加条目，无论它们是否能定址为JID
三种信息都必须支持，但前两种信息都与实体本身有关，而第三种信息与实体关联的条目有关；因此只需要两种不同的查询类型。
∙子条目信息的发现必须通过向它自己，而不是向父实体，发送单独的发现请求实现。
（其后果之一是，要发现整个三种信息，需要多个请求/响应对，以“遍历整个信息树”）。
∙身份和特性列表必须是柔性的。
∙协议本身必须是可扩展的。
发现Jabber实体的信息
基本协议
一个发出请求的实体会想发现网络中另一个实体的信息。
想得到的信息一般分为两种：
1.目标实体的身份（identity）。
在disco中，一个实体的身份细分成种类（category）（服务器、客户端、网关、目录等等）及其种类中的特殊类型（IM服务器、电话对处理的客户端、MSN网关对AIM网关、用户目录对聊天室目录等等）。
这个信息帮助请求实体测定服务组或服务“桶”，以使实体最恰当地放置其中（例如，或许用个合适的图标把实体显示成GUI）。
一个实体可以有多个身份。
当提供多个identity元素的时候，每个identity元素的name属性应该有相同的值。
2.目标实体提供的特性和支持的协议。
这个信息帮助请求实体测定对目标实体可以做什么样的动作（注册、搜索、联合等等），实体支持什么样的协议，以及是否有感兴趣的特性类型（例如，为了特性协商的目的）。
为了发现这样的信息，请求实体必须向目标实体的JID发送类型为“get”的IQ节，包含一个用命名空间'http:
//jabber.org/protocol/disco#info'标识的空的元素（'to'的地址是必需的，必须包含有效的JID；元素的'node'属性是可选的，本文中信息节点和条目节点一节对此有说明）。
例1.查询信息
from='romeo@
to='plays.shakespeare.lit'
id='info1'>
//jabber.org/protocol/disco#info'/>
然后目标实体必须返回一个IQ结果，或者返回一个错误（见本文错误条件）。
结果必须包含用命名空间'http:
//jabber.org/propocol/disco#info'标识的元素，元素中依次包含一个或多个元素及一个或多个元素。
（注意：
每个实体必须至少有一个identity，每个实体必须至少支持'http:
//jabber.org/protocol/disco#info'特性；然而，并不要求一个实体一定返回一个结果，它也可以返回一个错误，最可能的是或，虽然其他出错条件也是可以的）。
每个元素必须拥有'category'和'type'属性，用来说明实体的种类,而且可以MAY拥有一个'name'属性为这个实体指定一个自然语言的名字;这个元素也可以MAY拥有一个标准的'xml:
lang'属性,它使实体能返回本地化的结果，如果必要的话（即,元素可以MAY包含多个元素，使用相同的category+type但是不同的'xml:
lang'值；无论如何元素不能MUSTNOT以相同的category+type+xml:
lang和不同的'name'值包含多个元素，）.
每个元素必须拥有一个'var'属性，它的值是协议的命名空间或是实体提供的其他特性。
如果象本文中XMPP登记事项一节说明的那样，种类/类型的值和特性值都在公共登记处注册了的话就更好了。
例2.信息请求的结果集
from='plays.shakespeare.lit'
to='romeo@
id='info1'>
//jabber.org/protocol/disco#info'>
category='conference'
type='text'
name='Play-SpecificChatrooms'/>
category='directory'
type='chatroom'
name='Play-SpecificChatrooms'/>
//jabber.org/protocol/disco#info'/>
//jabber.org/protocol/disco#items'/>
//jabber.org/protocol/muc'/>
iq:
register'/>
iq:
search'/>
iq:
time'/>
iq:
version'/>
如果指定目标实体的JID不存在，服务器或其他认证实体应该返回一个错误，除非如果这么做会破坏在XMPPCore和XMPPIM6中说明的隐私和安全事项，或是破坏本地隐私和安全策略（见本文安全事项）:
例3.目标实体不存在
from='plays.shakespeare.lit'
to='romeo@
id='info1'>
//jabber.org/protocol/disco#info'/>
ietf:
params:
xml:
ns:
xmpp-stanzas'/>
如果隐私和安全事项或策略阻止服务器或其他授权实体返回错误，取而代之它应该返回一个错误:
例4.服务不可用
from='plays.shakespeare.lit'
to='romeo@
id='info1'>
//jabber.org/protocol/disco#info'/>
ietf:
params:
xml:
ns:
xmpp-stanzas'/>
当一个实体向一个由服务器做宿主的纯JID（）发送disco#info请求的时候，这个服务器本身必须代表寄宿的帐号回应一个IQ错误或IQ结果。
有关访问这些功能的重要规则，见本文的安全事项一节。
特别地，为响应向一个没有节点的纯JID发出的disco#info请求，如果访问没被拒绝，服务器应该为这个纯JID返回一个IQ结果，里面的主identity应该有具有合适类型的“account”种类，类型在ServiceDiscoveryIdentities注册中说明（最可能的是类型"registered"）。
注意：
这使得那些已授权或被信任的实体能发现帐号帐号是否存在及帐号的类型（例如，在IM系统中，在把帐号加入联系人列表之前检测它是否存在）。
例5.从纯JID那里请求信息
from='shakespeare.lit'
to='juliet@'
id='info2'>
//jabber.org/protocol/disco#info'/>
这里我们假定shakespeare.lit被信任，而帐号是个注册帐号：
例6.服务器替纯JID应答
from='juliet@'
to='shakespeare.lit'
id='info2'>
//jabber.org/protocol/disco#info'>
向关联实体发出的查询结果会不同，或能得到更详细的信息。
一个例子是向一个特别的会议室而不是父实体的会议服务发出查询：
例7.查询指定的会议室
from='juliet@
to='balconyscene@plays.shakespeare.lit'
id='info3'>
//jabber.org/protocol/disco#info'/>
from='balconyscene@plays.shakespeare.lit'
to='juliet@
id='info3'>
//jabber.org/protocol/disco#info'>
category='conference'
type='text'
name='RomeoandJuliet,ActII,SceneII'/>
//jabber.org/protocol/disco#info'/>
//jabber.org/protocol/muc'/>
//jabber.org/protocol/feature-neg'/>
另一个例子是向一个带明确资源连接的IM用户发出查询：
例8.查询连接资源的更详细的信息
from='juliet@
to='romeo@
id='info4'>
//jabber.org/protocol/disco#info'/>
from='romeo@
to='juliet@
id='info4'>
//jabber.org/protocol/disco#info'>
category='client'
type='pc'
name='Gabber'/>
iq:
time'/>
iq:
version'/>
信息节点
一个disco#info也查询可以MAY被定向到特定的关联到一个JID的节点标识符,尽管节点的主要用途是成为条目节点ItemsNodes而不是信息节点infonodes:
例子9.查询一个特定的JID和node的组合
from='romeo@
to='mim.shakespeare.lit'
id='info3'>
//jabber.org/protocol/disco#info'
node='http:
//jabber.org/protocol/commands'/>
如果请求包含'node'属性,应答必须MUST镜像这个指定的'node'属性以确保请求和应答之间的相关性.
例子10.JID+node结果
from='mim.shakespeare.lit'
to='romeo@
id='info3'>
//jabber.org/protocol/disco#info'
node='http:
//jabber.org/protocol/commands'>
category='automation'
type='command-list'/>
发现与Jabber实体相关的条目
基本协议
请求实体为了发现一个Jabber实体相关联的条目，它必须向目标实体发送类型为"get"的IQ节，其中包含一个空的元素，受限命名空间为'http:
//jabber.org/protocol/disco#items'：
例11.请求全部条目
from='romeo@
to='shakespeare.lit'
id='items1'>
//jabber.org/protocol/disco#items'/>
目标实体必须返回它的公开可用的条目列表，或者返回一个错误。
条目列表必须是类型为"result"的IQ段，每个条目用的子元素
//jabber.org/protocol/disco#items'（子元素
例12.所有条目的结果集
from='shakespeare.lit'
to='romeo@
id='items1'>
//jabber.org/protocol/disco#items'>
name='DirectoryofCharacters'/>
name='Play-SpecificChatrooms'/>
name='GatewaytoMarloweIM'/>
name='ShakespeareanLexicon'/>
name='CalendarofPerformances'/>
name='LatestShakespeareanNews'/>
name='BuyShakespeareStuff!
'/>
name='FrenchTranslationService'/>
如果没有条目与实体相关联（或者这些条目并非公开可用的），目标实体必须向请求实体返回一个空的query元素：
例13.空的结果集
from='shakespeare.lit'
to='romeo@
id='items1'>
//jabber.org/protocol/disco#items'/>
就请求disco#info来说，当实体向寄生在一个服务器的纯JID（）发送disco#items请求时，宿主服务器自身必须代表寄生帐号回应。
有关访问这个功能的重要准则，见本文的安全事项一节。
特别地，为响应发到一个不带节点的纯JID的disco#info请求，如果访问没被拒决，服务器应该返回相关的条目，包括适当的已连接或可用的资源:
例14.从
升级会员 