XEP-0138

2011年5月18日 (三) 12:36的最后版本

本文的英文原文来自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)支持以下方法：

LZW流压缩 6

实现注意

当使用ZLIB压缩的时候，在当前的发送完成之后，发送方的应用应该(SHOULD)完成ZLIB流部分刷新。注意这些语句有点含糊的：发送方的应用可能在发送每个XML节后刷新流并且发送数据，但是另一方面也可能在发送了等待发送队列里的所有节点后刷新流并且发送数据。何时刷新压缩应用的状态取决于发送方的应用。

安全事项

通过TLS(在RFC3920 RFC 3920中定义)加密的流和压缩流(在本文档定义的)并不是互相排斥的，但是通过TLS加密的流必须(MUST)在流压缩协商之前先协商，这是确保流的安全性。

IANA事项

本文档和互联网端口号授权组织 (IANA) 7没有交互。

XMPP注册事项

流特性

在流特性的注册项中，XMPP注册项 8中包含'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>

附录

附录A:文档信息

系列：XEP

序号：0138

发布者：XMPP标准基金会

状态：终结版

类型：标准跟踪

版本：2.0

最后更新：2009-05-27

批准机构：XMPP理事会

依赖标准：XMPP Core

替代标准：无

被替代标准：无

缩略名：compress

compress名字空间的XML架构: <http://www.xmpp.org/schemas/compress.xsd>

feature名字空间的XML架构: <http://www.xmpp.org/schemas/compress-feature.xsd>

注册表: <http://xmpp.org/registrar/compress.html>

原文控制： HTML RSS

本文的其它格式： XML PDF

附录B:作者信息

Joe Hildebrand

Email: jhildebr@cisco.com

JabberID: hildjj@jabber.org

Peter Saint-Andre

Email: stpeter@jabber.org

JabberID: stpeter@jabber.org

URI: https://stpeter.im/

附录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".

附录G:备注

1. RFC 3920: 可扩展的消息和出席信息协议 (XMPP): Core <http://tools.ietf.org/html/rfc3920>.
2. RFC 4346: TLS协议版本1.1 <http://tools.ietf.org/html/rfc4346>.
3. RFC 3749: TLS协议压缩方法 <http://tools.ietf.org/html/rfc3749>.
4. XEP-0170: 推荐的流特性协商顺序 <http://www.xmpp.org/extensions/xep-0170.html>.
5. RFC 1950: ZLIB压缩数据格式规范版本 3.3 <http://tools.ietf.org/html/rfc1950>.
6. XEP-0229: LZW流压缩 <http://www.xmpp.org/extensions/xep-0229.html>.
7. 互联网编号分配机构(IANA) 是用于互联网协议的唯一性参数值分配的核心协调者, 例如号码和URI计划. 更多信息, 见 <http://www.iana.org/>.
8. XMPP登记员XMPP Registrar 维护着一个保留的协议名字空间以及用于由XMPP标准基金会批准的XMPP扩展协议的上下文参数的注册项的列表. 更多信息, 见 <http://xmpp.org/registrar/>.

附录H:修订历史

注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用

Version 2.0 (2009-05-27)

Per a vote of the XMPP Council, advanced status to Final.

(psa)

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)

结束