diff --git a/xep-0323.xml b/xep-0323.xml index 0aec8e7d..7aee4506 100644 --- a/xep-0323.xml +++ b/xep-0323.xml @@ -1,4 +1,27 @@ + + + %ents; @@ -8,6 +31,7 @@
Internet of Things - Sensor Data This specification provides the common framework for sensor data interchange over XMPP networks. + &LEGALNOTICE; 0323 Experimental Standards Track @@ -20,24 +44,36 @@ - NOT_YET_ASSIGNED + sensor-data 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-04-16 - psa -

Initial published version approved by the XMPP Council.

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

Changed the id attrobutes of IQ stanzas, to highlight they are different from sequence numbers used in requests.

+

Fixed links to documents with new numbers.

+

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

+ + + + 0.1 + 2013-04-16 + psa + +

Initial published version approved by the XMPP Council.

+ + 0.0.5 2013-04-01 - pwa + pw

Added resource information of original called to their corresponding JIDs.

Changed the return type of a rejected message.

@@ -48,7 +84,7 @@ 0.0.4 2013-03-18 - pwa + pw

Added information about how to read sensors from large subsystems.

Added support for client/device provisioning tokens.

@@ -57,7 +93,7 @@ 0.0.3 2013-03-11 - pwa + pw

Changed time point to timestamp everywhere.

Corrected some errors in the text.

@@ -67,7 +103,7 @@ 0.0.2 2013-03-09 - pwa + pw

Corrected some errors in XML examples.

English corrected.

@@ -78,7 +114,7 @@ 0.0.1 2013-03-07 - pwa + pw

First draft.

 @@ -102,59 +138,65 @@ Description - XEP-0000-ColorParameter - Defines extensions for how color parameters can be handled, based on &xep0004; - - - XEP-0000-DynamicForms - Defines 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-BatteryPoweredSensors + xep-0000-IoT-BatteryPoweredSensors Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network. - xep-0000-SN-Concentrators - Defines how to handle architectures containing concentrators or servers handling multiple sensors. - - - xep-0000-SN-Control - Defines how to control actuators and other devices in sensor networks. - - - xep-0000-SN-Discovery + xep-0000-IoT-Discovery Defines 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-Events + xep-0000-IoT-Events Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured. - xep-0000-SN-Interoperability + xep-0000-IoT-Interoperability Defines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices. - xep-0000-SN-Multicast + xep-0000-IoT-Multicast Defines how sensor data can be multicast in efficient ways. - sensor-network-provisioning - Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented. - - - xep-0000-SN-PubSub + xep-0000-IoT-PubSub Defines how efficient publication of sensor data can be made in sensor networks. - sensor-data + xep-0000-IoT-Chat + Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture. + + + 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 This specification. 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-0324 + Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented. + + + XEP-0325 + Defines how to control actuators and other devices in Internet of Things. + + + XEP-0326 + Defines how to handle architectures containing concentrators or servers handling multiple sensors. + + + XEP-0331 + Defines extensions for how color parameters can be handled, based on &xep0004; + + + XEP-0336 + Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;. + @@ -207,18 +249,19 @@
Node
-
Graphs contain nodes and edges between nodes. In Sensor Networks, sensors, actuators, meters, devices, gatewats, 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.
+
+ 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.
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 +
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.
Parameter
-
Readable and/or writable property on a node/device. The XEP xep-0000-SN-Concentrators deals with reading and writing parameters +
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.
 @@ -251,7 +294,7 @@
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 + 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.
@@ -357,7 +400,7 @@

The device can also reject a read-out request. Reasons for rejecting a request may be missing privileges defined by provisioning rules, etc. It's not part of this XEP - to define such rules. A separate XEP (sensor-network-provisioning) defines an architecture for how such provisioning can be easily implemented. + to define such rules. A separate XEP (&xep0324;) defines an architecture for how such provisioning can be easily implemented.

