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

• Address and domain of XMPP Server.
• JID of the Thing.
• JID of Thing Registry, if separate from the XMPP Server.
• JID of first Provisioning Server, if separate from Thing Registry or XMPP Server.

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.

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.

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:

• DHCP
• Multicast DNS
• SSDP/UPnP

The following sections describe them in more detail.

Note: If server-less messaging is to be used, as described in &xep0174; 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.

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.

If the Thing does not have an account already, an account can be registered along what is specified in &xep0077;. If multiple servers are available, the first XMPP server that allows account creation can be used.

If a Thing Registry is not preconfigured, one must be found. The following lists methods to obtaining the JID for the Thing Registry. Note that the last two have security considerations that need to be taken into account.

1. Preconfigured JID to Thing Registry.
2. Preconfigured user name only, on the same XMPP domain as the XMPP Server connected to.
3. XMPP Server itself. This can be found out by sending a discovery request to the server, as described in Determining Support.
4. The account 'discovery' on the same domain. (For example: discovery@jabber.org)
5. Search for accounts on the XMPP server with nick-name "discovery". Search is performed using &xep0055;

Note: The above methods might yield multiple JIDs. Each should in turn be checked if the support the discovery extension. Note also that the last two have security considerations that need to be taken into account. These methods might be skipped, to avoid the possibility that an external user pretends to be a thing registry to hijack new Things installed into the network.

Once a Thing Registry has been found and been befriended, the Thing can register itself with the registry, as follows:

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.

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 Meta Tags section below.

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.

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.

Note: Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.

If a thing is self-owned, it can register itself with the Registry as normal, with the addition of setting the attribute selfOwned to true, 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.

A Thing might reside behind a gateway or concentrator and might not be directly connected to the XMPP network itself, as is described in &xep0326;. In these cases, there are three optional attributes that can be used to identify the Thing behind the JID: The nodeId 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 sourceId 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 cacheType. Finally, it is the triple (nodeId, sourceId, cacheType) which guarantees uniqueness within the concentrator.

For a Thing controlled by a concentrator to register itself in the Thing Registry, it simply adds the optional attributes nodeId, sourceId and cacheType as appropriate to the registration request, as follows:

If the Thing behind the concentrator is self-owned, it simply adds the selfOwned attribute to the request and sets it to true.

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.

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.

The above meta data would therefore generate the string:

Using UTF-8 encoding when generating the QR-code, this string returns the following QR-code:

To generate a QR-code, Google Chart API can be used: https://chart.googleapis.com/chart?cht=qr&chs=200x200&chl=IoTDisco;SN:394872348732948723;MAN:www.ktc.se;MODEL:IMC;#V:1.2;KEY:4857402340298342

Once the client has the required meta information about the Thing to claim ownership, it sends itself the following request to the Thing Registry:

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 public attribute with value false to the claim, as follows:

In this case, if the claim is successful, the Thing will not be made public in the Thing Registry, after the claim.

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 public 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:

If the Thing that has been claimed resides behind a concentrator, the result will contain those of the attributes nodeId, sourceId and cacheType that are required to access the Thing in calls made using &xep0323;, &xep0324;, &xep0325; and &xep0326;. The following example illustrates a response where a Thing behind a Concentrator has been claimed:

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:

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.

If the Thing was claimed as a private Thing, this is shown using the public attribute in the response, as follows:

If the public attribute is present and has value false, it means no further meta data updates are necessary, since the device is not searchable through the Thing Registry.

If the Thing resides behind a concentrator, the request must contain those of the attributes nodeId, sourceId and cacheType that are required to access the Thing, as follows:

The Thing simply returns an empty response to acknowledge the receipt of the information, as follows:

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.

Note: Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.

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:

If the Thing resides behind a concentrator, the request must contain those of the attributes nodeId, sourceId and cacheType that are required to access the Thing, as follows:

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:

However, if such a thing is not found, or if the thing is owned by another, an item-not-found error is returned, as follows:

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.

If the Thing lies behind a concentrator, the removal request would look as follows:

The Thing acknowledges the removal request by returning an empty response, as follows:

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 &xep0324;. If a Provisioning Server is not preconfigured, one must be found. The following lists methods to obtaining the JID for the Provisioning Server. Note that the last two have security considerations that need to be taken into account.

1. Preconfigured JID to Provisioning Server.
2. Preconfigured user name only, on the same XMPP domain as the XMPP Server connected to.
3. The XMPP Server itself can be a Provisioning Server. This can be found out by sending a discovery request to the server, as described in Determining Support.
4. 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 Determining Support.
5. The Owner itself can be a Provisioning Server. This can be found out by sending a discovery request to the Thing Registry, as described in Determining Support.
6. The account 'provisioning' on the same domain. (For example: provisioning@jabber.org)
7. Search for accounts on the XMPP server with nick-name "provisioning". Search is performed using &xep0055;

Note: The above methods might yield multiple JIDs. Each should in turn be checked if the support the discovery extension. Note also that the last two have security considerations that need to be taken into account. These methods might be skipped, to avoid the possibility that an external user pretends to be a thing registry to hijack new Things installed into the network.

Once a Provisioning Server has been found and been befriended, the Thing can delegate its trust to it, according to &xep0324;.

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.

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.

To update meta data about itself, a Thing simply sends a request to the Thing Registry, as follows:

If the Thing resides behind a concentrator, the request must contain those of the attributes nodeId, sourceId and cacheType that are required to access the Thing, as follows:

If the Thing is found in the registry and it is claimed, the registry simply acknowledges the update as follows:

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:

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.

Note: Meta Tag names are case insensitive. In this document, all tag names have been written using upper case letters.

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.

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.

The following table lists available search operators, their element names and meanings:

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.