No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0138.xml 14KB

  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>Stream Compression</title>
  10. <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>
  12. <number>0138</number>
  13. <status>Final</status>
  14. <type>Standards Track</type>
  15. <sig>Standards</sig>
  16. <dependencies>
  17. <spec>XMPP Core</spec>
  18. </dependencies>
  19. <supersedes/>
  20. <supersededby/>
  21. <shortname>compress</shortname>
  22. <schemaloc>
  23. <ns>compress</ns>
  24. <url></url>
  25. </schemaloc>
  26. <schemaloc>
  27. <ns>feature</ns>
  28. <url></url>
  29. </schemaloc>
  30. <registry/>
  31. &hildjj;
  32. &stpeter;
  33. <revision>
  34. <version>2.0</version>
  35. <date>2009-05-27</date>
  36. <initials>psa</initials>
  37. <remark><p>Per a vote of the XMPP Council, advanced status to Final.</p></remark>
  38. </revision>
  39. <revision>
  40. <version>1.3</version>
  41. <date>2007-09-26</date>
  42. <initials>psa</initials>
  43. <remark><p>Moved specification of LZW algorithm to XEP-0229.</p></remark>
  44. </revision>
  45. <revision>
  46. <version>1.2</version>
  47. <date>2007-08-22</date>
  48. <initials>psa</initials>
  49. <remark><p>Clarified when compression shall be considered to start; per XEP-0170, specified that compression should be negotiated after SASL.</p></remark>
  50. </revision>
  51. <revision>
  52. <version>1.1</version>
  53. <date>2005-12-14</date>
  54. <initials>psa</initials>
  55. <remark><p>More completely specified error handling; mentioned LZW (DCLZ) method.</p></remark>
  56. </revision>
  57. <revision>
  58. <version>1.0</version>
  59. <date>2005-06-16</date>
  60. <initials>psa</initials>
  61. <remark><p>Per a vote of the Jabber Council, advanced status to Draft.</p></remark>
  62. </revision>
  63. <revision>
  64. <version>0.5</version>
  65. <date>2005-05-18</date>
  66. <initials>psa</initials>
  67. <remark><p>Modifications to address Council feedback: used RFC 3920 terminology; specified error conditions; specified ZLIB as mandatory to implement.</p></remark>
  68. </revision>
  69. <revision>
  70. <version>0.4</version>
  71. <date>2005-05-11</date>
  72. <initials>psa</initials>
  73. <remark><p>Corrected several errors in the schemas.</p></remark>
  74. </revision>
  75. <revision>
  76. <version>0.3</version>
  77. <date>2005-03-28</date>
  78. <initials>psa</initials>
  79. <remark><p>Specified compression methods registry.</p></remark>
  80. </revision>
  81. <revision>
  82. <version>0.2</version>
  83. <date>2004-09-28</date>
  84. <initials>psa</initials>
  85. <remark><p>Fixed TLS text per list discussion.</p></remark>
  86. </revision>
  87. <revision>
  88. <version>0.1</version>
  89. <date>2004-07-16</date>
  90. <initials>jjh/psa</initials>
  91. <remark><p>Initial version.</p></remark>
  92. </revision>
  93. </header>
  94. <section1 topic='Introduction' anchor='intro'>
  95. <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>
  96. </section1>
  97. <section1 topic='Use Case' anchor='usecase'>
  98. <p>The protocol flow is as follows:</p>
  99. <example caption='Receiving Entity Offers Stream Compression Feature'><![CDATA[
  100. <stream:features>
  101. <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
  102. <compression xmlns=''>
  103. <method>zlib</method>
  104. <method>lzw</method>
  105. </compression>
  106. </stream:features>
  107. ]]></example>
  108. <p>Note: The &lt;compression/&gt; element MUST contain at least one &lt;method/&gt; child element. Each &lt;method/&gt; 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 <link url='#registrar-methods'>Compression Methods Registry</link> section of this document. The methods SHOULD be provided in order of preference.</p>
  109. <p>The initiating entity then MAY request compression by specifying one of the methods advertised by the receiving entity:</p>
  110. <example caption='Initiating Entity Requests Stream Compression'><![CDATA[
  111. <compress xmlns=''>
  112. <method>zlib</method>
  113. </compress>
  114. ]]></example>
  115. <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>
  116. <p>If the initiating entity requests a stream compression method that is not supported by the receiving entity, the receiving entity MUST return an &lt;unsupported-method/&gt; error:</p>
  117. <example caption='Receiving Entity Reports That Method is Unsupported'><![CDATA[
  118. <failure xmlns=''>
  119. <unsupported-method/>
  120. </failure>
  121. ]]></example>
  122. <p>If the receiving entity finds the requested method unacceptable or unworkable for any other reason, it MUST return a &lt;setup-failed/&gt; error:</p>
  123. <example caption='Receiving Entity Reports That Negotiation of Stream Compression Failed'><![CDATA[
  124. <failure xmlns=''>
  125. <setup-failed/>
  126. </failure>
  127. ]]></example>
  128. <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>
  129. <p>If no error occurs, the receiving entity MUST inform the initiating entity that compression has been successfully negotiated:</p>
  130. <example caption='Receiving Entity Acknowledges Negotiation of Stream Compression'><![CDATA[
  131. <compressed xmlns=''/>
  132. ]]></example>
  133. <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>
  134. <example caption='Initiating Entity Initiates New (Compressed) Stream'><![CDATA[
  135. <stream:stream
  136. xmlns='jabber:client'
  137. xmlns:stream=''
  138. to='shakespeare.lit'>
  139. ]]></example>
  140. <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>
  141. <example caption='Entity Closes Stream Because of a Processing Error'><![CDATA[
  142. <stream:error>
  143. <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
  144. <failure xmlns=''>
  145. <processing-failed/>
  146. </failure>
  147. </stream:error>
  148. </stream:stream>
  149. ]]></example>
  150. </section1>
  151. <section1 topic='Business Rules' anchor='bizrules'>
  152. <p>The following business rules apply:</p>
  153. <ul>
  154. <li>If stream compression is negotiated, it MUST be used in both directions.</li>
  155. <li>TLS compression and stream compression SHOULD NOT be used simultaneously.</li>
  156. <li>Stream compression MAY be offered after TLS negotiation if TLS compression is not used.</li>
  157. </ul>
  158. <p>For detailed recommendations regarding the order of stream feature negotiation, refer to &xep0170;.</p>
  159. </section1>
  160. <section1 topic='Mandatory-to-Implement Technologies' anchor='mandatory'>
  161. <p>Support for the ZLIB compression method as specified in &rfc1950; is REQUIRED.</p>
  162. <p>All other methods are OPTIONAL; such methods may be defined in future specifications or by registration as described in the <link url='#registrar-methods'>Compression Methods Registry</link> section of this document.</p>
  163. </section1>
  164. <section1 topic='Optional Technologies' anchor='optional'>
  165. <p>Implementations MAY support the following methods in addition to ZLIB:</p>
  166. <ul>
  167. <li>&xep0229;</li>
  168. </ul>
  169. </section1>
  170. <section1 topic='Implementation Notes' anchor='impl'>
  171. <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>
  172. </section1>
  173. <section1 topic='Security Considerations' anchor='security'>
  174. <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>
  175. <p>Many of the security considerations related to TLS compression (see Section 6 of <cite>RFC 3749</cite>) also apply to stream compression.</p>
  176. </section1>
  177. <section1 topic='IANA Considerations' anchor='iana'>
  178. <p>This document requires no interaction with &IANA;. </p>
  179. </section1>
  180. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  181. <section2 topic='Stream Features' anchor='registrar-stream'>
  182. <p>The &REGISTRAR; includes '' in its registry of stream features.</p>
  183. </section2>
  184. <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
  185. <p>The XMPP Registrar includes '' in its registry of protocol namespaces.</p>
  186. </section2>
  187. <section2 topic='Compression Methods Registry' anchor='registrar-methods'>
  188. <p>The XMPP Registrar maintains a registry of compression methods at &COMPRESSMETHODS;.</p>
  189. <section3 topic='Process' anchor='registrar-methods-process'>
  191. <code><![CDATA[
  192. <method>
  193. <name>the XML character data of the method element</name>
  194. <desc>a natural-language description of the compression method</desc>
  195. <doc>the document that specifies or registers the compression method</doc>
  196. </method>
  197. ]]></code>
  198. <p>The registrant may register more than one compression method at a time, each contained in a separate &lt;method/&gt; element.</p>
  199. </section3>
  200. <section3 topic='Registration' anchor='registrar-methods-init'>
  201. <code><![CDATA[
  202. <method>
  203. <name>zlib</name>
  204. <desc>the ZLIB compression method</desc>
  205. <doc>RFC 1950</doc>
  206. </method>
  207. ]]></code>
  208. </section3>
  209. </section2>
  210. </section1>
  211. <section1 topic='XML Schemas' anchor='schemas'>
  212. <section2 topic='Stream Feature' anchor='schemas-stream'>
  213. <code><![CDATA[
  214. <?xml version='1.0' encoding='UTF-8'?>
  215. <xs:schema
  216. xmlns:xs=''
  217. targetNamespace=''
  218. xmlns=''
  219. elementFormDefault='qualified'>
  220. <xs:annotation>
  221. <xs:documentation>
  222. The protocol documented by this schema is defined in
  223. XEP-0138:
  224. </xs:documentation>
  225. </xs:annotation>
  226. <xs:element name='compression'>
  227. <xs:complexType>
  228. <xs:sequence>
  229. <xs:element name='method' type='xs:NCName' maxOccurs='unbounded'/>
  230. </xs:sequence>
  231. </xs:complexType>
  232. </xs:element>
  233. </xs:schema>
  234. ]]></code>
  235. </section2>
  236. <section2 topic='Protocol Namespace' anchor='schemas-protocol'>
  237. <code><![CDATA[
  238. <?xml version='1.0' encoding='UTF-8'?>
  239. <xs:schema
  240. xmlns:xs=''
  241. targetNamespace=''
  242. xmlns=''
  243. elementFormDefault='qualified'>
  244. <xs:annotation>
  245. <xs:documentation>
  246. The protocol documented by this schema is defined in
  247. XEP-0138:
  248. </xs:documentation>
  249. </xs:annotation>
  250. <xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'
  251. schemaLocation=''/>
  252. <xs:element name='compress'>
  253. <xs:complexType>
  254. <xs:sequence>
  255. <xs:element name='method' type='xs:NCName' minOccurs='1' maxOccurs='unbounded'/>
  256. </xs:sequence>
  257. </xs:complexType>
  258. </xs:element>
  259. <xs:element name='compressed' type='empty'/>
  260. <xs:element name='failure'>
  261. <xs:complexType>
  262. <xs:choice>
  263. <xs:element name='setup-failed' type='empty'/>
  264. <xs:element name='processing-failed' type='empty'/>
  265. <xs:element name='unsupported-method' type='empty'/>
  266. <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
  267. <xs:group ref='err:stanzaErrorGroup'/>
  268. <xs:element ref='err:text' minOccurs='0'/>
  269. </xs:sequence>
  270. </xs:choice>
  271. </xs:complexType>
  272. </xs:element>
  273. <xs:simpleType name='empty'>
  274. <xs:restriction base='xs:string'>
  275. <xs:enumeration value=''/>
  276. </xs:restriction>
  277. </xs:simpleType>
  278. </xs:schema>
  279. ]]></code>
  280. </section2>
  281. </section1>
  282. </xep>