查看源代码

[[Category:XMPP扩展]]
[[Category:已翻译]]

'''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0138.html XEP-0138]'''

'''XEP-0138: 流压缩'''

本文定义了一个XMPP协议扩展,用于协商XML流的压缩,特别在标准TLS压缩无法协商的情况下. 该协议提供了一个模块化框架,可以容纳广泛的压缩算法; zlib压缩算法是强制性的实施，但实施也可以可能支持额外的其他算法.

注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于部署到生产系统,但是在它成为最终标准之前可能还会有一些变动.

'''文档信息'''

系列: [http://www.xmpp.org/extensions/ XEP] [[XMPP扩展|译文]]

编号: 0138

发行者: [http://www.xmpp.org/xsf/ XMPP标准化基金会] [[XMPP标准基金会|译文]]

状态: 草案

类型: 标准跟踪

版本: 1.3

最后更新日期: 2007-09-26

批准机构: [http://www.xmpp.org/council/ XMPP理事会] [[XMPP理事会|译文]]

依赖于: [[RFC3920|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: [mailto:jhildebrand@jabber.com 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/>

'''法律通告'''

'''版权'''

XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.

'''权限'''

特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。

'''免责声明'''

注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件.在任何情况XMPP标准基金会或作者不对此协议承担任何责任索赔，损害赔偿，或其他责任，无论是在一项行动的合同，侵权，或否则，所产生的，运出，或在他涉嫌与规格或执行，部署或以其它方式使用本协议. ##

'''责任限制'''

在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或同意以书面形式，XMPP标准基金会或任何作者不对本协议承担所造成的损失，包括任何直接，间接，特殊，偶发，或相应的损害赔偿的任何字符利用所产生的或不能使用的规格（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。

'''知识产权的一致性'''

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XSF, P.O. Box 1641, Denver, CO 80201 USA). 

'''讨论地点'''

首选的讨论的地方是标准讨论邮件列表: <http://mail.jabber.org/mailman/listinfo/standards>.

勘误表发送到[mailto:editor@xmpp.org editor@xmpp.org]

'''XMPP 相关信息'''

XMPP 是由XSF(XMPP标准化基金会)按互联网标准程序贡献的,和 IETF的RFC 2026兼容的规范,包括 XMPP核心(RFC 3920)和 XMPP IM(RFC 3921).在本文中定义的任何协议,都是在互联网标准程序之外开发的,是扩展XMPP，而不是改变、发展和修改 XMPP本身。

'''一致性术语'''

本文中以下关键词的含义如 RFC 2119 所述: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

==绪论==

XMPP Core指明了使用TLS(参考RFC2246)加密XML流，TLS包括了压缩加密流量的能力。然而，不是所有计算机平台都实现了TLS，而流压缩可以使基于这些平台的应用实现互通。本文档定义了在TLS之外的协议XML流的压缩算法。

==用例==

协议流如下：

'''例子1. 收到实体提供的流压缩特征'''

<source lang="xml">
<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>
</source>

注意：<compression/>元素必须(MUST)包含至少一个<method/>子元素。每个<method/>必须(MUST)包含指定了压缩方法的XML字符，方法名应该(SHOULD)是在本文档的Compression Methods Registry部分中注册的。

初始实体可能(MAY)在收到的压缩方法中请求一个压缩方法。

'''例子2. 初始实体请求流压缩'''

<source lang="xml">
<ccompress xmlns='http://jabber.org/protocol/compress'>
  <method>zlib</method>
</compress>
</source>

注意：如果初始实体不理解声明的压缩方法，它应该(SHOULD)忽略压缩选项，就像没有发布压缩方法一样处理。

如果接受实体不支持初始实体请求的压缩方法，那么接收者实体必须(MUST)返回一个<unsupported-method/>错误

'''例子3. 接收实体报告该方法不支持。'''

<source lang="xml">
<failure xmlns='http://jabber.org/protocol/compress'>
  <unsupported-method/>
</failure>
</source>

如果接收实体发现请求的方法不能接受或者由于其他原因而不能使用，它必须(MUST)返回一个<setup-failed/>错误：

'''例子4. 接收实体报告流压缩协商失败'''

<source lang="xml">
<failure xmlns='http://jabber.org/protocol/compress'>
  <setup-failed/>
</failure>
</source>

注意：协商失败不应该(SHOULD NOT)被看作不可挽救的错误，因此不应该(SHOULD NOT)导致流错误。特别的，初始实体可以在失败后，重新协商。

如果没有错误，接收实体必须(MUST)通知初始实体协商成功。

'''例子5. 接收实体通知流压缩的协商结果'''

<source lang="xml">
<compressed xmlns='http://jabber.org/protocol/compress'/>
</source>

现在2个实体必须(MUST)都忽略先前的流(未压缩的)，就像TLS协商和SASL协商(在RFC3920指定)一样，必须(MUST)用一个新的(压缩的)流开始通讯。因此初始实体必须(MUST)初始一个新的流给接收实体：

'''例子6. 初始实体初始新的(压缩)流'''

<source lang="xml">
<stream:stream
    xmlns='jabber:client'
    xmlns:stream='http://etherx.jabber.org/streams'
    to='shakespeare.lit'>
</source>

如果在新的(压缩)流发送之后处理失败，发现出错的实体应该(SHOULD)生成出错流并关闭流。

'''例子7. 因为流错误实体关闭流'''

<source lang="xml">
<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>
</source>

==业务规则==

应用以下规则：

如果正在协商流压缩，它必须(MUST)是双向的。

TLS压缩和流压缩不应该(SHOULD NOT)同时使用。

如果TLS(无论该TLS是否包含了TLS压缩功能)和流压缩都使用了，那么TLS必须(MUST)先压缩，然后再进行流压缩协商。

因为流压缩不应该在任何加密层之后完成，SASL协商(参考RFC3920)也可能调用加密层,所以流压缩应该(SHOULD)在SASL验证之后协商。关于流特点的协商顺序细节，参考Recommended Order of Stream Feature Negotiation

==强制实现的技术==

All other methods are OPTIONAL; such methods may be defined in future specifications or by registration as described in the Compression Methods Registry section of this document.

在RFC 1950的中对ZLIB压缩方法的支持是要求的(REQUIRED).

所有其他方法是可选的;这些方法可能将来会进入注册项.

==可选的技术==

除了ZLIB之外，具体的实现也可以(MAY)支持以下方法：

LZW流压缩

==实现注意==

当使用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>：

<source lang="xml">
<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>
</source>

登记者可能同时登记多个压缩方法，每个方法都包含一个独立的<method/>元素。

====注册====

<source lang="xml">
<method>
  <name>zlib</name>
  <desc>the ZLIB compression method</desc>
  <doc>RFC 1950</doc>
</method>
</source>

==XML Schemas==

===流特性===

<source lang="xml">
<?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>
</source>

===协议命名空间===

<source lang="xml">
<?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>
</source>

==备注==

# 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) 

结束