From de39518790e8e1f3110410d3c963d0cfe36ae0f6 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 30 Jan 2008 21:06:36 +0000 Subject: [PATCH] initial published version git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1621 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0230.xml | 139 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 139 insertions(+) create mode 100644 xep-0230.xml diff --git a/xep-0230.xml b/xep-0230.xml new file mode 100644 index 00000000..451e5927 --- /dev/null +++ b/xep-0230.xml @@ -0,0 +1,139 @@ + + +%ents; +]> + + +
+ Service Discovery Notifications + This specification defines a method for requesting and receiving notifications regarding XMPP service discovery items. + &LEGALNOTICE; + 0230 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0030 + XEP-0060 + + + + NOT YET ASSIGNED + &hildjj; + &stpeter; + + 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 <subscriptions/> 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;.

+ + +