XEP-0138
本文的英文原文来自XEP-0138
XEP-0138: 流压缩
摘要: 本文定义了一个XMPP协议扩展,用于协商XML流的压缩,特别在标准TLS压缩无法协商的情况下. 该协议提供了一个模块化框架,可以容纳广泛的压缩算法; ZLIB 压缩算法是强制性的实现,但实现也可以可能支持额外的其他算法.
作者: Joe Hildebrand, Peter Saint-Andre
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.
状态: 最终版
类型: 标准跟踪
版本: 2.0
最后更新日期: 2009-05-27
注意: 这里定义的协议是XMPP标准化基金会的一个最终版,可被认为是一个稳定的技术,供实现和布署.
目录 |
绪论
XMPP Core 1指明了使用TLS(参考RFC 4346 2 )加密XML流,TLS包括了压缩加密流量的能力(参考RFC 3749 3 )。然而,不是所有计算机平台都实现了TLS,而流压缩可以使基于这些平台的应用实现互通。本文档定义了在TLS之外的协议XML流的压缩算法。
用例
协议流如下:
例子1. 收到实体提供的流压缩特征
<stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> <compression xmlns='http://jabber.org/features/compress'> <method>zlib</method> <method>lzw</method> </compression> </stream:features>
注意:<compression/>元素必须(MUST)包含至少一个<method/>子元素。每个<method/>必须(MUST)包含指定了压缩方法的XML字符,方法名应该(SHOULD)是在本文档的 压缩方法注册 中注册的。
初始实体可能(MAY)在收到的压缩方法中请求一个压缩方法。
例子2. 初始实体请求流压缩
<ccompress xmlns='http://jabber.org/protocol/compress'> <method>zlib</method> </compress>
注意:如果初始实体不理解声明的压缩方法,它应该(SHOULD)忽略压缩选项,就像没有发布压缩方法一样处理。
如果接受实体不支持初始实体请求的压缩方法,那么接收者实体必须(MUST)返回一个<unsupported-method/>错误
例子3. 接收实体报告该方法不支持。
<failure xmlns='http://jabber.org/protocol/compress'> <unsupported-method/> </failure>
如果接收实体发现请求的方法不能接受或者由于其他原因而不能使用,它必须(MUST)返回一个<setup-failed/>错误:
例子4. 接收实体报告流压缩协商失败
<failure xmlns='http://jabber.org/protocol/compress'> <setup-failed/> </failure>
注意:协商失败不应该(SHOULD NOT)被看作不可挽救的错误,因此不应该(SHOULD NOT)导致流错误。特别的,初始实体可以在失败后,重新协商。
如果没有错误,接收实体必须(MUST)通知初始实体协商成功。
例子5. 接收实体通知流压缩的协商结果
<compressed xmlns='http://jabber.org/protocol/compress'/>
现在2个实体必须(MUST)都忽略先前的流(未压缩的),就像TLS协商和SASL协商(在RFC3920指定)一样,必须(MUST)用一个新的(压缩的)流开始通讯。因此初始实体必须(MUST)初始一个新的流给接收实体:
例子6. 初始实体初始新的(压缩)流
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='shakespeare.lit'>
如果在新的(压缩)流发送之后处理失败,发现出错的实体应该(SHOULD)生成出错流并关闭流。
例子7. 因为流错误实体关闭流
<stream:error> <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <failure xmlns='http://jabber.org/protocol/compress'/> <processing-failed/> </failure> </stream:error> </stream:stream>
业务规则
应用以下规则:
- 如果正在协商流压缩,它必须(MUST)是双向的。
- TLS压缩和流压缩不应该(SHOULD NOT)同时使用。
- 如果TLS压缩失败了,那么之后可以再进行流压缩协商。
关于流特性协商的顺序的细节,参考 推荐的流特性协商顺序
强制实现的技术
在RFC 1950 5 中对ZLIB压缩方法的支持必需的(REQUIRED).
所有其他方法是可选的;这些方法可能将来会进入本文的 压缩方法注册章节所述的注册项.
可选的技术
除了ZLIB之外,具体的实现也可以(MAY)支持以下方法:
实现注意
当使用ZLIB压缩的时候,在当前的发送完成之后,发送方的应用应该(SHOULD)完成ZLIB流部分刷新。注意这些语句有点含糊的:发送方的应用可能在发送每个XML节后刷新流并且发送数据,但是另一方面也可能在发送了等待发送队列里的所有节点后刷新流并且发送数据。何时刷新压缩应用的状态取决于发送方的应用。
安全事项
通过TLS(在RFC3920中定义)加密的流和压缩流(在本文档定义的)并不是互相排斥的,但是通过TLS加密的流必须(MUST)在流压缩协商之前先协商,这是确保流的安全性。
IANA事项
本文档和Internet Assigned Numbers Authority (IANA) [7]没有交互。
XMPP注册事项
流特性
在流特性的注册项中,XMPP注册项中包含'http://jabber.org/features/compress'
协议命名空间
在协议命名空间的注册项中,XMPP注册项中包含'http://jabber.org/protocol/compress'
压缩方法注册
在<http://www.xmpp.org/registrar/compress.html>中,XMPP注册项维护了压缩方法的注册。
过程
为了提交新的注册项到注册登记处,登记者必须根据以下表单将其包含在相关的扩展协议中或者发送邮件到<registrar@xmpp.org>:
<method> <name>the XML character data of the method element</name> <desc>a natural-language description of the compression method</desc> <doc>the document that specifies or registers the compression method</doc> </method>
登记者可能同时登记多个压缩方法,每个方法都包含一个独立的<method/>元素。
注册
<method> <name>zlib</name> <desc>the ZLIB compression method</desc> <doc>RFC 1950</doc> </method>
XML Schemas
流特性
<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='http://jabber.org/features/compress' xmlns='http://jabber.org/features/compress' elementFormDefault='qualified'> <xs:annotation> <xs:documentation> The protocol documented by this schema is defined in XEP-0138: http://www.xmpp.org/extensions/xep-0138.html </xs:documentation> </xs:annotation> <xs:element name='compression'> <xs:complexType> <xs:sequence> <xs:element name='method' type='xs:NCName' maxOccurs='unbounded'/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
协议命名空间
<?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='http://jabber.org/protocol/compress' xmlns='http://jabber.org/protocol/compress' elementFormDefault='qualified'> <xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/> <xs:annotation> <xs:documentation> The protocol documented by this schema is defined in XEP-0138: http://www.xmpp.org/extensions/xep-0138.html </xs:documentation> </xs:annotation> <xs:element name='compress'> <xs:complexType> <xs:sequence> <xs:element name='method' type='xs:NCName' minOccurs='1' maxOccurs='unbounded'/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name='compressed' type='empty'/> <xs:element name='failure'> <xs:complexType> <xs:choice> <xs:element name='setup-failed' type='empty'/> <xs:element name='processing-failed' type='empty'/> <xs:element name='unsupported-method' type='empty'/> <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'> <xs:group ref='err:stanzaErrorGroup'/> <xs:element ref='err:text' minOccurs='0'/> </xs:sequence> </xs:choice> </xs:complexType> </xs:element> <xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType> </xs:schema>
备注
- RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.
- RFC 2246: The TLS Protocol Version 1.0 <http://tools.ietf.org/html/rfc2246>.
- RFC 3749: Transport Layer Security Protocol Compression Methods <http://tools.ietf.org/html/rfc3749>.
- XEP-0170: Recommended Order of Stream Feature Negotiation <http://www.xmpp.org/extensions/xep-0170.html>.
- RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://tools.ietf.org/html/rfc1950>.
- XEP-0229: Stream Compression with LZW <http://www.xmpp.org/extensions/xep-0229.html>.
- The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
- The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.
修订历史
Version 1.3 (2007-09-26)
Moved specification of LZW algorithm to XEP-0229.
(psa)
Version 1.2 (2007-08-22)
Clarified when compression shall be considered to start; per XEP-0170, specified that compression should be negotiated after SASL.
(psa)
Version 1.1 (2005-12-14)
More completely specified error handling; mentioned LZW (DCLZ) method.
(psa)
Version 1.0 (2005-06-16)
Per a vote of the Jabber Council, advanced status to Draft.
(psa)
Version 0.5 (2005-05-18)
Modifications to address Council feedback: used RFC 3920 terminology; specified error conditions; specified ZLIB as mandatory to implement.
(psa)
Version 0.4 (2005-05-11)
Corrected several errors in the schemas.
(psa)
Version 0.3 (2005-03-28)
Specified compression methods registry.
(psa)
Version 0.2 (2004-09-28)
Fixed TLS text per list discussion.
(psa)
Version 0.1 (2004-07-16)
Initial version.
(jjh/psa)
结束
文档信息
编号: 0138
发行者: XMPP标准化基金会 译文
状态: 草案
类型: 标准跟踪
版本: 1.3
最后更新日期: 2007-09-26
依赖于: XMPP Core
上文: 无
下文: 无
简称: compress
compress命名空间的XML方案: <http://www.xmpp.org/schemas/compress.xsd>
feature命名空间的XML方案:<http://www.xmpp.org/schemas/compress-feature.xsd>
Wiki页: <http://wiki.jabber.org/index.php/Stream Compression (XEP-0138)>
作者信息
Joe Hildebrand
- Email: jhildebrand@jabber.com
- JabberID: [xmpp:hildjj@jabber.org hildjj@jabber.org]
Peter Saint-Andre
- JID: [xmpp:stpeter@jabber.org stpeter@jabber.org]
- URI: <https://stpeter.im/>