This XEP defines tree structures for nodes in different data sources. &xep0060; defines a model where a tree structure of nodes is published and users can browse this tree structure. Furthermore, it allows the possibility to publish items on these nodes as well as syndication of this information.

This XEP also defines data sources (in a tree structure). These data sources contain nodes. &xep0248; defines a structure called a node collection, a structure that allows the creation of collections containing loosely coupled nodes.

Even though this document defines tree structures of data, it is not however based on XEP-0060. There are multiple reasons for this:

• The structures defined in this specification do not include items to publish for each node.
• We want to be able to use XEP-0060 in parallel to this specification, for the purpose of publishing sensor data. More information about this is found in xep-0000-IoT-PubSub.html.
• For massive systems (hundreds of thousands, or millions, of nodes behind a concentrator, its vitally important to be able to manage sets of nodes directly (for example: Edit multiple nodes at once). Many of the operations in XEP-0060 only allow for operations of singular nodes. Furthermore, many simple operations require multiple messages per node. This document defines way to operate of sets of nodes simultaneously, as well as ways to perform operations with a smaller number of operations.
• In this document, nodes have specific functions, controlled by a specific Node Type. Different Node Types have different parameter sets, different options, commands, capabilities, etc. XEP-0060 does not differ between node types. There, nodes are only a structural way to sort data into a tree graph.
• In this document, nodes have real-time status, like errors, warnings, etc.

XEP-0248 defines the concept of node collections and syndication of information from nodes in these collections. But XEP-0248 is not used in this specification. There are multiple reasons:

• We want to be able to use XEP-0248 in parallel to this specification, for the purpose of publishing sensor data. More information about this is found in xep-0000-IoT-PubSub.html.
• Node IDs are not necessarily unique by themselves in the system. This document defines a uniqueness concept based on a triple of data: (Data Source ID, Cache Type, Node ID). This means that Nodes must have IDs unique within a given Cache Type, within a given data source.
• We need to expand on types of events generated from a data source, to make them adhere to the particulars of nodes as defined in this specification.
• Data sources own their nodes. XEP-0248 define a loosely coupled structure with references to nodes. In this document, a data source is the owner of all nodes contained in it.

&xep0050; defines how ad-hoc commands can be implemented and how clients can use such commands to interact with underlying logic. But XEP-0050 is not used in this specification. There are multiple reasons:

• We want to be able to use XEP-0050 for other types of commands, than commands defined in this specification. Generally, XEP-0050 is used to implement system-wide commands.
• Commands defined in this specification are context sensitive, i.e. they depend on the type of node and the context of the node on which the act.
• It is a requirement to be able to execute commands on sets of nodes directly.
• Since commands have to be context sensitive, a large concentrator system may have hundreds or thousands of different commands, making it impossible to create context sensitive GUI's using XEP-0050.
• Dialog types used for Ad-Hoc-commands are not sufficient. First, dynamic dialogs are required in the general case. (XEP-0326 define how to create dynamic forms.) Furthermore, the wizard style type of dialogs used for more complex dialogs in ad-hoc commands, are difficult to automate.

This document lists a sequence of commands. Some are very basic, while others are used for managing massive amounts of devices. When developing a small PLC, it might be difficult to motivate the implementation of the more advanced commands. They are simply not necessary for the management of the device. So, clients connecting to the concentrator need a way to learn what operations are available in the concentrator, and as a consequence what operations are not. To do this, the getCapabilities command is sent, as is shown in the following example.

A concentrator without databases, but still contain a rich interface for handling masses of nodes may present itself as follows:

A smaller gateway on the other hand, may have skipped the implementation of the batch commands that are used for larger systems:

But a small PLC, possibly with a fixed set of nodes, might have support for an even more reduced set of commands:

So, clients who need to interact with different types of concentrators need to be aware of what commands are supported, and limit operations to those commands.

This command will return a flat list of all available data sources on the concentrator. It is not structured hierarchically.

If the client is interested in the hierarchical structure of available data sources, it should request only the root sources, and then ask the client for their corresponding child data sources. If the client wants to present the data sources to a user, presenting them in their hierarchical order may be more intuitive.

Having the ID of a data source that contains child data sources, you can fetch the child sources as follows:

A client can subscribe to changes made in a data source. It does this by sending the subscribe command to the concentrator, as is shown in the following example:

Multiple subscriptions to the same source will not result in an error, however the server will still only send one event message for each event in the data source.

Important: Event subscriptions only last for as long as the client and concentrator both maintain presence. The concentrator must not persist event notification subscriptions, and if it goes offline and back online, or if the client goes offline or online again for any reason, the event subscription is removed.

Note: The parameters and messages attributes can be used to retrieve parameter and status message information about the nodes in event messages sent from the concentrator. Note that the xml:lang may be used to select the language used in such events, if the concentrator supports localization of strings.

The subscribe command has a set of optional attributes, one for each event type available, and with the same names (nodeAdded, nodeUpdated, nodeStatusChanged, nodeRemoved, nodeMovedUp and nodeMovedDown), that the client can use to subscribe to individual events, but not to others. They have the default value of true implying that if not provided, the default action is to subscribe to those events. The attributes parameters and messages can also be used to specify if node parameters and node messages respectively should be available in event messages. The default value for the these later attributes is false, implying that normal events do not include node parameter and node message information.

The following example shows how a client can subscribe to a set of events only:

For more information on types of events sent, see the Data Source Events section.

A client can unsubscribe to changes made in a data source it is subscribed to. It does this by sending the unsubscribe command to the concentrator, as is shown in the following example:

An unsubscription made to an existing data source, but where an event subscription does not exist, must not result in an error.

The unsubscribe command has a set of optional attributes, one for each event type available, and with the same names, that the client can use to unsubscribe from individual events, but not from others. They have the default value of true implying that if not provided, the default action is to unsubscribe from those events.

The following example shows how a client can unsubscribe from a subset of events, keeping subscriptions on the others (if subscribed to):

If a client comes back online and wants to know any changes that have taken place on the concentrator since last time it was in contact with it, it can include a getEventsSince attribute in the subscribe command sent to the concentrator. This will make the concentrator send all event messages since the given timestamp to the client before subscribing the client to events in the given data source.

Important: Event subscriptions only last for as long as the client and concentrator both maintain presence. The concentrator must not persist event notification subscriptions, and if it goes offline and back online, or if the client goes offline or online again for any reason, the event subscription is removed.

Note: The parameters and messages attributes can be used to retrieve parameter and status message information about the nodes in event messages sent from the concentrator.

For more information on types of events sent, see the Data Source Events section.

If during a subscription request the concentrator is not able to fulfill the request of retrieving previous events using the getEventsSince attribute, perhaps the attribute stretches too far back, or includes too many records, the concentrator can return an error message using a response code of NotImplemented. In this case, the subscription must not be made.

When receiving such an error from the concentrator, the client must make a decision if it should download the data source again, or keep the data source as is, and subscribing again without the getEventsSince attribute.

This command permits the client to check the existence of a node in the concentrator.

If the client wants to check the existence of multiple nodes on the concentrator, it can use this batch command instead:

The array returned will have one item for each item in the request, in the same order.

This command returns basic information about a node in the concentrator.

For more information, see Node Information.

This command lets the client get information from multiple nodes at once.

For more information, see Node Information.

This command returns basic information about a node in the concentrator, as well as node parameters.

For more information, see Node Information.

This command lets the client get information from multiple nodes at once, including node parameters.

For more information, see Node Information.

If the device does not manage too many nodes, it could choose to implement this function. It would return all available nodes with one call.

If the device does not manage too many nodes, it could choose to implement this function. It would return all available nodes with their parameters with one call.

This command assumes node types exist in a class hierarchy, and allows the caller to retrieve nodes with similar inheritance.

This command assumes node types exist in a class hierarchy, and allows the caller to retrieve nodes with similar inheritance. It also returns node parameters directly in the response.

Note that the caller can list multiple classes in the request. This would return only nodes having the correct base class(es) and implementing all interfaces.

This command assumes node types exist in a class hierarchy. It allows the caller to get a list of the node class hierarchy and implemented interfaces the node has.

Note: It is assumed the client already knows the node type of the node, so the response must not contain the type of the node, only its base classes and any implemented interfaces.

This command returns the root node of a data source (in case the source is a tree-shaped data source) or the nodes of a data source (in case the source is flat).

This command returns the root node of a data source (in case the source is a tree-shaped data source) or the root nodes of a data source (in case the source is flat), and also returns the parameters for the corresponding nodes.

This command returns the child nodes of a node in a data source.

This command returns the child nodes of a node in a data source, and also returns the parameters for the corresponding nodes.

This command returns a list of available indices in a data source. Indices can be used for efficient node look-up.

This command can be used to get a node or nodes from a data source using an index and an index value.

This command can be used to get a node or nodes from a data source using an index and an index value, and also returns the parameters for the corresponding nodes.

This command can be used to get nodes from a set of data source using indices and index values.

This command can be used to get nodes from a set of data source using indices and index values, and also returns the parameters for the corresponding nodes.

This command can be used to get a list of available index values, given a data source and an index.

In a tree formed data source, all nodes except the root node has a parent node. The getAncestors command allows the client to get a list of all ancestors (parent, grand parent, etc.) of a node, as is shown in the following example:

Note that the concentrator returns information about the node itself in the response. The parameters and messages attributes are used in the request to control if the concentrator should return node parameters and node status messages in the response as well.

As the order of siblings in a tree can be important, depending on the context and type of nodes involved, the client may be allowed to move nodes up and down among siblings. To move a node upwards among its siblings is done using the command moveNodeUp, as is shown in the following example:

Note that a node that is first among its siblings will maintain its position. The response to the command must still be OK.

As the order of siblings in a tree can be important, depending on the context and type of nodes involved, the client may be allowed to move nodes up and down among siblings. To move a node downwards among its siblings is done using the command moveNodeDown, as is shown in the following example:

Note that a node that is last among its siblings will maintain its position. The response to the command must still be OK.

To move a set of nodes upwards among its siblings is done using the command moveNodesUp, as is shown in the following example:

Note that a node that is first among its siblings will maintain its position. The response to the command must still be OK. If an attempt is performed to move a sequence of nodes that are together first as siblings, none of the nodes move relative to each other.

To move a set of nodes downwards among its siblings is done using the command moveNodesDown, as is shown in the following example:

Note that a node that is last among its siblings will maintain its position. The response to the command must still be OK. If an attempt is performed to move a sequence of nodes that are together last as siblings, none of the nodes move relative to each other.

Previously described commands can return parameters for a node. But these parameters are for presentational or informational use. If the client wants to edit the parameters of a node, another set of commands must be used. This use case shows how getNodeParametersForEdit can be used to edit available parameters for one node.

Note: When editing parameters for a node, a different set of parameters might be returned compared to the set of parameters available in commands mentioned above. There may be various reasons for this, among other things (but not limited to) user rights, node settings, and parameter type. User rights may restrict the number of parameters the user can access. The node may be configured not to allow editing of certain parameters. Also, some types of parameters may only be available in an edit mode (like long multi-line parameters) and not in a shorter presentation mode.

The following table lists the different XEP's the client should implement to be able to support parameter forms according to this proposal:

Read-only parameters will be returned with the readOnly element, as defined in XEP-0336. Clients SHOULD support this extension if using this command. However, the server MUST NOT change parameters in a node that are read-only, even if clients happen to try to set them.

After editing the form, the client uses the setNodeParametersAfterEdit command to set the parameters in the node. Note that it is possible to set the same parameters (or a sub-set of the same parameters) to a different node using this command, without the need to get new form parameters. However, after the first successful set operation, any form session used for dynamic validation during edit will not be available on the server anymore and must be ignored by the server.

Note that validation rules, pagination, etc., can be stripped from the form when submitting it to the server. Also the form type attribute must be set to 'submit'. Note also that as the result attribute is OK, it is assumed the server has dropped any parameter form resources related to the form, which disables any future dynamic validation of the contents of the form. The newly edited node will also be available in the response in a node element.

The following example shows how the server responds when the client tries to set invalid parameters. The response contains detailed information about why, information which the client can use to inform the user (if any) of what went wrong.

As the result attribute is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 XEP-0336: Dynamic Data Forms <http://xmpp.org/extensions/xep-0336.html> for more information.

Advanced concentrators handling large quantities of nodes may let users edit sets of nodes at once to be practical. This is done by publishing the getCommonNodeParametersForEdit command. It will return a form with parameters that are common for all selected nodes. Since nodes may have different node types it is assumed that different nodes have different sets of parameters. But if this command is used, only parameters matching in IDs, descriptions, validation rules, etc., (but not values) will be returned in a form.

Important: A parameter that exists in multiple nodes, but has different parameter values among the nodes, will be marked with the notSame element, according to XEP-0336. Clients using this command MUST support the extensions defined in XEP-0336.

Note that parameters that are not available in all selected nodes will have been removed. Also and ID-parameter will have been removed, since they cannot be set for a collection of nodes.

Fields marked with the notSame element only present one value, perhaps the value of the first node. However, the field should be clearly marked in any end-user GUI (for example by graying the field), and MUST ONLY be sent back to the server in a set operation if explicitly edited by the end-user. The parameter will be set in all selected nodes in that case. Unedited fields should be treated as if the end-user accepts the different values for the current set of nodes.

After editing the form, the client uses the setCommonNodeParametersAfterEdit command to set the parameters in the set of nodes. Note that it is possible to set the same parameters (or a sub-set of the same parameters) to a different set of nodes using this command, without the need to get new form parameters. However, after the first successful set operation, any form session used for dynamic validation during edit will not be available on the server any more.

Note that validation rules, pagination, etc., can be stripped from the form when submitting it to the server. Also the form type attribute must be set to 'submit'. Note also that as the result attribute is OK, it is assumed the server has dropped any parameter form resources related to the form, which disables any future dynamic validation of the contents of the form.

Important: A parameter that exists in multiple nodes, but has different parameter values among the nodes, will be marked with the notSame element, according to XEP-0336. Such parameters MUST NOT be sent back to the server unless they have explicitly been edited or signed by the end-user. The value sent back to the server will be set in all nodes.

The following example shows how the server responds when the client tries to set invalid parameters to a set of nodes. The response contains detailed information about why, information which the client can use to inform the user (if any) of what went wrong.

As the result attribute is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

Each node in the concentrator has a state. This state is a dynamic run-time state, and therefore not presented as a more static property. This state can be any of the following values, in order of increasing importance:

Other types of "states" are of course possible, such as phase - installation phase, test phase, production phase, etc. - but such "states" are seen as static and presented as parameters on the node. The purpose of the dynamic state attribute of a node, is to give a dynamic runtime state that has the possibility to change during runtime, which operators must be aware of.

The following commands have an optional attribute messages, with which they can ask the server to return any events logged on the node, giving more details of the current state of the node:

• getNode
• getNodes
• getChildNodes
• getAllNodes
• getRootNodes
• getNodesFromIndex
• getNodesFromIndices

The messages attribute can be combined with the parameters attribute to provide both node parameters and messages in the response.

Since nodes are context sensitive, depending on node type and tree structure, before being able to create a new node, it is important to know what types of nodes that can be added to a given node. This is done using the getAddableNodeTypes command, as is shown in the following example:

When you know what type of node you want to create, you need to get a set of parameters you need to fill in for the new node, before you can create it. This is done using the getParametersForNewNode command, as is shown in the following example:

After editing the form, the client uses the createNewNode command to create the new node using the parameters provided in the form.

Note that validation rules, pagination, etc., can be stripped from the form when submitting it to the server. Also the form type attribute must be set to 'submit'. Note also that as the result attribute is OK, it is assumed the server has dropped any parameter form resources related to the form, which disables any future dynamic validation of the contents of the form. The newly created node with corresponding parameters is also returned in the response in a node element.

The following example shows how the server responds when it cannot accept parameters provided when trying to create a node. The response will contain detailed information about why, information which the client can use to inform the user (if any) of what went wrong.

As the result attribute is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

To destroy (remove) a node from the concentrator, the destroyNode command is sent, as is shown in the following example:

Since the result attribute in the response is OK, the node has been removed.

If the result attribute in the response is other than OK, the node was not removed from the concentrator. The result attribute contains the reason why the operation failed, as is shown in the following example:

Each node can have a context sensitive set of commands available to it. This is shown using the hasCommands attribute in the Node Information record describing the corresponding node. If the client wants to get a list of available commands, the getNodeCommands command is sent to the concentrator, as is shown in the following example:

There are three types of commands available: Simple, Parameterized and Query. Simple commands take no parameters, and are therefore simpler to execute. Parameterized commands require the client to get a set of parameters for the corresponding command before it can be executed. Query commands also require a set of parameters to be executed, but return a response after (or during) execution in an asynchronous fashion. Queries can also be aborted during execution. A Query with an empty parameter set is considered to be a simple query, not requiring a parameter dialog to be shown.

For more information about command attributes, see Node Commands.

Executing a simple command is done by sending the executeNodeCommand command to the concentrator, as is shown in the following example:

To execute a parameterized command or a query on the node, the client first needs to get (and edit) a set of parameters for the command. Getting a set of parameters for a parameterized command is done as follows:

Executing a parameterized command is also done by sending the executeNodeCommand command to the concentrator, but including the edited form parameters, as is shown in the following example:

If an error occurs during the execution of a command or if the server rejects the execution of a command, the server returns a response code different from OK. If the response code is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

Executing a Node Query also requires the client to get a set of parameters for the query. This is done in the same way as for parametrized commands, as is shown in the following example:

Executing the query is then done by sending the executeNodeQuery command to the concentrator, but including the edited form parameters, as is shown in the following example:

After the successful execution of a query command, a sequence of query events will follow. These events will include a queryId attribute to identify to which query the corresponding events correspond. See section about Query Events for more information about this.

Note: Queries with no visible parameters in the command parameter form need not display a parameter form to the user before being executed. However, if a confirmation question is defined for the command, such a confirmation question should always be presented to the user (if possible) before executing the command.

If an error occurs during the reception of a query or if the server rejects the execution of a query, the server returns a response code different from OK. If the response code is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

One a query has been accepted and started running, the client can abort it using the abortNodeQuery command, as is shown in the following example.

Note: The execution of a query is an asynchronous process, with a small delay between the compilation and transmission of query events and the reception of them by a client. A client may thinkt a query is still active when asking to abort it, when the query might actually have been finished and removed on the query side. Therefore, clients should be aware of this when receiving NotFound responses from a concentrator, that the query might already have been finished.

Using the command getCommonNodeCommands, the client can receive commands that are common for a set of nodes, as is shown in the following example:

Executing a simple command on multiple nodes is done by sending the executeCommonNodeCommand command to the concentrator, as is shown in the following example:

To execute a parameterized command on a set of nodes, the client first needs to get (and edit) a set of parameters for the common command. Getting a set of parameters for a common parameterized command is done as follows:

Executing a common parameterized command is also done by sending the executeCommonNodeCommand command to the concentrator, but including the edited form parameters, as is shown in the following example:

If an error occurs during the execution of a common command or if the server rejects the execution of a common command, the server returns a response code different from OK. If the response code is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

When executing a command, simple or parameterized, on multiple nodes, it might happen that the command fails on some nodes, but not on others, even though any parameters are validated beforehand. Therefore, the client needs to check any result elements in the response, even though the response code is OK.

The following example shows the execution of a parameterized command on multiple nodes that fail on some nodes but are executed on others. Note that individual error messages can be provided as error attribute messages for each node that fails in the corresponding result element.

Executing a Node Query on multiple nodes also requires the client to get a set of parameters for the query common to all nodes. This is done in the same way as for parametrized commands, as is shown in the following example:

Executing the query is then done by sending the executeCommonNodeQuery command to the concentrator, but including the edited form parameters, as is shown in the following example:

After the successful execution of a query command, a sequence of query events will follow. These events will include a queryId attribute to identify to which query the corresponding events correspond. They will also include node reference attributes so the receptor can distinguish information from different nodes in the query. See section about Query Events for more information about this.

Note: Queries with no visible parameters in the command parameter form need not display a parameter form to the user before being executed. However, if a confirmation question is defined for the command, such a confirmation question should always be presented to the user (if possible) before executing the command.

If an error occurs during the execution of a common query or if the server rejects the execution of a common query, the server returns a response code different from OK. If the response code is FormError, the server maintains any parameter form resources related to the form, and features such as dynamic validation of the contents of the form will still be available until the parameters have been successfully set, the operation has been explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

When executing a query on multiple nodes, it might happen that the query is rejected on some nodes, but not on others, even though any parameters are validated beforehand. Therefore, the client needs to check any result elements in the response, even though the response code is OK.

The following example shows the execution of a query on multiple nodes that fail on some nodes but are executed on others. Note that individual error messages can be provided as error attribute messages for each node that fails in the corresponding result element.

To abort a query common to a set of nodes you use the abortCommonNodeQuery command, as is shown in the following example:

Note: The execution of a query is an asynchronous process, with a small delay between the compilation and transmission of query events and the reception of them by a client. A client may thinkt a query is still active when asking to abort it, when the query might actually have been finished and removed on the query side. Therefore, clients should be aware of this when receiving NotFound responses from a concentrator, that the query might already have been finished. In the case of aborting queries on multiple nodes, servers must ignore nodes where the query has already finished executing.

This event is sent when the query is started on a node. It is sent using a queryStarted event element. This element does not take any attributes.

This event is sent when the query is done on a node. It is sent using a queryDone event element. This element does not take any attributes.

This event is sent when the query has been aborted on a node. It is sent using a queryAborted event element. This element does not take any attributes.

A query result can consist of zero or more data tables. Each data table consists of a set of columns and records containing value items for the these columns. A new table is identified by a query event named newTable. a newTable event contains a sequence of column events each identifying a column in the table.

For more information about column definitions, see Table Column definitions in query results.

A set of records in an open table is reported using the newRecords query event.

For more information about records, see Record Item definitions in query results.

This event is sent when the query is done with a table. It is sent using a tableDone event element. The query must not send any more records to a table that has been closed using this query event.

Some queries may want to return other types of data than tables, like images, graphs, etc. These may be combined with table information or not. A query returns such an object using the newObject query event. Each object is MIME encoded, and the MIME Type is sent in the contentType attribute. The object itself is Base-64 encoded.

During the processing of a query, the query might want to report a message of some kind. This is done using the queryMessage query event.

For more information about query messages, see Message definitions in query results.

Enables the executing process of the query to set a custom title for the result. Note that the result only has one title.

Once the parameter form has been filled out, a database readout can be started using the startDatabaseReadout command. Data read from the concentrator will follow the same flow of sensor data as that described in &xep0323;. The only difference is that the read-out is started with the startDatabaseReadout command instead of the req command of the sensor data namespace.

The following diagram shows the flow of messages when requesting a readout from a database:

The following example shows a startDatabaseReadout request:

The following example shows a response when the concentrator rejects the read-out request:

The error might also be a result of invalid input parameters being sent:

A client can cancel a database read-out using the cancel read-out command, as described in Internet of Things - Sensor Data.

This section shows how a provisioning server can be used to restrict access to data sources to users allowed to access those data sources.

Notice the following:

• The user has a userToken it received during connection with the service. This user token should be included in all calls made by the user.
• The service has a serviceToken it received during service registration. This service token should be aggregated by all calls made by the service.
• The concentrators should cache all calls made to the provisioning server according to available cache rules.
• The conversion of a Data Source ID to a Privilege ID should be performed according to rules defined in xep-0000-IoT-Interoperability.

This section shows how a provisioning server can be used to restrict access to node parameters that users allowed to access and edit.

• Not that privileges for all parameters needs to be checked in every call. And if lost from the cache, a new request needs to be made to the provisioning server.
• The conversion of a Parameter ID (and Page) to a Privilege ID should be performed according to rules defined in xep-0000-IoT-Interoperability.

This section shows how a provisioning server can be used to restrict access to node commands to users allowed to access those commands.

In addition to rules noted above, also notice the following:

• Not that privileges for all parameters needs to be checked in every call. And if lost from the cache, a new request needs to be made to the provisioning server.
• The conversion of a Command ID to a Privilege ID should be performed according to rules defined in xep-0000-IoT-Interoperability.