XEP-0123: Entity Metadata

WARNING: This document has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (if any).

Table of Contents

1. Background and Requirements

Traditionally, the only mechanism for communicating detailed information about entities on the Jabber network has been an XML version of the vCard format for electronic business cards (see vcard-temp [1]). Unfortunately, the vCard format has several major drawbacks:

1. It is mainly limited to data about persons (although it has been used on the Jabber network to describe things like servers).
2. The format contains relatively few data fields.
3. The format is not extensible.
4. As implemented, the data is not searchable.
5. As implemented, the data cannot be filtered depending on the identity of the requestor.

It is becoming increasingly important to define a robust, extensible format for describing entities on the Jabber network. Such a format should be:

1. Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, Multi-User Chat [2] rooms, Publish-Subscribe [3] nodes, and in general anything that can be addressed as a Jabber ID (as defined in XMPP Core [4]).
2. Usable in encapsulating any information about the entity itself (name, address, description, title, etc.).
3. Extensible enough to handle any metadata that may be needed for current and future applications (including, at a minimum, everything that can be defined in vCard); it must be possible to use it for public protocols defined by the IETF or XMPP Standards Foundation as well as for custom or private protocols.
4. Well-defined enough, through datatyping and public registries where applicable, to enable robust searching and filtering based on defined data fields and their values.

2. Protocol

Information about entities is provided using the Infobits [5] protocol and registered infobit keynames (mainly those specified in vCard Infobits Mapping [6] although entity metadata is by no means limited to vCard information and could include infobits such as those specified in Dublin Core Infobits Mapping [7]). The metadata is discovered by interacting with a common Service Discovery [8] node named "metadata". The queried entity replies with a service discovery result containing any infobits that the entity wishes to reveal about itself to the requesting entity. This information is always metadata about the entity itself, not any other entities or any relationships that the entity may have to other entities.

3. Use Cases

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

<iq type='result'
    from='romeo@montague.net/orchard'
    to='juliet@capulet.com/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    ...
    <item jid='juliet@capulet.com'
          node='metadata'
          name='Information about Juliet Capulet'/>
    ...
  </query>
</iq>
    

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

<iq type='result'
    from='romeo@montague.net'
    to='juliet@capulet.com/balcony'
    id='request2'>
  <query xmlns='http://jabber.org/protocol/disco#info'
         node='metadata'>
    <info 'http://jabber.org/protocol/infobits'>
      <bit key='fn'>Romeo Montague</bit>
      <bit key='country'>Italy</bit>
      <bit key='city'>Verona</bit>
      <bit key='gender'>male</bit>
      <bit key='nickname'>loverboy</bit>
    </info>
  </query>
</iq>
    

4. Integration with Directory Services

One of the primary motivations behind this proposal is to enable the construction of useful directory services on the Jabber network. Examples of such services include but are not limited to:

• robust user directories
• directories of groupchat rooms
• directories of pubsub nodes
• server directories

Although such directories will be a valuable addition to the network, it is imperative to understand that the canonical source for metadata about an entity is the entity itself. Mechanisms for keeping directories synchronized with entities are outside the scope of this document, and in any case a directory may not be privy to all information about an entity (since in general a user should publish to a directory only the information that he or she deems world-readable).

Directories SHOULD require registration using In-Band Registration [9]. Before registering with a directory, an entity SHOULD adjust its access controls or privacy rules accordingly, including appropriate definition of classes and addition of the directory server's JID to the relevant privacy rules. Upon accepting registration from an entity, a directory SHOULD immediately send a metadata request to the registering entity. Synchronization of metadata is a matter for the directory implementation to determine, and perhaps negotiate with the registering entity; all such synchronization and negotiation is out of scope for this document.

5. Security Considerations

Metadata MAY be world-readable. Entities MUST take care to ensure that they exercise proper control over access to such information. Users of IM clients SHOULD be warned that their data may be world-readable and be given the option to not publish such information or control it via appropriate mechanisms (such as privacy rules).

6. IANA Considerations

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

7. XMPP Registrar Considerations

Appendices

Appendix A: Document Information

Series: XEP
Number: 0123
Publisher: XMPP Standards Foundation
Status: Retracted
Type: Standards Track
Version: 0.3
Last Updated: 2003-12-16
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: N/A
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: 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 XMPP Standards 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 document 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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

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

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END