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

2.4pre1 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1814 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-04-28 22:32:45 +00:00
parent 0e4da267b3
commit 6594b9a72c
1 changed files with 7 additions and 113 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
xep-0030.xml
View File

@ -35,6 +35,12 @@
&pgmillard;
&reatmon;
&stpeter;
<revision>
<version>2.4pre1</version>
<date>in progress, last updated 2008-04-28</date>
<initials>psa</initials>
<remark><p>Removed disco-publish feature (implementations should use publish-subscribe instead).</p></remark>
</revision>
<revision>
<version>2.3</version>
<date>2007-02-15</date>
@ -609,94 +615,7 @@
</section1>
<section1 topic='Publishing Available Items' anchor='publish'>
<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/throne'
id='pubinfo'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<p>If the server supports service discovery publishing and the server wishes to disclose that fact to the user, it MUST include a feature of 'http://jabber.org/protocol/disco#publish' in its response.</p>
<example caption="Server responds with identity and feature information"><![CDATA[
<iq from='shakespeare.lit'
id='pubinfo'
to='kinglear@shakespeare.lit/throne'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='server' type='im'/>
...
<feature var='http://jabber.org/protocol/disco#publish'/>
...
</query>
</iq>
]]></example>
<p>In order to publish items, an entity uses an IQ-set transaction to its server, which is responsible for responding to requests on behalf of that entity. Each &lt;item/&gt; child element of the parent query MUST possess the following attributes:</p>
<ul>
<li><strong>action</strong> -- specifies the action to be taken for the item</li>
<li><strong>jid</strong> -- specifies the Jabber ID of the item "owner" or location</li>
</ul>
<p>The &lt;item/&gt; element MAY also possess the following attributes:</p>
<ul>
<li><strong>name</strong> -- specifies a natural-language name for the item.</li>
<li><strong>node</strong> -- specifies the particular node associated with the JID of the item "owner" or location</li>
</ul>
<p>The allowable values for the 'action' attribute are "update" and "remove"). If the action is "update", the server MUST either create a new entry (if the node and jid combination does not already exist) or overwrite an existing entry. If the action is "remove", the item MUST be removed from persistent storage.</p>
<p>The following example shows a user publishing a list of his biological children to a well-known (but fictitious) service discovery node.</p>
<example caption='Publishing items'><![CDATA[
<iq from='kinglear@shakespeare.lit/throne'
id='publish1'
type='set'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='jabber:iq:kids'>
<item action='update'
jid='cordelia@shakespeare.lit'
name='Cordelia'/>
<item action='update'
jid='goneril@shakespeare.lit'
name='Goneril'/>
<item action='update'
jid='regan@shakespeare.lit'
name='Regan'/>
</query>
</iq>
]]></example>
<example caption="Server responds with success"><![CDATA[
<iq id='publish1'
to='kinglear@shakespeare.lit/throne'
type='result'/>
]]></example>
<p>Subsequent queries to "jid='kinglear@shakespeare.lit'" and "node='jabber:iq:kids'" will yield the list shown above (absent the 'action' attributes).</p>
<p>If the server or service does not support persistent storage, it MUST respond to IQ-set requests with a &feature; error.</p>
<example caption='Persistent storage is not available'><![CDATA[
<iq id='publish1'
to='kinglear@shakespeare.lit/throne'
type='error'>
<query xmlns='http://jabber.org/protocol/disco#items'
node='jabber:iq:kids'>
<item action='update'
jid='cordelia@shakespeare.lit'
name='Cordelia'/>
<item action='update'
jid='goneril@shakespeare.lit'
name='Goneril'/>
<item action='update'
jid='regan@shakespeare.lit'
name='Regan'/>
</query>
<error code='501' type='cancel'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>This feature has been removed in favor of the XMPP publish-subscribe technology defined in <cite>XEP-0060</cite>.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
@ -732,10 +651,6 @@
<th>Condition</th>
<th>Cause</th>
</tr>
<tr>
<td>&feature;</td>
<td>The sender has attempted to publish items but the server does not support the <link url="#publish">Publishing Available Items</link> feature.</td>
</tr>
<tr>
<td>&notfound;</td>
<td>The JID or JID+NodeID of the specified target entity does not exist and that fact can be divulged in accordance with privacy and security considerations and policies.</td>
@ -835,15 +750,6 @@
</feature>]]></code>
<p>The registrant may register more than one feature at a time, each contained in a separate &lt;feature/&gt; element.</p>
</section4>
<section4 topic='Initial Submission' anchor='registrar-reg-features-init'>
<p>This document defines a "publish" feature that is not associated with either of the protocol namespaces listed above; the registry submission for this feature is as follows:</p>
<code><![CDATA[
<feature var='http://jabber.org/protocol/disco#publish'>
<desc>the service discovery "publish" feature</desc>
<doc>XEP-0030</doc>
</feature>
]]></code>
</section4>
</section3>
<section3 topic='Well-Known Nodes' anchor='registrar-reg-nodes'>
<p>A "using protocol" may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar maintains a registry of well-known service discovery nodes at &NODES;.</p>
@ -913,10 +819,6 @@ xmpp:romeo@montague.net?disco;type=get;request=items
<name>get</name>
<desc>an IQ get</desc>
</value>
<value>
<name>set</name>
<desc>an IQ set (disco publish)</desc>
</value>
</values>
</key>
</keys>
@ -1014,14 +916,6 @@ xmpp:romeo@montague.net?disco;type=get;request=items
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='action' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='remove'/>
<xs:enumeration value='update'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='jid' type='xs:string' use='required'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
<xs:attribute name='node' type='xs:string' use='optional'/>