我希望实现与XEP-0142中定义的功能相同的功能（用户在不知道该组织或工作组的特定成员的地址的情况下联系组织或工作组的代表）。
但是在XEP-0142网站上说“不建议实施此处描述的协议”。如果我们使用相同的结果会有什么后果？
我在satckoverflow上找到了https://stackoverflow.com/questions/16837281/chat-application-with-queues-xep0142，但在那里我找不到任何解决方案。
请建议我，如果我可以使用那个没有任何问题或请建议我任何其他替代方案来实现该功能。
答案 0 :(得分：1)
结果取决于您的要求。如果您可以控制客户端和服务器的功能，那么实现此功能就没有任何问题。如果不这样做，则可能意味着客户端或服务器不会实现此功能。
建议只是说XMPP不再支持这种实现，这意味着开发基于XMPP的解决方案的软件供应商可能已经或可能没有如上所述实现此功能。
答案 1 :(得分：0)
Openfire可靠地实现了这个名为fastpath的XEP。有关更多信息，请参阅openfire（和Spark）的fastpath插件。
因此，您可以重复使用Spark客户端或编写自己的客户端来实现所需的功能。
答案 2 :(得分：0)
大多数人都被当前的文字混淆或警告a＆＃39; Deferred＆＃39; XEP伴随着，读取
警告：XMPP推迟了对本文档的审议 标准基金会。本文描述的协议的实现 不推荐。
这应该在很久以前改为 1,2
警告：此文档在12之后已自动延期 在之前的实验状态中几个月不活动。 不建议实施此处描述的协议 生产系统。但是，探索性实现是 鼓励恢复标准流程。
更准确地描述了情况a＆＃39; Deferred＆＃39; XEP在：它已经超过12个月没有更新。如果有人会加强，并继续努力，这是每个人可以做的事情，那么它可以回到标准轨道上：
来自XEP-0001 § 8.1 Standard Track XEPs的请注意，如果XEP是延迟的，XMPP扩展编辑器可能会在某些情况下 点重新分配到实验状态
。
XEP-0001详细介绍了该过程。
1：http://logs.xmpp.org/council/2013-07-24/#15:12:32
2：http://mail.jabber.org/pipermail/council/2013-August/003748.html