mirror of
https://github.com/moparisthebest/xeps
synced 2025-01-30 23:10:10 -05:00
moved disco section
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@832 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
8ca666de61
commit
1574fe49f2
112
xep-0150.xml
112
xep-0150.xml
@ -39,12 +39,12 @@
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2005-05-26</date>
|
||||
<initials>psa</initials>
|
||||
<initials>psa/jjh</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>When an XMPP 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'>
|
||||
@ -56,7 +56,7 @@
|
||||
</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>The basic concept behind XMPP Entity Tag use is semantically equivalent to the use in HTTP (although we use the term "data object" to refer to the payload); 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 object 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 data object, and the responding entity will return either an IQ result with the changed data object or an IQ error indicating that the data object 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'
|
||||
@ -109,61 +109,11 @@
|
||||
</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: The <not-modified/> error condition is not specified as a stanza error condition in &rfc3920; and an error code of 304 was not included in the older Jabber error codes (see &xep0086;). However, the <not-modified/> error condition is included in &rfc3920bis;.</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>
|
||||
@ -239,8 +189,8 @@
|
||||
]]></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>
|
||||
<p>The payloads exchanged in the &xep0016; protocol 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 its privacy lists:</p>
|
||||
<example caption='Client Requests Privacy List'><![CDATA[
|
||||
<iq type='get'
|
||||
from='romeo@montague.net/orchard'
|
||||
@ -334,6 +284,56 @@
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Discovering Support' anchor='disco'>
|
||||
<p><cite>XEP-0131</cite> specifies how support for a particular SHIM header can be explicitly determined using &xep0030;. To review, the protocol flow between a client and a server is 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 as specified herein, 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>
|
||||
</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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user