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已经被作者收回了，可见这也不是一个好的例子。
保持客户端简单
背景
几乎所有的Jabber技术都是在一个客户端-服务器架构里实现的. 虽然那不是必需的(存在一些端到端的XMPP应用), 它通常是个好主意. 除了其他因素, 一个客户端-服务器架构使得Jabber社区能够强制大部分的复杂性落在服务器和组件上, 从而也就保持了客户端的简单. 这个原则从开始的时候就贯穿于Jabber社区, 并且成为继续创新的一个重要基础.
意义
"保持客户端简单"有很多实现影响, 其中有这些:
- 不必要的时候不嵌套协议(你定义的协议越多, 写一个客户端的难度越大).
- 容易降级，这样更简单的客户端或更旧的客户端仍能参与网络.
- 如果需要大规模的处理, 让服务器或组件处理它.
- 除非绝对必要，不强加客户端额外的需求(类似XSLT处理器等).
示例
一个好的保持客户端简单的例子是presence节: 客户端只发送<presence/>而服务器处理出席信息探测, 广播, 和适当的路由决策. 另一个例子是多用户聊天 13: 尽管该协议比较复杂, 它的写法能让旧的客户端加入和参与到MUC房间，即使他们不能理解更高级的MUC扩展.
重用现有的协议
背景
从1999年开始Jabber社区已经开发了很多协议用于XML流, 出席信息, 以及即时消息. 那时候, 社区的成员已经定义了不少作为进一步开发的基础的模块. 此外, 一些聪明人已经在其他标准开发组织创建了开放的协议, 包括 IETF, World Wide Web Consortium (W3C) 14, OASIS [15], International Telecommunication Union (ITU) 16, 以及 Dublin Core Metadata Initiative (DCMI) 17.
意义
好的协议设计者通过重用那些已经被XSF和其他标准开发组织定义的协议"站在巨人的肩膀上". 那不意味着我们没有定义心的协议, 因为有时候那是必要的. 无论如何, 我们知道有其他人完成了工作然后我们使用它, 特别是当那个工作是Jabber社区核心权限领域之外的的时候(例如, 安全性或多媒体数据格式而不是XML流, 出席信息, 和实时消息). 此外, XSF喜欢在任何可能的地方重用协议. 最后, 和XMPP一样, XMPP扩展也通过XSF来定义: 除非通过XMPP扩展流程,不修改现存的schemas (例如, 添加新的元素和属性); 反之, 在一个新的命名空间定义扩展).
示例
重用现有的Jabber协议的例子包括Stream Initiation 18 (它重用了Feature Negotiation 19) 和 ‘’‘XEP-0126: Invisibility’‘’ (它重用了定义于 XMPP IM 的隐私列表协议). 重用非Jabber协议的例子包括SOCKS5 Bytestreams 20 (它使用了RFC 1928 21) 和Common Alerting Protocol (CAP) over XMPP 22 (它定义了一个方法通过Jabber来发送Common Alerting Protocol 23数据). 再一次的 XEP-0071 提供了一个例子: 它重用了 XHTML 1.0 (一个由认可的标准开发组织开发的开放协议) 而不是 RTF (一个由微软公司控制的封闭协议).
模块化更好
背景
大部分Jabber实现使用模块化架构来建造, 在这里很多功能片被作为独立的组件编码然后组装成更大的整体, 通过核心的路由逻辑集成到系统(示例包括允许插件开发的客户端和允许外挂外部组件的服务器). 我们能看到很多Jabber协议采用同一个方法: 每一个指定一个定义良好的并且松散地连接到其他域的功能域并且由XMPP提供的核心传输协议集成在一起.
意义
最好的Jabber协议是安静地专注并提供有限但强大的功能并应用到一个特定的域，或, 有时候, 被其他Jabber协议重用. 即使该域更加复杂, 那些地址代表的协议也需要清楚地定义它的范围, 尽可能限制那个范围, 并且只定义必要的协议来满足核心需求.
示例
Service Discovery 24和Data Forms 25 是好的专注的例子, 单一用途的协议. 相比之下, Multi-User Chat 更复杂, 但是它自我限制于虚拟房间的上下文中的文本会议领域(例如, 它不涉及服务级别的管理)并且有独立的命名空间用于最终用户, 主持人, 和房间所有者功能. 一个专注于更小领域的好的例子是 Roster Item Exchange 26.
认识到你的优势
背景
Jabber技术的核心优势是在出席信息感知网络的终端之间的和小的XML片段相关的流. 由于在通常情况下, 我们最大的优势也是我们最大的弱点. 所以XMPP没有为二进制数据, 大的XML文件, 多媒体流, 或其他这类应用而优化.
意义
我们不解决交换二进制数据,流媒体,或传输大的XML文件的问题不是一件坏事, 因为其他协议和技术已经解决了那些领域. 但是很重要的一点是认识到我们擅长做什么和我们不擅长做什么. 例如, 在Jabber带内27发送base64编码的二进制数据, 流语音或视频, 或一致的大节不是个好主意, 并且那些依赖这类行为的应用被设计得更适合在带外通讯它们的数据.
示例
SI File Transfer 28 是一个好的关于XMPP的优势和弱点的例子, 因为它指定重带宽数据传输首选带外传输.
