<abstract>This specification defines a method for requesting and receiving notifications regarding XMPP service discovery items.</abstract>
&LEGALNOTICE;
<number>0230</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
<spec>XEP-0060</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT YET ASSIGNED</shortname>
&hildjj;
&stpeter;
<revision>
<version>0.1</version>
<date>2008-01-30</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2008-01-06</date>
<initials>jjh/psa</initials>
<remark><p>Corrected example to use full JIDs and SubIDs.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2008-01-03</date>
<initials>jjh/psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0115; defines a way for entities to receive dynamically-updated information about &xep0030; capabilities, rather than polling for updates by sending repeated disco#info requests. However, there is no comparable method for receiving updated disco#items information (this might be helpful when the number of associated entities is large or dynamic, e.g., at a multi-user chat service). This document specifies such a method by re-using semantics from &xep0060;.</p>
</section1>
<section1topic='Protocol'anchor='protocol'>
<p>Before a requesting entity asks for service discovery items with notifications, it SHOULD send directed presence to the responding entity so that the responding entity knows when to stop sending notifications.</p>
<p>The requesting entity then sends a disco#items request to the responding entity, including a <subscribe/> element qualified by the 'http://jabber.org/protocol/pubsub' namespace, which in turn specifies a node of 'http://jabber.org/protocol/disco#items'.</p>
<p>If the responding entity does not recognize inclusion of the <subscribe/> element as a child of the <query/> element, it MUST return the service discovery items but MUST NOT send subsequent notifications to the requesting entity.</p>
<p>If the requesting entity did not share presence with the responding entity, the responding entity MUST return the service discovery items but SHOULD NOT send subsequent notifications to the requesting entity.</p>
<p>If the responding entity recognizes inclusion of the <subscribe/> element as a child of the <query/> element and the requesting entity is allowed to receive notifications, the responding entity MUST return the service discovery items (including a <subscriptions/> element) and SHOULD send subsequent notifications to the requesting entity.</p>
<examplecaption='Result-set for all items'><![CDATA[
<p>The responding entity then SHOULD send subsequent notifications to the requesting entity when associated items are added to or deleted from the potential result set.</p>
<examplecaption='A notification (new item)'><![CDATA[