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

1.0 ACTIVE

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@308 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-04 16:07:21 +00:00
parent b4931fb363
commit 82948a0927
2 changed files with 18 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0170.xml
View File

@ -10,7 +10,7 @@
<abstract>This document specifies a recommended order for negotiation of XMPP stream features.</abstract>
&LEGALNOTICE;
<number>0170</number>
<status>Proposed</status>
<status>Active</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<approver>Council</approver>
@ -24,6 +24,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.0</version>
<date>2007-01-04</date>
<initials>psa</initials>
<remark>Per a vote of the XMPP Council, advanced status to Active.</remark>
</revision>
<revision>
<version>0.5</version>
<date>2006-12-06</date>
@ -71,18 +77,16 @@
<li>TLS</li>
<li>SASL</li>
<li>Resource binding</li>
<li>IM session establishment</li>
</ol>
<p>That order MUST be followed if no other stream features are negotiated.</p>
</section2>
<section2 topic='Stream Compression' anchor='c2s-compress'>
<p>&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<ol>
<li>TLS</li>
<li>SASL</li>
<li>Stream compression</li>
<li>Resource binding</li>
<li>IM session establishment</li>
</ol>
</section2>
<section2 topic='In-Band Registration' anchor='c2s-register'>
@ -92,7 +96,6 @@
<li>In-band registration</li>
<li>SASL</li>
<li>Resource binding</li>
<li>IM session establishment</li>
</ol>
<p>If both stream compression and in-band registration are negotiated, the following order is RECOMMENDED:</p>
<ol>
@ -101,7 +104,6 @@
<li>SASL</li>
<li>Stream compression</li>
<li>Resource binding</li>
<li>IM session establishment</li>
</ol>
</section2>
</section1>
@ -123,7 +125,7 @@
</ol>
</section2>
<section2 topic='Stream Compression' anchor='s2s-compress'>
<p>&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
<ol>
<li>TLS</li>
<li>SASL</li>

12
xep-0190.xml
View File

@ -7,10 +7,10 @@
<xep>
<header>
<title>Best Practice for Closing Idle Streams</title>
<abstract>This document specifies a best practice for closing an idle XMPP stream.</abstract>
<abstract>This document specifies a best practice for closing an XML stream that is perceived to be idle.</abstract>
&LEGALNOTICE;
<number>0190</number>
<status>Proposed</status>
<status>Active</status>
<type>Informational</type>
<jig>Standards JIG</jig>
<dependencies>
@ -25,6 +25,12 @@
<email>lynX@jabber.getting.psyced.org</email>
<jid>lynX@ve.symlynX.com</jid>
</author>
<revision>
<version>1.0</version>
<date>2007-01-04</date>
<initials>psa</initials>
<remark>Per a vote of the XMPP Council, advanced status to Active.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-07-26</date>
@ -47,7 +53,7 @@
<section1 topic='Introduction' anchor='intro'>
&RFC3920BISNOTE;
<p><cite>RFC 3920</cite> describes several ways to terminate an XMPP stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.</p>
<p><cite>RFC 3920</cite> describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.</p>
<p>Note: The recommendation described herein has been incorporated into <cite>rfc3920bis</cite>.</p>
</section1>