<p>When a Jabber instant messaging client connects to its server, it typically retrieves a great deal of information, such as a user's roster, privacy lists, and service discovery information. However, this information may not have changed since the client last retrieved the data. In order to improve client start-up time or conserve bandwidth in certain environments, it would be desirable if the client could cache the information and retrieve it only if it has changed.</p>
<p>Such a mechanism exists as part of &rfc2616; in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since &xep0131; enables an XMPP entity to communicate any HTTP header, it should be possible to re-use existing Entity Tag semantics for caching information sent over an XMPP network. This document defines best practices for such functionality, which could be used between any two XMPP entities that support SHIM headers (though it is envisioned to be most useful for clients that retrieve information from servers and services).</p>
<li>Enable caching of information sent over an XMPP network (i.e., retrieval of information only if it has changed since it was last retrieved).</li>
<li>Re-use existing HTTP Entity Tag semantics.</li>
</ol>
</section1>
<section1topic='Concepts and Approach'anchor='approach'>
<p>In HTTP, an "entity" is the information transferred as the payload of a request or response, and an "Entity Tag" is an opaque string that uniquely identifies that payload. For example, when an HTTP server sends an entity in an HTTP response, it can include an ETag header that identifies the payload as cacheable, and the client can cache that entity; in future requests, the client can include the same value in an If-None-Match header and the server will either return an HTTP 304 ("Not Modified") error if the entity has not changed or return the entity in the HTTP response if it has changed. (Note: For information about the semantics of Entity Tags, the ETag header, and the If-None-Match header, refer to Sections 3.11, 14.19, and 14.26 respectively of <cite>RFC 2616</cite>.)</p>
<p>Similarly, the basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP; this is made possible by a straightforward application of SHIM headers as specified in <cite>XEP-0131</cite>. In the context of an IQ request-response interaction, the responding entity will include an ETag SHIM header in its IQ response (indicating that the data can be cached), the requesting entity will include that identical value in an If-None-Match SHIM header when it queries the server for the same entity, and the responding entity will return either an IQ result with the changed entity or an IQ error indicating that the entity has not changed.</p>
<p>If the responding entity does not understand the If-None-Match header or does not handle Entity Tags for the namespace in the request, it MUST ignore the header and return whatever information it would have returned if the header had not been present.</p>
<p>If the responding entity determines that the requested information has not changed since it was last retrieved by the requesting entity, then it MUST return a <not-modified/> error corresponding to the HTTP 304 error returned by HTTP entities that support the ETag header:</p>
<examplecaption='Responding Entity Returns Not Modified Error'><