JEP-0030: Service Discovery

This JEP defines a protocol for discovering (1) information about Jabber entities and (2) the items associated with such entities.

NOTICE: The protocol defined herein is a Final Standard of the Jabber Software Foundation and may be considered a stable technology for implementation and deployment.

JEP Information

Status: Final
Type: Standards Track
Number: 0030
Version: 2.1
Last Updated: 2005-03-03
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core
Supersedes: JEP-0011, JEP-0094
Superseded By: None
Short Name: disco
Schema for disco#info: <http://jabber.org/protocol/disco/info.xsd>
Schema for disco#items: <http://jabber.org/protocol/disco/items.xsd>
Registry: <http://www.jabber.org/registrar/disco.html>
Wiki Page: <http://wiki.jabber.org/index.php/Service Discovery (JEP-0030)>

Author Information

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Table of Contents

1. Introduction

The ability to discover information about entities on the Jabber network is extremely valuable. Such information might include features offered or protocols supported by the entity, the entity's type or identity, and additional entities that are associated with the original entity in some way (often thought of as "children" of the "parent" entity). While mechanisms for doing so are not defined in XMPP Core [1], several protocols have been used in the past within the Jabber community for service discovery, specifically Jabber Browsing [2] and Agent Information [3]. However, those protocols are perceived to be inadequate for several reasons:

1. Neither Jabber Browsing nor Agent Information is easily extensible. For example, the categories and subcategories listed for JID-Types in JEP-0011 are explicitly defined as the only official categories, and any additions to the list of JID-Types would require a modification to JEP-0011. While the Jabber Browsing specification does allow for the use of unofficial categories and types prefixed with the string 'x-', this introduces migration issues. This lack of flexibility violates one of the Jabber community's core Protocol Design Guidelines [4].

2. In Agent Information, there is no way to advertise supported features. While Jabber Browsing includes such a mechanism, the only way to express the availability of a feature is to advertise a supported protocol namespace. Yet some features may not be uniquely associated with a protocol namespace, which are one implementation of features but not the only one.

3. A Jabber Browsing result returns a combination of (1) namespaces supported by a Jabber Entity, (2) items associated with a Jabber Entity, and (3) namespaces supported by the associated items. This approach mixes information levels and requires parents to know everything about child nodes, thereby introducing significant confusion.

4. In both Jabber Browsing and Agent Information, items must be addressable as JIDs; however, this may not be possible in some applications.

This JEP addresses the perceived weaknesses of both the Jabber Browsing and Agent Information protocols. The result is a standards-track protocol for service discovery (often abbreviated to "disco", as is familiar in protocols such as Simple Object Access Protocol (SOAP) [5]).

2. Requirements

The authors have designed the service discovery protocol with the following requirements in mind:

• The protocol MUST support all functionality supported by the protocols it supersedes (Jabber Browsing and Agent Information).

• There are three kinds of information that need to be discovered about an entity:

  1. its basic identity (type and/or category)
  2. the features it offers and protocols it supports
  3. any additional items associated with the entity, whether or not they are addressable as JIDs

  All three MUST be supported, but the first two kinds of information relate to the entity itself whereas the third kind of information relates to items associated with the entity itself; therefore two different query types are needed.

• Discovering information about a child item MUST be accomplished by sending a separate discovery request to that item, not to the parent entity. (One result of this is that discovering complete information about an entire tree will require multiple request/response pairs in order to "walk the tree".)

• The lists of identities and features MUST be flexible.

• The protocol itself MUST be extensible.

3. Discovering Information About a Jabber Entity

A requesting entity may want to discover information about another entity on the network. The information desired generally is of two kinds:

1. The target entity's identity. In disco, an entity's identity is broken down into its category (server, client, gateway, directory, etc.) and its particular type within that category (IM server, phone vs. handheld client, MSN gateway vs. AIM gateway, user directory vs. chatroom directory, etc.). This information helps requesting entities to determine the group or "bucket" of services into which the entity is most appropriately placed (e.g., perhaps the entity is shown in a GUI with an appropriate icon). An entity MAY have multiple identities. When multiple identity elements are provided, the name attributes for each identity element SHOULD have the same value.

2. The features offered and protocols supported by the target entity. This information helps requesting entities determine what actions are possible with regard to this entity (registration, search, join, etc.), what protocols the entity supports, and specific feature types of interest, if any (e.g., for the purpose of feature negotiation).

In order to discover such information, the requesting entity MUST send an IQ stanza of type "get", containing an empty <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, to the JID of the target entity (the 'to' address is REQUIRED and MUST contain a valid JID; a 'node' attribute on the <query/> element is OPTIONAL as described in the Nodes section of this document):

