moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

no Council objections to publication

This commit is contained in:
stpeter 2011-08-25 16:43:23 -06:00
parent 3be586beb3
commit 26ce4b9a2d
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
inbox/quickstart.xml → xep-0305.xml
View File

@ -39,7 +39,7 @@
<p>XMPP clients SHOULD also cache whatever information they can, especially the roster (see &xep0237;) and &xep0030; information. Servers SHOULD support &xep0237; and SHOULD include &xep0115; data in stream features to facilitate such caching. (Caching of service discovery data also applies to server-to-server connections.)</p> <p>XMPP clients SHOULD also cache whatever information they can, especially the roster (see &xep0237;) and &xep0030; information. Servers SHOULD support &xep0237; and SHOULD include &xep0115; data in stream features to facilitate such caching. (Caching of service discovery data also applies to server-to-server connections.)</p>
</section1> </section1>
<section1 topic='Pipelining' anchor='pipelining'> <section1 topic='Pipelining' anchor='pipelining'>
<p>One method of speeding the connection process is pipelining of requests, as in the QUICKSTART extension proposed for SMTP &smtpquickstart;. The application of similar principles to XMPP was originally suggested by Tony Finch.</p> <p>One method of speeding the connection process is pipelining of requests, as in &rfc2920; and the QUICKSTART extension proposed for SMTP &smtpquickstart;. The application of similar principles to XMPP was originally suggested by Tony Finch in February 2008 &lt;<link url='http://mail.jabber.org/pipermail/standards/2008-February/017966.html'>http://mail.jabber.org/pipermail/standards/2008-February/017966.html</link>&gt;..</p>
<p>In essence, pipelining lets an initiating entity assume that the receiving entity supports the same (or almost the same) features it did on the previous connection attempt. As a result, the initiating entity can proactively send multiple XMPP-related "commands" in a single TCP packet, thus reducing the number of round trips.</p> <p>In essence, pipelining lets an initiating entity assume that the receiving entity supports the same (or almost the same) features it did on the previous connection attempt. As a result, the initiating entity can proactively send multiple XMPP-related "commands" in a single TCP packet, thus reducing the number of round trips.</p>
<p>If an XMPP server supports pipelining, then it MUST advertise a stream feature of &lt;pipelining xmlns='urn:xmpp:pipelining:0'/&gt;.</p> <p>If an XMPP server supports pipelining, then it MUST advertise a stream feature of &lt;pipelining xmlns='urn:xmpp:pipelining:0'/&gt;.</p>
<p>If both parties support pipelining, they can proceed as follows (the examples use the XML from the client-server stream establishment section of <cite>RFC 6120</cite>, although the same principles apply to server-to-server streams).</p> <p>If both parties support pipelining, they can proceed as follows (the examples use the XML from the client-server stream establishment section of <cite>RFC 6120</cite>, although the same principles apply to server-to-server streams).</p>