查看源代码
来自Jabber/XMPP中文翻译计划
XEP-0134
的源代码
跳转到:
导航
,
搜索
根据下列原因,你没有权限编辑本页:
您刚才请求的操作只有这个用户组中的用户才能使用:
用户
您可以查看并复制此页面的源代码:
[[Category:XMPP扩展]] [[Category:翻译中]] '''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0134.html XEP-0134] '''XEP-0134: XMPP设计准则''' {| !摘要: |本文定义了Jabber协议和其他扩展的智能设计的最佳实践. |- !作者: |Peter Saint-Andre |- !版权: |© 1999 - 2013 XMPP标准化基金会(XSF). 参见[[XEP-0134#附录C:法律通告|法律通告]]. |- !状态: |活跃 |- !类型: |信息 |- !版本: |1.1 |- !最后更新日期: |2004-12-09 |} ----- 注意: 这个信息规格定义了那些已被XMPP委员会和/或XSF董事会批准的最佳实践或协议范本. 对本协议实现是被鼓励的,最佳实践和协议范本适于部署到生产系统. ----- ==简介== 可扩展的消息和出席信息协议(XMPP)为在XMPP的核心XML流技术上的各种各样的应用提供了一个坚实的, 弹性的基础. 随着[[RFC6120|XMPP Core]] [[XEP-0134#附录G:备注|1]] 和 [[RFC6121|XMPP IM]] [[XEP-0134#附录G:备注|2]] 的升级从而进入互联网标准流程, 对建设基于XMPP的应用和扩展的兴趣更加速了. 不幸的是, 不是每一个希望建设公共或私有XMPP扩展的人都熟悉关键那些原有的Jabber技术开发者提出的设计准则或今天那些指导成功的基于XMPP的协议的设计. 因此尝试把那些由Jabber开发者和协议设计者拥有的经常是隐形的知识翻译成更加显性的策略和原则来让其他人遵守是有益的. (更多互联网协议设计的洞见, 参阅 [http://tools.ietf.org/html/rfc3117 RFC 3117] [[XEP-0134#附录G:备注|3]].) 解释"Jabber方法"的最终结果希望在Jabber/XMPP社区内对好的协议设计实践有一个广泛和深入的理解. ==准则== ===XMPP是神圣的=== ''背景'' 当[http://xmpp.org/xsf/ XMPP标准基金会(XSF)] [[XEP-0134#附录G:备注|4]] 提交 '''XMPP Core''' 和 '''XMPP IM''' 协议给[http://www.ietf.org/ 互联网工程任务组(IETF)] [[XEP-0134#附录G:备注|5]]的时候, 它放弃了在Jabber社区开发的核心XML流技术上变更控制. 无论如何, XSF还是保留了定义XMPP扩展的权力; 此外, 那一权力不仅限于XSF, 因为任何人可以定义他们自己的公共或私有的XMPP扩展. 这些扩展通常使用结构化的XML数据格式,由一个唯一性的不同于当前被IETF或XSF保留的命名空间来限定. ''意义'' 当我们说"XMPP是神圣的", 我们的意思是好的协议设计必须在XMPP的上下文内工作并且不需要修改核心协议. 事实是, 任何这类修改都需要由IETF来执行. 而且, 核心语义几乎提供了一个协议设计者需要的大部分语义. 如果你认为你需要定义一种新的顶级节(不同于 <message/>, <presence/>, 和 <iq/>) 或任何节的一个新的'type'属性值, 那么你需要再想想. 把XMPP视为一个传输层并且在那一层之上建立扩展(也就是说, 这暗示你在工作于高级结构的时候,不能(must not)修改基础, 例如理论上不能添加元素和属性到XMPP schemas,否则应用将忽略它们; 你应该在一个独立的命名空间定义你自有的扩展). 尊重XMPP的另一个含义是任何时候如果可能就使用结构化的数据格式(例如, 应用[http://www.w3.org/TR/REC-xml/ XML 1.0] [[XEP-0134#附录G:备注|6]]而不是二进制或纯文本格式). 最后, 如XMPP Core解释的, <presence/>节仅用于广播网络和通讯可用性; 更多高级的信息发布, 使用[http://xmpp.org/extensions/xep-0060.html Publish-Subscribe] [[XEP-0134#附录G:备注|7]]. ''示例'' 一个好的尊敬XMPP协议的例子是[http://xmpp.org/extensions/xep-0126.html 隐身]] [[XEP-0134#附录G:备注|8]]; 因为Jabber社区在某个时候曾经非正式地定义了<presence type='invisible'/>, 因为XMPP兼容性的原因那个协议被废弃了. 另一个例子是[http://xmpp.org/extensions/xep-0071.html XHTML-IM] [[XEP-0134#附录G:备注|9]], 它重用了[http://www.w3.org/TR/xhtml1 XHTML 1.0] [[XEP-0134#附录G:备注|10]] (分享给XMPP一个通用的XML根的一个结构化格式) 而不是[http://msdn.microsoft.com/library/en-us/dnrtfspec/html/rtfspec.asp 富文本格式(RTF)] [[XEP-0134#附录G:备注|11]] (一个不是源自XML的非结构化的格式). 更进一步的例子是"扩展的出席信息"协议(见[http://xmpp.org/extensions/xep-0119.html 扩展出席信息协议族] [[XEP-0134#附录G:备注|12]]), 它被建立于XEP-0060之上而不是重载<presence/>节. 译者注:XEP-0119已经被作者收回了,可见这也不是一个好的例子。 ===保持简单的客户端=== ===重用现有的协议=== ===模块化更好=== ===认识到你的长处=== ===要明确=== ===保持弹性=== ===隐私和安全问题=== ==安全事项== ==IANA事项== ==XMPP注册处事项==
该页面使用的模板:
模板:XEP附录CDEF
(
查看源代码
) (保护)
返回到
XEP-0134
。
查看
页面
讨论
查看源代码
历史
个人工具
登录/创建账户
导航
首页
社区专页
新闻动态
最近更改
随机页面
帮助
XMPP资源
XMPP公共服务
XMPP客户端软件
XMPP服务器软件
友情链接
搜索
工具箱
链入页面
链出更改
特殊页面