A rejection response is shown in the following diagram. @@ -384,10 +427,10 @@ - + id='S0001'> + ]]> @@ -399,9 +442,9 @@ - + to='client@clayster.com/amr' + id='S0001'> + ]]> @@ -412,8 +455,8 @@ - + to='client@clayster.com/amr'> + @@ -432,22 +475,22 @@ - + id='S0002'> + - + to='client@clayster.com/amr' + id='S0002'> + - + to='client@clayster.com/amr'> + Timeout. ]]> @@ -461,17 +504,17 @@ - + id='S0003'> + - + to='client@clayster.com/amr' + id='S0003'> + Access denied. ]]> @@ -488,27 +531,27 @@ - + id='S0004'> + - + to='client@clayster.com/amr' + id='S0004'> + - + to='client@clayster.com/amr'> + - + to='client@clayster.com/amr'> + @@ -520,8 +563,8 @@ - + to='client@clayster.com/amr'> + @@ -533,8 +576,8 @@ - + to='client@clayster.com/amr'> + @@ -554,8 +597,8 @@ - + to='client@clayster.com/amr'> + ]]> @@ -567,10 +610,10 @@ - + id='S0005'> + @@ -578,14 +621,14 @@ - + to='client@clayster.com/amr' + id='S0005'> + - + to='client@clayster.com/amr'> + @@ -595,8 +638,8 @@ - + to='client@clayster.com/amr'> + @@ -623,10 +666,10 @@ - + id='S0006'> + @@ -635,14 +678,14 @@ - + to='client@clayster.com/amr' + id='S0006'> + - + to='client@clayster.com/amr'> + @@ -660,41 +703,41 @@ - + id='S0007'> + - + to='client@clayster.com/amr' + id='S0007'> + - + id='S0008'> + - + to='client@clayster.com/amr' + id='S0008'> + ]]> -

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

+

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

