<abstract>This document defines an XMPP protocol extension for negotiating compression of XML streams, especially in situations where standard TLS compression cannot be negotiated. The protocol provides a modular framework that can accommodate a wide range of compression algorithms; the ZLIB compression algorithm is mandatory-to-implement, but implementations may support other algorithms in addition.</abstract>
<remark><p>Clarified when compression shall be considered to start; per XEP-0170, specified that compression should be negotiated after SASL.</p></remark>
<remark><p>Modifications to address Council feedback: used RFC 3920 terminology; specified error conditions; specified ZLIB as mandatory to implement.</p></remark>
<p>&xmppcore; specifies the use of Transport Layer Security (TLS; see &rfc5246;) for encryption of XML streams, and TLS includes the ability to compress encrypted traffic (see &rfc3749;). However, not all computing platforms are able to implement TLS, and traffic compression may be desirable for communication by applications on such computing platforms. This document defines a mechanism for negotiating the compression of XML streams outside the context of TLS.</p>
<p>Note: The <compression/> element MUST contain at least one <method/> child element. Each <method/> element MUST contain XML character data that specifies the name of a compression method, and such method names SHOULD be registered as described in the <linkurl='#registrar-methods'>Compression Methods Registry</link> section of this document. The methods SHOULD be provided in order of preference.</p>
<p>The initiating entity then MAY request compression by specifying one of the methods advertised by the receiving entity:</p>
<p>Note: If the initiating entity did not understand any of the advertised compression methods, it SHOULD ignore the compression option and proceed as if no compression methods were advertised.</p>
<p>If the initiating entity requests a stream compression method that is not supported by the receiving entity, the receiving entity MUST return an <unsupported-method/> error:</p>
<examplecaption='Receiving Entity Reports That Method is Unsupported'><![CDATA[
<p>If the receiving entity finds the requested method unacceptable or unworkable for any other reason, it MUST return a <setup-failed/> error:</p>
<examplecaption='Receiving Entity Reports That Negotiation of Stream Compression Failed'><![CDATA[
<p>Note: Failure of the negotiation SHOULD NOT be treated as an unrecoverable error and therefore SHOULD NOT result in a stream error. In particular, the initiating entity is free to retry the compression negotiation if it fails.</p>
<p>If no error occurs, the receiving entity MUST inform the initiating entity that compression has been successfully negotiated:</p>
<examplecaption='Receiving Entity Acknowledges Negotiation of Stream Compression'><![CDATA[
<p>Both entities MUST now consider the previous (uncompressed) stream to be null and void, just as with TLS negotiation and SASL negotiation (as specified in <cite>RFC 3920</cite>) and MUST begin compressed communications with a new (compressed) stream. Therefore the initiating entity MUST initiate a new stream to the receiving entity:</p>
<examplecaption='Initiating Entity Initiates New (Compressed) Stream'><![CDATA[
<p>If compression processing fails after the new (compressed) stream has been established, the entity that detects the error SHOULD generate a stream error and close the stream:</p>
<examplecaption='Entity Closes Stream Because of a Processing Error'><![CDATA[
<p>Support for the ZLIB compression method as specified in &rfc1950; is REQUIRED.</p>
<p>All other methods are OPTIONAL; such methods may be defined in future specifications or by registration as described in the <linkurl='#registrar-methods'>Compression Methods Registry</link> section of this document.</p>
<p>When using ZLIB for compression, the sending application SHOULD complete a partial flush of ZLIB when its current send is complete. Note that this statement is deliberately somewhat vague: the sending application may end up performing this partial flush after sending every XML stanza, but on the other hand may perform the partial flush only after sending a group of stanzas that have been queued up for delivery. When to flush the state of the compression application is up to the sending application.</p>
<p>Stream encryption via TLS (as defined in <cite>RFC 3920</cite>) and stream compression (as defined herein) are not mutually exclusive, but stream encryption via TLS MUST be negotiated before negotiation of stream compression in order to secure the stream.</p>