%ents; ]>
Service Discovery Notifications This specification defines a method for requesting and receiving notifications regarding XMPP service discovery items. &LEGALNOTICE; 0230 Deferred Standards Track Standards Council XMPP Core XEP-0030 XEP-0060 NOT YET ASSIGNED &hildjj; &stpeter; 0.1.2 2018-09-08 fs

Add forgotten node attribute in example 2.

0.1.1 2016-10-04 egp

Add forgotten namespace in example 3, and change the text to describe the correct element.

0.1 2008-01-30 psa

Initial published version.

0.0.2 2008-01-06 jjh/psa

Corrected example to use full JIDs and SubIDs.

0.0.1 2008-01-03 jjh/psa

First draft.

&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;.

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.

]]>

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'.

]]>

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.

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.

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 <subscription/> element) and SHOULD send subsequent notifications to the requesting entity.

]]>

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.

]]> ]]>

When the requesting entity goes offline, the responding entity will receive unavailable presence.

]]>

The responding entity then MUST NOT send further notifications.

This document introduces no new security considerations above and beyond those already defined for service discovery and publish-subscribe.

This document requires no interaction with &IANA;.

This document requires no interaction with the ®ISTRAR;.