xeps/xep-0123.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Entity Metadata</title>
  <abstract>NOTE: This proposal was retracted by the author on 2004-02-19.</abstract>
  <!--
  <abstract>Using Infobits and Service Discovery to define and communicate metadata about entities.</abstract>
  -->
  &LEGALNOTICE;
  <number>0123</number>
  <status>Retracted</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XMPP IM</spec>
    <spec>XEP-0030</spec>
    <spec>XEP-0120</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>N/A</shortname>
  &stpeter;
  <revision>
    <version>0.3</version>
    <date>2003-12-16</date>
    <initials>psa</initials>
    <remark>Incorporated infobits changes and vCard infobit mappings; metadata about relationships to be moved to forthcoming specification.</remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2003-10-23</date>
    <initials>psa</initials>
    <remark>Changed ent to entity, rel to relation.</remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2003-10-22</date>
    <initials>psa</initials>
    <remark>Initial version, split off from XEP-0120.</remark>
  </revision>
</header>
<section1 topic='Background and Requirements'>
  <p>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 &xep0054;). Unfortunately, the vCard format has several major drawbacks:</p>
  <ol>
    <li>It is mainly limited to data about persons (although it has been used on the Jabber network to describe things like servers).</li>
    <li>The format contains relatively few data fields.</li>
    <li>The format is not extensible.</li>
    <li>As implemented, the data is not searchable.</li>
    <li>As implemented, the data cannot be filtered depending on the identity of the requestor.</li>
  </ol>
  <p>It is becoming increasingly important to define a robust, extensible format for describing entities on the Jabber network. Such a format should be:</p>
  <ol>
    <li>Applicable not just to people but to any entity on the network, including but not limited to servers, components, bots, &xep0045; rooms, &xep0060; nodes, and in general anything that can be addressed as a Jabber ID (as defined in &xmppcore;).</li>
    <li>Usable in encapsulating any information about the entity itself (name, address, description, title, etc.).</li>
    <li>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.</li>
    <li>Well-defined enough, through datatyping and public registries where applicable, to enable robust searching and filtering based on defined data fields and their values.</li>
  </ol>
</section1>
<section1 topic='Protocol'>
  <p>Information about entities is provided using the &xep0120; protocol and registered infobit keynames (mainly those specified in &xep0125; although entity metadata is by no means limited to vCard information and could include infobits such as those specified in &xep0121;). The metadata is discovered by interacting with a common &xep0030; 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.</p>
</section1>
<section1 topic='Use Cases'>
  <section2 topic='Discovering Support'>
    <p>Support for entity metadata is discovered by means of Service Discovery. If the queried entity provides metadata about itself, it SHOULD advertise that fact by listing an item named "metadata" in response to a disco#items query.</p>
    <example caption='One Entity Queries Another via Disco'><![CDATA[
<iq type='get'
    from='juliet@capulet.com/balcony'
    to='romeo@montague.net/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]></example>
    <p>The entity returns its associated items:</p>
    <example caption='Entity Returns Disco Item Results'><![CDATA[
<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>
]]></example>
  </section2>
  <section2 topic='Requesting Metadata About Another Entity'>
    <p>In order to request the advertised metadata, the requesting entity sends a disco#info request to the 'metadata' node of the JID communicated in the previous result.</p>
    <example caption='Requestor Requests Metadata'><![CDATA[
<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>
]]></example>
    <p>The entity returns its metadata to the requestor.</p>
    <example caption='Entity Returns Metadata Result'><![CDATA[
<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>
]]></example>
  </section2>
</section1>
<section1 topic='Integration with Directory Services'>
  <p>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:</p>
  <ul>
    <li>robust user directories</li>
    <li>directories of groupchat rooms</li>
    <li>directories of pubsub nodes</li>
    <li>server directories</li>
  </ul>
  <p>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).</p>
  <p>Directories SHOULD require registration using &xep0077;. 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.</p>
</section1>
<section1 topic='Security Considerations'>
  <p>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).</p>
</section1>
<section1 topic='IANA Considerations'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations'>
  <section2 topic='Service Discovery Nodes'>
    <p>Upon advancement of this proposal to a status of Draft, the &REGISTRAR; shall add the 'metadata' node to its registry of common Service Discovery nodes.</p>
  </section2>
</section1>
</xep>