Example 1. Querying for further information

<iq type='get'
    from='romeo@montague.net/orchard'
    to='plays.shakespeare.lit'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

The target entity then MUST either return an IQ result, or return an error (see the Error Conditions section of this document). The result MUST contain a <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more <identity/> elements and one or more <feature/> elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely <feature-not-implemented/> or <service-unavailable/>, although other error conditions may be appropriate.) Each <identity/> element MUST possess 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity. Each <feature/> element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity. Preferably, both the category/type values and the feature values will be registered in a public registry, as described in the Jabber Registrar Considerations section of this document.

Example 2. Result-set for information request

<iq type='result'
    from='plays.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        type='text'
        name='Play-Specific Chatrooms'/>
    <identity
        category='directory'
        type='chatroom'
        name='Play-Specific Chatrooms'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='jabber:iq:register'/>
    <feature var='jabber:iq:search'/>
    <feature var='jabber:iq:time'/>
    <feature var='jabber:iq:version'/>
  </query>
</iq>
    

If the JID or JID+Node of the specified target entity does not exist, the server or other authoritative entity SHOULD return an <item-not-found/> error, unless doing so would violate the privacy and security considerations specified in XMPP Core and XMPP IM [6], or local privacy and security policies:

Example 3. Target entity does not exist

<iq type='error'
    from='plays.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
  <error code='404' type='cancel'>
    <item-not-found xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
  </error>
</iq>
    

If privacy and security considerations or policies prevent the server or other authoritative entity from returning an <item-not-found/> error, it SHOULD return a <service-unavailable/> error instead:

Example 4. Service unavailable

<iq type='error'
    from='plays.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
  <error code='503' type='cancel'>
    <service-unavailable xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/>
  </error>
</iq>
    

A query sent to a more specific entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:

Example 5. Querying a specific conference room

<iq type='get'
    from='juliet@capulet.com/balcony'
    to='balconyscene@plays.shakespeare.lit'
    id='info2'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='balconyscene@plays.shakespeare.lit'
    to='juliet@capulet.com/balcony'
    id='info2'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        type='text'
        name='Romeo and Juliet, Act II, Scene II'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='http://jabber.org/protocol/feature-neg'/>
    <feature var='muc-password'/>
    <feature var='muc-hidden'/>
    <feature var='muc-temporary'/>
    <feature var='muc-open'/>
    <feature var='muc-unmoderated'/>
    <feature var='muc-nonanonymous'/>
  </query>
</iq>

Another example of this is sending a query to a specific connected resource for an IM user:

Example 6. Querying a connected resource for further information

<iq type='get'
    from='juliet@capulet.com/balcony'
    to='romeo@montague.net/orchard'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq type='result'
    from='romeo@montague.net/orchard'
    to='juliet@capulet.com/balcony'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='client'
        type='pc'
        name='Gabber'/>
    <feature var='jabber:iq:time'/>
    <feature var='jabber:iq:version'/>
  </query>
</iq>
    

A query MAY also be directed to a specific node identifier associated with a JID:

Example 7. Querying a specific JID and node combination

<iq type='get'
    from='romeo@montague.net/orchard'
    to='mim.shakespeare.lit'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='http://jabber.org/protocol/commands'/>
</iq>
    

Example 8. JID+node result

<iq type='result'
    from='mim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='http://jabber.org/protocol/commands'>
    <identity
        category='automation'
        type='command-list'/>
  </query>
</iq>
    

If a specific entity (JID or JID+node) does not support the disco#info namespace, does not have a defined identity, or refuses to return disco#info results to the specific requesting entity or to any requesting entity, it SHOULD return an appropriate error message (such as <service-unavailable/>, <feature-not-implemented/>, <forbidden/>, or <not-allowed/>, respectively). One example is shown below.

Example 9. JID+node error

<iq type='error'
    from='mim.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='info3'>
  <query xmlns='http://jabber.org/protocol/disco#info' 
         node='http://jabber.org/protocol/commands'/>
  <error code='405' type='cancel'>
    <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
    

Other error conditions may be appropriate depending on the application; refer to the Error Conditions section of this document.

4. Discovering the Items Associated with a Jabber Entity

<iq type='get'
    from='romeo@montague.net/orchard'
    to='shakespeare.lit'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
      

