XEP-0134
(→XMPP注册处事项) |
(→XMPP注册处事项) |
||
| 第166行： | 第166行： | ||
本文和不需要和XMPP注册处交互. | 本文和不需要和XMPP注册处交互. | ||
| + | |||
| + | ==附录== | ||
| + | ===附录A:文档信息=== | ||
| + | ===附录B:作者信息=== | ||
| + | {{Template:XEP附录CDEF}} | ||
| + | ===附录G:备注=== | ||
| + | ===附录H:修订历史=== | ||
2013年3月28日 (四) 01:41的版本
本文的英文原文来自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的优势和弱点的例子, 因为它指定重带宽数据传输首选带外传输.
要明确
背景
首先是代码(主要是jabberd 29). 尽管代码有它自己的方式明确, 不是每个人能读代码, 而且为了在不同的代码库中达到功能性的重用，详细的规格是必要的. Jabber社区已经艰难地学习了那一课.
意义
详细的, 明确的规格是好的规格. 定义你的术语. 使用一致性术语，类似MUST和SHOULD而不是松散的英语单词，类似"does"和"will". 遵守Follow the Guidelines for Authors of XMPP Extension Protocols 30. 定义错误条件. 包含很多示例. 通过在XML Schema Part 1 31 和 XML Schema Part 2 32 中定义的schemas和datatypes约束允许的XML.
示例
XMPP Core 和 XMPP IM 是大的文档，以痛苦的细节定义了可扩展的消息和出席信息协议. 尽管这些规格写起来不好玩, 它们为好的协议设计和文档提供了一个模式.
保持弹性
背景
明确定义的需要和弹性的需要之间必须取得平衡. 一个完全严格的协议可能在压力之下或当条件改变时被打破, 反之一个更具弹性的协议可能弯曲和适应. 对于好的协议设计来说关键是了解什么时候该明确什么时候该弹性.
意义
通常, 一个协议需要定义功能性的梗概, 但是不必要定义一个特定领域使用的参数或值. 为了允许成长和变更, 定义 XMPP Registrar 33 将会保持对特定参数和值的跟踪, 它比明确地在协议本身限定它们更加合理.
示例
因为旧的Agent Information 34和Jabber Browsing 35协议中的实体类型和种类被定义成确定的固定值, Service Discovery 把那个公呢功能放到 XMPP Registrar 了. 类似的, Stream Initiation 36 为它的范本定义了一个注册项, Advanced Message Processing 37 为处理条件和动作定义了注册项, 并且很多XMPP扩展协议注册了 FORM_TYPE 值，如 Field Standardization for Data Forms 38里定义的那样.
隐私和安全问题
背景
从一开始, Jabber社区中隐私和安全性就是重要的. 这不需要改变.
意义
好的协议尊重由用户和应用通讯或生成的数据的机密性，一如尊重系统或网络整体的安全性事项已经在核心XMPP层处理了, 应用级的协议不能(must not)在隐私和安全性上妥帖. 注意这些事项, 随着由协议设计者所做的严格的跨区域审查和关闭审查(以XMPP Council 39 和 Standards SIG 40的形式), 将帮助确保我们开发的协议会在互联网上为通讯提供一个坚实的基础.
示例
大家知道, 由Jabber社区开发的 XMPP IM 定义的出席信息订阅模式在联系人能查看一个用户的出席信息之前要求批准. 类似的, Jabber总是包含强的验证方法, 这个验证方法通过使用 SASL (RFC 4422 41)得到了很大的提升.
安全事项
没有直接和本提议相关的安全特性, 本协议只是一些信息. 无论如何, 以上讨论的, 遵循这些准则开发的协议应该适当地定义隐私和安全事项. 和互联网设计相关的安全性的帮助文档参见RFC 3552 42.
IANA事项
本文档与互联网编号分配授权机构(IANA) 43无关
XMPP注册处事项
本文和不需要和XMPP注册处交互.
附录
附录A:文档信息
附录B:作者信息
附录C:法律通告
版权
XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.
权限
特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。
免责声明'
## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##
责任限制
在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。
知识产权的一致性
XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).
附录D:和XMPP的关系
可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.
附录E:讨论地点
主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.
在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .
勘误表可以发送邮件到 <editor@xmpp.org>.
附录F:需求一致性
以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
