This JEP defines best practices for the use of Entity Tags in XMPP extensions.
WARNING: Consideration of this JEP has been Deferred by the Jabber Software Foundation. Implementation of the protocol described herein is not recommended.
Status: Deferred
Type: Informational
Number: 0150
Version: 0.1
Last Updated: 2005-06-02
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2616, JEP-0131
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/Use of Entity Tags in XMPP Extensions (JEP-0150)>
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
Email:
jhildebrand@jabber.com
JID:
hildjj@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
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.
Such a mechanism exists as part of RFC 2616 [1] in the form of the Entity Tags, which are included in the ETag and If-None-Match headers used for HTTP caching. Since Stanza Headers and Internet Metadata (SHIM) [2] 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 JEP 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).
This JEP addresses the following requirements:
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 RFC 2616.)
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 JEP-0131. 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.
Here is an example of such a request-response flow (the example is that of roster retrieval):
Example 1. Client Requests Roster
<iq type='get'
from='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
</iq>
Example 2. Server Returns Roster Including ETag Header
<iq type='result'
to='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@montague.net' name='Romeo'>
<group>Friends</group>
</item>
<item jid='nurse@capulet.com' name='Nurse'>
<group>Servants</group>
</item>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-long-opaque-string</header>
</headers>
</query>
</iq>
Example 3. Client Requests Roster Including If-None-Match Header
<iq type='get'
from='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='If-None-Match'>some-long-opaque-string</header>
</headers>
</query>
</iq>
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.
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:
Example 4. Responding Entity Returns Not Modified Error
<iq type='error'
to='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='If-None-Match'>some-long-opaque-string</header>
</headers>
</query>
<error code='304' type='modify'>
<not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Note: The <not-modified/> error is not specified as a stanza error in RFC 3920 [3] and an error code of 304 was not included in the older Jabber error codes (see Error Condition Mappings [4]). The authors of this proposal will request that the relevant error condition be added to the successor to RFC 3920 during the process of revising the XMPP specifications within the Internet Standards Process.
Note: In HTTP, an Entity Tag may be either "strong" or "weak" (see Section 13.3.3 of RFC 2616); Entity Tags as used in XMPP extensions MUST be considered strong rather than weak.
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 SOAP over XMPP [5] and in certain applications that use Data Forms [6].
JEP-0131 specifies how support for a particular SHIM header can be determined using Service Discovery [7]. To review, the protocol flow between a client and a server would be as follows:
Example 5. Client Queries Server Regarding SHIM Header Support
<iq from='juliet@capulet.com/balcony'
to='capulet.com'
id='header1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim'/>
</iq>
Example 6. Server Communicates Supported SHIM Headers
<iq from='capulet.com'
to='juliet@capulet.com/balcony'
id='header1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim'>
...
<feature var='http://jabber.org/protocol/shim#ETag'/>
<feature var='http://jabber.org/protocol/shim#If-None-Match'/>
...
</query>
</iq>
The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.
Note: If an XMPP entity supports Entity Tags, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.
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 Multi-User Chat [8] 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.
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":
Example 7. Client Queries Server Regarding Supported Entity Tag Namespaces
<iq from='juliet@capulet.com/balcony'
to='capulet.com'
id='header1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim#ETag'/>
</iq>
Example 8. Server Communicates Supported Entity Tag Namespaces
<iq from='capulet.com'
to='juliet@capulet.com/balcony'
id='header1'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/shim#ETag'>
...
<feature var='jabber:iq:roster'/>
<feature var='jabber:iq:privacy'/>
...
</query>
</iq>
Alternatively, as shown above and as used in HTTP, the requesting entity MAY implicitly discover that Entity Tag functionality is supposed with regard to a given response entity type if the responding entity includes an ETag SHIM header in its response.
As specified in RFC 3921 [9], 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 RFC 3921 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 500 or even 1,000 items). Therefore a server may support Entity Tag functionality with regard to roster management. The process is as follows.
First, the client requests its roster:
Example 9. Client Requests Roster
<iq type='get'
from='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'/>
</iq>
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):
Example 10. Server Returns Roster Including ETag Header
<iq type='result'
to='juliet@capulet.com/balcony'
id='roster1'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@montague.net' name='Romeo'>
<group>Friends</group>
</item>
<item jid='nurse@capulet.com' name='Nurse'>
<group>Servants</group>
</item>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-long-opaque-string</header>
</headers>
</query>
</iq>
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:
Example 11. Client Requests Roster, Including If-None-Match Header
<iq type='get'
from='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='If-None-Match'>some-long-opaque-string</header>
</headers>
</query>
</iq>
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:
Example 12. Server Returns Not Modified Error
<iq type='error'
to='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-long-opaque-string</header>
</headers>
</query>
<error code='304' type='modify'>
<not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
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:
Example 13. Server Returns Roster
<iq type='result'
to='juliet@capulet.com/balcony'
id='roster2'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@montague.net' name='Romeo'>
<group>Friends</group>
</item>
<item jid='nurse@capulet.com' name='Nurse'>
<group>Servants</group>
</item>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-new-opaque-string</header>
</headers>
</query>
</iq>
The payloads exchanged in the privacy list protocol (specified Section 10 of RFC 3921) 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.
First, a client requests a privacy lists:
Example 14. Client Requests Privacy List
<iq type='get'
from='romeo@montague.net/orchard'
id='getlist1'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
</query>
</iq>
The server returns the list and includes an Entity Tag in an ETag SHIM header.
Example 15. Server Returns Privacy List Including ETag Header
<iq type='result'
to='romeo@example.net/orchard'
id='getlist1'>
<query xmlns='jabber:iq:privacy'>
<list name='special'>
<item type='jid'
value='juliet@example.com'
action='allow'
order='6'/>
<item type='jid'
value='benvolio@example.org'
action='allow'
order='7'/>
<item type='jid'
value='mercutio@example.org'
action='allow'
order='42'/>
<item action='deny' order='666'/>
</list>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-long-opaque-string</header>
</headers>
</query>
</iq>
Later, the client requests the same privacy list again and includes the provided Entity Tag in an If-None-Match SHIM header:
Example 16. Client Requests Privacy List Including If-None-Match Header
<iq type='get'
from='romeo@montague.net/orchard'
id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='If-None-Match'>some-long-opaque-string</header>
</headers>
</query>
</iq>
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:
Example 17. Server Returns Not Modified Error
<iq type='error'
to='romeo@example.net/orchard'
id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-long-opaque-string</header>
</headers>
</query>
<error code='304' type='modify'>
<not-modified xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
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:
Example 18. Server Returns Privacy List
<iq type='result'
to='romeo@example.net/orchard'
id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='special'>
<item type='jid'
value='juliet@example.com'
action='allow'
order='6'/>
<item type='jid'
value='benvolio@example.org'
action='allow'
order='7'/>
<item type='jid'
value='mercutio@example.org'
action='allow'
order='42'/>
<item action='deny' order='666'/>
</list>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='ETag'>some-new-opaque-string</header>
</headers>
</query>
</iq>
To follow.
This proposal requires no interaction with the Internet Assigned Numbers Authority (IANA) [10].
This proposal requires no interaction with the Jabber Registrar [11].
This JEP describes best practices for use of JEP-0131 and therefore does not require a dedicated schema.
1. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>.
2. JEP-0131: Stanza Headers and Internet Metadata (SHIM) <http://www.jabber.org/jeps/jep-0131.html>.
3. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
4. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.
5. JEP-0072: SOAP over XMPP <http://www.jabber.org/jeps/jep-0072.html>.
6. JEP-0004: Data Forms <http://www.jabber.org/jeps/jep-0004.html>.
7. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
8. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
9. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
10. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
11. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END