XEP-0134
本文的英文原文来自XEP-0134
XEP-0134: XMPP设计准则
| 摘要: | 本文定义了Jabber协议和其他扩展的智能设计的最佳实践. |
|---|---|
| 作者: | Peter Saint-Andre |
| 版权: | © 1999 - 2013 XMPP标准化基金会(XSF). 参见法律通告. |
| 状态: | 活跃 |
| 类型: | 信息 |
| 版本: | 1.1 |
| 最后更新日期: | 2004-12-09 |
注意: 这个信息规格定义了那些已被XMPP委员会和/或XSF董事会批准的最佳实践或协议范本. 对本协议实现是被鼓励的,最佳实践和协议范本适于部署到生产系统.
目录 |
简介
可扩展的消息和出席信息协议(XMPP)为在XMPP的核心XML流技术上的各种各样的应用提供了一个坚实的, 弹性的基础. 随着XMPP Core 1 和 XMPP IM 2 的升级从而进入互联网标准流程, 对建设基于XMPP的应用和扩展的兴趣更加速了. 不幸的是, 不是每一个希望建设公共或私有XMPP扩展的人都熟悉关键那些原有的Jabber技术开发者提出的设计准则或今天那些指导成功的基于XMPP的协议的设计. 因此尝试把那些由Jabber开发者和协议设计者拥有的经常是隐形的知识翻译成更加显性的策略和原则来让其他人遵守是有益的. (更多互联网协议设计的洞见, 参阅 RFC 3117 3.) 解释"Jabber方法"的最终结果希望在Jabber/XMPP社区内对好的协议设计实践有一个广泛和深入的理解.
准则
XMPP是神圣的
背景
当XMPP标准基金会(XSF) 4 提交 XMPP Core 和 XMPP IM 协议给互联网工程任务组(IETF) 5的时候, 它放弃了在Jabber社区开发的核心XML流技术上变更控制. 无论如何, XSF还是保留了定义XMPP扩展的权力; 此外, 那一权力不仅限于XSF, 因为任何人可以定义他们自己的公共或私有的XMPP扩展. 这些扩展通常使用结构化的XML数据格式，由一个唯一性的不同于当前被IETF或XSF保留的命名空间来限定.
意义
当我们说"XMPP是神圣的", 我们的意思是好的协议设计必须在XMPP的上下文内工作并且不需要修改核心协议. 事实是, 任何这类修改都需要由IETF来执行. 而且, 核心语义几乎提供了一个协议设计者需要的大部分语义. 如果你认为你需要定义一种新的顶级节(不同于 <message/>, <presence/>, 和 <iq/>) 或任何节的一个新的'type'属性值, 那么你需要再想想. 把XMPP视为一个传输层并且在那一层之上建立扩展(也就是说, 这暗示你在工作于高级结构的时候,不能(must not)修改基础， 例如理论上不能添加元素和属性到XMPP schemas，否则应用将忽略它们; 你应该在一个独立的命名空间定义你自有的扩展). 尊重XMPP的另一个含义是任何时候如果可能就使用结构化的数据格式(例如, 应用XML 1.0 6而不是二进制或纯文本格式). 最后, 如XMPP Core解释的, <presence/>节仅用于广播网络和通讯可用性; 更多高级的信息发布, 使用Publish-Subscribe 7.
示例
一个好的尊敬XMPP协议的例子是隐身] 8; 因为Jabber社区在某个时候曾经非正式地定义了<presence type='invisible'/>, 因为XMPP兼容性的原因那个协议被废弃了. 另一个例子是XHTML-IM 9, 它重用了XHTML 1.0 10 (分享给XMPP一个通用的XML根的一个结构化格式) 而不是富文本格式(RTF) 11 (一个不是源自XML的非结构化的格式). 更进一步的例子是"扩展的出席信息"协议(见扩展出席信息协议族 12), 它被建立于XEP-0060之上而不是重载<presence/>节. 译者备注：XEP-0119已经被作者收回了，可见这也不是一个好的例子。
