对的正确 XMPP 客户端响应是什么？节？

发布于 2024-07-15 05:29:28 字数 1535 浏览 1 评论 0原文

以下是当我从服务器上的名册中手动删除联系人时服务器向我发送的内容 (openfire)：

'<iq type="set" id="183-87" to="[email protected]/hydra"><query xmlns="jabber:iq:roster"><item jid="[email protected]" name="baz" ask="unsubscribe" subscription="none"><group>Buddies</group></item></query></iq>'
'<iq type="set" id="187-88" to="[email protected]/hydra"><query xmlns="jabber:iq:roster"><item jid="[email protected]" name="baz" subscription="none"><group>Buddies</group></item></query></iq>'
'<presence type="unsubscribed" to="[email protected]" from="[email protected]"/>'

如果我用“取消订阅”状态节进行响应（根据 RFC 3921，我认为这是正确的），服务器会不断向我发送垃圾邮件有更多“取消订阅”的存在。

不管怎样，下次我的客户登录时，名单中没有任何变化。难道我做错了什么？

原文

Here's what the server is sending me (openfire) when I manually delete a contact from the roster on the server:

'<iq type="set" id="183-87" to="[email protected]/hydra"><query xmlns="jabber:iq:roster"><item jid="[email protected]" name="baz" ask="unsubscribe" subscription="none"><group>Buddies</group></item></query></iq>'
'<iq type="set" id="187-88" to="[email protected]/hydra"><query xmlns="jabber:iq:roster"><item jid="[email protected]" name="baz" subscription="none"><group>Buddies</group></item></query></iq>'
'<presence type="unsubscribed" to="[email protected]" from="[email protected]"/>'

If I respond with a 'unsubscribe' presence stanza (which I think is correct according to RFC 3921), the server keeps spamming me with more 'unsubscribed' presences.

Either way, the next time my client logs in, nothing has changed in the roster. Am I doing something wrong?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

十年九夏 2024-07-22 05:29:28

这取决于您所谈论的客户 - 是订阅者还是被订阅者。

。

如果客户端是订阅者，则什么也没有：

根据第9.4节，如果订阅者发送取消订阅请求，或者其他原因导致客户端取消订阅，服务器必须通过取消订阅响应确认该请求/报告状态更改。至此，互动结束。

如果订阅者每次收到来自服务器的取消订阅状态的通知并发送另一个取消订阅请求，告知其先前的订阅已被删除，那么订阅将永远不会结束。

。

如果客户端是订阅节点，则可能会向其发送取消订阅以确认允许删除订阅，但是当您在正常机制之外更改名册时，这是否仍然有效？我不确定。

我对 9.4 中表格的阅读是针对取消订阅期间订阅者和服务器之间的消息的：

subscriber            server             subscribee
    | -- unsubscribe --> |                    |
    |                    | -- unsubscribe --> |
    |                    | <- unsubscribed -- | (optional)
    |                    | -- unsubscribed -> |
    | <- unsubscribed -- |                    |

我对第 8.6 节，名册删除是这样的：

subscriber            server             subscribee
    | ----- remove ----> |                    |
    |                    | -- unsubscribe --> |
    |                    | -- unsubscribed -> |
    |                    | -- unavailable --> |
    | <- unsubscribed -- |                    |
    | <-- unavailable -- |                    |

无需任何客户的确认。

It depends which client you're talking about - whether it's the subscriber or the subscribee.

If the client is the subscriber, then nothing:

According to section 9.4, if the subscriber sends an unsubscribe request, or something else causes the client to be unsubscribed, the server must acknowledge the request/report the state change with an unsubscribed response. That's the end of the interaction.

If the subscriber sends another unsubscribe request each time it's informed that it receives a unsubscribed status from the server telling it that a previous subscription has been removed, then it will never end.

If the client is the subscribed node, then it may be sent an unsubscribe to confirm that removing the subscription is allowed, but whether that still stands when you're changing the roster outside of the normal mechanism I'm not sure.

My reading of the table in 9.4 is for the messages between subscribee and server during unsubscription is:

subscriber            server             subscribee
    | -- unsubscribe --> |                    |
    |                    | -- unsubscribe --> |
    |                    | <- unsubscribed -- | (optional)
    |                    | -- unsubscribed -> |
    | <- unsubscribed -- |                    |

My reading of section 8.6, roster removal is this:

subscriber            server             subscribee
    | ----- remove ----> |                    |
    |                    | -- unsubscribe --> |
    |                    | -- unsubscribed -> |
    |                    | -- unavailable --> |
    | <- unsubscribed -- |                    |
    | <-- unavailable -- |                    |

With no acknowledgement required by either client.

回复收藏 0 原文