moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

deleted the commented sections, clarified one bullet point, pointed to RFC 3749 from security considerations

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-05-22 14:36:22 -06:00
parent e696a6d10e
commit 08701ceaa1
1 changed files with 2 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
xep-0138.xml Normal file → Executable file
View File

@ -151,52 +151,12 @@
]]></example> ]]></example>
</section1> </section1>
<!--
<section1 topic='Feature Negotiation (Optional)' anchor='negotiation'>
<p>The initiating entity and receiving entity MAY support &xep0020; for more fine-grained negotiation of parameters (such as compression levels). Such support is OPTIONAL, and the initiating entity should expect that the receiving entity may not support feature negotiation. Because use of &xep0030; to discover negotiable features is inconvenient during stream negotiation, the initiating entity SHOULD negotiate only features that are registered for use with the 'http://jabber.org/protocol/compress' FORM_TYPE as described in the <link url="#registrar-formtype">Field Standardization</link> section of this document.</p>
<p>The initiating entity MAY include a feature negotiation child within the initial &lt;compress/&gt; element requesting stream compression:</p>
<example caption='Initiating Entity Requests Stream Compression (With Feature Negotiation)'><![CDATA[
<compress xmlns='http://jabber.org/protocol/compress'>
<method>foobar</method>
<feature xmlns='http://jabber.org/protocol/feature-neg'>
<x xmlns='jabber:x:data' type='submit'>
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/compress/method/foobar</value>
</field>
<field var='foobar-compression-level'>
<value>3</value>
</field>
</x>
</feature>
</compress>
]]></example>
<p>If the receiving entity does not support the use of feature negotiation within stream compression, it MUST ignore the &lt;feature/&gt; element.</p>
<p>If the receiving entity does not support one or more of the included features, it MUST return a &lt;failure/&gt; containing an XMPP &feature; error and SHOULD specify the feature(s) not implemented in an XMPP &lt;text/&gt; element.</p>
<example caption="Receiving entity does not support a feature"><![CDATA[
<compress xmlns='http://jabber.org/protocol/compress'>
<failure>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>foobar-compression-level</text>
</failure>
</compress>
]]></example>
<p>If the receiving entity supports none of the included options for a certain feature, it MUST return a &lt;failure/&gt; containing an XMPP &notacceptable; error and SHOULD specify the option(s) not supported in an XMPP &lt;text/&gt; element.</p>
<example caption="Receiving entity does not support an option"><![CDATA[
<compress xmlns='http://jabber.org/protocol/compress'>
<failure>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>foobar-compression-level: 3</text>
</compress>
]]></example>
</section1>
-->
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
<p>The following business rules apply:</p> <p>The following business rules apply:</p>
<ul> <ul>
<li>If stream compression is negotiated, it MUST be used in both directions.</li> <li>If stream compression is negotiated, it MUST be used in both directions.</li>
<li>TLS compression and stream compression SHOULD NOT be used simultaneously.</li> <li>TLS compression and stream compression SHOULD NOT be used simultaneously.</li>
<li>Stream compression MAY be offered after TLS negotiation if TLS compression fails.</li> <li>Stream compression MAY be offered after TLS negotiation if TLS compression is not used.</li>
</ul> </ul>
<p>For detailed recommendations regarding the order of stream feature negotiation, refer to &xep0170;.</p> <p>For detailed recommendations regarding the order of stream feature negotiation, refer to &xep0170;.</p>
</section1> </section1>
@ -219,6 +179,7 @@
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<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> <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>
<p>Many of the security considerations related to TLS compression (see Section 6 of <cite>RFC 3749</cite>) also apply to stream compression.</p>
</section1> </section1>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>
@ -255,11 +216,6 @@
]]></code> ]]></code>
</section3> </section3>
</section2> </section2>
<!--
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Reserved fields shall be registered with the XMPP Registrar as necessary.</p>
</section2>
-->
</section1> </section1>
<section1 topic='XML Schemas' anchor='schemas'> <section1 topic='XML Schemas' anchor='schemas'>