<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
  <head>
    <META http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>XEP-xxxx: Internet of Things - Discovery</title>
    <link rel="stylesheet" type="text/css" href="xmpp.css">
    <link href="prettify.css" type="text/css" rel="stylesheet">
    <link rel="shortcut icon" type="image/x-icon" href="favicon.ico"><script type="text/javascript" src="prettify.js"></script><meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=2.0">
    <meta name="DC.Title" content="Internet of Things - Discovery">
    <meta name="DC.Creator" content="Peter Waher">
    <meta name="DC.Creator" content="Ronny Klauck">
    <meta name="DC.Description" content="This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things.">
    <meta name="DC.Publisher" content="XMPP Standards Foundation">
    <meta name="DC.Contributor" content="XMPP Extensions Editor">
    <meta name="DC.Date" content="2014-04-09">
    <meta name="DC.Type" content="XMPP Extension Protocol">
    <meta name="DC.Format" content="XHTML">
    <meta name="DC.Identifier" content="XEP-xxxx">
    <meta name="DC.Language" content="en">
    <meta name="DC.Rights" content="This XMPP Extension Protocol is copyright © 1999 - 2013 by the XMPP Standards Foundation (XSF).">
  </head>
  <body onload="prettyPrint()">
    <h1>XEP-xxxx: Internet of Things - Discovery</h1>
    <table>
      <tr valign="top">
        <td><strong>Abstract:</strong></td>
        <td>This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things.</td>
      </tr>
      <tr valign="top">
        <td><strong>Authors:</strong></td>
        <td>Peter Waher, Ronny Klauck</td>
      </tr>
      <tr valign="top">
        <td><strong>Copyright:</strong></td>
        <td>© 1999 - 2013 XMPP Standards Foundation. <a href="#appendix-legal">SEE LEGAL NOTICES</a>.</td>
      </tr>
      <tr valign="top">
        <td><strong>Status:</strong></td>
        <td>ProtoXEP</td>
      </tr>
      <tr valign="top">
        <td><strong>Type:</strong></td>
        <td>Standards Track</td>
      </tr>
      <tr valign="top">
        <td><strong>Version:</strong></td>
        <td>0.0.3</td>
      </tr>
      <tr valign="top">
        <td><strong>Last Updated:</strong></td>
        <td>2014-04-09</td>
      </tr>
    </table>
    <hr>
    <p style="color:red">WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <<a href="http://xmpp.org/extensions/">http://xmpp.org/extensions/</a>> and announced on the <standards@xmpp.org> mailing list.</p>
    <hr>
    <h2>Table of Contents</h2>
    <div class="indent">
      <p><br>1.  <a href="#intro">Introduction</a><br>2.  <a href="#glossary">Glossary</a><br>3.  <a href="#usecases">Use Cases</a><br>   
      3.1.  <a href="#sect-ID0EWMAC">Production</a><br>   
      3.2.  <a href="#sect-ID0EYNAC">Installation</a><br>   
      3.3.  <a href="#sect-ID0EBOAC">Finding XMPP Server</a><br>      
      3.3.1.  <a href="#sect-ID0E5OAC">DHCP</a><br>        
      3.3.1.1.  <a href="#sect-ID0EXAAE">XMPP Server Option</a><br>        
      3.3.1.2.  <a href="#option">Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters for IoT Discovery</a><br>      
      3.3.2.  <a href="#sect-ID0EMCAE">Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD)</a><br>        
      3.3.2.1.  <a href="#sect-ID0EPDAE">DNS Records</a><br>        
      3.3.2.2.  <a href="#txt">IoT Discovery TXT Record Parameters Registry</a><br>      
      3.3.3.  <a href="#sect-ID0EYIAE">SSDP/UPnP</a><br>   
      3.4.  <a href="#sect-ID0EXJAE">Connection to XMPP Server</a><br>   
      3.5.  <a href="#sect-ID0ERKAE">Finding Thing Registry</a><br>   
      3.6.  <a href="#sect-ID0EIMAE">Registering Thing</a><br>   
      3.7.  <a href="#sect-ID0ESNAE">Register self-owned Thing</a><br>   
      3.8.  <a href="#sect-ID0EDOAE">Register Thing behind Concentrator</a><br>   
      3.9.  <a href="#sect-ID0E3PAE">Claiming Ownership of a Thing</a><br>   
      3.10.  <a href="#sect-ID0EEWAE">Removing Thing from Registry</a><br>   
      3.11.  <a href="#sect-ID0EEYAE">Finding Provisioning Server</a><br>   
      3.12.  <a href="#sect-ID0EI1AE">Delegating Trust</a><br>   
      3.13.  <a href="#sect-ID0E51AE">Update Meta Information about Thing in Registry</a><br>   
      3.14.  <a href="#sect-ID0E33AE">Search for Public Things in Registry</a><br>   
      3.15.  <a href="#sect-ID0EKKAG">Unregistering Thing from Registry</a><br>   
      3.16.  <a href="#sect-ID0ELLAG">Disowning Thing</a><br>4.  <a href="#support">Determining Support</a><br>5.  <a href="#impl">Implementation Notes</a><br>   
      5.1.  <a href="#jidvscomponent">JID vs Component Thing Registries</a><br>   
      5.2.  <a href="#tags">Meta Tags</a><br>   
      5.3.  <a href="#sect-ID0EL2AG">Friendships between Things and Registry</a><br>6.  <a href="#security">Security Considerations</a><br>   
      6.1.  <a href="#jcp">Jabber Components Protocol</a><br>   
      6.2.  <a href="#sect-ID0EJ4AG">Hijacking predefined JIDs</a><br>   
      6.3.  <a href="#sect-ID0ES4AG">Hijacking things in public areas</a><br>   
      6.4.  <a href="#sect-ID0E64AG">Key meta information in searches</a><br>   
      6.5.  <a href="#sect-ID0EC6AG">KEY tag</a><br>   
      6.6.  <a href="#sect-ID0EV6AG">Tag name spam</a><br>   
      6.7.  <a href="#sect-ID0ECABG">External services for creating QR-codes</a><br>7.  <a href="#iana">IANA Considerations</a><br>8.  <a href="#registrar">XMPP Registrar Considerations</a><br>9.  <a href="#schema">XML Schema</a><br>10.  <a href="#moreinfo">For more information</a><br>11.  <a href="#ack">Acknowledgements</a></p>
      <p><a href="#appendices">Appendices</a><br>    <a href="#appendix-docinfo">A: Document Information</a><br>    <a href="#appendix-authorinfo">B: Author Information</a><br>    <a href="#appendix-legal">C: Legal Notices</a><br>    <a href="#appendix-xmpp">D: Relation to XMPP</a><br>    <a href="#appendix-discuss">E: Discussion Venue</a><br>    <a href="#appendix-conformance">F: Requirements Conformance</a><br>    <a href="#appendix-notes">G: Notes</a><br>    <a href="#appendix-revs">H: Revision History</a></p>
    </div>
    <hr>
    <h2>1.
       <a name="intro">Introduction</a></h2>
                <p class="" style="">
                        When installing massive amounts of Things into public networks care has to be taken to make installation simple, but at the same time secure so that the Things cannot be
                        hijacked or hacked, making sure access to the Thing is controlled by the physical owner of the Thing. One of the main problems is how
                        to match the characteristics of a Thing, like serial number, manufacturer, model, etc., with information automatically created by the Thing itself, like perhaps its JID, in
                        an environment with massive amount of Things without rich user interfaces. Care has also to be taken when specifying rules for access rights and user privileges.
                </p>
                <p class="" style="">
                        This document provides a network architecture based on the XMPP protocol that provides a means to safely install, configure, find and connect massive amounts of Things together, and
                        at the same time minimizing the risk that Things get hijacked. It also provides information how each individual step in the process can be performed with as little manual intervention
                        as possible, aiming where possible at zero-configuration networking. Furthermore, this document specifies how to create a registry that allows simple access to public Things
                        without risking their integrity unnecessarily.
                </p>
                <p class="" style="">
                        Internet of Things contains many different architectures and use cases. For this reason, the IoT standards have been divided into multiple XEPs according to the following table:
                </p>
                <div class="indent">
      <p class="caption"><a name="table-1"></a>Table 1: Internet of Things XEPs</p>
      <table border="1" cellpadding="3" cellspacing="0">
                        <tr class="body">
                                <th colspan="" rowspan="">XEP</th>
                                <th colspan="" rowspan="">Description</th>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-BatteryPoweredSensors</td>
                                <td colspan="" rowspan="">Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-Discovery</td>
                                <td colspan="" rowspan="">This specification. Defines the peculiars of Thing discovery in Internet of Things. Apart from discovering Things by JID, it also defines how to discover Things based on location, etc.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-Events</td>
                                <td colspan="" rowspan="">Defines how Things send events, how event subscription, hysteresis levels, etc., are configured.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-Interoperability</td>
                                <td colspan="" rowspan="">Defines guidelines for how to achieve interoperability in Internet of Things, publishing interoperability interfaces for different types of devices.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-Multicast</td>
                                <td colspan="" rowspan="">Defines how sensor data can be multicast in efficient ways.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-PubSub</td>
                                <td colspan="" rowspan="">Defines how efficient publication of sensor data can be made in Internet of Things.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">xep-0000-IoT-Chat</td>
                                <td colspan="" rowspan="">Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0322</td>
                <td colspan="" rowspan="">
                                        Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not an Internet of Things specific XEP, this XEP should be considered
                                        in all Internet of Things implementations where memory and packet size is an issue.
                                </td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0323</td>
                                <td colspan="" rowspan="">
                                        Provides the underlying architecture, basic operations and data structures for sensor data communication over XMPP networks.
                                        It includes a hardware abstraction model, removing any technical detail implemented in underlying technologies. This XEP is used by all other
                                        Internet of Things XEPs.
                                </td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0324</td>
                                <td colspan="" rowspan="">Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0325</td>
                                <td colspan="" rowspan="">Defines how to control actuators and other devices in Internet of Things.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0326</td>
                                <td colspan="" rowspan="">Defines how to handle architectures containing concentrators or servers handling multiple Things.</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0331</td>
                                <td colspan="" rowspan="">Defines extensions for how color parameters can be handled, based on <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0004.html">Data Forms</a></span>  [<a href="#nt-ID0EXCAC">1</a>]</td>
                        </tr>
                        <tr class="body">
                                <td colspan="" rowspan="">XEP-0336</td>
                                <td colspan="" rowspan="">Defines extensions for how dynamic forms can be created, based on <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0004.html">Data Forms</a></span>  [<a href="#nt-ID0EODAC">2</a>], <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0122.html">Data Forms Validation</a></span>  [<a href="#nt-ID0E1DAC">3</a>], <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0137.html">Publishing Stream Initiation Requests</a></span>  [<a href="#nt-ID0EGEAC">4</a>] and <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0141.html">Data Forms Layout</a></span>  [<a href="#nt-ID0ESEAC">5</a>].</td>
                        </tr>
                </table>
    </div>
        <h2>2.
       <a name="glossary">Glossary</a></h2>
                <p class="" style="">The following table lists common terms and corresponding descriptions.</p>
                <div class="indent">
      <dl>
                        <di>
                                <dt><strong>Actuator</strong></dt>
                                <dd>Device containing at least one configurable property or output that can and should be controlled by some other entity or device.</dd>
                        </di>
                        <di>
                                <dt><strong>Authority</strong></dt>
                                <dd>Used synonymously with Provisioning Server.</dd>
                        </di>
                        <di>
                                <dt><strong>Computed Value</strong></dt>
                                <dd>A value that is computed instead of measured.</dd>
                        </di>
                        <di>
                                <dt><strong>Concentrator</strong></dt>
                                <dd>Device managing a set of devices which it publishes on the XMPP network.</dd>
                        </di>
                        <di>
                                <dt><strong>Field</strong></dt>
                                <dd>
                                        One item of sensor data. Contains information about: Node, Field Name, Value, Precision, Unit, Value Type, Status, Timestamp, Localization information, etc.
                                        Fields should be unique within the triple (Node ID, Field Name, Timestamp).
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Field Name</strong></dt>
                                <dd>Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc.</dd>
                        </di>
                        <di>
                                <dt><strong>Field Type</strong></dt>
                                <dd>What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc.</dd>
                        </di>
                        <di>
                                <dt><strong>Historical Value</strong></dt>
                                <dd>A value stored in memory from a previous timestamp.</dd>
                        </di>
                        <di>
                                <dt><strong>Identification Value</strong></dt>
                                <dd>A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.)</dd>
                        </di>
                        <di>
                                <dt><strong>Localization information</strong></dt>
                                <dd>Optional information for a field, allowing the sensor to control how the information should be presented to human viewers.</dd>
                        </di>
                        <di>
                                <dt><strong>Meter</strong></dt>
                                <dd>A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc.</dd>
                        </di>
                        <di>
                                <dt><strong>Momentary Value</strong></dt>
                                <dd>A momentary value represents a value measured at the time of the read-out.</dd>
                        </di>
                        <di>
                                <dt><strong>Node</strong></dt>
                                <dd>
                                        Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes whereas links between sensors (friendships)
                                        are depicted as edges. In abstract terms, it's easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.).
                                        Each Node has a Node ID.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Node ID</strong></dt>
                                <dd>
                                        An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted
                                        ID scheme.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Parameter</strong></dt>
                                <dd>
                                        Readable and/or writable property on a node/device. The XEP-0326 <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0326.html">Internet of Things - Concentrators</a></span>  [<a href="#nt-ID0EUIAC">6</a>] deals with reading and writing parameters
                                        on nodes/devices. Fields are not parameters, and parameters are not fields.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Peak Value</strong></dt>
                                <dd>A maximum or minimum value during a given period.</dd>
                        </di>
                        <di>
                                <dt><strong>Provisioning Server</strong></dt>
                                <dd>
                                        An application that can configure a network and provide services to users or Things. In Internet of Things, a Provisioning Server knows who knows whom,
                                        what privileges users have, who can read what data and who can control what devices and what parts of these devices.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Precision</strong></dt>
                                <dd>
                                        In physics, precision determines the number of digits of precision. In sensor networks however, this definition is not easily applicable. Instead, precision
                                        determines, for example, the number of decimals of precision, or power of precision. Example: 123.200 MWh contains 3 decimals of precision. All entities parsing and
                                        delivering field information in sensor networks should always retain the number of decimals in a message.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Sensor</strong></dt>
                                <dd>
                                        Device measuring at least one digital value (0 or 1) or analog value (value with precision and physical unit). Examples: Temperature sensor, pressure sensor, etc.
                                        Sensor values are reported as fields during read-out. Each sensor has a unique Node ID.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>SN</strong></dt>
                                <dd>Sensor Network. A network consisting, but not limited to sensors, where transport and use of sensor data is of primary concern. A sensor network may contain actuators, network applications, monitors, services, etc.</dd>
                        </di>
                        <di>
                                <dt><strong>Status Value</strong></dt>
                                <dd>A value displaying status information about something.</dd>
                        </di>
                        <di>
                                <dt><strong>Timestamp</strong></dt>
                                <dd>Timestamp of value, when the value was sampled or recorded.</dd>
                        </di>
                        <di>
                                <dt><strong>Thing</strong></dt>
                                <dd>
                                        Internet of Things basically consists of Things connected to the Internet. Things can be any device, sensor, actuator etc., that can have an
                                        Internet connection.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Thing Registry</strong></dt>
                                <dd>
                                        A registry where Things can register for simple and secure discovery by the owner of the Thing. The registry can also be used as a database for meta information
                                        about Things in the network.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Token</strong></dt>
                                <dd>
                                        A client, device or user can get a token from a provisioning server. These tokens can be included in requests to other entities in the network, so these entities can validate
                                        access rights with the provisioning server.
                                </dd>
                        </di>
                        <di>
                                <dt><strong>Unit</strong></dt>
                                <dd>Physical unit of value. Example: MWh, l/s, etc.</dd>
                        </di>
                        <di>
                                <dt><strong>Value</strong></dt>
                                <dd>A field value.</dd>
                        </di>
                        <di>
                                <dt><strong>Value Status</strong></dt>
                                <dd>Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc.</dd>
                        </di>
                        <di>
                                <dt><strong>Value Type</strong></dt>
                                <dd>Can be numeric, string, boolean, Date & Time, Time Span or Enumeration.</dd>
                        </di>
                        <di>
                                <dt><strong>WSN</strong></dt>
                                <dd>Wireless Sensor Network, a sensor network including wireless devices.</dd>
                        </di>
                        <di>
                                <dt><strong>XMPP Client</strong></dt>
                                <dd>Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients.</dd>
                        </di>
                </dl>
    </div>
        <h2>3.
       <a name="usecases">Use Cases</a></h2>
                <p class="" style="">
                        The life cycle of a Thing can be divided into multiple steps. The following sections will list many of these steps in possible order of occurrence during the
                        life cycle of the Thing.
                </p>
                <div class="indent">
      <h3>3.1 <a name="sect-ID0EWMAC">Production</a></h3>
                        <p class="" style="">
                                During production of a Thing, decisions have to be made whether the following parameters should be pre-configured, manually entered after installation or
                                automatically found and/or created by the device if possible (zero-configuration networking):
                        </p>
                        <ul class="" style="">
                                <li class="" style="">
                                        Address and domain of XMPP Server.
                                </li>
                                <li class="" style="">
                                        JID of the Thing.
                                </li>
                                <li class="" style="">
                                        JID of Thing Registry, if separate from the XMPP Server.
                                </li>
                                <li class="" style="">
                                        JID of first Provisioning Server, if separate from Thing Registry or XMPP Server.
                                </li>
                        </ul>
                        <p class="" style="">
                                A decision has to be made at this point if global/manufacturer/customer servers should be used, or if local resources should be searched for and used if found.
                                The first option is easy to configure in a production environment and might have commercial significance,
                                but cannot use local resources where available. The second leaves much responsibility to the Thing for finding local resources, but has the advantage of allowing for a more
                                decentralized network architecture. A detailed discussion of the two alternatives goes beyond the scope of this specification, and will not be presented here.
                        </p>
                </div>
                <div class="indent">
      <h3>3.2 <a name="sect-ID0EYNAC">Installation</a></h3>
                        <p class="" style="">
                                Apart from physical installation, and connection to power and communication infrastructure, the installation phase of a Thing might also require manual entry of values that
                                could not be set in the production environment. Since Things might have very limited human user interfaces, external tools might be required to provide this information. Due
                                to its complexity, any manual entry of configuration parameters should be avoided, if possible. However, manual entry of some parameters might allow for Things to use local
                                resources where such cannot be found nor set in a production environment.
                        </p>
                </div>
                <div class="indent">
      <h3>3.3 <a name="sect-ID0EBOAC">Finding XMPP Server</a></h3>
                        <p class="" style="">
                                If the address of an XMPP Server is not preconfigured, the Thing must attempt to find one in its local surroundings. This can be done using one of several methods:
                        </p>
                        <ul class="" style="">
                                <li class="" style="">DHCP</li>
                                <li class="" style="">Multicast DNS</li>
                                <li class="" style="">SSDP/UPnP</li>
                        </ul>
                        <p class="" style="">
                                The following sections describe them in more detail.
                        </p>
                        <div class="indent">
        <h3>3.3.1 <a name="sect-ID0E5OAC">DHCP</a></h3>
                                <p class="" style="">
                                        DHCP offers an internal structure for advertising configuration information to clients in a network.
                                        This includes configuration parameters and other control elements, which are transmitted in special marked data elements, called 'options', as described in
                                        <span class="ref" style="">
                                                <a href="http://tools.ietf.org/html/rfc3942">RFC 3942</a>
                                        </span>  [<a href="#nt-ID0EOPAC">7</a>].
                                </p>
                                <p class="" style="">
                                        <a href="http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.txt">Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters</a> lists currently assigned 'options' by IANA.
                                        <span class="strong">Note:</span> There does exist no 'option' for XMPP at the moment.
                                        Options 224 to 254 are marked as 'site-specific option range' to support local (to a site) configuration options (i.e., reserved as 'Private Use').
                                </p>
                                <p class="" style="">
                                        Possible codes for the XMPP server option:
                                </p>
                                <ul class="" style="">
                                        <li class="" style="">Use 'site-specific option range'. Use of 'option-code' 224.</li>
                                        <li class="" style="">
                                                <span class="strong">TBD:</span> Define and register DHCP and BOOTP option as described in <a href="#option">Parameters for IoT Discovery</a>. Use of 'option-code' 84.
                                        </li>
                                </ul>
                                <div class="indent">
          <h3>3.3.1.1 <a name="sect-ID0EXAAE">XMPP Server Option</a></h3>
                                        <p class="" style="">
                                                This option specifies the name of the XMPP server.
                                                The name may or may not be qualified with the local domain name.
                                                See <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc1035">RFC 1035</a></span>  [<a href="#nt-ID0EFBAE">8</a>] for character set restrictions.
                                        </p>
                                        <p class="" style="">
                                                The code for this option is 224 (for 'site-specific option range') or 84 (for <a href="#option">DHCP and BOOTP Parameters for IoT Discovery</a>), and its minimum length is 1.
                                        </p>
                                        <p class="caption"><a name="example-1"></a>Example 1. IoT Discovery DHCP Option</p>
          <div class="indent">
            <pre class="prettyprint">
                                                
   <option code> <data length> machine
                                        </pre>
          </div>
                                        <p class="" style="">So, for example, if the machine name is "pronto", the code for the option is 224, the XMPP server option would be as follows:</p>
                                        <p class="caption"><a name="example-2"></a>Example 2. IoT Discovery DHCP Option Example</p>
          <div class="indent">
            <pre class="prettyprint">
                                                
   224 12 pronto.local
                                        </pre>
          </div>
                                </div>
                                <div class="indent">
          <h3>3.3.1.2 <a name="option">Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters for IoT Discovery</a></h3>
                                        <p class="" style="">The following parameters in use as of MONTH 201x. Refer to the DHCP and BOOTP parameters itself for a complete and current list of parameters (this specification might or might not be revised when new parameters are registered).</p>
                                        <p class="caption"><a name="example-3"></a>Example 3. IoT Discovery DHCP and BOOTP Parameters Registry</p>
          <div class="indent">
            <pre class="prettyprint">
                                                
   <tag>84</tag>
   <name>XMPP server</name>
   <data length>N</data length>
   <meaning>XMPP Servers DHCP Option</meaning>
   <reference>[RFC6120]</reference>
                                        </pre>
          </div>
                                </div>
                        </div>
                        <div class="indent">
        <h3>3.3.2 <a name="sect-ID0EMCAE">Multicast DNS (mDNS) and DNS Service Discovery (DNS-SD)</a></h3>
                                <p class="" style="">
                                        An introduction of mDNS/DNS-SD (e.g., how it works and terminology) is described in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0174.html">Link-Local Messaging</a></span>  [<a href="#nt-ID0E1CAE">9</a>] (i.e., sections [1.2] and [2]).
                                        For the purpose of IoT Discovery we are interested only in the "xmpp-client" service.
                                        An XMPP server MUST publish four different kinds of DNS records to advertise its availability using the services of type "xmpp-client".
                                        An XMPP chat client (actually its mDNS daemon) can send out multicast DNS queries for services of type "xmpp-client".
                                        <span class="strong">Note:</span> the service of type "xmpp-client" is the reservered name for client-to-server connections by IANA, as described in <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc6120">RFC 6120</a></span>  [<a href="#nt-ID0EIDAE">10</a>].
                                </p>
                                <div class="indent">
          <h3>3.3.2.1 <a name="sect-ID0EPDAE">DNS Records</a></h3>
                                        <p class="" style="">In order to advertise its availability, a server MUST publish four different kinds of DNS records:</p>
                                        <ol start="" class="" style="">
                                                <li class="" style="">
                                                        <p class="" style="">A PTR record of the following form:</p>
                                                        <p class="caption"><a name="example-4"></a>Example 4. PTR record</p>
              <div class="indent">
                <pre class="prettyprint">
                                                                
   _xmpp-client._tcp.local. PTR machine._xmpp-client._tcp.local.
                                                        </pre>
              </div>
                                                </li>
                                                <li class="" style="">
                                                        <p class="" style="">An address ("A" or "AAAA") record of the following form (where the IP address can be either an IPv4 address or an IPv6 address):</p>
                                                        <p class="caption"><a name="example-5"></a>Example 5. A record</p>
              <div class="indent">
                <pre class="prettyprint">
                                                                
   machine.local. A ip-address
                                                        </pre>
              </div>
                                                </li>
                                                <li class="" style="">
                                                        <p class="" style="">A SRV record of the following form:</p>
                                                        <p class="caption"><a name="example-6"></a>Example 6. SRV record</p>
              <div class="indent">
                <pre class="prettyprint">
                                                                
   machine._xmpp-client._tcp.local <ttl> SRV <priority> <weight> port-number machine.local.
                                                        </pre>
              </div>
                                                </li>
                                                <li class="" style="">
                                                        <p class="" style="">
                                                                A TXT record whose name is the same as the SRV record and whose value follows the format described in the <a href="#txt">TXT Record</a> section of this document, consisting of a set of strings that typically represent a series of key-value pairs such as the following:
                                                        </p>
                                                        <p class="caption"><a name="example-7"></a>Example 7. TXT record</p>
              <div class="indent">
                <pre class="prettyprint">
                                                                
   txtvers=1
   ordom=example.com
   regis=registry
   provis=provisioning
                                                        </pre>
              </div>
                                                        <p class="" style="">Note: The DNS-SD specification stipulates that the TXT record MUST be published, but that it MAY contain no more than a single zero byte (e.g., if the server does not wish to publish any personal information).</p>
                                                </li>
                                        </ol>
                                        <p class="" style="">
                                                For the purpose of IoT Discovery we are interested only in the "xmpp-client" service.
                                                An XMPP server MUST publish four different kinds of DNS records to advertise its availability using the services of type "xmpp-client".
                                                An XMPP chat client (actually its mDNS daemon) can send out multicast DNS queries for services of type "xmpp-client".
                                                <span class="strong">Note:</span> the service of type "xmpp-client" is the reservered name for client-to-server connections by IANA, as described in <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc6120">RFC 6120</a></span>  [<a href="#nt-ID0EBGAE">11</a>].
                                        </p>
                                        <p class="" style="">So, for example, if the machine name is "pronto", the IP address is "10.2.1.188", and the personal information, the DNS records would be as follows:</p>
                                        <p class="caption"><a name="example-8"></a>Example 8. IoT Discovery DNS Records Example</p>
          <div class="indent">
            <pre class="prettyprint">
                                                
   _xmpp-client._tcp.local. PTR pronto._xmpp-client._tcp.local.
        
   pronto._xmpp-client._tcp.local. SRV 5222 pronto.local. 
                                
   pronto.local. A 10.2.1.188
                                
   pronto._xmpp-client._tcp.local. IN TXT 
   "txtvers=1"
   "ordom=example.com"
   "regis=registry"
   "provis=provisioning"
                                        </pre>
          </div>
                                        <p class="" style="">The IPv4 and IPv6 addresses associated with a machine might vary depending on the local network to which the machine is connected. For example, on an Ethernet connection the physical address might be "192.168.0.100" but when the machine is connected to a wireless network the physical address might change to "10.10.1.188". See <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc3927">RFC 3927</a></span>  [<a href="#nt-ID0EZGAE">12</a>] for details.</p>
                                        <p class="" style="">If the machine name asserted by a client is already taken by another machine on the network, the client MUST assert a different machine name, which SHOULD be formed by adding the character "-" and digit "1" to the end of the machine name string (e.g., "pronto-1"), adding the character "-" and digit "2" if the resulting machine name is already taken (e.g., "pronto-2"), and similarly incrementing the digit until a unique machine name is constructed.</p>
                                        <p class="" style="">
                                                <span class="strong">Note:</span> DNS-SD enables service definitions to include a TXT record that specifies parameters to be used in the context of the relevant service type. For detailed information refer to <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0174.html">Link-Local Messaging</a></span>  [<a href="#nt-ID0EQHAE">13</a>] (Link-Local Messaging - TXT Record).
                                        </p>
                                </div>
                                <div class="indent">
          <h3>3.3.2.2 <a name="txt">IoT Discovery TXT Record Parameters Registry</a></h3>
                                        <p class="" style="">The registration process is described in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0174.html">Link-Local Messaging</a></span>  [<a href="#nt-ID0EGIAE">14</a>] (Link-Local Messaging - Registration Process).</p>
                                        <p class="" style="">The following submission registers parameters in use as of MONTH 201x. Refer to the registry itself for a complete and current list of parameters (this specification might or might not be revised when new parameters are registered).</p>
                                        <p class="caption"><a name="example-9"></a>Example 9. IoT Discovery TXT Record Parameters Registry</p>
          <div class="indent">
            <pre class="prettyprint">
                                                
   <param>
      <name>ordom</name>
      <desc>The "origin domain" of the XMPP service.</desc>
      <status>recommended</status>
   </param>

   <param>
      <name>regis</name>
      <desc>
         The username portion of the JID to Thing Registry;
         can contain a space-separated list of more than one JID.
      </desc>
      <status>optional</status>
   </param>

   <param>
      <name>provis</name>
      <desc>
         The username portion of the JID to provisioning server;
         can contain a space-separated list of more than one JID.
      </desc>
      <status>optional</status>
   </param>
                                        </pre>
          </div>
                                </div>
                                
                        </div>
                        <div class="indent">
        <h3>3.3.3 <a name="sect-ID0EYIAE">SSDP/UPnP</a></h3>
                                <p class="" style="">TBD</p>
                                
                        </div>
                        <p class="" style="">
                                <span class="strong">Note:</span> If server-less messaging is to be used, as described in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0174.html">Link-Local Messaging</a></span>  [<a href="#nt-ID0EPJAE">15</a>] this step can be used to find the Thing Registry and optionally the
                                Provisioning Server and other peers it want to connect to. The next section can thus be skipped.
                        </p>
                </div>
                <div class="indent">
      <h3>3.4 <a name="sect-ID0EXJAE">Connection to XMPP Server</a></h3>
                        <p class="" style="">
                                Once an XMPP Server has been found, a connection can be made. If multiple XMPP Servers are found, the client is free to choose the one that best suits its purposes.
                        </p>
                        <p class="" style="">
                                If the Thing does not have an account already, an account can be registered along what is specified in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0077.html">In-Band Registration</a></span>  [<a href="#nt-ID0EJKAE">16</a>]. If multiple servers are available, the first XMPP server that
                                allows account creation can be used.
                        </p>
                </div>
                <div class="indent">
      <h3>3.5 <a name="sect-ID0ERKAE">Finding Thing Registry</a></h3>
                        <p class="" style="">
                                If a Thing Registry is not preconfigured, one must be found. A Thing Registry can be hosted either as a server component using <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0114.html">Jabber Component Protocol</a></span>  [<a href="#nt-ID0E6KAE">17</a>] or as an XMPP Client accessible through
                                a JID. The following lists methods to obtaining the Component Address or JID for the Thing Registry. Note that the last one has <a href="#security">security considerations</a> 
                                that need to be taken into account, if implemented.
                        </p>
                        <ol start="" class="" style="">
                                <li class="" style="">
                                        Preconfigured Component Address of Thing Registry. A Component address is normally a subdomain to the domain of the XMPP Server that hosts the component.
                                </li>
                                <li class="" style="">
                                        Preconfigured bare JID of Thing Registry.
                                </li>
                                <li class="" style="">
                                        Preconfigured subdomain part of Component Address. This will be added to the domain of the XMPP Server used to connet to.
                                </li>
                                <li class="" style="">
                                        Preconfigured user name of JID. This will be added to the domain of the XMPP Server used to connected to.
                                </li>
                                <li class="" style="">
                                        Searching through Server Components on the XMPP Server currently connected to, as described in <a href="#support">Determining Support</a>.
                                </li>
                        </ol>
                </div>
                <div class="indent">
      <h3>3.6 <a name="sect-ID0EIMAE">Registering Thing</a></h3>
                        <p class="" style="">
                                Once a Thing Registry has been found and been befriended, the Thing can register itself with the registry, as follows:
                        </p>
                        <p class="caption"><a name="example-10"></a>Example 10. Register Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='1'>
      <register xmlns='urn:xmpp:iot:discovery'>
          <str name='SN' value='394872348732948723'/>
          <str name='MAN' value='www.ktc.se'/>
          <str name='MODEL' value='IMC'/>
          <num name='V' value='1.2'/>
          <str name='KEY' value='4857402340298342'/>
      </register>
   </iq>
   
   <iq type='result'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='1'/>
                        </pre>
      </div>
                        <p class="" style="">
                                There are two types of tags: Tags with string values and tags with numerical values. The distinction is important, since the type of value affects how
                                comparisons are made later when performing searches in the registry.
                        </p>
                        <p class="" style="">
                                The Thing should only register parameters required to be known by the owner of the Thing. Dynamic meta information must be avoided at this point.
                                To claim the ownership of the Thing, the owner needs to present the same meta information as registered by the Thing. Before an owner has claimed
                                ownership of the Thing, it will not be returned in any search results. A list of predefined meta tag names can be found in the <a href="#tags">Meta Tags</a>
                                section below.
                        </p>
                        <p class="" style="">
                                The Thing can register itself as many times as it wants, and the response is always empty. Only one record per resource-less JID must be created. A new
                                registration overrides any previous information, including meta tags previously reported but not available in the new registration. Once a Thing has been
                                claimed by an owner, it should not register itself again, unless it is reset and the installation process restarted.
                        </p>
                        <p class="" style="">
                                If the Thing tries to register itself even though the Thing has already been claimed in the registry, the registry must not update any meta data in the registry, and instead
                                respond with the following response. When the thing receives this, it can safely extract the JID of the owner and switch its internal state to claimed.
                        </p>
                        <p class="caption"><a name="example-11"></a>Example 11. Registration response when alrady claimed</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='1'>
      <claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                <span class="strong">Note:</span> Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.
                        </p>
                </div>
                <div class="indent">
      <h3>3.7 <a name="sect-ID0ESNAE">Register self-owned Thing</a></h3>
                        <p class="" style="">
                                If a thing is self-owned, it can register itself with the Registry as normal, with the addition of setting the attribute <span class="strong">selfOwned</span> to <span class="strong">true</span>,
                                as is shown below. This registers the Thing directly as PUBLIC CLAIMED, with no need for an owner to claim ownership of the device. This can be useful if
                                installing Things that should be publically available.
                        </p>
                        <p class="caption"><a name="example-12"></a>Example 12. Register self-owned Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='2'>
      <register xmlns='urn:xmpp:iot:discovery' selfOwned='true'>
          <str name='SN' value='394872348732948723'/>
          <str name='MAN' value='www.ktc.se'/>
          <str name='MODEL' value='IMC'/>
          <num name='V' value='1.2'/>
          <str name='KEY' value='4857402340298342'/>
      </register>
   </iq>
   
   <iq type='result'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='2'/>
                        </pre>
      </div>
                </div>
                <div class="indent">
      <h3>3.8 <a name="sect-ID0EDOAE">Register Thing behind Concentrator</a></h3>
                        <p class="" style="">
                                A Thing might reside behind a gateway or concentrator and might not be directly connected to the XMPP network itself, as is described in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0326.html">Internet of Things - Concentrators</a></span>  [<a href="#nt-ID0EROAE">18</a>]. In these cases, there are three optional
                                attributes that can be used to identify the Thing behind the JID: The <span class="strong">nodeId</span> attribute gives the ID of the Thing (a.k.a. "Node"). The Node might reside in
                                specific Data Source (large systems might have multiple sources of nodes). In this case, the data source is specified in the <span class="strong">sourceId</span> attribute. Normally, the Node ID
                                is considered to be unique within the concentrator. If multiple data sources are available, the Node ID is unique within the data source. However, a third attribute allows the uniqueness
                                to be restricted to a given <span class="strong">cacheType</span>. Finally, it is the triple (<span class="strong">nodeId</span>, <span class="strong">sourceId</span>, <span class="strong">cacheType</span>) which guarantees
                                uniqueness within the concentrator.
                        </p>
                        <p class="" style="">
                                For a Thing controlled by a concentrator to register itself in the Thing Registry, it simply adds the optional attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> as appropriate to the registration request, as follows:
                        </p>
                        <p class="caption"><a name="example-13"></a>Example 13. Register Thing behind Concentrator</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='rack@clayster.com/plcs'
       to='discovery.clayster.com'
       id='3'>
      <register xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'>
          <str name='SN' value='394872348732948723'/>
          <str name='MAN' value='www.ktc.se'/>
          <str name='MODEL' value='IMC'/>
          <num name='V' value='1.2'/>
          <str name='KEY' value='4857402340298342'/>
      </register>
   </iq>
   
   <iq type='result'
       from='discovery.clayster.com'
       to='rack@clayster.com/plcs'
       id='3'/>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing behind the concentrator is self-owned, it simply adds the <span class="strong">selfOwned</span> attribute to the request and sets it to <span class="strong">true</span>.
                        </p>
                </div>
                <div class="indent">
      <h3>3.9 <a name="sect-ID0E3PAE">Claiming Ownership of a Thing</a></h3>
                        <p class="" style="">
                                As mentioned above, the owner of the Thing must provide the information provided by the Thing to the Registry, in order to claim ownership over it. To avoid the
                                possibility that somebody can guess the information, the information must necessarily be long. This creates the problem of transfer of information. One method to solve this
                                is through the use of QR-codes. Such codes can be either printed on a sticker and put on the Thing itself, its wrapping, or displayed on its display when not claimed.
                                This QR-code can then be photographed by a smart phone or tablet, decoded and the information retrieved can be used in the ownership claim call.
                        </p>
                        <p class="" style="">
                                If QR-codes are used to transfer Thing meta data for ownership claims, it must be generated as follows: To the string "IoTDisco" is appended all meta tags in order.
                                Each tag name is prefixed by a semi-colon (;), and if the tag is numeric, the tag is prefixed by an additional hash sign (#). Each tag value is prefixed by a colon (:). 
                                If the meta value contains semi-colons or back-slashes, each one is prefixed by a back-slash. When decoding the string, this allows the decoder to correctly differ 
                                between tag delimiters and characters belonging to tag values. A tag name must never contain colon, hash sign or white space characters.
                        </p>
                        <p class="" style="">
                                The above meta data would therefore generate the string:
                        </p>
                        <p class="caption"><a name="example-14"></a>Example 14. String to encode as a QR-code</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   IoTDisco;SN:394872348732948723;MAN:www.ktc.se;MODEL:IMC;#V:1.2;KEY:4857402340298342
                        </pre>
      </div>
                        <p class="" style="">
                                Using UTF-8 encoding when generating the QR-code, this string returns the following QR-code:
                        </p>
                        <p class="" style="">
                                <img alt="" src="https://chart.googleapis.com/chart?cht=qr&chs=200x200&chl=IoTDisco;SN:394872348732948723;MAN:www.ktc.se;MODEL:IMC;#V:1.2;KEY:4857402340298342">
                        </p>
                        <p class="" style="">
                                To generate a QR-code, Google Chart API can be used:
                                <a href="https://chart.googleapis.com/chart?cht=qr&chs=200x200&chl=IoTDisco;SN:394872348732948723;MAN:www.ktc.se;MODEL:IMC;#V:1.2;KEY:4857402340298342">https://chart.googleapis.com/chart?cht=qr&chs=200x200&chl=IoTDisco;SN:394872348732948723;MAN:www.ktc.se;MODEL:IMC;#V:1.2;KEY:4857402340298342</a>
                        </p>
                        <p class="" style="">
                                Once the client has the required meta information about the Thing to claim ownership, it sends itself the following request to the Thing Registry:
                        </p>
                        <p class="caption"><a name="example-15"></a>Example 15. Claim Ownership of public Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='owner@clayster.com/phone'
       to='discovery.clayster.com'
       id='4'>
      <mine xmlns='urn:xmpp:iot:discovery'>
          <str name='SN' value='394872348732948723'/>
          <str name='MAN' value='www.ktc.se'/>
          <str name='MODEL' value='IMC'/>
          <num name='V' value='1.2'/>
          <str name='KEY' value='4857402340298342'/>
      </mine>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If this claim is successful, the Thing is marked as a public claimed Thing. The thing can always be removed later, but after the claim, the Thing is public. If you want to claim
                                a private Thing, you can add the <span class="strong">public</span> attribute with value <span class="strong">false</span> to the claim, as follows:
                        </p>
                        <p class="caption"><a name="example-16"></a>Example 16. Claim Ownership of private Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='owner@clayster.com/phone'
       to='discovery.clayster.com'
       id='4'>
      <mine xmlns='urn:xmpp:iot:discovery' public='false'>
          <str name='SN' value='394872348732948723'/>
          <str name='MAN' value='www.ktc.se'/>
          <str name='MODEL' value='IMC'/>
          <num name='V' value='1.2'/>
          <str name='KEY' value='4857402340298342'/>
      </mine>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                In this case, if the claim is successful, the Thing will not be made public in the Thing Registry, after the claim.
                        </p>
                        <p class="" style="">
                                If a claim is successful, i.e. there's a Thing that has not been claimed with EXACTLY the same meta data (however, the order is not important), the Thing is marked in the
                                Registry as CLAIMED, and as public or private depending on the <span class="strong">public</span> attribute, and an empty result is returned as follows. If there's a claimed Thing with
                                exactly the same meta data, and the JID of the claimant (without resource) matches the JID of the claimer (without resource), a success response is also returned, containing
                                the resource-less JID of the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-17"></a>Example 17. Ownership claim successful</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='4'>
      <claimed xmlns='urn:xmpp:iot:discovery' jid='thing@clayster.com'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing that has been claimed resides behind a concentrator, the result will contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing in calls made using <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0323.html">Internet of Things - Sensor Data</a></span>  [<a href="#nt-ID0EUSAE">19</a>], <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0324.html">Internet of Things - Provisioning</a></span>  [<a href="#nt-ID0EATAE">20</a>], <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0325.html">Internet of Things - Control</a></span>  [<a href="#nt-ID0EMTAE">21</a>] and <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0326.html">Internet of Things - Concentrators</a></span>  [<a href="#nt-ID0EYTAE">22</a>]. The following example illustrates
                                a response where a Thing behind a Concentrator has been claimed:
                        </p>
                        <p class="caption"><a name="example-18"></a>Example 18. Ownership claim of a Thing behind a concentrator successful</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='4'>
      <claimed xmlns='urn:xmpp:iot:discovery' jid='rack@clayster.com/plcs' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If, on the other hand, no such Thing was found, or if such a Thing was found, but it is already claimed by somebody else, a failure response is returned. This response
                                should avoid to inform the client in detail why the claim failed, as follows:
                        </p>
                        <p class="caption"><a name="example-19"></a>Example 19. Ownership claim failure</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='error'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='4'>
      <error type='cancel'>
         <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      </error>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                When the Thing has been successfully claimed, the Registry sends information about this to the Thing, to inform it that it has been claimed and the resource-less JID of owner.
                                After receiving this information, it doesn't need to register itself with the Registry anymore.
                        </p>
                        <p class="caption"><a name="example-20"></a>Example 20. Ownership claimed</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='5'>
      <claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing was claimed as a private Thing, this is shown using the <span class="strong">public</span> attribute in the response, as follows:
                        </p>
                        <p class="caption"><a name="example-21"></a>Example 21. Ownership claim of private Thing successful</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='5'>
      <claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com' public='false'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the <span class="strong">public</span> attribute is present and has value <span class="strong">false</span>, it means no further meta data updates are necessary, since
                                the device is not searchable through the Thing Registry.
                        </p>
                        <p class="" style="">
                                If the Thing resides behind a concentrator, the request must contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-22"></a>Example 22. Ownership of Thing behind concentrator claimed</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='rack@clayster.com/plcs'
       id='5'>
      <claimed xmlns='urn:xmpp:iot:discovery' jid='owner@clayster.com' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                The Thing simply returns an empty response to acknowledge the receipt of the information, as follows:
                        </p>
                        <p class="caption"><a name="example-23"></a>Example 23. Ownership claimed acknowledged</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='5'/>
                        </pre>
      </div>
                        <p class="" style="">
                                After receiving this, the thing knows it can accept friendship requests from the corresponding owner. It can also safely send a friendship request to the owner.
                        </p>
                        <p class="" style="">
                                <span class="strong">Note:</span> Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.
                        </p>
                </div>
                <div class="indent">
      <h3>3.10 <a name="sect-ID0EEWAE">Removing Thing from Registry</a></h3>
                        <p class="" style="">
                                After a Thing has been claimed and is registed as a PUBLIC CLAIMED Thing in the Registry, it implies the Thing is available in searches. The owner can choose to remove
                                the Thing from the Registry, to avoid that the Thing appears in searches. To remove a Thing from the Registry the owner simply sends a removal request to the Registry
                                with the resource-less JID of the Thing to remove, as follows:
                        </p>
                        <p class="caption"><a name="example-24"></a>Example 24. Remove Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='owner@clayster.com/phone'
       to='discovery.clayster.com'
       id='6'>
      <remove xmlns='urn:xmpp:iot:discovery' jid='thing@clayster.com'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing resides behind a concentrator, the request must contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-25"></a>Example 25. Remove Thing behind concentrator</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='owner@clayster.com/phone'
       to='discovery.clayster.com'
       id='6'>
      <remove xmlns='urn:xmpp:iot:discovery' jid='rack@clayster.com/plcs' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If such a Thing is found and is owned by the caller, it is removed from the Registry, and an empty response is returned, to acknowledge the removal of the Thing
                                from the registry, as follows:
                        </p>
                        <p class="caption"><a name="example-26"></a>Example 26. Thing removed</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='6'/>
                        </pre>
      </div>
                        <p class="" style="">
                                However, if such a thing is not found, or if the thing is owned by another, an <span class="strong">item-not-found</span> error is returned, as follows:
                        </p>
                        <p class="caption"><a name="example-27"></a>Example 27. Removal failure</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='error'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='6'>
      <error type='cancel'>
         <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      </error>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                After successfully removing a Thing from the Registry, and if the Thing is friend to the Registry, the Registry informs the Thing it has been removed from the Registry.
                                It does this, so the Thing can remove the friendship and stop any meta data updates to the Registry.
                        </p>
                        <p class="caption"><a name="example-28"></a>Example 28. Thing removed from registry by owner</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='7'>
      <removed xmlns='urn:xmpp:iot:discovery'/>
   </iq>
   
   <iq type='result'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='7'/>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing lies behind a concentrator, the removal request would look as follows:
                        </p>
                        <p class="caption"><a name="example-29"></a>Example 29. Thing behind concentrator removed from registry by owner</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='rack@clayster.com/plcs'
       id='7'>
      <removed xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                The Thing acknowledges the removal request by returning an empty response, as follows:
                        </p>
                        <p class="caption"><a name="example-30"></a>Example 30. Removal acknowledgement</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='7'/>
                        </pre>
      </div>
                </div>
                <div class="indent">
      <h3>3.11 <a name="sect-ID0EEYAE">Finding Provisioning Server</a></h3>
                        <p class="" style="">
                                Up to this point only basic configuration and ownership and visibility of a Thing has been covered. For more advanced operations, a Thing might be required to
                                use a Provisioning Server to whom it can delegate trust and allow making decisions, controlling access rights and privileges for the Thing, as described in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0324.html">Internet of Things - Provisioning</a></span>  [<a href="#nt-ID0ESYAE">23</a>].
                                If a Provisioning Server is not preconfigured, one must be found. The following lists methods to obtaining the JID for the Provisioning Server.
                        </p>
                        <ol start="" class="" style="">
                                <li class="" style="">
                                        Preconfigured Component Address of Provisioning Server. A Component address is normally a subdomain to the domain of the XMPP Server that hosts the component.
                                </li>
                                <li class="" style="">
                                        Preconfigured bare JID of Provisioning Server.
                                </li>
                                <li class="" style="">
                                        Preconfigured subdomain part of Component Address. This will be added to the domain of the XMPP Server used to connet to.
                                </li>
                                <li class="" style="">
                                        Preconfigured user name of JID. This will be added to the domain of the XMPP Server used to connected to.
                                </li>
                                <li class="" style="">
                                        The Thing Registry itself can be a Provisioning Server. This can be found out by sending a discovery request to the Thing Registry,
                                        as described in <a href="#support">Determining Support</a>.
                                </li>
                                <li class="" style="">
                                        The Owner itself can be a Provisioning Server. This can be found out by sending a discovery request to the Owner,
                                        as described in <a href="#support">Determining Support</a>.
                                </li>
                                <li class="" style="">
                                        Searching through Server Components on the XMPP Server currently connected to, as described in <a href="#support">Determining Support</a>.
                                </li>
                        </ol>
                </div>
                <div class="indent">
      <h3>3.12 <a name="sect-ID0EI1AE">Delegating Trust</a></h3>
                        <p class="" style="">
                                Once a Provisioning Server has been found and been befriended, the Thing can delegate its trust to it, according to <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0324.html">Internet of Things - Provisioning</a></span>  [<a href="#nt-ID0EW1AE">24</a>].
                        </p>
                </div>
                <div class="indent">
      <h3>3.13 <a name="sect-ID0E51AE">Update Meta Information about Thing in Registry</a></h3>
                        <p class="" style="">
                                Once a Thing has been claimed and chooses to reside as a public Thing in the registry, it can update its meta information at any time. This meta information
                                will be available in searches made to the registry by third parties and is considered public. However, the Thing should be connected to a provisioning server
                                at this point, so that correct decisions can be made regarding to friendship, readout and control requests made by parties other than the owner.
                        </p>
                        <p class="" style="">
                                Meta information updated in this way will only overwrite tags provided in the request, and leave other tags previously reported as is. To remove a string-valued tag,
                                it should be updated with an empty value. It is also recommended that key meta information required to claim ownership of the Thing after a factory reset is
                                either removed, truncated or otherwise modified after it has been claimed so that third parties with physical access to a public Thing cannot hijack it by searching
                                for it, extracting its meta information from the registry, then resetting it and then claiming ownership of it.
                        </p>
                        <p class="" style="">
                                To update meta data about itself, a Thing simply sends a request to the Thing Registry, as follows:
                        </p>
                        <p class="caption"><a name="example-31"></a>Example 31. Update Meta Data request</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='8'>
      <update xmlns='urn:xmpp:iot:discovery'>
          <str name='KEY' value=''/>
          <str name='CLASS' value='PLC'/>
          <num name='LON' value='-71.519722'/>
          <num name='LAT' value='-33.008055'/>
      </update>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing resides behind a concentrator, the request must contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-32"></a>Example 32. Update Meta Data of Thing behind concentrator</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='rack@clayster.com/plcs'
       to='discovery.clayster.com'
       id='8'>
      <update xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'>
          <str name='KEY' value=''/>
          <str name='CLASS' value='PLC'/>
          <num name='LON' value='-71.519722'/>
          <num name='LAT' value='-33.008055'/>
      </update>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing is found in the registry and it is claimed, the registry simply acknowledges the update as follows:
                        </p>
                        <p class="caption"><a name="example-33"></a>Example 33. Update Meta Data request acknowledgement</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='8'/>
                        </pre>
      </div>
                        <p class="" style="">
                                However, if the Thing is not found in the registry, probably because the owner has removed it from the registry, an error response is returned. When receiving
                                such a response, the Thing should assume it is the owner who has removed it from the registry, and that further meta data updates are not desired. The Thing
                                can then unfriend the registry and stop further meta data updates. The error response from the registry would look as follows:
                        </p>
                        <p class="caption"><a name="example-34"></a>Example 34. Update Meta Data request failure</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='error'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='8'>
      <error type='cancel'>
         <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      </error>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing on the other hand is found in the Registry, but is not claimed, the registry must not update any meta data in the registry, and instead
                                respond with the following response. When the thing receives this, the Thing can assume it has been disowned, and perform a new registration in the Registry so
                                that it can be re-claimed.
                        </p>
                        <p class="caption"><a name="example-35"></a>Example 35. Update Meta Data response to request from disowned Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='8'>
      <disowned xmlns='urn:xmpp:iot:discovery'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                <span class="strong">Note:</span> Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.
                        </p>
                </div>
                <div class="indent">
      <h3>3.14 <a name="sect-ID0E33AE">Search for Public Things in Registry</a></h3>
                        <p class="" style="">
                                It is possible for anyone with access to the Thing Registry to search for public Things that have been claimed, including self-owned Things. Such searches
                                will never return things that have not been claimed or have been removed from the registry.
                        </p>
                        <p class="" style="">
                                A search is performed by providing one or more comparison operators in a search request to the registry. If more than one comparison operator is provided, the
                                search is assumed to be performed on the intersection (i.e. AND) of all operators. If the union (i.e. OR) of different conditions is desired, multiple consecutive
                                searches have to be performed.
                        </p>
                        <p class="" style="">
                                The following table lists available search operators, their element names and meanings:
                        </p>
                        <div class="indent">
        <p class="caption"><a name="table-2"></a>Table 2: Search operators</p>
        <table border="1" cellpadding="3" cellspacing="0">
                                <tr class="body">
                                        <th colspan="" rowspan="">Element</th>
                                        <th colspan="" rowspan="">Type</th>
                                        <th colspan="" rowspan="">Operator</th>
                                        <th colspan="" rowspan="">Description</th>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strEq</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag = c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strNEq</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag <> c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values not equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strGt</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag > c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values greater than a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strGtEq</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag >= c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values greater than or equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strLt</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag < c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values lesser than a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strLtEq</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag <= c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values lesser than or equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strRange</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">min <(=) tag <(=) max</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values within a specified range of values. The endpoints can be included or excluded in the search.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strNRange</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag <(=) min OR tag >(=) max</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values outside of a specified range of values. The endpoints can be included or excluded in the range (and therefore correspondingly excluded or included in the search).</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">strMask</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">tag LIKE c</td>
                                        <td colspan="" rowspan="">Searches for string values tags with values similar to a provided constant value including wildcards.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numEq</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag = c</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numNEq</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag <> c</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values not equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numGt</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag > c</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values greater than a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numGtEq</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag >= c</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values greater than or equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numLt</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag < c</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values lesser than a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numLtEq</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag <= c</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values lesser than or equal to a provided constant value.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numRange</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">min <(=) tag <(=) max</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values within a specified range of values. The endpoints can be included or excluded in the search.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">numNRange</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">tag <(=) min OR tag >(=) max</td>
                                        <td colspan="" rowspan="">Searches for numerical values tags with values outside of a specified range of values. The endpoints can be included or excluded in the range (and therefore correspondingly excluded or included in the search).</td>
                                </tr>
                        </table>
      </div>
                        <p class="" style="">
                                The following example shows how a search for specific devices within a specific geographic area can be found. More precisely, it searches for a certain kind of PLC
                                produced by a certain manufacturer, but only versions 1.0 <= v < 2.0 and with serial numbers beginning with 39487. The PLCs must also lie within latitude 33 ad 34
                                degrees south and between longitude 70 and 72 west.
                        </p>
                        <p class="caption"><a name="example-36"></a>Example 36. Searching for Things</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='get'
       from='curious@clayster.com/client'
       to='discovery.clayster.com'
       id='9'>
      <search xmlns='urn:xmpp:iot:discovery' offset='0' maxCount='20'>
          <strEq name='MAN' value='www.ktc.se'/>
          <strEq name='MODEL' value='IMC'/>
          <strMask name='SN' value='39487*' wildcard='*'/>
          <numRange name='V' min='1' minIncluded='true' max='2' maxIncluded='false'/>
          <numRange name='LON' min='-72' minIncluded='true' max='-70' maxIncluded='true'/>
          <numRange name='LAT' min='-34' minIncluded='true' max='-33' maxIncluded='true'/>
      </search>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                The <span class="strong">offset</span> attribute tells the registry the number of responses to skip before returning found things. It provides a mechanism to page result sets
                                that are too large to return in one response. the <span class="strong">maxCount</span> attribute contains the desired maximum number of things to return in the response. The
                                registry can lower this value, if it decides the requested maximum number is too large.
                        </p>
                        <p class="" style="">
                                If tag names are not found corresponding to the names provided in the search, the result set will always be empty. There's a reserved tag named <span class="strong">KEY</span>
                                that can be used to provide information shared only between things and their owners. If a search contains an operator referencing this tag name, the result set
                                must also always be empty. Searches on <span class="strong">KEY</span> MUST never find things. Furthermore, search results must never return <span class="strong">KEY</span> tags.
                        </p>
                        <p class="" style="">
                                The registry returns any things found in a response similar to the following:
                        </p>
                        <p class="caption"><a name="example-37"></a>Example 37. Search result</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='curious@clayster.com/client'
       id='9'>
      <found xmlns='urn:xmpp:iot:discovery' more='false'>
          <thing owner='owner@clayster.com' jid='thing@clayster.com'>
             <str name='SN' value='394872348732948723'/>
             <str name='MAN' value='www.ktc.se'/>
             <str name='MODEL' value='IMC'/>
             <num name='V' value='1.2'/>
             <str name='CLASS' value='PLC'/>
             <num name='LON' value='-71.519722'/>
             <num name='LAT' value='-33.008055'/>
          </thing>
          ...
      </found>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If a Thing resides behind a concentrator, the response must contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-38"></a>Example 38. Search result containing Thing behind a concentrator</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='curious@clayster.com/client'
       id='9'>
      <found xmlns='urn:xmpp:iot:discovery' more='false'>
          <thing owner='owner@clayster.com' jid='rack@clayster.com' nodeId='imc1' sourceId='MeteringTopology'>
             <str name='SN' value='394872348732948723'/>
             <str name='MAN' value='www.ktc.se'/>
             <str name='MODEL' value='IMC'/>
             <num name='V' value='1.2'/>
             <str name='CLASS' value='PLC'/>
             <num name='LON' value='-71.519722'/>
             <num name='LAT' value='-33.008055'/>
          </thing>
          ...
      </found>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If more results are available in the search (accessible by using the <span class="strong">offset</span> attribute in a new search), the <span class="strong">more</span> attribute is
                                present with value <span class="strong">true</span>.
                        </p>
                        <p class="" style="">
                                <span class="strong">Note:</span> Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.
                        </p>
                </div>
                <div class="indent">
      <h3>3.15 <a name="sect-ID0EKKAG">Unregistering Thing from Registry</a></h3>
                        <p class="" style="">
                                A thing can unregister itself from the Registry. This can be done in an uninstallation procedure for instance. To unregister from the registry, it simply sends
                                an un-registration request to the registry as follows.
                        </p>
                        <p class="caption"><a name="example-39"></a>Example 39. Unregister Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='10'>
      <unregister xmlns='urn:xmpp:iot:discovery'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing resides behind a concentrator, the request must contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-40"></a>Example 40. Unregistring Thing behind concentrator</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='rack@clayster.com/plcs'
       to='discovery.clayster.com'
       id='10'>
      <unregister xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                The registry always returns an empty response, simply to acknowledge the receipt of the request.
                        </p>
                        <p class="caption"><a name="example-41"></a>Example 41. Unregister Thing acknowledgement</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='10'/>
                        </pre>
      </div>
                </div>
                <div class="indent">
      <h3>3.16 <a name="sect-ID0ELLAG">Disowning Thing</a></h3>
                        <p class="" style="">
                                The owner of a Thing can disown the Thing, returning it to a state without owner. This is done by sending the following request to the Thing Registry:
                        </p>
                        <p class="caption"><a name="example-42"></a>Example 42. Disowning Thing</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='owner@clayster.com/phone'
       to='discovery.clayster.com'
       id='11'>
      <disown xmlns='urn:xmpp:iot:discovery' jid='thing@clayster.com'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing resides behind a concentrator, the request must contain those of the attributes <span class="strong">nodeId</span>, <span class="strong">sourceId</span>
                                and <span class="strong">cacheType</span> that are required to access the Thing, as follows:
                        </p>
                        <p class="caption"><a name="example-43"></a>Example 43. Disowning Thing behind concentrator</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='owner@clayster.com/phone'
       to='discovery.clayster.com'
       id='11'>
      <disown xmlns='urn:xmpp:iot:discovery' jid='rack@clayster.com/plcs' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If such a Thing is not found, or if the thing is not owned by the caller, an <span class="strong">item-not-found</span> error is returned, as follows:
                        </p>
                        <p class="caption"><a name="example-44"></a>Example 44. Failure to disown Thing - Not Found</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='error'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='11'>
      <error type='cancel'>
         <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      </error>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If such a Thing is found, and it is owned by the caller, but not online as a friend, the Thing cannot be disowned, since it would put the Thing in a state from which
                                it cannot be re-claimed. Therefore, the Thing Registry must respond in the following manner:
                        </p>
                        <p class="caption"><a name="example-45"></a>Example 45. Failure to disown Thing - Offline</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='error'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='11'>
      <error type='cancel'>
         <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      </error>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                Before returning a response to the caller, the Thing Registry informs the Thing it has been disowned.
                                It does this, so the Thing can remove the friendship to the owner, and perform a new registration.
                        </p>
                        <p class="caption"><a name="example-46"></a>Example 46. Thing disowned in registry by owner</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='thing@clayster.com/imc'
       id='12'>
      <disowned xmlns='urn:xmpp:iot:discovery'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                If the Thing lies behind a concentrator, the disowned request would look as follows:
                        </p>
                        <p class="caption"><a name="example-47"></a>Example 47. Thing behind concentrator disowned in registry by owner</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='set'
       from='discovery.clayster.com'
       to='rack@clayster.com/plcs'
       id='12'>
      <disowned xmlns='urn:xmpp:iot:discovery' nodeId='imc1' sourceId='MeteringTopology'/>
   </iq>
                        </pre>
      </div>
                        <p class="" style="">
                                The Thing acknowledges that it has been disowned by returning an empty response, as follows:
                        </p>
                        <p class="caption"><a name="example-48"></a>Example 48. Acknowledging disownment</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='thing@clayster.com/imc'
       to='discovery.clayster.com'
       id='12'/>
                        </pre>
      </div>
                        <p class="" style="">
                                When receiving the acknowledgement from the Thing, the Thing is set as an unclaimed Thing in the Registry. Furthermore, all tags corresponding to the Thing are removed from the
                                registry, and a random KEY tag is added of sufficient complexity to make sure other clients cannot claim the Thing by guessing. Finally, an empty response is returned, to 
                                acknowledge that the Thing has been disowned, as follows:
                        </p>
                        <p class="caption"><a name="example-49"></a>Example 49. Thing disowned</p>
      <div class="indent">
        <pre class="prettyprint">
                                
   <iq type='result'
       from='discovery.clayster.com'
       to='owner@clayster.com/phone'
       id='11'/>
                        </pre>
      </div>
                        <p class="" style="">
                                If for any reason, the Thing does not acknowledge the disowned request, or an error occurs, the Registry returns the same error as if the Thing would have been offline.
                        </p>
                </div>
        <h2>4.
       <a name="support">Determining Support</a></h2>
                <p class="" style="">
                        If an entity is a Thing Registry and supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:iot:discovery" in response
                        to <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0030.html">Service Discovery</a></span>  [<a href="#nt-ID0EFOAG">25</a>] information requests.
                </p>
                <p class="caption"><a name="example-50"></a>Example 50. Service discovery information request</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq type='get'
       from='device@clayster.com/device'
       to='provisioning@clayster.com'
       id='13'>
      <query xmlns='http://jabber.org/protocol/disco#info'/>
   </iq>
                </pre>
    </div>
                <p class="caption"><a name="example-51"></a>Example 51. Service discovery information response</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com/device'
       id='13'>
     <query xmlns='http://jabber.org/protocol/disco#info'>
        ...
        <feature var='urn:xmpp:iot:discovery'/>
        ...
     </query>
   </iq>
                </pre>
    </div>
                <p class="" style="">
                        To search for a Thing Registry hosted as a component on an XMPP Server, you first request a list of available components, as follows: 
                </p>
                <p class="caption"><a name="example-52"></a>Example 52. Checking if server supports components</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq from='device@clayster.com/device' to='clayster.com' type='get' id='14'>
      <query xmlns="http://jabber.org/protocol/disco#info"/>
   </iq>
                </pre>
    </div>
                <p class="caption"><a name="example-53"></a>Example 53. Response confirming support for components</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq type="result" id="14" from="clayster.com" to="device@clayster.com/device">
      <query xmlns="http://jabber.org/protocol/disco#info">
         ...
         <feature var="http://jabber.org/protocol/disco#items"/>
         ...
      </query>
   </iq>
                </pre>
    </div>
                <p class="" style="">
                        If components (items) are supported, a request for available components is made:
                </p>
                <p class="caption"><a name="example-54"></a>Example 54. Requesting list of server components</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq from='device@clayster.com/device' to='clayster.com' type='get' id='15'>
      <query xmlns="http://jabber.org/protocol/disco#items"/>
   </iq>
                </pre>
    </div>
                <p class="caption"><a name="example-55"></a>Example 55. Response containing list of server components</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq type="result" id="15" from="clayster.com" to="995fab3dd759452ca9c370647323af0c@clayster.com/ebe2348e">
      <query xmlns="http://jabber.org/protocol/disco#items">
       ...
         <item jid="discovery.clayster.com" name="Registro de cosas"/>
       ...
      </query>
   </iq>
                </pre>
    </div>
                <p class="" style="">
                        The client then loops through all components (items) and checks what features they support, until a Thing Registry is found:
                </p>
                <p class="caption"><a name="example-56"></a>Example 56. Service discovery information request made to each component</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq type='get'
       from='device@clayster.com/device'
       to='discovery.clayster.com'
       id='16'>
      <query xmlns='http://jabber.org/protocol/disco#info'/>
   </iq>
                </pre>
    </div>
                <p class="caption"><a name="example-57"></a>Example 57. Service discovery information response from each component</p>
    <div class="indent">
      <pre class="prettyprint">
                        
   <iq type='result'
       from='provisioning@clayster.com'
       to='device@clayster.com/device'
       id='16'>
      <query xmlns='http://jabber.org/protocol/disco#info'>
         ...
         <feature var='urn:xmpp:iot:discovery'/>
         ...
      </query>
   </iq>
                </pre>
    </div>
        <h2>5.
       <a name="impl">Implementation Notes</a></h2>
                <div class="indent">
      <h3>5.1 <a name="jidvscomponent">JID vs Component Thing Registries</a></h3>
                        <p class="" style="">
                                A client must treat the connection between a Thing Registry differently if it is hosted as a client, having a JID, or if it is hosted as a Jabber Server Component.
                                If it is hosted as a server component, there's no need for the thing to become friends with the Thing Registry. Messages and requests can be made directly to the
                                server component without having to add it to the roster or request presence subscriptions. If the Thing Registry is hosted as a client, having a JID (@ in the address),
                                the Thing Registry must be added to the roster of the client before the client can communicate with the Thing Registry.
                        </p>
                </div>
                <div class="indent">
      <h3>5.2 <a name="tags">Meta Tags</a></h3>
                        <p class="" style="">
                                This document does not limit the number or names of tags used by Things to register meta information about themselves. However, it provides some general limits and defines
                                the meaning of a few tags that must have the meanings specified herein.
                        </p>
                        <p class="" style="">
                                The maximum length of a tag name is <span class="strong">32</span> characters. Tag names must not include colon (:), hash sign (#) or white space characters. String tag values
                                must not exceed 128 characters in length.
                        </p>
                        <p class="" style="">
                                The following table lists predefined tag names and their corresponding meanings.
                        </p>
                        <div class="indent">
        <p class="caption"><a name="table-3"></a>Table 3: Predefined tags</p>
        <table border="1" cellpadding="3" cellspacing="0">
                                <tr class="body">
                                        <th colspan="" rowspan="">Tag Name</th>
                                        <th colspan="" rowspan="">Type</th>
                                        <th colspan="" rowspan="">Description</th>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">ALT</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">Altitude (meters)</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">APT</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Apartment associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">AREA</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Area associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">BLD</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Building associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">CITY</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">City associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">CLASS</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Class of Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">COUNTRY</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Country associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">KEY</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Key, shared between thing and owner.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">LAT</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">Latitude (degrees)</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">LON</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">Longitude (degrees)</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">MAN</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Domain name owned by the Manufacturer</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">MLOC</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Meter Location ID</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">MNR</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Meter Number</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">MODEL</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Name of Model</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">NAME</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Name associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">PURL</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">URL to product information for the Thing.</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">REGION</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Region associated with the Thing</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">SN</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Serial Number</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">STREET</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Street Name</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">STREETNR</td>
                                        <td colspan="" rowspan="">String</td>
                                        <td colspan="" rowspan="">Street Number</td>
                                </tr>
                                <tr class="body">
                                        <td colspan="" rowspan="">V</td>
                                        <td colspan="" rowspan="">Numeric</td>
                                        <td colspan="" rowspan="">Version Number</td>
                                </tr>
                        </table>
      </div>
                        <p class="" style="">
                                It is up to the Thing Registry to choose which tags it persists and which tags it doesn't. To avoid the possibility of malicious reporting of tags, some limit should be
                                imposed on what tags are supported. As a minimum, a Thing Registry must support all predefined tags, as listed above.
                        </p>
                        <p class="" style="">
                                <span class="strong">Note:</span> Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.
                        </p>
                </div>
                <div class="indent">
      <h3>5.3 <a name="sect-ID0EL2AG">Friendships between Things and Registry</a></h3>
                        <p class="" style="">
                                In the case the Thing Registry is not the XMPP Server to which the Thing is connected, a friendship relationship between the Thing and the Thing Registry needs to be handled.
                                To minimize the number of concurrent friends the Thing Registry needs to maintain, a Thing must only maintain an active friendship with the registry if it needs to
                                communicate with the registry. This means that unless updating meta data frequently, the Thing must unfriend the Registry when done with its communication. If only
                                updating meta data intermittently, the friendship can be reestablished when needed, and removed when done.
                        </p>
                </div>
        <h2>6.
       <a name="security">Security Considerations</a></h2>
                <div class="indent">
      <h3>6.1 <a name="jcp">Jabber Components Protocol</a></h3>
                        <p class="" style="">
                                The <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0114.html">Jabber Component Protocol</a></span>  [<a href="#nt-ID0EH3AG">26</a>] provides an elegant way to introduce external services as server components using a third port into the server (the first two being the client-to-server port
                                and the server-to-server port). But since XEP-0114 is historical, meaning it is not guaranteed to conform to v1.0 of the XMPP specification, it has some serious security
                                issues:
                        </p>
                        <ol start="" class="" style="">
                                <li class="" style="">It lacks SSL/TLS support, or the starttls element to switch to TLS after connecting. This makes it possible to sniff traffic in this port.</li>
                                <li class="" style="">It lacks SASL authentication. Instead a simple handshake is performed</li>
                                <li class="" style="">There is no way to actually verify that the server is the server. This makes it possible to create a simple Man-in-the-middle attack.</li>
                        </ol>
                        <p class="" style="">
                                For these reasons, it is not recommended that a Thing Registry service, publishing itself as a Jabber Server Component, does so from outside of the network. Instead, 
                                the Thing Registry should be installed on the same server or on a server in the same local area network, so that the Jabber Component protocol port is closed to the
                                Internet.
                        </p>
                        <p class="" style="">
                                Since it is not guaranteed that an XMPP Server operator allows installation of third party products (such as a Thing Registry), the option to host a Thing Registry using
                                a normal JID is still available. It can be used in proof of concepts, etc. For scalability issues it is recommended that the Thing Registry be hosted as a Jabber Server
                                Component when the population of Things grows.
                        </p>
                </div>
                <div class="indent">
      <h3>6.2 <a name="sect-ID0EJ4AG">Hijacking predefined JIDs</a></h3>
                        <p class="" style="">
                                If using predefined user names when searching for a Thing Registry or Provisioning Server, care must be taken to which XMPP Server things connect.
                                It might be possible for third parties to register these predefined account names, and pretend to be a Thing Registry or Provisioning Server and in this way hijack 
                                unsuspecting Things. If installing things using this method of finding a Thing Registry or Provisioning Server, these accounts must be registered beforehand, to make 
                                sure the things cannot be hijacked.
                        </p>
                </div>
                <div class="indent">
      <h3>6.3 <a name="sect-ID0ES4AG">Hijacking things in public areas</a></h3>
                        <p class="" style="">
                                The combination of visible key meta information (perhaps in a visible QR-code) and a factory default reset button on a Thing, opens up the possibility to hijack the Thing.
                                To avoid this, at least one of the two should be removed after successful installation. Either the key meta information (QR-code) should be placed on the package or separate
                                paper and not on the thing itself, or the factory default reset button should be sealed or hidden and only accessible by licensed maintenance personell. If using an electronic
                                means to present the key meta information (for instance by displayed a QR-code on a display on the thing), care should be taken so that the information cannot be displayed
                                without breaking a seal, or other means to protect the Thing.
                        </p>
                        <p class="" style="">
                                Regardless the above security measures, a Thing can be hijacked by a third party in the time window between successful installation of the device and until the correct owner
                                has claimed ownership of the device. Minimizing this time window, and using a shared secret (KEY tag) between the Thing and its owner, decreases the possibility of getting the
                                thing hijacked.
                        </p>
                </div>
                <div class="indent">
      <h3>6.4 <a name="sect-ID0E64AG">Key meta information in searches</a></h3>
                        <p class="" style="">
                                Care should be taken what key meta information is used to accept an ownership claim. After a successful claim, this meta information is still available in the registry,
                                at least until the Thing is removed from the registry. While public in the registry, the meta information can be searched and presented to third parties. Access to this
                                information can help third parties to hijack Things, if they can reset them to factory default settings.
                        </p>
                        <p class="" style="">
                                To avoid this, the Thing can do three things after a successful ownership claim:
                        </p>
                        <ul class="" style="">
                                <li class="" style="">
                                        Including a <span class="strong">KEY</span> tag in the key meta information. The <span class="strong">KEY</span> tag is not searchable nor presented in search results.
                                </li>
                                <li class="" style="">
                                        Remove, truncate or change some key meta information after a successful ownership claim. Partial information is not sufficient for a successful ownership claim.
                                </li>
                                <li class="" style="">
                                        Remove the Thing from the registry.
                                </li>
                        </ul>
                </div>
                <div class="indent">
      <h3>6.5 <a name="sect-ID0EC6AG">KEY tag</a></h3>
                        <p class="" style="">
                                The <span class="strong">KEY</span> tag is unique in that it is not searchable nor available is search results. For this reason it is ideal for providing secrets shared only
                                between the Thing and the owner. By providing a sufficiently long KEY value in the key meta information required to claim the Thing, guessing the information even though
                                the other meta information is available, will be sufficiently hard to make it practically impossible.
                        </p>
                        <p class="" style="">
                                Even though the <span class="strong">KEY</span> tag is not searchable or available in search results, it should be emptied by the Thing after a successful claim, just to make sure
                                the key cannot be learned by looking into the database of the registry, or by some other means.
                        </p>
                </div>
                <div class="indent">
      <h3>6.6 <a name="sect-ID0EV6AG">Tag name spam</a></h3>
                        <p class="" style="">
                                This document does not limit tag names or the number of tags that can be used by Things. This opens up the possibility of tag spam. Malicious things could fill the database
                                of the registry by reporting random tag names until the database is full.
                        </p>
                        <p class="" style="">
                                To prevent such malicious attacks, the registry could limit the tags it allows to be stored in the database. The registry must however allow the storage of the predefined
                                tag names defined in this document. If it has a configurable list of approved tags that can be stored, or if it allows any tags is an implementation decision.
                        </p>
                </div>
                <div class="indent">
      <h3>6.7 <a name="sect-ID0ECABG">External services for creating QR-codes</a></h3>
                        <p class="" style="">
                                If using external services when creating QR-codes, like the Google Charts API used in this document, make sure HTTPS is used and certificates validated. If HTTP is used,
                                meta-data tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices.
                        </p>
                </div>
                <div class="indent">
      <h3>6..1 <a name="sect-ID0ELABG">DHCP Security Considerations</a></h3>
                        <p class="" style="">TBD</p>
                        
                </div>
                <div class="indent">
      <h3>6..2 <a name="sect-ID0EWABG">DNS Security Considerations</a></h3>
                        <p class="" style="">TBD</p>
                        
                </div>
                <div class="indent">
      <h3>6..3 <a name="sect-ID0EBBBG">UPnP Security Considerations</a></h3>
                        <p class="" style="">TBD</p>
                        
                </div>
        <h2>7.
       <a name="iana">IANA Considerations</a></h2>
                <p class="" style="">This document requires no interaction with the <span class="ref" style=""><a href="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a></span>  [<a href="#nt-ID0E2BBG">27</a>].</p>
        <h2>8.
       <a name="registrar">XMPP Registrar Considerations</a></h2>
                <p class="" style="">
                        The <a href="#schema">protocol schema</a> needs to be added to the list of <a href="http://xmpp.org/resources/schemas/">XMPP protocol schemas</a>.
                </p>
        <h2>9.
       <a name="schema">XML Schema</a></h2>
                <p class="caption">
    </p>
    <div class="indent">
      <pre class="prettyprint">
                        
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:iot:discovery'
    xmlns='urn:xmpp:iot:discovery'
    elementFormDefault='qualified'>
 
    <xs:element name='register' type='Register'/>
    <xs:element name='mine' type='Mine'/>
    <xs:element name='update' type='MetaDataNodeInfo'/>
 
    <xs:element name='claimed' type='Claimed'/>
    <xs:element name='remove' type='Jid'/>
    <xs:element name='removed' type='NodeInfo'/>
    <xs:element name='unregister' type='NodeInfo'/>
    <xs:element name='disown' type='Jid'/>
    <xs:element name='disowned' type='NodeInfo'/>
 
    <xs:element name='search'>
        <xs:complexType>
            <xs:choice minOccurs='1' maxOccurs='unbounded'>
                <xs:element name='strEq' type='StrTag'/>
                <xs:element name='strNEq' type='StrTag'/>
                <xs:element name='strGt' type='StrTag'/>
                <xs:element name='strGtEq' type='StrTag'/>
                <xs:element name='strLt' type='StrTag'/>
                <xs:element name='strLtEq' type='StrTag'/>
                <xs:element name='strRange' type='StrRange'/>
                <xs:element name='strNRange' type='StrRange'/>
                <xs:element name='strMask'>
                    <xs:complexType>
                        <xs:attribute name='name' type='xs:string' use='required'/>
                        <xs:attribute name='value' type='xs:string' use='required'/>
                        <xs:attribute name='wildcard' type='xs:string' use='required'/>
                    </xs:complexType>
                </xs:element>
                <xs:element name='numEq' type='NumTag'/>
                <xs:element name='numNEq' type='NumTag'/>
                <xs:element name='numGt' type='NumTag'/>
                <xs:element name='numGtEq' type='NumTag'/>
                <xs:element name='numLt' type='NumTag'/>
                <xs:element name='numLtEq' type='NumTag'/>
                <xs:element name='numRange' type='NumRange'/>
                <xs:element name='numNRange' type='NumRange'/>
            </xs:choice>
            <xs:attribute name='offset' type='xs:nonNegativeInteger' use='optional' default='0'/>
            <xs:attribute name='maxCount' type='xs:positiveInteger' use='optional'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='found'>
        <xs:complexType>
            <xs:sequence minOccurs='0' maxOccurs='unbounded'>
                <xs:element name='thing'>
                    <xs:complexType>
                        <xs:choice minOccurs='0' maxOccurs='unbounded'>
                            <xs:element name='str' type='StrTag'/>
                            <xs:element name='num' type='NumTag'/>
                        </xs:choice>
                        <xs:attribute name='owner' type='xs:string' use='required'/>
                        <xs:attribute name='jid' type='xs:string' use='required'/>
                        <xs:attributeGroup ref='nodeInfo'/>
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
            <xs:attribute name='more' type='xs:boolean' use='optional' default='false'/>
        </xs:complexType>
    </xs:element>
 
    <xs:attributeGroup name='nodeInfo'>
        <xs:attribute name='nodeId' type='xs:string' use='optional'/>
        <xs:attribute name='sourceId' type='xs:string' use='optional'/>
        <xs:attribute name='cacheType' type='xs:string' use='optional'/>
    </xs:attributeGroup>
    
    <xs:complexType name='MetaData'>
        <xs:choice minOccurs='0' maxOccurs='unbounded'>
            <xs:element name='str' type='StrTag'/>
            <xs:element name='num' type='NumTag'/>
        </xs:choice>
        <xs:attributeGroup ref='nodeInfo'/>
    </xs:complexType>
 
    <xs:complexType name='MetaDataNodeInfo'>
        <xs:complexContent>
            <xs:extension base='MetaData'>
                <xs:attributeGroup ref='nodeInfo'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='Register'>
        <xs:complexContent>
            <xs:extension base='MetaDataNodeInfo'>
                <xs:attribute name='selfOwned' type='xs:boolean' use='optional' default='false'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
  
    <xs:complexType name='Mine'>
        <xs:complexContent>
            <xs:extension base='MetaData'>
                <xs:attribute name='public' type='xs:boolean' use='optional' default='true'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='Claimed'>
        <xs:complexContent>
            <xs:extension base='Jid'>
                <xs:attribute name='public' type='xs:boolean' use='optional' default='false'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='Jid'>
        <xs:attribute name='jid' type='xs:string' use='required'/>
        <xs:attributeGroup ref='nodeInfo'/>
    </xs:complexType>
 
    <xs:complexType name='NodeInfo'>
        <xs:attributeGroup ref='nodeInfo'/>
    </xs:complexType>
 
    <xs:complexType name='StrTag'>
        <xs:attribute name='name' type='xs:string' use='required'/>
        <xs:attribute name='value' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='NumTag'>
        <xs:attribute name='name' type='xs:string' use='required'/>
        <xs:attribute name='value' type='xs:double' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='StrRange'>
        <xs:attribute name='name' type='xs:string' use='required'/>
        <xs:attribute name='min' type='xs:string' use='required'/>
        <xs:attribute name='minIncluded' type='xs:boolean' use='optional' default='true'/>
        <xs:attribute name='max' type='xs:string' use='required'/>
        <xs:attribute name='maxIncluded' type='xs:boolean' use='optional' default='true'/>
    </xs:complexType>
 
    <xs:complexType name='NumRange'>
        <xs:attribute name='name' type='xs:string' use='required'/>
        <xs:attribute name='min' type='xs:double' use='required'/>
        <xs:attribute name='minIncluded' type='xs:boolean' use='optional' default='true'/>
        <xs:attribute name='max' type='xs:double' use='required'/>
        <xs:attribute name='maxIncluded' type='xs:boolean' use='optional' default='true'/>
    </xs:complexType>
 
</xs:schema>
                </pre>
    </div>
        <h2>10.
       <a name="moreinfo">For more information</a></h2>
                <p class="" style="">
                        For more information, please see the following resources:
                </p>
                <ul class="" style="">
                        <li class="" style="">
                                <p class="" style="">
                                        The <a href="http://wiki.xmpp.org/web/Tech_pages/SensorNetworks">Sensor Network section of the XMPP Wiki</a> contains further information about the
                                        use of the sensor network XEPs, links to implementations, discussions, etc.
                                </p>
                        </li>
                        <li class="" style="">
                                <p class="" style="">
                                        The XEP's and related projects are also available on <a href="https://github.com/joachimlindborg/">github</a>, thanks to Joachim Lindborg.
                                </p>
                        </li>
                        <li class="" style="">
                                <p class="" style="">
                                        A presentation giving an overview of all extensions related to Internet of Things can be found here:
                                        <a href="http://prezi.com/esosntqhewhs/iot-xmpp/">http://prezi.com/esosntqhewhs/iot-xmpp/</a>.
                                </p>
                        </li>
                </ul>
        <h2>11.
       <a name="ack">Acknowledgements</a></h2>
                <p class="" style="">
                        Thanks to Henrik Svedlund, Ivan Vučica, Joachim Lindborg, Joakim Eriksson, Joakim Ramberg, Johannes Hund, Karin Forsell, Kevin Smith, Lance Stout, Lars Åkerskog, Olof Zandrén, 
                        Philipp Hancke, Steffen Larsen, Teemu Väisänen and Yusuke Doi for all valuable feedback.
                </p>
        <hr><a name="appendices"></a><h2>Appendices</h2>
    <hr><a name="appendix-docinfo"></a><h3>Appendix A: Document Information</h3>
    <p class="indent">
            Series: <a href="http://xmpp.org/extensions/">XEP</a><br>
            Number: xxxx<br>
            Publisher: <a href="/xsf/">XMPP Standards Foundation</a><br>
            Status: 
            <a href="http://xmpp.org/extensions/xep-0001.html#states-ProtoXEP">ProtoXEP</a><br>
            Type:
            <a href="http://xmpp.org/extensions/xep-0001.html#types-Standards Track">Standards Track</a><br>
            Version: 0.0.3<br>
            Last Updated: 2014-04-09<br>
                Approving Body: <a href="http://xmpp.org/council/">XMPP Council</a><br>Dependencies: XMPP Core, XEP-0001, XEP-0030, XEP-0077, XEP-0114, XEP-0174, XEP-0323, XEP-0324, XEP-0325, XEP-0326<br>
                Supersedes: None<br>
                Superseded By: None<br>
            Short Name: NOT_YET_ASSIGNED<br>
            This document in other formats: 
                <a class="standardsButton" href="http://xmpp.org/extensions/xep-xxxx.xml">XML</a> 
                <a class="standardsButton" href="http://xmpp.org/extensions/xep-xxxx.pdf">PDF</a></p>
    <hr><a name="appendix-authorinfo"></a><h3>Appendix B: Author Information</h3>
    <div class="indent">
      <h3>Peter Waher</h3>
      <p class="indent">
        Email:
        <a href="mailto:peter.waher@clayster.com">peter.waher@clayster.com</a><br>
        JabberID: 
        <a href="xmpp:peter.waher@jabber.org">peter.waher@jabber.org</a><br>
        URI: 
        <a href="http://www.linkedin.com/in/peterwaher">http://www.linkedin.com/in/peterwaher</a><br></p>
      <h3>Ronny Klauck</h3>
      <p class="indent">
        Email:
        <a href="mailto:rklauck@informatik.tu-cottbus.de">rklauck@informatik.tu-cottbus.de</a><br>
        JabberID: 
        <a href="xmpp:TBD">TBD</a><br>
        URI: 
        <a href="http://www-rnks.informatik.tu-cottbus.de/~rklauck">http://www-rnks.informatik.tu-cottbus.de/~rklauck</a><br></p>
    </div>
    <hr><a name="appendix-legal"></a><h3>Appendix C: Legal Notices</h3>
    <div class="indent">
      <h4>Copyright</h4>This XMPP Extension Protocol is copyright © 1999 - 2013 by the <a href="http://xmpp.org/">XMPP Standards Foundation</a> (XSF).<h4>Permissions</h4>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.<h4>Disclaimer of Warranty</h4><span style="font-weight: bold">## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##</span><h4>Limitation of Liability</h4>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.<h4>IPR Conformance</h4>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <<a href="http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/">http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/</a>> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).</div>
    <hr><a name="appendix-xmpp"></a><h3>Appendix D: Relation to XMPP</h3>
    <p class="indent">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.</p>
    <hr><a name="appendix-discuss"></a><h3>Appendix E: Discussion Venue</h3>
    <p class="indent">The primary venue for discussion of XMPP Extension Protocols is the <<a href="http://mail.jabber.org/mailman/listinfo/standards">standards@xmpp.org</a>> discussion list.</p>
    <p class="indent">Discussion on other xmpp.org discussion lists might also be appropriate; see <<a href="http://xmpp.org/about/discuss.shtml">http://xmpp.org/about/discuss.shtml</a>> for a complete list.</p>
    <p class="indent">Errata can be sent to <<a href="mailto:editor@xmpp.org">editor@xmpp.org</a>>.</p>
    <hr><a name="appendix-conformance"></a><h3>Appendix F: Requirements Conformance</h3>
    <p class="indent">The following requirements keywords as used in this document are to be interpreted as described in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".</p>
    <hr><a name="appendix-notes"></a><h3>Appendix G: Notes</h3>
    <div class="indent">
      <p><a name="nt-ID0EXCAC">1</a>. XEP-0004: Data Forms <<a href="http://xmpp.org/extensions/xep-0004.html">http://xmpp.org/extensions/xep-0004.html</a>>.</p>
      <p><a name="nt-ID0EODAC">2</a>. XEP-0004: Data Forms <<a href="http://xmpp.org/extensions/xep-0004.html">http://xmpp.org/extensions/xep-0004.html</a>>.</p>
      <p><a name="nt-ID0E1DAC">3</a>. XEP-0122: Data Forms Validation <<a href="http://xmpp.org/extensions/xep-0122.html">http://xmpp.org/extensions/xep-0122.html</a>>.</p>
      <p><a name="nt-ID0EGEAC">4</a>. XEP-0137: Publishing Stream Initiation Requests <<a href="http://xmpp.org/extensions/xep-0137.html">http://xmpp.org/extensions/xep-0137.html</a>>.</p>
      <p><a name="nt-ID0ESEAC">5</a>. XEP-0141: Data Forms Layout <<a href="http://xmpp.org/extensions/xep-0141.html">http://xmpp.org/extensions/xep-0141.html</a>>.</p>
      <p><a name="nt-ID0EUIAC">6</a>. XEP-0326: Internet of Things - Concentrators <<a href="http://xmpp.org/extensions/xep-0326.html">http://xmpp.org/extensions/xep-0326.html</a>>.</p>
      <p><a name="nt-ID0EOPAC">7</a>. 
                                                RFC 3942: Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options <<a href="http://tools.ietf.org/html/rfc3942">http://tools.ietf.org/html/rfc3942</a>>.
                                        </p>
      <p><a name="nt-ID0EFBAE">8</a>. RFC 1035: Domain Names - Implementation and Specification <<a href="http://tools.ietf.org/html/rfc1035">http://tools.ietf.org/html/rfc1035</a>>.</p>
      <p><a name="nt-ID0E1CAE">9</a>. XEP-0174: Link-Local Messaging <<a href="http://xmpp.org/extensions/xep-0174.html">http://xmpp.org/extensions/xep-0174.html</a>>.</p>
      <p><a name="nt-ID0EIDAE">10</a>. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <<a href="http://tools.ietf.org/html/rfc6120">http://tools.ietf.org/html/rfc6120</a>>.</p>
      <p><a name="nt-ID0EBGAE">11</a>. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <<a href="http://tools.ietf.org/html/rfc6120">http://tools.ietf.org/html/rfc6120</a>>.</p>
      <p><a name="nt-ID0EZGAE">12</a>. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses <<a href="http://tools.ietf.org/html/rfc3927">http://tools.ietf.org/html/rfc3927</a>>.</p>
      <p><a name="nt-ID0EQHAE">13</a>. XEP-0174: Link-Local Messaging <<a href="http://xmpp.org/extensions/xep-0174.html">http://xmpp.org/extensions/xep-0174.html</a>>.</p>
      <p><a name="nt-ID0EGIAE">14</a>. XEP-0174: Link-Local Messaging <<a href="http://xmpp.org/extensions/xep-0174.html">http://xmpp.org/extensions/xep-0174.html</a>>.</p>
      <p><a name="nt-ID0EPJAE">15</a>. XEP-0174: Link-Local Messaging <<a href="http://xmpp.org/extensions/xep-0174.html">http://xmpp.org/extensions/xep-0174.html</a>>.</p>
      <p><a name="nt-ID0EJKAE">16</a>. XEP-0077: In-Band Registration <<a href="http://xmpp.org/extensions/xep-0077.html">http://xmpp.org/extensions/xep-0077.html</a>>.</p>
      <p><a name="nt-ID0E6KAE">17</a>. XEP-0114: Jabber Component Protocol <<a href="http://xmpp.org/extensions/xep-0114.html">http://xmpp.org/extensions/xep-0114.html</a>>.</p>
      <p><a name="nt-ID0EROAE">18</a>. XEP-0326: Internet of Things - Concentrators <<a href="http://xmpp.org/extensions/xep-0326.html">http://xmpp.org/extensions/xep-0326.html</a>>.</p>
      <p><a name="nt-ID0EUSAE">19</a>. XEP-0323: Internet of Things - Sensor Data <<a href="http://xmpp.org/extensions/xep-0323.html">http://xmpp.org/extensions/xep-0323.html</a>>.</p>
      <p><a name="nt-ID0EATAE">20</a>. XEP-0324: Internet of Things - Provisioning <<a href="http://xmpp.org/extensions/xep-0324.html">http://xmpp.org/extensions/xep-0324.html</a>>.</p>
      <p><a name="nt-ID0EMTAE">21</a>. XEP-0325: Internet of Things - Control <<a href="http://xmpp.org/extensions/xep-0325.html">http://xmpp.org/extensions/xep-0325.html</a>>.</p>
      <p><a name="nt-ID0EYTAE">22</a>. XEP-0326: Internet of Things - Concentrators <<a href="http://xmpp.org/extensions/xep-0326.html">http://xmpp.org/extensions/xep-0326.html</a>>.</p>
      <p><a name="nt-ID0ESYAE">23</a>. XEP-0324: Internet of Things - Provisioning <<a href="http://xmpp.org/extensions/xep-0324.html">http://xmpp.org/extensions/xep-0324.html</a>>.</p>
      <p><a name="nt-ID0EW1AE">24</a>. XEP-0324: Internet of Things - Provisioning <<a href="http://xmpp.org/extensions/xep-0324.html">http://xmpp.org/extensions/xep-0324.html</a>>.</p>
      <p><a name="nt-ID0EFOAG">25</a>. XEP-0030: Service Discovery <<a href="http://xmpp.org/extensions/xep-0030.html">http://xmpp.org/extensions/xep-0030.html</a>>.</p>
      <p><a name="nt-ID0EH3AG">26</a>. XEP-0114: Jabber Component Protocol <<a href="http://xmpp.org/extensions/xep-0114.html">http://xmpp.org/extensions/xep-0114.html</a>>.</p>
      <p><a name="nt-ID0E2BBG">27</a>. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <<a href="http://www.iana.org/">http://www.iana.org/</a>>.</p>
    </div>
    <hr><a name="appendix-revs"></a><h3>Appendix H: Revision History</h3>
    <p>Note: Older versions of this specification might be available at <a href="http://xmpp.org/extensions/attic/">http://xmpp.org/extensions/attic/</a></p>
    <div class="indent">
      <h4>Version 0.0.3 (2014-04-09)</h4>
      <div class="indent">
                                <p class="" style="">Introduced possibility for hosting Thing Registry as a Jabber Server Component, using XEP-0114.</p>
                                <p class="" style="">
                                        Expanded de section <a href="#support">Determining Support</a>, explaining how to search through server components.
                                </p>
                                <p class="" style="">Removed the possibility to search for nick names, as a way of finding Thing Registries.</p>
                                <p class="" style="">Added Security and Implementation Notes describing the pros and cons of hosting a Thing Registry as a Server Component vs. as a Client.</p>
                         (pw)
    </div>
      <h4>Version 0.0.2 (2014-03-31)</h4>
      <div class="indent">
                                <p class="" style="">Removed any hard-coded account names.</p>
                         (pw)
    </div>
      <h4>Version 0.0.1 (2014-03-11)</h4>
      <div class="indent">
                                <p class="" style="">First draft.</p>
                         (pw,rk)
    </div>
    </div>
    <hr>
    <p>END</p>
  </body>
</html>