<iq type='result'
    from='shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='people.shakespeare.lit'
          name='Directory of Characters'/>
    <item jid='plays.shakespeare.lit'
          name='Play-Specific Chatrooms'/>
    <item jid='mim.shakespeare.lit'
          name='Gateway to Marlowe IM'/>
    <item jid='words.shakespeare.lit'
          name='Shakespearean Lexicon'/>
    <item jid='globe.shakespeare.lit'
          name='Calendar of Performances'/>
    <item jid='headlines.shakespeare.lit'
          name='Latest Shakespearean News'/>
    <item jid='catalog.shakespeare.lit'
          name='Buy Shakespeare Stuff!'/>
    <item jid='en2fr.shakespeare.lit'
          name='French Translation Service'/>
  </query>
</iq>
      

<iq type='result'
    from='shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='items1'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
      

<iq type='get'
    from='romeo@montague.net/orchard'
    to='catalog.shakespeare.lit'
    id='items2'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
        

<iq type='result'
    from='catalog.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='items2'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='catalog.shakespeare.lit'
          node='books'
          name='Books by and about Shakespeare'/>
    <item jid='catalog.shakespeare.lit'
          node='clothing'
          name='Wear your literary taste with pride'/>
    <item jid='catalog.shakespeare.lit'
          node='music'
          name='Music from the time of Shakespeare'/>
  </query>
</iq>
      

<iq type='get'
    from='romeo@montague.net/orchard'
    to='catalog.shakespeare.lit'
    id='items3'>
  <query xmlns='http://jabber.org/protocol/disco#items' 
         node='music'/>
</iq>
      

<iq type='result'
    from='catalog.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='items3'>
  <query xmlns='http://jabber.org/protocol/disco#items' 
         node='music'>
    <item jid='catalog.shakespeare.lit'
          node='music/A'/>
    <item jid='catalog.shakespeare.lit'
          node='music/B'/>
    <item jid='catalog.shakespeare.lit'
          node='music/C'/>
    <item jid='catalog.shakespeare.lit'
          node='music/D'/>
    .
    .
    .
  </query>
</iq>
      

<iq type='get'
    from='romeo@montague.net/orchard'
    to='catalog.shakespeare.lit'
    id='items4'>
  <query xmlns='http://jabber.org/protocol/disco#items' 
         node='music/D'/>
</iq>
      

<iq type='result'
    from='catalog.shakespeare.lit'
    to='romeo@montague.net/orchard'
    id='items4'>
  <query xmlns='http://jabber.org/protocol/disco#items' 
         node='music/D'>
    <item jid='catalog.shakespeare.lit'
          node='music/D/dowland-firstbooke'
          name='John Dowland - First Booke of Songes or Ayres'/>
    <item jid='catalog.shakespeare.lit'
          node='music/D/dowland-solace'
          name='John Dowland - A Pilgrimes Solace'/>
  </query>
</iq>
      

<iq from='juliet@capulet.com/chamber'
    id='items4'
    to='romeo@montague.net'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items' 
         node='http://jabber.org/protocol/tune'/>
</iq>
      

<iq from='romeo@montague.net'
    id='items4'
    to='juliet@capulet.com/chamber'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items' 
         node='http://jabber.org/protocol/tune'>
    <item jid='pubsub.shakespeare.lit'
          name='Romeo&apos;s CD player'
          node='s623nms9s3bfh8js'/>
    <item jid='pubsub.montague.net'
          node='music/R/Romeo/iPod'/>
    <item jid='tunes.characters.lit'
          node='g8k4kds9sd89djf3'/>
  </query>
</iq>
      

5. Publishing Available Items

The server handling rules defined in XMPP IM 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 <user@host>. This functionality is currently employed so that the user can "publish" information (e.g., vCard information as specified in vcard-temp [10]) 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.

Implementations of service discovery that are built into instant messaging servers SHOULD allow user 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:

Example 21. User sends disco#info request to server

<iq from='kinglear@shakespeare.lit'
    id='pubinfo'
    to='shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

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.

Example 22. Server responds with identity and feature information

<iq from='shakespeare.lit'
    id='pubinfo'
    to='kinglear@shakespeare.lit'
    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>
    

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 <item/> child element of the parent query MUST possess the following attributes:

• action -- specifies the action to be taken for the item
• jid -- specifies the Jabber ID of the item "owner" or location

The <item/> element MAY also possess the following attributes:

• name -- specifies a natural-language name for the item.
• node -- specifies the particular node associated with the JID of the item "owner" or location

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.

The following example shows a user publishing a list of his biological children to a well-known (but fictitious) service discovery node.

Example 23. Publishing items

<iq from='kinglear@shakespeare.lit'
    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 24. Server responds with success

