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.)
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.
+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 <http://mail.jabber.org/pipermail/standards/2008-February/017966.html>..
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.
If an XMPP server supports pipelining, then it MUST advertise a stream feature of <pipelining xmlns='urn:xmpp:pipelining:0'/>.
If both parties support pipelining, they can proceed as follows (the examples use the XML from the client-server stream establishment section of RFC 6120, although the same principles apply to server-to-server streams).