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 &jep0054;). 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, &jep0045; rooms, &jep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).
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 Jabber Software 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.

Information about entities is provided using the &jep0120; protocol and registered infobit keynames (mainly those specified in &jep0125; although entity metadata is by no means limited to vCard information and could include infobits such as those specified in &jep0121;). The metadata is discovered by interacting with a common &jep0030; 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.

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 JEP, 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 &jep0077;. 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 JEP.

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

This JEP requires no interaction with &IANA;.