mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
de16d33554
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@47 4b5297f7-1745-476d-ba37-a9c6900126ab
354 lines
18 KiB
XML
354 lines
18 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Use of Entity Tags in XMPP Extensions</title>
|
|
<abstract>This document defines best practices for the use of Entity Tags in XMPP extensions.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0150</number>
|
|
<status>Experimental</status>
|
|
<type>Informational</type>
|
|
<jig>Standards JIG</jig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>RFC 2616</spec>
|
|
<spec>XEP-0131</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>N/A</shortname>
|
|
&hildjj;
|
|
&stpeter;
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2005-08-09</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Added security considerations.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2005-06-02</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Initial version.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2005-05-26</date>
|
|
<initials>psa</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<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>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p>This document addresses the following requirements:</p>
|
|
<ol>
|
|
<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>
|
|
<section1 topic='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>Here is an example of such a request-response flow (the example is that of roster retrieval):</p>
|
|
<example caption='Client Requests Roster'><![CDATA[
|
|
<iq type='get'
|
|
from='juliet@capulet.com/balcony'
|
|
id='roster1'>
|
|
<query xmlns='jabber:iq:roster'/>
|
|
</iq>
|
|
]]></example>
|
|
<example caption='Server Returns Roster Including ETag Header'><![CDATA[
|
|
<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>
|
|
<example caption='Client Requests Roster Including If-None-Match Header'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
<example caption='Responding Entity Returns Not Modified Error'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<section2 topic='Discovering Support' anchor='support'>
|
|
<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>
|
|
<example caption='Client Queries Server Regarding SHIM Header Support'><![CDATA[
|
|
<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>
|
|
<example caption='Server Communicates Supported SHIM Headers'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<p>The client now knows that the server supports the ETag and If-None-Match SHIM headers and can proceed accordingly.</p>
|
|
<p>Note: If an XMPP entity supports Entity Tags, it MUST at a minimum support both the ETag and If-None-Match SHIM headers.</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>
|
|
<example caption='Client Queries Server Regarding Supported Entity Tag Namespaces'><![CDATA[
|
|
<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>
|
|
<example caption='Server Communicates Supported Entity Tag Namespaces'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
<section2 topic='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>First, the client requests its roster:</p>
|
|
<example caption='Client Requests Roster'><![CDATA[
|
|
<iq type='get'
|
|
from='juliet@capulet.com/balcony'
|
|
id='roster1'>
|
|
<query xmlns='jabber:iq:roster'/>
|
|
</iq>
|
|
]]></example>
|
|
<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>
|
|
<example caption='Server Returns Roster Including ETag Header'><![CDATA[
|
|
<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>
|
|
<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>
|
|
<example caption='Client Requests Roster, Including If-None-Match Header'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
<example caption='Server Returns Not Modified Error'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
<example caption='Server Returns Roster'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic='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>First, a client requests a privacy lists:</p>
|
|
<example caption='Client Requests Privacy List'><![CDATA[
|
|
<iq type='get'
|
|
from='romeo@montague.net/orchard'
|
|
id='getlist1'>
|
|
<query xmlns='jabber:iq:privacy'>
|
|
<list name='special'/>
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
<p>The server returns the list and includes an Entity Tag in an ETag SHIM header.</p>
|
|
<example caption='Server Returns Privacy List Including ETag Header'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<p>Later, the client requests the same privacy list again and includes the provided Entity Tag in an If-None-Match SHIM header:</p>
|
|
<example caption='Client Requests Privacy List Including If-None-Match Header'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
<example caption='Server Returns Not Modified Error'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<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>
|
|
<example caption='Server Returns Privacy List'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<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>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This proposal requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>This proposal requires no interaction with the ®ISTRAR;.</p>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<p>This document describes best practices for use of XEP-0131 and therefore does not require a dedicated schema.</p>
|
|
</section1>
|
|
<section1 topic='Open Issues' anchor='issues'>
|
|
<p>Is the ETag tied to a bare JID or full JID?</p>
|
|
</section1>
|
|
</xep>
|