只能通过百度快照找到原文了:)

[xmpp][添加好友]rfc3921中presence和roster集成的一点思考


[xmpp][添加好友]rfc3921中presence和roster集成的一点思考
Jabber(XMPP)中文翻译计划

http://wiki.jabbercn.org/space/start/2007-05-03/1
————————————————–

[ 开始 | 索引 | 登录 或 注册 | 忘记密码 ]
start > 2007-05-03 > 1
2007-05-03 #1
由how创建。最后一次被how修改，在1年1天之前。 被访问了 459 次。 #1
[编辑] [rdf]
标签
附件
rfc3921中presence和roster集成的一点思考
最近发现psi的添加联系人功能和别的客户端软件有一点小小不同, 也暴露出RFC3921中presence和roster集成中兼容性的一点小问题.

假定 user@jabbercn.org 使用 psi , 而 contact@rooyee.biz 使用 rooyee messenger ,情形如下:

1. contact@rooyee.biz 向 user@jabbercn.org 发出添加好友的请求

<iq id="rosterset1" type="set">

<query xmlns="jabber:iq:roster">

<item jid="user@jabbercn.org" name="user"/>

</query>

</iq>

<presence from="contact@rooyee.biz" to="user@jabbercn.org" type="subscribe"/>

2. user@jabbercn.org 向 contact@rooyee.biz 发出添加好友请求(也就是请求对方加自己为好友)

<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribe"/>

3. user@jabbercn.org 同意成为 contact@rooyee.biz 的好友(也就是批准对方添加自己)

<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribed"/>

4. contact@rooyee.biz 同意 成为user@jabbercn.org 的好友(也就是批准对方添加自己)

<presence from="contact@rooyee.biz" to="user@jabbercn.org" type="subscribed"/>

在RFC3921第八章:名册条目和出席信息订阅的集成中规定, 正常的用户之间的相互订阅中,本方接收到对方请求之后,首先要做的是批准对方请求,然后才是向对方提出订阅请求, 而在上述例子中,psi客户端(也就是用户user@jabbercb.org)是把这两步颠倒过来的(第二步和第三步).

现在兼容性的问题就来了, jabberd2服务器是严格按照RFC3921第八章:名册条目和出席信息订阅的集成来实现的,使用psi的user@jabbercn.org在批准contact@rooyee.biz之前就向对方请求订阅,导致最后user@jabbercn.org的状态是From,而contact@rooyee.biz状态则为Both, 也就是说 user@jabbercn.org 无法正常完成添加好友功能.

然后我们再来看看RFC3921第九章订阅状态中规定, 如果单从订阅状态考虑, 那么psi的处理方式并非那么无理. 我们看看每一步动作之后双方的状态改变情况(以下每一步的状态对应前述例子的每一步):

1. user@jabbercn.org : None + Pending In

contact@rooyee.biz : None + Pending Out

2. user@jabbercn.org : None + Pending In/Out

contact@rooyee.biz : None + Pending Out/In

3. user@jabbercn.org : From + Pending Out

contact@rooyee.biz : To + Pending In

4. user@jabbercn.org : Both

contact@rooyee.biz : Both

openfire中就是这样单纯按订阅状态处理的, 所以psi客户端和openfire服务器配合的时候可以正常地添加好友.

接下来我们再看RFC3921第六章的管理订阅和RFC3921第七章的名册管理, 如果不考虑集成的问题, 把相互加好友变成你加我加上我加你,那么就需要把前述的例子的第二步改成如下

2. user@jabbercn.org向contact@rooyee.biz发出添加好友请求(也就是请求对方加自己为好友)

<iq id="rosterset2" type="set">

<query xmlns="jabber:iq:roster">

<item jid="contact@rooyee.biz" name="contact"/>

</query>

</iq>

<presence from="user@jabbercn.org" to="contact@rooyee.biz" type="subscribe"/>

pandion客户端就是采用这个处理方式, 它和目前的服务器都可以很好地兼容.

综上所述, RFC3921的第六章第七章是把出席信息订阅和名册管理分开考虑的, 因为在XMPP中是允许存在独立的出席信息应用的,所以从逻辑上来讲它们是独立的, 第八章则考虑到了它们的集成,这是大部分XMPP应用中的典型需求, 第九章基于订阅状态处理的规则对于第八章的优化, 它侧重于使得服务器实现更加简单和易于兼容.