From 27748b38dbbc2076656b2aedff893a298e18a19b Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Mon, 10 Mar 2014 12:07:37 -0600 Subject: [PATCH] XEP-0326 v0.2: Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic; Added the following node query events: title, status, beginSection and endSection; Updated the schema to more strictly validate references to x-data forms; Updated attribute names so queries and responses are consistent; Updated the language; Added section about how to determine support; Corrected language and examples; Node Query command type added; Fixed links to documents with new numbers; Changed namespace urn:xmpp:sn to urn:xmpp:iot --- xep-0326.xml | 2635 ++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 1927 insertions(+), 708 deletions(-) diff --git a/xep-0326.xml b/xep-0326.xml index 6387fd4c..cc295963 100644 --- a/xep-0326.xml +++ b/xep-0326.xml @@ -1,6 +1,8 @@ + + %ents; @@ -10,7 +12,7 @@
Internet of Things - Concentrators This specification describes how to manage and get information from concentrators of devices over XMPP networks. - &LEGALNOTICE; + &LEGALNOTICE; 0326 Experimental Standards Track @@ -26,33 +28,52 @@ XEP-0141 XEP-0323 XEP-0324 - xep-0000-DynamicForms - xep-0000-ColorParameter + XEP-0331 + XEP-0336 - NOT_YET_ASSIGNED + sensor-network-concentrators Peter Waher peter.waher@clayster.com peter.waher@jabber.org - http://se.linkedin.com/pub/peter-waher/1a/71b/a29/ + http://www.linkedin.com/in/peterwaher - - 0.1 - 2013-05-06 - psa -

Initial published version approved by the XMPP Council.

 - - - 0.0.1 - 2013-03-20 - pwa - -

First draft.

- - + + 0.2 + 2014-03-10 + pw + +

Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.

+

Added the following node query events: title, status, beginSection and endSection.

+

Updated the schema to more strictly validate references to x-data forms.

+

Updated attribute names so queries and responses are consistent.

+

Updated the language.

+

Added section about how to determine support.

+

Corrected language and examples.

+

Node Query command type added.

+

Fixed links to documents with new numbers.

+

Changed namespace urn:xmpp:sn to urn:xmpp:iot

+ + + + 0.1 + 2013-05-06 + psa + +

Initial published version approved by the XMPP Council.

+ + + + 0.0.1 + 2013-03-20 + pw + +

First draft.

+ +

