XEP-0123: Entity Metadata

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 (XEP-0054) [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 (XEP-0045) [2] rooms, Publish-Subscribe (XEP-0060) [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 (XEP-0120) [5] protocol and registered infobit keynames (mainly those specified in vCard Infobits Mapping (XEP-0125) [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 (XEP-0121) [7]). The metadata is discovered by interacting with a common Service Discovery (XEP-0030) [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 (XEP-0077) [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

XMPP Core, XMPP IM, XEP-0030, XEP-0120

Supersedes

None

Superseded By

None

Short Name

N/A

Source Control

HTML

This document in other formats: XML  PDF

Appendix B: Author Information¶

Peter Saint-Andre

Email

xsf@stpeter.im

JabberID

peter@jabber.org

URI

http://stpeter.im/

Appendix C: Legal Notices¶

Appendix D: Relation to XMPP¶

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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/

1. Version 0.3 (2003-12-16)¶
   Incorporated infobits changes and vCard infobit mappings; metadata about relationships to be moved to forthcoming specification.
   psa
2. Version 0.2 (2003-10-23)¶
   Changed ent to entity, rel to relation.
   psa
3. Version 0.1 (2003-10-22)¶
   Initial version, split off from XEP-0120.
   psa

END