moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

2.3pre1 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@505 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-02-09 00:04:34 +00:00
parent ecd0e29c4f
commit bb5d51b855
1 changed files with 25 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
xep-0030.xml
View File

@ -35,6 +35,18 @@
&pgmillard;
&reatmon;
&stpeter;
<revision>
<version>2.3pre1</version>
<date>in progress, last updated 2007-02-08</date>
<initials>psa</initials>
<remark>Added implementation note regarding Entity Capabilities.</remark>
</revision>
<revision>
<version>2.2</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark>Further specified and clarified security considerations relating to server handling of requests sent to bare JIDs.</remark>
</revision>
<revision>
<version>2.2</version>
<date>2006-01-24</date>
@ -271,7 +283,7 @@
</query>
</iq>
]]></example>
<p>If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an &notfound; error, unless doing so would violate the privacy and security considerations specified in <strong>XMPP Core</strong> and &xmppim; or local privacy and security policies (see also the <link url='#security'>Security Considerations</link> of this document):</p>
<p>If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an &notfound; error, unless doing so would violate the privacy and security considerations specified in <cite>XMPP Core</cite> and &xmppim; or local privacy and security policies (see also the <link url='#security'>Security Considerations</link> of this document):</p>
<example caption='Target entity does not exist'><![CDATA[
<iq type='error'
from='plays.shakespeare.lit'
@ -561,7 +573,7 @@
</section2>
<section2 topic='Relationship Between an Entity and its Items' anchor='items-relationship'>
<p>This section explains in greater detail the relationship between an entity and its associated items.</p>
<p>In general, the items returned by an entity in a disco#items result MUST be items over which the entity has some relationship of ownership -- either direct control over the item itself (e.g., <strong>Publish-Subscribe</strong> nodes owned by the entity) or at least the ability to provide or vouch for the item in a canonical way on the Jabber network (e.g., groupchat rooms directly hosted by a multi-user chat service or IRC channels to which a gateway provides access).</p>
<p>In general, the items returned by an entity in a disco#items result MUST be items over which the entity has some relationship of ownership -- either direct control over the item itself (e.g., <cite>Publish-Subscribe</cite> nodes owned by the entity) or at least the ability to provide or vouch for the item in a canonical way on the Jabber network (e.g., groupchat rooms directly hosted by a multi-user chat service or IRC channels to which a gateway provides access).</p>
<p>Such a relationship does not constrain the relationship between the owning entity's address and the address of the associated entity. In particular, any of the following scenarios is perfectly acceptable:</p>
<ol>
<li><p>Upon querying an entity (JID1) for items, one receives a list of items that can be addressed as JIDs; each associated item has its own JID, but no such JID equals JID1.</p></li>
@ -602,7 +614,7 @@
</section1>
<section1 topic='Publishing Available Items' anchor='publish'>
<p>The server handling rules defined in <strong>XMPP IM</strong> require that the server itself reply on behalf of the user if the 'to' attribute of an IQ get or set is of the form &lt;user@host&gt;. This functionality is currently employed so that the user can "publish" information (e.g., vCard information as specified in &xep0054;) in a way that makes it possible for other entities to retrieve that information even if the user is unavailable. The service discovery specification defined herein builds on that notion by enabling a user to publish some of its service discovery information to the server, which shall store that information in persistent storage and return that information when other entities request it from the user's "bare JID" (user@host), either alone or in combination with a particular node.</p>
<p>The server handling rules defined in <cite>XMPP IM</cite> require that the server itself reply on behalf of the user if the 'to' attribute of an IQ get or set is of the form &lt;user@host&gt;. This functionality is currently employed so that the user can "publish" information (e.g., vCard information as specified in &xep0054;) in a way that makes it possible for other entities to retrieve that information even if the user is unavailable. The service discovery specification defined herein builds on that notion by enabling a user to publish some of its service discovery information to the server, which shall store that information in persistent storage and return that information when other entities request it from the user's "bare JID" (user@host), either alone or in combination with a particular node.</p>
<p>Implementations of service discovery that are built into instant messaging servers SHOULD allow users to publish items in this fashion, although they are not required to do so in order to conform to the service discovery specification. In order to discover whether his or her server supports this publish functionality, the user SHOULD send a disco#info request to his or her server:</p>
<example caption="User sends disco#info request to server"><![CDATA[
<iq from='kinglear@shakespeare.lit'
@ -693,8 +705,15 @@
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>In order to retrieve full information about an entity and its associated items, the requesting application needs to "walk the tree" of items. Naturally, this can result in a large number of requests and responses. The requesting application SHOULD NOT send follow-up requests to all items associated with an entity if the list of such items is long (e.g., more than twenty items). Entities that will routinely host a large number of items (e.g., IRC gateways or NNTP services) SHOULD structure nodes into hierarchies and/or provide more robust searching capabilities, for example via &xep0055;; they SHOULD NOT return extremely large result sets via Service Discovery.</p>
<p>This document does not require that a responding entity must return the same results in response to the same request from different requesting entities (e.g., an entity could return a different list of items or features based on the degree to which it trusts the requesting entity, or based on the known capabilities of the requesting entity). However, the responding entity SHOULD return the same &lt;identity/&gt; element (category+type) to all disco#info requests sent to the same JID+node combination.</p>
<section2 topic='Number of Info Requests' anchor='impl-info'>
<p>When the requesting application is a client, it may want to retrieve service discovery information about all of a user's contacts after retrieving the user's roster and receiving presence from contacts in the user's roster (e.g., to show capabilities). Unfortunately, a user's roster can be quite large, resulting in sending a large number of outbound disco#info requests and receiving a large number of inbound disco#info responses upon login. Because this "disco flood" is undesirable for reasons of scalability and bandwidth usage, client applications SHOULD use &xep0115; to determine the capabilities of entities from which they receive presence information and SHOULD NOT send disco#info requests to such entities.</p>
</section2>
<section2 topic='Number of Items Requests' anchor='impl-items'>
<p>In order to retrieve full information about an entity and its associated items, the requesting application needs to "walk the tree" of items. Naturally, this can result in a large number of requests and responses. The requesting application SHOULD NOT send follow-up requests to all items associated with an entity if the list of such items is long (e.g., more than twenty items). Entities that will routinely host a large number of items (e.g., IRC gateways or NNTP services) SHOULD structure nodes into hierarchies and/or provide more robust searching capabilities, for example via &xep0055;; they SHOULD NOT return extremely large result sets via Service Discovery.</p>
</section2>
<section2 topic='Response Consistency' anchor='impl-consistency'>
<p>This document recommends but does not require that a responding entity must return the same results in response to the same request from different requesting entities (e.g., an entity could return a different list of items or features based on the degree to which it trusts the requesting entity, or based on the known capabilities of the requesting entity). However, the responding entity SHOULD return the same &lt;identity/&gt; element (category+type) to all disco#info requests sent to the same JID+node combination.</p>
</section2>
</section1>
<section1 topic='Error Conditions' anchor='errors'>
@ -731,7 +750,7 @@
<td>The target entity does not support this protocol, or the specified target entity does not exist but that fact cannot be divulged because of pricacy and security considerations.</td>
</tr>
</table>
<p>The other error conditions specified in <strong>XMPP Core</strong> MAY be returned as well (&forbidden;, &notallowed;, &notauthorized;, etc.), including application-specific conditions.</p>
<p>The other error conditions specified in <cite>XMPP Core</cite> MAY be returned as well (&forbidden;, &notallowed;, &notauthorized;, etc.), including application-specific conditions.</p>
<p>As noted above, if an entity has no associated items, it MUST return an empty &QUERY; element (rather than an error) in response to a disco#items request.</p>
</section1>