<iq id='publish1'
    to='kinglear@shakespeare.lit'
    type='result'/>
    

Subsequent queries to "jid='kinglear@shakespeare.lit'" and "node='jabber:iq:kids'" will yield the list shown above (absent the 'action' attributes).

If the server or service does not support persistent storage, it MUST respond to IQ-set requests with a <feature-not-implemented/> error.

Example 25. Persistent storage is not available

<iq id='publish1'
    to='kinglear@shakespeare.lit'
    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:xml:params:ns:xmpp-stanzas'/>
  </error>
</iq>
    

6. Implementation Notes

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 Jabber Search [11]; they SHOULD NOT return extremely large result sets via Service Discovery.

This JEP 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 <identity/> element (category+type) to all disco#info requests sent to the same JID+node combination.

As mentioned above, when an entity sends a request to a bare JID (account@domain) hosted by a server, the server itself shall reply on behalf of the hosted account. The primary identity returned in the server's response to a disco#info query SHOULD have a category of "account", with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). In response to a disco#items query, if the requesting entity is subscribed to the account's presence, then the server SHOULD include one <item/> for each of the account's "available resources" (as that term is defined in RFC 3921); if the requesting entity is not subscribed to the account's presence, then the server MUST NOT return items for the account's available resources.

7. Error Conditions

The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see Error Condition Mappings [12]).

Table 1: Error Conditions

The other error conditions specified in XMPP Core MAY be returned as well (<forbidden/>, <not-allowed/>, <not-authorized/>, etc.), including application-specific conditions.

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.

8. Security Considerations

Certain attacks may be made easier when an entity discloses (via disco#info responses) that it supports particular protocols or features; however, in general, service discovery introduces no new vulnerabilities, since a malicious entity could discover that the responding entity supports such protocols and features by sending requests specific to those protocols rather than by sending service discovery requests.

A responding entity is under no obligation to return the identical service discovery response when replying to service discovery requests received from different requesting entities, and MAY perform authorization checks before responding in order to determine how (or whether) to respond.

9. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [13].

10. Jabber Registrar Considerations

<category>
  <name>the name of the category (all lower-case)</name>
  <desc>a natural-language description of the category</desc>
  <type>
    <name>the name of the specific type (all lower-case)</name>
    <desc>a natural-language description of the type</desc>
    <doc>the document (e.g., JEP) in which this type is specified</doc>
  </type>
</category>
          

<category>
  <name>hierarchy</name>
  <desc>
    An entity that exists in the context of a 
    service discovery node hierarchy.
  </desc>
  <type>
    <name>branch</name>
    <desc>
      A "container node" for other entities in a 
      service discovery node hierarchy.
    </desc>
    <doc>JEP-0030</doc>
  </type>
  <type>
    <name>leaf</name>
    <desc>
      A "terminal node" in a service discovery 
      node hierarchy.
    </desc>
    <doc>JEP-0030</doc>
  </type>
</category>
          

<feature var='name of feature or namespace'>
  <desc>a natural-language description of the feature</desc>
  <doc>the document (e.g., JEP) in which this feature is specified</doc>
</feature>

<feature var='http://jabber.org/protocol/disco#publish'>
  <desc>the service discovery "publish" feature</desc>
  <doc>JEP-0030</doc>
</feature>
          

<node>
  <name>the name of the node</name>
  <desc>a natural-language description of the node</desc>
  <doc>the document (e.g., JEP) in which this node is specified</doc>
</node>
          

11. XML Schemas

<?xml version='1.0' encoding='UTF-8' ?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/disco#info'
    xmlns='http://jabber.org/protocol/disco#info'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      JEP-0030: http://www.jabber.org/jeps/jep-0030.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:sequence minOccurs='0'>
        <xs:element ref='identity' maxOccurs='unbounded'/>
        <xs:element ref='feature' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='node' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='identity'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='category' type='xs:string' use='required'/>
          <xs:attribute name='name' type='xs:string' use='optional'/>
          <xs:attribute name='type' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='feature'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='var' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
      

<?xml version='1.0' encoding='UTF-8' ?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/disco#items'
    xmlns='http://jabber.org/protocol/disco#items'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      JEP-0030: http://www.jabber.org/jeps/jep-0030.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='query'>
    <xs:complexType>
      <xs:sequence minOccurs='0'>
        <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
      <xs:attribute name='node' type='xs:string' use='optional'/>
    </xs:complexType>
  </xs:element>

  <xs:element name='item'>
    <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'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
      

Notes

Revision History

END