@@ -704,11 +747,11 @@ ... - + ... ]]> @@ -723,8 +766,7 @@ affected negatively by this for two reasons:

    -
  • For sensors with limited memory, or where package size is important, EXI - Efficient XML Interchange (EXI) Format <http://www.w3.org/TR/exi/>. is supposed to be used. +
  • For sensors with limited memory, or where package size is important, &xep0322; is supposed to be used. EXI compresses strings as normalized index values, making the string appear only once in the packet. Therefore, shortening string length doesn't affect packet size much. Element and attribute names in known namespaces are furthermore only encoded by index in schema, not by name.
  • If limited memory or package size is not a consideration, readability and ease of implementation is preferred to short messages.
    • @@ -746,7 +788,7 @@

    • Since free strings are used, XML validation cannot be used to secure correct names are used.
      • -
    • xep-0000-SN-Interoperability lists recommendations on how field names and units should be used in order to achieve maximum interoperability in SN.
      • +
    • xep-0000-IoT-Interoperability lists recommendations on how field names and units should be used in order to achieve maximum interoperability in SN.
    • Consumers of sensor data need to include unit conversion algorithms.
    @@ -801,7 +843,7 @@ - +

    There are different types of fields, apart from types of values a field can have. These types are conceptual types, similar to categories. They are not exclusive, and can be combined. @@ -997,21 +1039,20 @@ can also be included.

    - More information about how multiple devices behind a JID can be handled, is described in the XEP xep-0000-SN-Concentrators. + More information about how multiple devices behind a JID can be handled, is described in the XEP-0326 + Internet of Things - Concentrators.

    All examples in this document have been simplified examples where a few devices containing a few fields have been read. However, in many cases large subsystems with - very many sensors containing many fields have to be read, as is documented in xep-0000-SN-Concentrators.html - - xep-0000-SN-Concentrators.html - . In such cases, a node may have to be specified using two or perhaps - even three ID's: a sourceId identifying the data source controlling the device, a possible cacheType narrowing down the search to - a specific kind of node, and the common nodeId. For more information about this, see xep-0000-SN-Concentrators.html. + very many sensors containing many fields have to be read, as is documented in Internet of Things - Concentrators. + In such cases, a node may have to be specified using two or perhaps even three ID's: a sourceId identifying the data source controlling the device, a possible + cacheType narrowing down the search to a specific kind of node, and the common nodeId. For more information about this, see + Internet of Things - Concentrators.

    - Note: For cases where the nodeId is sufficient to uniquelly identify the node, it is sufficient to provide this attribute in the request. + Note: For cases where the nodeId is sufficient to uniquely identify the node, it is sufficient to provide this attribute in the request. If there is ambiguity in the request, the receptor must treat the request as a request with a set of nodes, all with the corresponding nodeId as requested.

    @@ -1033,7 +1074,7 @@

    This specification allows for localization of field names in meter data read-out. This is performed by assigning each localizable string a String ID which should be unique within a given Language Module. A Language Module can be any string, including URI's or namespace names. - The XEP xep-0000-SN-Interoperability details how such localizations can be made in an interoperable way. + The XEP xep-0000-IoT-Interoperability details how such localizations can be made in an interoperable way.

    Note: Localization of strings are for human consumption only. Machines should use the unlocalized strings in program logic. @@ -1046,22 +1087,22 @@ - + id='S0009'> + - + to='client@clayster.com/amr' + id='S0009'> + - + to='client@clayster.com/amr'> +

    - Note: The XEP xep-0000-SN-Interoperability details how such localizations can be made in an interoperable way. + Note: The XEP xep-0000-IoT-Interoperability details how such localizations can be made in an interoperable way.

    The stringIds attribute merits some further explanation. The value of this attribute must match the following regular expression: @@ -1120,7 +1161,7 @@ ^\d+([|]\w+([.]\w+)*([|][^,]*)?)?(,\d+([|]\w+([.]\w+)*([|][^,]*)?)?)*$

    - This basically means, it's of the format: ID_1[|[Module_1][|Seed_1]][...[ID_n[|[Module_n][|Seed_n]]]] + This basically means, it's of the format: ID_1[|[Module_1][|Seed_1]][...[,ID_n[|[Module_n][|Seed_n]]]]

    Where brackets [] mean the contents inside is optional, ID_i is an integer representing the string ID in a language module. Module_i @@ -1181,7 +1222,7 @@

  • Communication should be restricted to friends as long as possible. Approved friendships provide a mechanism of limiting sensor information to authorized and authenticated users. However, there are cases where multicast messages may want to go outside of recognized friendships. More information about such use cases, see the - XEP xep-0000-SN-Multicast. + XEP xep-0000-IoT-Multicast.
  • Sensors may have very limited user interfaces. Even though installation of sensor networks is beyond the scope of this document, a simple installation scheme may include a @@ -1190,7 +1231,7 @@
  • More advanced access rights, privileges, automatic friendship recognition, etc., may be managed by a third party. How to implement more advanced provisioning and detailed - access rights to sensor information is detailed in the XEP sensor-network-provisioning. In short, a device, service or user can get a + access rights to sensor information is detailed in the XEP-0324 Internet of Things - Provisioning. In short, a device, service or user can get a deviceToken, serviceToken and userToken respectivelly from a provisioning server. The service or device then uses these tokens in all readout requests and the device being read out can in turn use these tokens to validate access rights with the provisioning server.
    • @@ -1200,8 +1241,9 @@

    This document requires no interaction with &IANA;.

    -

    REQUIRED.

    - +

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

    @@ -1209,8 +1251,8 @@ @@ -1423,6 +1465,30 @@ ]]> + +

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

    +
      +
    • +

      + The Sensor Network section of the XMPP Wiki contains further information about the + use of the sensor network XEPs, links to implementations, discussions, etc. +

      +
      • +
    • +

      + The XEP's and related projects are also available on github, thanks to Joachim Lindborg. +

      +
      • +
    • +

      + A presentation giving an overview of all extensions related to Internet of Things can be found here: + http://prezi.com/esosntqhewhs/iot-xmpp/. +

      +
      • +
    +

    Thanks to Joachim Lindborg, Karin Forsell, Tina Beckman, Kevin Smith and Tobias Markmann for all valuable feedback.