@@ -75,7 +96,81 @@

  • Effective synchronization of contents between interested parties.
  • Effective ways to interact with entities controlled by the concentrator.
    • - + +

    + Sensor networks contains many different architectures and use cases. For this reason, the sensor network standards have been divided into multiple XEPs according to the following table: +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    XEPDescription
    xep-0000-IoT-BatteryPoweredSensorsDefines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.
    xep-0000-IoT-DiscoveryDefines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.
    xep-0000-IoT-EventsDefines how sensors send events, how event subscription, hysteresis levels, etc., are configured.
    xep-0000-IoT-InteroperabilityDefines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.
    xep-0000-IoT-MulticastDefines how sensor data can be multicast in efficient ways.
    xep-0000-IoT-PubSubDefines how efficient publication of sensor data can be made in sensor networks.
    xep-0000-IoT-ChatDefines 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.
    XEP-0322 + Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a sensor network specific XEP, this XEP should be considered + in all sensor network implementations where memory and packet size is an issue. +
    XEP-0323 + 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 sensor network XEPs. +
    XEP-0324Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.
    XEP-0325Defines how to control actuators and other devices in Internet of Things.
    XEP-0326This specification. Defines how to handle architectures containing concentrators or servers handling multiple sensors.
    XEP-0331Defines extensions for how color parameters can be handled, based on &xep0004;
    XEP-0336Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.
    + +

    Even though there are technologies available in forms of XEPs that solve parts of the above mentioned problem, they do not provide sufficient support. The following paragraphs will take the time to list why different technologies are not applicable. @@ -83,7 +178,7 @@

    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 syndicalization of this information. + 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 @@ -98,7 +193,7 @@

  • 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-SN-PubSub.html. + 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 @@ -117,13 +212,13 @@

    - XEP-0248 defines the concept of node collections and syndicalization of information from nodes in these collections. But XEP-0248 is not used in this specification. + 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-SN-PubSub.html. + 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 @@ -160,229 +255,160 @@
    • Dialog types used for Ad-Hoc-commands are not sufficient. First, dynamic dialogs are required in the general case. - (XEP xep-0000-DynamicForms.html define how to create dynamic forms.) Furthermore, the + (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.
    - -

    - Sensor networks contains many different architectures and use cases. For this reason, the sensor network standards have been divided into multiple XEPs according to the following table: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    XEPDescription
    XEP-0000-ColorParameterDefines extensions for how color parameters can be handled, based on &xep0004;
    XEP-0000-DynamicFormsDefines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.
    exi - Defines how to EXI can be used in XMPP to achieve efficient compression of data. Albeit not a sensor network specific XEP, this XEP should be considered - in all sensor network implementations where memory and packet size is an issue. -
    xep-0000-SN-BatteryPoweredSensorsDefines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.
    xep-0000-SN-ConcentratorsThis specification. Defines how to handle architectures containing concentrators or servers handling multiple sensors.
    xep-0000-SN-ControlDefines how to control actuators and other devices in sensor networks.
    xep-0000-SN-DiscoveryDefines the peculiars of sensor discovery in sensor networks. Apart from discovering sensors by JID, it also defines how to discover sensors based on location, etc.
    xep-0000-SN-EventsDefines how sensors send events, how event subscription, hysteresis levels, etc., are configured.
    xep-0000-SN-InteroperabilityDefines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.
    xep-0000-SN-MulticastDefines how sensor data can be multicast in efficient ways.
    sensor-network-provisioningDefines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.
    xep-0000-SN-PubSubDefines how efficient publication of sensor data can be made in sensor networks.
    sensor-data - 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 sensor network XEPs. -

    The following table lists common terms and corresponding descriptions.

    -
    - -
    Actuator
    -
    Device containing at least one configurable property or output that can and should be controlled by some other entity or device.
    -     - -
    Computed Value
    -
    A value that is computed instead of measured.
    -     - -
    Concentrator
    -
    Device managing a set of devices which it publishes on the XMPP network.
    -     - -
    Data Source
    -
    - A Data source contains a collection of nodes. Three types of data sources exist: Singular, Flat and Tree. Singular data sources only include one object. - Flat data sources contain a list of objects and Tree data sources contain nodes formed as a tree graph with one root element. -
    -     - -
    Field
    -
    - 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). -
    -     - -
    Field Name
    -
    Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc.
    -     - -
    Field Type
    -
    What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc.
    -     - -
    Historical Value
    -
    A value stored in memory from a previous timestamp.
    -     - -
    Identification Value
    -
    A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.)
    -     - -
    Localization information
    -
    Optional information for a field, allowing the sensor to control how the information should be presented to human viewers.
    -     - -
    Meter
    -
    A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc.
    -     - -
    Momentary Value
    -
    A momentary value represents a value measured at the time of the read-out.
    -     - -
    Node
    -
    - Graphs contain nodes and edges between nodes. In Sensor Networks, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes and links between sensors (friendships) - are depicted as edges. In abstract terms, it's easier to talk about a Node, than have to list different types of nodes possible (sensors, actuators, meters, devices, gateways, etc.). - Each Node has a Node ID. Nodes belong to a data source, and all nodes have a Node Type. Some nodes have a parent node, and some nodes have child nodes. Nodes with the same - parent nodes a called sibling nodes. -
    -     - -
    Node ID
    -
    - An ID uniquelly identifying a node within its corresponding context. If a globally unique ID is desired, an architechture should be used using a universally accepted - ID scheme. -
    -     - -
    Node Type
    -
    Each node has a Node Type. The Node Type defines the functionality of the node in the system.
    -     - -
    Parameter
    -
    - Readable and/or writable property on a node/device. The XEP xep-0000-SN-Concentrators deals with reading and writing parameters - on nodes/devices. Fields are not parameters, and parameters are not fields. -
    -     - -
    Peak Value
    -
    A maximum or minimum value during a given period.
    -     - -
    Precision
    -
    - 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. -
    -     - -
    Sensor
    -
    - 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. -
    -     - -
    SN
    -
    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.
    -     - -
    Status Value
    -
    A value displaying status information about something.
    -     - -
    Timestamp
    -
    Timestamp of value, when the value was sampled or recorded.
    -     - -
    Token
    -
    - A client, device or user can get a token from a provisioning server. These tokens can be included in requeests to other entities in the network, so these entities can validate - access rights with the provisioning server. -
    -     - -
    Unit
    -
    Physical unit of value. Example: MWh, l/s, etc.
    -     - -
    Value
    -
    A field value.
    -     - -
    Value Status
    -
    Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc.
    -     - -
    Value Type
    -
    Can be numeric, string, boolean, Date & Time, Time Span or Enumeration.
    -     - -
    WSN
    -
    Wireless Sensor Network, a sensor network including wireless devices.
    -     - -
    XMPP Client
    -
    Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients.
    -     -
    +
    + +
    Actuator
    +
    Device containing at least one configurable property or output that can and should be controlled by some other entity or device.
    +     + +
    Computed Value
    +
    A value that is computed instead of measured.
    +     + +
    Concentrator
    +
    Device managing a set of devices which it publishes on the XMPP network.
    +     + +
    Data Source
    +
    + A Data source contains a collection of nodes. Three types of data sources exist: Singular, Flat and Tree. Singular data sources only include one object. + Flat data sources contain a list of objects and Tree data sources contain nodes formed as a tree graph with one root element. +
    +     + +
    Field
    +
    + 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). +
    +     + +
    Field Name
    +
    Name of a field of sensor data. Examples: Energy, Volume, Flow, Power, etc.
    +     + +
    Field Type
    +
    What type of value the field represents. Examples: Momentary Value, Status Value, Identification Value, Calculated Value, Peak Value, Historical Value, etc.
    +     + +
    Historical Value
    +
    A value stored in memory from a previous timestamp.
    +     + +
    Identification Value
    +
    A value that can be used for identification. (Serial numbers, meter IDs, locations, names, etc.)
    +     + +
    Localization information
    +
    Optional information for a field, allowing the sensor to control how the information should be presented to human viewers.
    +     + +
    Meter
    +
    A device possible containing multiple sensors, used in metering applications. Examples: Electricity meter, Water Meter, Heat Meter, Cooling Meter, etc.
    +     + +
    Momentary Value
    +
    A momentary value represents a value measured at the time of the read-out.
    +     + +
    Node
    +
    + 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. Nodes belong to a data source, and all nodes have a Node Type. Some nodes have a parent node, and some nodes have child nodes. Nodes with the same + parent nodes a called sibling nodes. +
    +     + +
    Node ID
    +
    + 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. +
    +     + +
    Node Type
    +
    Each node has a Node Type. The Node Type defines the functionality of the node in the system.
    +     + +
    Parameter
    +
    + Readable and/or writable property on a node/device. The XEP-0326 &xep0326; deals with reading and writing parameters + on nodes/devices. Fields are not parameters, and parameters are not fields. +
    +     + +
    Peak Value
    +
    A maximum or minimum value during a given period.
    +     + +
    Precision
    +
    + 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. +
    +     + +
    Sensor
    +
    + 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. +
    +     + +
    SN
    +
    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.
    +     + +
    Status Value
    +
    A value displaying status information about something.
    +     + +
    Timestamp
    +
    Timestamp of value, when the value was sampled or recorded.
    +     + +
    Token
    +
    + 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. +
    +     + +
    Unit
    +
    Physical unit of value. Example: MWh, l/s, etc.
    +     + +
    Value
    +
    A field value.
    +     + +
    Value Status
    +
    Status of field value. Contains important status information for Quality of Service purposes. Examples: Ok, Error, Warning, Time Shifted, Missing, Signed, etc.
    +     + +
    Value Type
    +
    Can be numeric, string, boolean, Date & Time, Time Span or Enumeration.
    +     + +
    WSN
    +
    Wireless Sensor Network, a sensor network including wireless devices.
    +     + +
    XMPP Client
    +
    Application connected to an XMPP network, having a JID. Note that sensors, as well as applications requesting sensor data can be XMPP clients.
    +     +

    @@ -404,14 +430,14 @@ from='client@clayster.com/client' to='subsystem@clayster.com' id='1'> - + - + getCapabilities getAllDataSources getRootDataSources @@ -440,9 +466,13 @@ getNodeCommands getCommandParameters executeNodeCommand + executeNodeQuery + abortNodeQuery getCommonNodeCommands getCommonCommandParameters executeCommonNodeCommand + executeCommonNodeQuery + abortCommonNodeQuery moveNodeUp moveNodeDown moveNodesUp @@ -458,20 +488,20 @@

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

    - + - + - + getCapabilities getAllDataSources getRootDataSources @@ -500,9 +530,13 @@ getNodeCommands getCommandParameters executeNodeCommand + executeNodeQuery + abortNodeQuery getCommonNodeCommands getCommonCommandParameters executeCommonNodeCommand + executeCommonNodeQuery + abortCommonNodeQuery moveNodeUp moveNodeDown moveNodesUp @@ -521,14 +555,14 @@ from='client@clayster.com/client' to='gateway@clayster.com' id='2'> - + - + getCapabilities getAllDataSources getRootDataSources @@ -548,6 +582,8 @@ getNodeCommands getCommandParameters executeNodeCommand + executeNodeQuery + abortNodeQuery moveNodeUp moveNodeDown moveNodesUp @@ -566,14 +602,14 @@ from='client@clayster.com/client' to='plc@clayster.com' id='3'> - + - + getCapabilities getAllDataSources containsNode @@ -583,6 +619,8 @@ getNodeCommands getCommandParameters executeNodeCommand + executeNodeQuery + abortNodeQuery ]]> @@ -602,17 +640,17 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='4'> - + - - - - + + + + ... ]]> @@ -629,17 +667,17 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='5'> - + - - - - + + + + ... ]]> @@ -655,26 +693,26 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='6'> - + - - - - - - - - + + + + + + + + ]]> - +

    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: @@ -685,14 +723,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='57'> - + - + ]]>

    @@ -714,20 +752,23 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='60'> - + - + ]]>

    - The subscribe command has a set of optional attributes, one for each event type available, and with the same names, that the + 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. + 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: @@ -738,7 +779,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='61'> - @@ -746,7 +787,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='61'> - + ]]>

    @@ -764,14 +805,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='58'> - + - + ]]>

    @@ -791,7 +832,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='62'> - @@ -799,7 +840,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='62'> - + ]]> @@ -815,14 +856,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='59'> - + - + ... Sequence of event messages sent from concentrator to client.]]> @@ -840,6 +881,33 @@ 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. +

    + + + + + + + + ]]> + +     @@ -852,14 +920,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='7'> - + - true + true ]]> @@ -873,7 +941,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='8'> - + @@ -885,7 +953,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='8'> - + true true false @@ -907,22 +975,22 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='9'> - + - @@ -934,7 +1002,7 @@

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

    - + @@ -953,13 +1021,13 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='10'> - - - - + + + + ]]> @@ -977,15 +1045,16 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='11'> - + - + @@ -1003,7 +1072,7 @@

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

    - + @@ -1022,9 +1091,9 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='12'> - - + + @@ -1034,8 +1103,8 @@ - + @@ -1045,8 +1114,8 @@ - + @@ -1073,22 +1142,22 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='13'> - + - - - - - + + + + + ]]> @@ -1103,16 +1172,16 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='14'> - + - - + + @@ -1122,8 +1191,8 @@ - + @@ -1133,8 +1202,8 @@ - + @@ -1144,8 +1213,8 @@ - + @@ -1163,7 +1232,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='15'> - + Namespace.BaseClass1 @@ -1172,11 +1241,11 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='15'> - - - + + + ]]> @@ -1192,7 +1261,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='16'> - + Namespace.BaseClass1 @@ -1201,9 +1270,9 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='16'> - - + + @@ -1213,8 +1282,8 @@ - + @@ -1243,14 +1312,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='17'> - + - + Namespace.BaseClass1 Namespace.AbstractBase @@ -1258,10 +1327,14 @@ ]]> +

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

    @@ -1270,23 +1343,23 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='18'> - + - - + + ]]>

    - This commands 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 + 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.

    @@ -1295,16 +1368,16 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='19'> - + - - + + @@ -1320,7 +1393,7 @@

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

    - + - - - + + + ]]>

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

    - + - - + + @@ -1373,8 +1446,8 @@ - + @@ -1392,20 +1465,20 @@

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

    - + - +     - + country region city @@ -1428,16 +1501,16 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='23'> - + - - + + ]]>     @@ -1452,7 +1525,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='24'> - @@ -1460,9 +1533,9 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='24'> - - + + @@ -1481,7 +1554,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='25'> - + @@ -1491,11 +1564,11 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='25'> - - - + + + ]]> @@ -1510,7 +1583,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='26'> - + @@ -1520,15 +1593,15 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='26'> - - + + - + @@ -1547,14 +1620,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='27'> - + - + A1-1 A1-2 ... @@ -1573,32 +1646,32 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='42'> - + - - - - - - - - - - + + + + + + + + + + ]]> @@ -1618,14 +1691,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='53'> - + - + ]]>

    @@ -1643,14 +1716,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='54'> - + - + ]]>

    @@ -1667,7 +1740,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='55'> - + @@ -1678,7 +1751,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='55'> - + ]]>

    @@ -1690,13 +1763,13 @@

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

    - + - + @@ -1707,7 +1780,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='56'> - + ]]>

    @@ -1735,19 +1808,19 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='28'> - + - + + xmlns:xdl='http://jabber.org/protocol/xdata-layout' + xmlns:xdd='urn:xmpp:xdata:dynamic'> Node1 @@ -1845,16 +1918,16 @@ Makes it possible to layout parameters into pages and sections. - XEP-0000-ColorParameter + XEP-0331 Defines extensions for how color parameters can be handled. - xep-0000-DynamicForms + XEP-0336 Makes it possible to create dynamic forms, with server-side validation and forms that change dynamically depending on input.

    - Read-only parameters will be returned with the readOnly element, as defined in xep-0000-DynamicForms. + 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.

    @@ -1863,7 +1936,7 @@

    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 any more. + 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.

    - + 009c7956-001c-43fb-8edb-76bcf74272c9 @@ -1905,9 +1978,9 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='29'> - - + + @@ -1938,7 +2011,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='30'> - + 009c7956-001c-43fb-8edb-76bcf74272c9 @@ -1972,7 +2045,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='30'> - + There already exists a node with this ID. ]]> @@ -1980,9 +2053,9 @@

    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-0000-DynamicForms + explicitly cancelled or a form session time-out has occurred. See XEP-0336 - XEP-xxxx: Dynamic Data Forms <xep-0000-DynamicForms.html> + XEP-0336: Dynamic Data Forms <http://xmpp.org/extensions/xep-0336.html> for more information.

    @@ -1995,8 +2068,8 @@

    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-0000-DynamicForms. Clients using this command MUST - support the extensions defined in xep-0000-DynamicForms. + notSame element, according to XEP-0336. Clients using this command MUST + support the extensions defined in XEP-0336.

    - + @@ -2015,12 +2088,12 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='31'> - + + xmlns:xdl='http://jabber.org/protocol/xdata-layout' + xmlns:xdd='urn:xmpp:xdata:dynamic'> Node1, Node2, Node3 @@ -2113,7 +2186,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='32'> - + @@ -2132,9 +2205,9 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='32'> - - + + @@ -2144,8 +2217,8 @@ - + @@ -2155,8 +2228,8 @@ - + @@ -2176,7 +2249,7 @@

    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-0000-DynamicForms. Such parameters MUST NOT be sent back to the server + 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.

    @@ -2185,13 +2258,13 @@ 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.

    - + - + @@ -2213,7 +2286,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='33'> - + Parameter not available. ]]> @@ -2221,11 +2294,10 @@

    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-0000-DynamicForms - xep-0000-DynamicForms.html for more information. + 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: @@ -2292,23 +2364,24 @@ getNodesFromIndices

    • - + - + - - Internal clock is offset more than 7 seconds. + + Internal clock is offset more than 7 seconds. ]]> @@ -2316,22 +2389,22 @@ The messages attribute can be combined with the parameters attribute to provide both node parameters and messages in the response.

    - + - + - + @@ -2340,7 +2413,8 @@ - Internal clock is offset more than 7 seconds. + Internal clock is offset more than 7 seconds. ]]> @@ -2358,14 +2432,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='36'> - + - + @@ -2384,19 +2458,20 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='37'> - + - + + xmlns:xdl='http://jabber.org/protocol/xdata-layout' + xmlns:xdd='urn:xmpp:xdata:dynamic'> Metering Topology @@ -2430,7 +2505,8 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='38'> - + 0B146517-8EA3-4BEC-A2E9-CF3F209D4A5D @@ -2449,9 +2525,9 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='38'> - - + + @@ -2477,7 +2553,8 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='39'> - + 0B146517-8EA3-4BEC-A2E9-CF3F209D4A5D @@ -2496,7 +2573,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='39'> - + There already exists a node with this ID. Referenced node was not found. @@ -2505,8 +2582,7 @@

    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-0000-DynamicForms - xep-0000-DynamicForms.html for more information. + explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

    @@ -2519,14 +2595,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='40'> - +     - + ]]>

    @@ -2544,14 +2620,14 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='41'> - + - + ]]> @@ -2569,28 +2645,36 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='43'> - + - - + - + ]]>

    - There are two types of commands available: Simple and Parameterized. 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. For more information about command attributes, see Node Commands. + 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.

    @@ -2603,20 +2687,20 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='44'> - + - + ]]>

    - To execute a parameterized command 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 + 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:

    @@ -2625,19 +2709,20 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='45'> - + - + + xmlns:xdl='http://jabber.org/protocol/xdata-layout' + xmlns:xdd='urn:xmpp:xdata:dynamic'> Schedule wake-up call E14E330F-8496-46F0-8F40-178808AB13A7 @@ -2673,7 +2758,8 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='46'> - + E14E330F-8496-46F0-8F40-178808AB13A7 @@ -2692,7 +2778,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='46'> - + ]]>     @@ -2701,8 +2787,7 @@ 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-0000-DynamicForms - xep-0000-DynamicForms.html for more information. + explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

    - + E14E330F-8496-46F0-8F40-178808AB13A7 @@ -2729,12 +2815,178 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='47'> - + You are not allowed to harass people at 04:30:00! ]]> + +

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

    + + + + + + + + + Search for events + + E14E330F-8496-46F0-8F40-178808AB13A7 + + + From what point in time events will be fetched. + + 2013-04-16T12:58:00 + + + + + + To what point in time events will be fetched. + + 2013-04-23T12:58:00 + + + + + + Only return events including this text. + + + + + + ]]> + +

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

    + + + + + + 2013-04-16T12:58:00 + + + 2013-04-23T12:58:00 + + + Harass + + + + + + + + + + ...]]> + +

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

    + + + + + + 2013-04-23T12:58:00 + + + 2013-04-16T12:58:00 + + + Harass + + + + + + + + The TO timestamp needs to be later than the FROM timestamp. + + ]]> + +     + +

    + 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, @@ -2746,7 +2998,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='48'> - + @@ -2760,15 +3012,15 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='48'> - - + - - + ]]> @@ -2783,7 +3035,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='49'> - + @@ -2797,7 +3049,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='49'> - + true true true @@ -2819,7 +3071,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='50'> - + @@ -2833,12 +3085,12 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='50'> - + + xmlns:xdl='http://jabber.org/protocol/xdata-layout' + xmlns:xdd='urn:xmpp:xdata:dynamic'> Schedule wake-up call E14E330F-8496-46F0-8F40-178808AB13A7 @@ -2859,7 +3111,7 @@ - + ]]> @@ -2874,7 +3126,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='51'> - + @@ -2899,7 +3151,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='51'> - + true true true @@ -2915,8 +3167,7 @@ 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-0000-DynamicForms - xep-0000-DynamicForms.html for more information. + explicitly cancelled or a form session time-out has occurred. See XEP-0336 for more information.

    - + @@ -2949,7 +3200,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='52'> - + You are not allowed to harass people at 04:30:00! ]]> @@ -2962,7 +3213,9 @@ 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. + 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.

    - + @@ -2995,17 +3248,506 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='72'> - + true true - false + false true - false + false true ]]>     + +

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

    + + + + + + + + + + + + + + + + Schedule wake-up call + + E14E330F-8496-46F0-8F40-178808AB13A7 + + + From what point in time events will be fetched. + + 2013-04-16T12:58:00 + + + + + + To what point in time events will be fetched. + + 2013-04-23T12:58:00 + + + + + + Only return events including this text. + + + + + ]]> + +

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

    + + + + + + + + + + + + 2013-04-16T12:58:00 + + + 2013-04-23T12:58:00 + + + Harass + + + + + + + + + + ...]]> + +

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

    + + + + + + + + + + + + 2013-04-23T12:58:00 + + + 2013-04-16T12:58:00 + + + Harass + + + + + + + + The TO timestamp needs to be later than the FROM timestamp. + + ]]> + +     + +

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

    + + + + + + + + + + + + 2013-04-23T12:58:00 + + + 2013-04-16T12:58:00 + + + Harass + + + + + + + + true + true + false + true + true + true + + ]]> + +     + +

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

    +     +     + +

    + Query events are sent as a response to executing queries on nodes. They are reported asynchronously from the concentrator to the client executing the query. Each + event is wrapped in a queryProgress element within a message sent from the concentrator to the client. Each such queryProgress + element can include any number of query events, and the client must process them in the order they appear in the message. +

    +

    + Each queryProgress element contains a queryId attribute identifying the query to which the events correspond. They also contain + sourceId, nodeId and an optional cacheType to identify from which node in a concentrator the events originated. +

    +

    + Note: A queryProgress element can only contain events from a single query executed on a single node. If a query is executed on + multiple nodes, events resulting from different nodes will be sent in different messages. +

    +

    + The following subsections describe each query event in turn. +

    + +

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

    + + + + ... + + + 2013-04-24T17:43:15 + Harassed + + ... + + ... + + ]]> + +

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

    + + + + ... + 30 events found. + ... + + ]]> + +

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

    + + + + ... + + ... + </queryProgress> + </message>]]> + </example> + </section3> + <section3 topic='Status'> + <p> + Permits the executing process to report the current status. This can change a lot during execution and values should not be persisted, like + query messages. Instead, they can be displayed in a status bar, just to give the end-user feedback of the status of a long-running query. + </p> + <example caption='Status'> + <![CDATA[ + <message from='concentrator@clayster.com' + to='client@clayster.com/client'> + <queryProgress xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringGroups' nodeId='Apartment 1-1' cacheType='Apartment' queryId='Query0001'> + ... + <status message='Processing. 67% done.'/> + ... + </queryProgress> + </message>]]> + </example> + </section3> + <section3 topic='Starting a section or subsection'> + <p> + Starts a new section in the query result. In large query results, sections can be used to format the result using an intuitive disposition + in a visually appealing way. Nested sections should be interepreted as sub-sections. Tables and objects started or reported within a section + belong in that section, and should be listed sequentially in the order they are reported to the client. + </p> + <example caption='Starting a section or subsection'> + <![CDATA[ + <message from='concentrator@clayster.com' + to='client@clayster.com/client'> + <queryProgress xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringGroups' nodeId='Apartment 1-1' cacheType='Apartment' queryId='Query0001'> + ... + <beginSection header='1. Stockholm'/> + ... + <beginSection header='1.1. Solna'/> + ... + </queryProgress> + </message>]]> + </example> + <p> + Note that the use of sections in a query result is optional. Tables and objects received outside the scope of sections should be placed + in a default section by the client. + </p> + </section3> + <section3 topic='Closing a section or subsection'> + <p> + Closes the current section or sub-section. Tables inside closed sections can still be open and receive fields. Tables are closed using the + <strong>tableDone</strong> query event. + </p> + </section3> + <example caption='Starting a section or subsection'> + <![CDATA[ + <message from='concentrator@clayster.com' + to='client@clayster.com/client'> + <queryProgress xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringGroups' nodeId='Apartment 1-1' cacheType='Apartment' queryId='Query0001'> + ... + <endSection/> + ... + <endSection/> + ... + </queryProgress> + </message>]]> + </example> </section2> <section2 topic='Data Source Events' anchor='sourceevents'> <p> @@ -3036,16 +3778,18 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeAdded xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1' nodeType='Namespace.NodeType1' cacheType='Node' state='None' - hasChildren='false' isReadable='true' isConfigurable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'/> + <nodeAdded xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1' nodeType='Namespace.NodeType1' + cacheType='Node' state='None' hasChildren='false' isReadable='true' isControllable='true' hasCommands='true' + parentId='Root' lastChanged='2013-03-19T17:58:01'/> </message>]]> </example> <example caption='Node added event, with parameters'> <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeAdded xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1' nodeType='Namespace.NodeType1' cacheType='Node' state='None' - hasChildren='false' isReadable='true' isConfigurable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'> + <nodeAdded xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1' nodeType='Namespace.NodeType1' + cacheType='Node' state='None' hasChildren='false' isReadable='true' isControllable='true' hasCommands='true' + parentId='Root' lastChanged='2013-03-19T17:58:01'> <string id='id' name='Node ID' value='Node1'/> <string id='type' name='Node Type' value='Watchamacallit Temperature Sensor v1.2'/> <string id='sn' name='Serial Number' value='123456'/> @@ -3062,6 +3806,19 @@ removing it from the current source (sending a <strong>nodeRemoved</strong> event) and then adding it to the new data source (sending a <strong>nodeAdded</strong> event), in that order. </p> + <p> + If a node is added to a parent where order of nodes is important, the attributes <strong>afterNodeId</strong> and also optionally + <strong>afterNodeCacheType</strong> used to identify the node after which the new node should be inserted. + </p> + <example caption='Ordered Node added event, without parameters'> + <![CDATA[ + <message from='concentrator@clayster.com' + to='client@clayster.com/client'> + <nodeAdded xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node2' nodeType='Namespace.NodeType1' + cacheType='Node' state='None' hasChildren='false' isReadable='true' isControllable='true' hasCommands='true' + parentId='Root' lastChanged='2013-03-19T17:58:01' afterNodeId='Node1' afterNodeCacheType='Node'/> + </message>]]> + </example> </section3> <section3 topic='Node removed'> <p> @@ -3072,7 +3829,7 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeRemoved xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1'/> + <nodeRemoved xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1'/> </message>]]> </example> <p> @@ -3090,16 +3847,18 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeUpdated xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1' nodeType='Namespace.NodeType1' cacheType='Node' state='None' - hasChildren='false' isReadable='true' isConfigurable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'/> + <nodeUpdated xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1' nodeType='Namespace.NodeType1' + cacheType='Node' state='None' hasChildren='false' isReadable='true' isControllable='true' hasCommands='true' + parentId='Root' lastChanged='2013-03-19T17:58:01'/> </message>]]> </example> <example caption='Node updated event, with parameters'> <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeUpdated xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1' nodeType='Namespace.NodeType1' cacheType='Node' state='None' - hasChildren='false' isReadable='true' isConfigurable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'> + <nodeUpdated xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1' nodeType='Namespace.NodeType1' + cacheType='Node' state='None' hasChildren='false' isReadable='true' isControllable='true' hasCommands='true' + parentId='Root' lastChanged='2013-03-19T17:58:01'> <string id='id' name='Node ID' value='Node1'/> <string id='type' name='Node Type' value='Watchamacallit Temperature Sensor v1.2'/> <string id='sn' name='Serial Number' value='123456'/> @@ -3119,16 +3878,18 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeUpdated xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' oldId='OldNode1' id='Node1' nodeType='Namespace.NodeType1' cacheType='Node' state='None' - hasChildren='false' isReadable='true' isConfigurable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'/> + <nodeUpdated xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' oldId='OldNode1' nodeId='Node1' + nodeType='Namespace.NodeType1' cacheType='Node' state='None' hasChildren='false' isReadable='true' + isControllable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'/> </message>]]> </example> <example caption='Node renamed event, with parameters'> <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeUpdated xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' oldId='OldNode1' id='Node1' nodeType='Namespace.NodeType1' cacheType='Node' state='None' - hasChildren='false' isReadable='true' isConfigurable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'> + <nodeUpdated xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' oldId='OldNode1' nodeId='Node1' + nodeType='Namespace.NodeType1' cacheType='Node' state='None' hasChildren='false' isReadable='true' + isControllable='true' hasCommands='true' parentId='Root' lastChanged='2013-03-19T17:58:01'> <string id='id' name='Node ID' value='Node1'/> <string id='type' name='Node Type' value='Watchamacallit Temperature Sensor v1.2'/> <string id='sn' name='Serial Number' value='123456'/> @@ -3154,14 +3915,14 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeStatusChanged xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1' cacheType='Node' state='ErrorUnsigned'/> + <nodeStatusChanged xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1' cacheType='Node' state='ErrorUnsigned'/> </message>]]> </example> <example caption='Node status changed event, with messages'> <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeStatusChanged xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1' cacheType='Node' state='ErrorUnsigned'> + <nodeStatusChanged xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1' cacheType='Node' state='ErrorUnsigned'> <message timestamp='2013-03-22T12:49:34' type='Error'>Sensor does not respond to read-out requests.</message> </nodeStatusChanged> </message>]]> @@ -3176,7 +3937,7 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeMovedUp xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1'/> + <nodeMovedUp xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1'/> </message>]]> </example> <p> @@ -3194,7 +3955,7 @@ <![CDATA[ <message from='concentrator@clayster.com' to='client@clayster.com/client'> - <nodeMovedDown xmlns='urn:xmpp:sn:concentrators' sourceId='MeteringTopology' id='Node1'/> + <nodeMovedDown xmlns='urn:xmpp:iot:concentrators' sourceId='MeteringTopology' nodeId='Node1'/> </message>]]> </example> <p> @@ -3224,18 +3985,18 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='64'> - <getDatabases xmlns='urn:xmpp:sn:concentrators' xml:lang='en'/> + <getDatabases xmlns='urn:xmpp:iot:concentrators' xml:lang='en'/> </iq> <iq type='result' from='concentrator@clayster.com' to='client@clayster.com/client' id='64'> - <getDatabasesResponse xmlns='urn:xmpp:sn:concentrators' result='OK'> - <database id='LocalDB' name='Local Database'/> - <database id='LocalDBTest' name='Local Test Database'/> - <database id='LocalDBProduction' name='Local Production Database'/> - <database id='RemoteDB' name='Remote Database'/> + <getDatabasesResponse xmlns='urn:xmpp:iot:concentrators' result='OK'> + <database databaseId='LocalDB' name='Local Database'/> + <database databaseId='LocalDBTest' name='Local Test Database'/> + <database databaseId='LocalDBProduction' name='Local Production Database'/> + <database databaseId='RemoteDB' name='Remote Database'/> </getDatabasesResponse> </iq>]]> </example> @@ -3251,19 +4012,19 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='65'> - <getDatabaseReadoutParameters xmlns='urn:xmpp:sn:concentrators' xml:lang='en' databaseId='LocalDB'/> + <getDatabaseReadoutParameters xmlns='urn:xmpp:iot:concentrators' xml:lang='en' databaseId='LocalDB'/> </iq> <iq type='result' from='concentrator@clayster.com' to='client@clayster.com/client' id='65'> - <getDatabaseReadoutParametersResponse xmlns='urn:xmpp:sn:concentrators' result='OK'> + <getDatabaseReadoutParametersResponse xmlns='urn:xmpp:iot:concentrators' result='OK'> <x type='form' xmlns='jabber:x:data' xmlns:xdv='http://jabber.org/protocol/xdata-validate' - xmlns:xdl:='http://jabber.org/protocol/xdata-layout' - xmlns:xdd:='http://jabber.org/protocol/xdata-dynamic'> + xmlns:xdl='http://jabber.org/protocol/xdata-layout' + xmlns:xdd='urn:xmpp:xdata:dynamic'> <title>Database read-out @@ -3488,17 +4249,15 @@

    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 sensor-data - - XEP-xxxx: Sensor Data sensor-data - . The only difference is that the read-out is started with the startDatabaseReadout command instead of the req + 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: @@ -3509,7 +4268,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='66'> - + @@ -3620,7 +4379,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='66'> - + ... Readout messages follow.]]> @@ -3636,7 +4395,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='67'> - + @@ -3650,7 +4409,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='67'> - + ]]>

    @@ -3662,7 +4421,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='68'> - + @@ -3683,7 +4442,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='68'> - + The To timestamp cannot be older than the From timestamp. ]]> @@ -3691,8 +4450,8 @@

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

    - + @@ -3714,7 +4473,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='70'> - + ... @@ -3723,19 +4482,48 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='71'> - + - + ]]>     + +

    If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:iot:concentrators" in response to &xep0030; information requests.

    + + + +]]> + + + + + ... + + ... + +]]> + +

    + In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined + in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead. +

    +

    @@ -3749,39 +4537,39 @@ Description - id + nodeId required -   +   The ID of the node in the data source. displayName optional -   +   If provided, a string presentable to users. If localization is supported and a correct language attribute was provided, this string will be localized. nodeType optional -   +   A string representing the type of the node. localId optional -   +   If provided, an ID for the node, but unique locally between siblings. logId optional -   +   If provided, an ID for the node, as it would appear or be used in system logs. cacheType optional -   +   Used to uniquely identify the node in sources where the ID of the node is not sufficient. Example: In a spatial ordering different nodes may represent countries, regions, cities, areas, streets, buildings and apartments in the same source. However, the ID of each node would depend on what type of node it represents. It might be valid to have a region, city and/or area with the same ID. So, to these circumstances, a Cache Type of Country, Region, City, Area, @@ -3790,13 +4578,13 @@ state required -   +   Current overall state of the node. hasChildren required -   +   If the node has children or not. @@ -3816,10 +4604,10 @@ If the node can be read. (*) - isConfigurable + isControllable optional false - If the node can be configured. (**) + If the node can be controlled. (**) hasCommands @@ -3830,27 +4618,27 @@ parentId optional -   +   The node ID of the parent node. If not available, the node is considered a root node. parentCacheType optional -   +   The Cache Type of the parent node. lastChanged optional -   +   When the node was last changed. Can be used by clients to synchronize content between the concentrator and itself.

    - (*) See sensor-data for more information about how to read nodes. + (*) See Internet of Things - Sensor Data for more information about how to read nodes.

    - (**) See xep-0000-SN-Control for more information about how to configure nodes. + (**) See Internet of Things - Control for more information about how to control nodes.

    (***) Note that cacheType is optional. In some data sources it might be necessary to include a cache type to allow for IDs that are not unique @@ -3970,7 +4758,7 @@ from='client@clayster.com/client' to='concentrator@clayster.com' id='69'> - + ... @@ -3979,7 +4767,7 @@ from='concentrator@clayster.com' to='client@clayster.com/client' id='69'> - + ]]> @@ -3994,7 +4782,7 @@ Description - id + command required ID of the command. Used to identify the command. @@ -4101,6 +4889,178 @@ More information can be found in the XEP-xxxx: Interoperability Interoperability section.

    + +

    + Table columns in query results can have the following attributes: +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AttributeUseDescription
    columnIdRequiredID of column
    headerOptionalIf provided, a localized name to be displayed instead of the column ID.
    alignmentOptionalAlignment of contents in the column. If provided, the client does not need to guess alignment from the type of data reported.
    nrDecimalsOptionalIf floating point data is presented in the column and a fixed number of decimals is desired, this attribute is used to fix the number of decimals used.
    dataSourceIdOptionalIf contents of columns contains references to nodes in a data source, this attribute defines the data source ID.
    cacheTypeNameOptionalIf contents of columns contains references to nodes in a data source, this attribute defines the cache type.
    fgColorOptionalIf presentation of this column should be done using a specific foreground color.
    bgColorOptionalIf presentation of this column should be done using a specific background color.
    +     + +

    + Records contain arrays of items, each item correspond to a specific column with the same ordinal index. Each item is specified together with its type. + This, so receptors can integrate the result with type information if necessary. The following different type elements are available: +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    ElementContents
    booleanA boolean value, corresponding to the xs:boolean data type.
    colorA color value. These are strings containing 6 case-insensitive hexadecimal digits of the form RRGGBB, where RR=Red component, GG=Green component, BB=Blue component.
    dateTimeA Date & Time value, corresponding to the xs:dateTime data type.
    doubleA floating-point value, corresponding to the xs:double data type.
    durationA duration value, corresponding to the xs:duration data type.
    intA 32-bit integer value, corresponding to the xs:int data type.
    longA 64-bit value, corresponding to the xs:long data type.
    stringA string value, corresponding to the xs:string data type.
    timeA time value, corresponding to the xs:time data type.
    base64A base-64 encoded object. The object is MIME encoded, and the attribute contentType contains the MIME Type which includes information on how to decode the value.
    voidContains no information. This represents a NULL value.
    +     + +

    + Messages in query results contain apart from a message text, also contain some classification on what the message is using two attributes: The + type attribute gives a rough idea about the type of message and level the importance of the message. +

    + + + + + + + + + + + + + + + + + + + + + +
    TypeDescription
    InformationInformation message
    WarningMessage contains a warning. The situation could turn into an error if consideration or action is not taken.
    ErrorMessage contains an error. The error message describes the error, and the error has been handled correctly by the device performing the query.
    ExceptionMessage contains an exception message. An unforseen and perhaps an unhandled event has occurred during the execution of the query.
    + + + + + + + + + + + + + + + + + +
    LevelDescription
    MinorMinor event. Message describes common tasks.
    MediumMedium event. Message might describe a state change, something has been updated, or important information.
    MajorMajor event. Message might describe architectural change or vital information.
    +     + +

    + Many commands exist in single and batch versions. Large concentrators require efficient ways to manage sets of nodes simultaneously, while for small + concentrators, it is sufficient to manage nodes one at a time. +

    +

    + A concentrator is not required to implement both sets of commands if not desired. However, it must report which commands it supports in the + getCapabilities command. A caller can then adapt its calls based on what commands are supported. +

    +

    + If a caller wants to call the single item version of a command, but the concentrator only supports the batch version, it should call the batch version, but + only include the single node in the list of nodes. +

    +

    + On the other hand, if the caller wants to perform an operation on a set of nodes, but the concentrator only supports the single item version of the command, + it needs to manually perform the operation on each node separately, unless failing the request is an option. +

    +     @@ -4123,7 +5083,7 @@

    For concentrators to be interoperable in sensor networks, they need to adhere to rules and guidelines described in the - xep-0000-SN-Interoperability document. + xep-0000-IoT-Interoperability document.

    @@ -4138,8 +5098,8 @@ The concentrator can restrict friendships to trusted friends, and then assign access rights internally to the approved contacts.
  • - The concentrator can use a provisioning server (see XEP-xxxx: Provisioning sensor-network-provisioning) - to delegate trust to a third party responsible for controlling who can get access to the concentrator (isFriend or canAccess commands), + The concentrator can use a provisioning server (see &xep0324;) + to delegate trust to a third party responsible for controlling who can get access to the concentrator (isFriend or canAccess commands), and what items can be viewed (hasPrivilege or downloadPrivileges commands).
  • @@ -4150,107 +5110,108 @@
    • - -

    - The sensor-network-provisioning document describes how trust can be delegated to trusted provisioning servers - that can be used to restrict access to and privileges in a network. -

    -

    - If a concentrator has a trusted relationship with a provisioning server, external or internal, the provisioning server must be used to guarantee that the - concetrator only allows access according to rules defiend by the provisioning server. In order to do this, it's important that clients always provide - available tokens (userToken, serviceToken and deviceToken) to the concentrator so that it can forward this - information to the provisioning server. -

    -

    - The following subsections show different examples of how such an integration can be performed. -

    - -

    - 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-SN-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-SN-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-SN-Interoperability. -
      • -
    -     -     - + +

    + The Internet of Things - Provisioning document describes how trust can be delegated to trusted provisioning servers + that can be used to restrict access to and privileges in a network. +

    +

    + If a concentrator has a trusted relationship with a provisioning server, external or internal, the provisioning server must be used to guarantee that the + concentrator only allows access according to rules defined by the provisioning server. In order to do this, it's important that clients always provide + available tokens (userToken, serviceToken and deviceToken) to the concentrator so that it can forward this + information to the provisioning server. +

    +

    + The following subsections show different examples of how such an integration can be performed. +

    + +

    + 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. +
      • +
    +     +     + -

    This document requires no interaction with &IANA;.

    -     +

    This document requires no interaction with &IANA;.

    + -

    REQUIRED.

    - -     +

    + The protocol schema needs to be added to the list of XMPP protocol schemas. +

    + - + @@ -4295,7 +5256,7 @@ - + @@ -4311,7 +5272,7 @@ - + @@ -4342,7 +5303,7 @@ - + @@ -4358,7 +5319,7 @@ - + @@ -4388,7 +5349,7 @@ - + @@ -4417,7 +5378,7 @@ - + @@ -4425,6 +5386,27 @@ + + + + + + + + + + + + + + + + + + + + + @@ -4444,14 +5426,36 @@ - + + + + + + + + + + + + + + + + + + + + + + + @@ -4488,7 +5492,17 @@ - + + + + + + + + + + + @@ -4498,6 +5512,7 @@ + @@ -4510,6 +5525,7 @@ + @@ -4520,7 +5536,7 @@ - + @@ -4538,7 +5554,7 @@ - + @@ -4547,6 +5563,151 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -4588,6 +5749,32 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -4656,7 +5843,7 @@ - + @@ -4709,7 +5896,7 @@ - + @@ -4719,7 +5906,7 @@ - + @@ -4731,7 +5918,7 @@ - + @@ -4745,7 +5932,7 @@ - + @@ -4755,7 +5942,7 @@ - + @@ -4852,7 +6039,7 @@ - + @@ -4919,7 +6106,7 @@ - + @@ -4933,7 +6120,7 @@ - + @@ -4968,7 +6155,15 @@ - + + + + + + + + + @@ -4998,7 +6193,31 @@ ]]> + +

    + For more information, please see the following resources: +

    + +     -

    Thanks to Joachim Lindborg and Karin Forsell for all valuable feedback.

    +

    Thanks to Joachim Lindborg, Karin Forsell, Tina Beckman and Klaudiusz Staniek for all valuable feedback.