<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'><![CDATA[
<p>Note: The <not-modified/> error is not specified as a stanza error in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). The authors of this proposal will request that the <not-modified/> error condition be added to the successor to <cite>RFC 3920</cite> during the process of revising the XMPP specifications within the Internet Standards Process.</p>
<p>Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of <cite>RFC 2616</cite>); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.</p>
<p>Note: The ETag and If-None-Match headers SHOULD be used only in &IQ; stanzas, although they MAY be used in &MESSAGE; stanza interactions if IQ request-response semantics are not appropriate, for example in &xep0072; and in certain applications that use &xep0004;.</p>
<p><cite>XEP-0131</cite> specifies how support for a particular SHIM header can be determined using &xep0030;. To review, the protocol flow between a client and a server would be as follows:</p>
<p>Note: Even if an entity supports the ETag and If-None-Match SHIM headers, it is not required to support Entity Tag functionality for all namespaces. For example, a server could support Entity Tags only for rosters and privacy lists but not for the 'jabber:iq:last' or 'jabber:iq:version' namespaces. Similarly, a &xep0045; service could support Entity Tags only for room lists (retrieved via a "disco#items" request) but not for other requests. As noted, if an entity does not support Entity Tags for a given namespace or request, it SHOULD proceed as if the ETag or If-None-Match SHIM header had not been included in the request.</p>
<p>Optionally, an entity MAY communicate the namespaces for which it supports Entity Tag functionality by listing those namespaces in its response to a "disco#info" request sent to a node of "http://jabber.org/protocol/shim#ETag":</p>
<examplecaption='Client Queries Server Regarding Supported Entity Tag Namespaces'><![CDATA[
<p>Alternatively, as shown above and as used in HTTP, the requesting entity MAY implicitly discover that Entity Tag functionality is supported with regard to a given response entity type if the responding entity includes an ETag SHIM header in its response.</p>
</section2>
<section2topic='Caching and Retrieving Rosters'anchor='roster'>
<p>As specified in &rfc3921;, an XMPP instant messaging client will typically store its "roster" (contact list) on the server so that any connecting client for that account can retrieve the roster at will. Since <cite>RFC 3921</cite> defines no upper limit on the number of items allowed in the roster, it is possible for a roster to become quite large (e.g., there are known cases of rosters with more than 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.</p>
<p>If the server supports Entity Tag functionality for rosters, it SHOULD include an ETag SHIM header in its response (although it MAY decide not to include the header if the roster is deemed to be not worth caching because it is so small):</p>
<examplecaption='Server Returns Roster Including ETag Header'><![CDATA[
<p>The client would then cache that roster and associate the included Entity Tag with that cached copy. In order to subsequently retrieve the roster, the client would include the last known Entity Tag value with the request in an If-None-Match SHIM header:</p>
<examplecaption='Client Requests Roster, Including If-None-Match Header'><![CDATA[
<p>If the roster did not change since the client last retrieved the roster and the server supports Entity Tags for the 'jabber:iq:roster' namespace, the server MUST return a <not-modified/> error:</p>
<examplecaption='Server Returns Not Modified Error'><![CDATA[
<p>If the roster has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the roster as if the If-None-Match header was not included:</p>
<section2topic='Caching and Retrieving Privacy Lists'anchor='privacy'>
<p>The payloads exchanged in the privacy list protocol (specified Section 10 of <cite>RFC 3921</cite>) can also be quite large. Therefore a server might want to support Entity Tags in the context of privacy list management. The process is as follows.</p>
<p>If the privacy list did not change since the client last retrieved it and the server supports Entity Tags for the 'jabber:iq:privacy' namespace, the server MUST return a <not-modified/> error:</p>
<examplecaption='Server Returns Not Modified Error'><![CDATA[
<p>If the privacy list has changed, the provided Entity Tag value is not valid, or the server does not support Entity Tags, it MUST return the privacy list as if the If-None-Match header was not included:</p>
<p>If a malicious entity gains access to a user's credentials or is able to masquerade as another entity on the network (e.g., as a man in the middle), it could force retrieval of information before it has changed. However, such access would compromise communications in a more serious fashion and corruption of the Entity Tags functionality is insignificant in comparison.</p>