moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

XEP-0323 v0.2: 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

Browse Source
This commit is contained in:
Matthew A. Miller 2014-03-10 12:02:48 -06:00
parent ed76be2d35
commit f3525dabcf
1 changed files with 219 additions and 153 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

360
xep-0323.xml
View File

@ -1,4 +1,27 @@
<?xml version='1.0' encoding='UTF-8'?>
<!-- TODO: unsure eller inProgress statusfält mellan missing och automaticEstimate. -->
<!-- TODO: Ändra §5.6. Field Status Values to Field Quality of Service levels.
Det skall också stå att dessa flaggor är "summan av" många års erfarenhet från många olika system
nu står det bara just mätarsystem i första meningen.
Även exempel:
ta exemplet vattenmätaren:
[8:58:12 PM] Peter Waher: finns ett klassiskt problem
[8:58:18 PM] Peter Waher: vad händer när det inte kommer in pulser?
[8:58:23 PM] Peter Waher: har vattnet slutat flöda?
[8:58:27 PM] Peter Waher: eller flödar det långsamt?
[8:58:50 PM] Peter Waher: så mätare, istället för att rapportera 0, har någon form av invers funktion 1/t, där flödet långsamt avtar
[8:58:58 PM] Peter Waher: men det är ett estimat, för mätaren kan inte göra mer
[8:59:10 PM] Peter Waher: där kan således den lilla sensor rapportera automaticEstimate istf. automaticReadout
[8:59:18 PM] Peter Waher: för mätaren erkänner att den inte vet, och att den gissar
[8:59:31 PM] Peter Waher: den QoS-nivån är väldigt värdefull i sammanhanget
[8:59:42 PM] Peter Waher: eftersom man slipper göra felet att tro att det är läckage
[8:59:49 PM] Joachim Lindborg: Bra exempel att ha i den texten
[8:59:56 PM] Peter Waher: även om man ser ett "flöde" på mätaren
-->
<!-- Optional writable-attribute (utan default-värde) på fält, för att enklare kunna synkronisera med XEP-0325. -->
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
@ -8,6 +31,7 @@
<header>
<title>Internet of Things - Sensor Data</title>
<abstract>This specification provides the common framework for sensor data interchange over XMPP networks.</abstract>
&LEGALNOTICE;
<number>0323</number>
<status>Experimental</status>
<type>Standards Track</type>
@ -20,24 +44,36 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<shortname>sensor-data</shortname>
<author>
<firstname>Peter</firstname>
<surname>Waher</surname>
<email>peter.waher@clayster.com</email>
<jid>peter.waher@jabber.org</jid>
<uri>http://se.linkedin.com/pub/peter-waher/1a/71b/a29/</uri>
<uri>http://www.linkedin.com/in/peterwaher</uri>
</author>
<revision>
<version>0.2</version>
<date>2014-03-10</date>
<initials>pw</initials>
<remark>
<p>Changed the id attrobutes of IQ stanzas, to highlight they are different from sequence numbers used in requests.</p>
<p>Fixed links to documents with new numbers.</p>
<p>Changed namespace urn:xmpp:sn to urn:xmpp:iot:sensordata</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2013-04-16</date>
<initials>psa</initials>
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
<remark>
<p>Initial published version approved by the XMPP Council.</p>
</remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2013-04-01</date>
<initials>pwa</initials>
<initials>pw</initials>
<remark>
<p>Added resource information of original called to their corresponding JIDs.</p>
<p>Changed the return type of a rejected message.</p>
@ -48,7 +84,7 @@
<revision>
<version>0.0.4</version>
<date>2013-03-18</date>
<initials>pwa</initials>
<initials>pw</initials>
<remark>
<p>Added information about how to read sensors from large subsystems.</p>
<p>Added support for client/device provisioning tokens.</p>
@ -57,7 +93,7 @@
<revision>
<version>0.0.3</version>
<date>2013-03-11</date>
<initials>pwa</initials>
<initials>pw</initials>
<remark>
<p>Changed time point to timestamp everywhere.</p>
<p>Corrected some errors in the text.</p>
@ -67,7 +103,7 @@
<revision>
<version>0.0.2</version>
<date>2013-03-09</date>
<initials>pwa</initials>
<initials>pw</initials>
<remark>
<p>Corrected some errors in XML examples.</p>
<p>English corrected.</p>
@ -78,7 +114,7 @@
<revision>
<version>0.0.1</version>
<date>2013-03-07</date>
<initials>pwa</initials>
<initials>pw</initials>
<remark>
<p>First draft.</p>
</remark>
@ -102,59 +138,65 @@
<th>Description</th>
</tr>
<tr>
<td>XEP-0000-ColorParameter</td>
<td>Defines extensions for how color parameters can be handled, based on &xep0004;</td>
</tr>
<tr>
<td>XEP-0000-DynamicForms</td>
<td>Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.</td>
</tr>
<tr>
<td>exi</td>
<td>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.</td>
</tr>
<tr>
<td>xep-0000-SN-BatteryPoweredSensors</td>
<td>xep-0000-IoT-BatteryPoweredSensors</td>
<td>Defines how to handle the peculiars related to battery powered devices, and other devices intermittently available on the network.</td>
</tr>
<tr>
<td>xep-0000-SN-Concentrators</td>
<td>Defines how to handle architectures containing concentrators or servers handling multiple sensors.</td>
</tr>
<tr>
<td>xep-0000-SN-Control</td>
<td>Defines how to control actuators and other devices in sensor networks.</td>
</tr>
<tr>
<td>xep-0000-SN-Discovery</td>
<td>xep-0000-IoT-Discovery</td>
<td>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.</td>
</tr>
<tr>
<td>xep-0000-SN-Events</td>
<td>xep-0000-IoT-Events</td>
<td>Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured.</td>
</tr>
<tr>
<td>xep-0000-SN-Interoperability</td>
<td>xep-0000-IoT-Interoperability</td>
<td>Defines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.</td>
</tr>
<tr>
<td>xep-0000-SN-Multicast</td>
<td>xep-0000-IoT-Multicast</td>
<td>Defines how sensor data can be multicast in efficient ways.</td>
</tr>
<tr>
<td>sensor-network-provisioning</td>
<td>Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.</td>
</tr>
<tr>
<td>xep-0000-SN-PubSub</td>
<td>xep-0000-IoT-PubSub</td>
<td>Defines how efficient publication of sensor data can be made in sensor networks.</td>
</tr>
<tr>
<td>sensor-data</td>
<td>xep-0000-IoT-Chat</td>
<td>Defines how human-to-machine interfaces should be constructed using chat messages to be user friendly, automatable and consistent with other IoT extensions and possible underlying architecture.</td>
</tr>
<tr>
<td>XEP-0322</td>
<td>
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.
</td>
</tr>
<tr>
<td>XEP-0323</td>
<td>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.</td>
</tr>
<tr>
<td>XEP-0324</td>
<td>Defines how provisioning, the management of access privileges, etc., can be efficiently and easily implemented.</td>
</tr>
<tr>
<td>XEP-0325</td>
<td>Defines how to control actuators and other devices in Internet of Things.</td>
</tr>
<tr>
<td>XEP-0326</td>
<td>Defines how to handle architectures containing concentrators or servers handling multiple sensors.</td>
</tr>
<tr>
<td>XEP-0331</td>
<td>Defines extensions for how color parameters can be handled, based on &xep0004;</td>
</tr>
<tr>
<td>XEP-0336</td>
<td>Defines extensions for how dynamic forms can be created, based on &xep0004;, &xep0122;, &xep0137; and &xep0141;.</td>
</tr>
</table>
</section1>
<section1 topic='Glossary' anchor='glossary'>
@ -207,18 +249,19 @@
</di>
<di>
<dt>Node</dt>
<dd>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.).
<dd>
Graphs contain nodes and edges between nodes. In Internet of Things, sensors, actuators, meters, devices, gateways, etc., are often depicted as nodes whereas links between sensors (friendships)
are depicted as edges. In abstract terms, it's easier to talk about a Node, rather than list different possible node types (sensors, actuators, meters, devices, gateways, etc.).
Each Node has a Node ID.</dd>
</di>
<di>
<dt>Node ID</dt>
<dd>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
<dd>An ID uniquely identifying a node within its corresponding context. If a globally unique ID is desired, an architecture should be used using a universally accepted
ID scheme.</dd>
</di>
<di>
<dt>Parameter</dt>
<dd>Readable and/or writable property on a node/device. The XEP xep-0000-SN-Concentrators deals with reading and writing parameters
<dd>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.</dd>
</di>
<di>
@ -251,7 +294,7 @@
<di>
<dt>Token</dt>
<dd>
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.
</dd>
</di>
@ -357,7 +400,7 @@
</p>
<p>
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 (<link url='sensor-network-provisioning.html'>sensor-network-provisioning</link>) 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.
</p>
<p>
A rejection response is shown in the following diagram.
@ -384,10 +427,10 @@
<example caption='Read-out request of momentary values from a device'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='1'>
<req xmlns='urn:xmpp:sn' seqnr='1' momentary='true'/>
id='S0001'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='1' momentary='true'/>
</iq>]]>
</example>
@ -399,9 +442,9 @@
<![CDATA[
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='1'>
<accepted xmlns='urn:xmpp:sn' seqnr='1'/>
to='client@clayster.com/amr'
id='S0001'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='1'/>
</iq>]]>
</example>
@ -412,8 +455,8 @@
<example caption='Momentary read-out response'>
<![CDATA[
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='1' done='true'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='1' done='true'>
<node nodeId='Device01'>
<timestamp value='2013-03-07T16:24:30'>
<numeric name='Temperature' momentary='true' automaticReadout='true' value='23.4' unit='°C'/>
@ -432,22 +475,22 @@
<example caption='Momentary read-out failure'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='2'>
<req xmlns='urn:xmpp:sn' seqnr='2' momentary='true'/>
id='S0002'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='2' momentary='true'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='2'>
<accepted xmlns='urn:xmpp:sn' seqnr='2'/>
to='client@clayster.com/amr'
id='S0002'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='2'/>
</iq>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<failure xmlns='urn:xmpp:sn' seqnr='2' done='true'>
to='client@clayster.com/amr'>
<failure xmlns='urn:xmpp:iot:sensordata' seqnr='2' done='true'>
<error nodeId='Device01' timestamp='2013-03-07T17:13:30'>Timeout.</error>
</failure>
</message>]]>
@ -461,17 +504,17 @@
<example caption='Momentary read-out rejected'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='3'>
<req xmlns='urn:xmpp:sn' seqnr='3' momentary='true'/>
id='S0003'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='3' momentary='true'/>
</iq>
<iq type='error'
from='device@clayster.com'
to='master@clayster.com/amr'
id='3'>
<rejected xmlns='urn:xmpp:sn' seqnr='3'>
to='client@clayster.com/amr'
id='S0003'>
<rejected xmlns='urn:xmpp:iot:sensordata' seqnr='3'>
<error>Access denied.</error>
</rejected>
</iq>]]>
@ -488,27 +531,27 @@
<example caption='Scheduled read-out of device with multiple responses'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='4'>
<req xmlns='urn:xmpp:sn' seqnr='4' all='true' when='2013-03-07T19:00:00'/>
id='S0004'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='4' all='true' when='2013-03-07T19:00:00'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='4'>
<accepted xmlns='urn:xmpp:sn' seqnr='4' queued='true'/>
to='client@clayster.com/amr'
id='S0004'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='4' queued='true'/>
</iq>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<started xmlns='urn:xmpp:sn' seqnr='4'/>
to='client@clayster.com/amr'>
<started xmlns='urn:xmpp:iot:sensordata' seqnr='4'/>
</message>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='4'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='4'>
<node nodeId='Device01'>
<timestamp value='2013-03-07T19:00:00'>
<numeric name='Temperature' momentary='true' automaticReadout='true' value='23.4' unit='°C'/>
@ -520,8 +563,8 @@
</message>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='4'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='4'>
<node nodeId='Device01'>
<timestamp value='2013-03-07T19:00:00'>
<numeric name='Temperature, Max' peak='true' automaticReadout='true' value='25.9' unit='°C'/>
@ -533,8 +576,8 @@
</message>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='4'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='4'>
<node nodeId='Device01'>
<timestamp value='2013-03-07T18:00:00'>
<numeric name='Temperature' historicalHour='true' automaticReadout='true' value='24.5' unit='°C'/>
@ -554,8 +597,8 @@
</message>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<done xmlns='urn:xmpp:sn' seqnr='4'/>
to='client@clayster.com/amr'>
<done xmlns='urn:xmpp:iot:sensordata' seqnr='4'/>
</message>]]>
</example>
</section2>
@ -567,10 +610,10 @@
<example caption='Read-out of multiple devices'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='5'>
<req xmlns='urn:xmpp:sn' seqnr='5' momentary='true'>
id='S0005'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='5' momentary='true'>
<node nodeId='Device02'/>
<node nodeId='Device03'/>
</req>
@ -578,14 +621,14 @@
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='5'>
<accepted xmlns='urn:xmpp:sn' seqnr='5'/>
to='client@clayster.com/amr'
id='S0005'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='5'/>
</iq>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='5'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='5'>
<node nodeId='Device02'>
<timestamp value='2013-03-07T19:31:15'>
<numeric name='Temperature' momentary='true' automaticReadout='true' value='23.4' unit='°C'/>
@ -595,8 +638,8 @@
</message>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='5' done='true'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='5' done='true'>
<node nodeId='Device03'>
<timestamp value='2013-03-07T19:31:16'>
<numeric name='Temperature' momentary='true' automaticReadout='true' value='22.8' unit='°C'/>
@ -623,10 +666,10 @@
<example caption='Read-out of multiple devices'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='6'>
<req xmlns='urn:xmpp:sn' seqnr='6' momentary='true'>
id='S0006'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='6' momentary='true'>
<node nodeId='Device04'/>
<field name='Energy'/>
<field name='Power'/>
@ -635,14 +678,14 @@
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='6'>
<accepted xmlns='urn:xmpp:sn' seqnr='6'/>
to='client@clayster.com/amr'
id='S0006'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='6'/>
</iq>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='6' done='true'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='6' done='true'>
<node nodeId='Device04'>
<timestamp value='2013-03-07T22:03:15'>
<numeric name='Energy' momentary='true' automaticReadout='true' value='12345.67' unit='MWh'/>
@ -660,41 +703,41 @@
<example caption='Scheduled read-out of device with multiple responses'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='8'>
<req xmlns='urn:xmpp:sn' seqnr='8' all='true' when='2013-03-09T23:30:00'/>
id='S0007'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='8' all='true' when='2013-03-09T23:30:00'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='8'>
<accepted xmlns='urn:xmpp:sn' seqnr='8' queued='true'/>
to='client@clayster.com/amr'
id='S0007'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='8' queued='true'/>
</iq>
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='8'>
<cancel xmlns='urn:xmpp:sn' seqnr='8'/>
id='S0008'>
<cancel xmlns='urn:xmpp:iot:sensordata' seqnr='8'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='8'>
<cancelled xmlns='urn:xmpp:sn' seqnr='8'/>
to='client@clayster.com/amr'
id='S0008'>
<cancelled xmlns='urn:xmpp:iot:sensordata' seqnr='8'/>
</iq>]]>
</example>
</section2>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>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.</p>
<p>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.</p>
<example caption="Service discovery information request">
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -704,11 +747,11 @@
<![CDATA[
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
to='client@clayster.com/amr'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:sn'/>
<feature var='urn:xmpp:iot:sensordata'/>
...
</query>
</iq>]]>
@ -723,8 +766,7 @@
affected negatively by this for two reasons:
</p>
<ul>
<li>For sensors with limited memory, or where package size is important, <span class='ref'><link url='http://www.w3.org/TR/exi/'>EXI</link></span>
<note>Efficient XML Interchange (EXI) Format &lt;<link url='http://www.w3.org/TR/exi/'>http://www.w3.org/TR/exi/</link>&gt;.</note> is supposed to be used.
<li>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.</li>
<li>If limited memory or package size is not a consideration, readability and ease of implementation is preferred to short messages.</li>
@ -746,7 +788,7 @@
</p>
<ul>
<li>Since free strings are used, XML validation cannot be used to secure correct names are used.</li>
<li>xep-0000-SN-Interoperability lists recommendations on how field names and units should be used in order to achieve maximum interoperability in SN.</li>
<li>xep-0000-IoT-Interoperability lists recommendations on how field names and units should be used in order to achieve maximum interoperability in SN.</li>
<li>Consumers of sensor data need to include unit conversion algorithms.</li>
</ul>
</section2>
@ -801,7 +843,7 @@
</tr>
</table>
</section2>
<section2 topic='Field Types'>
<section2 topic='Field Types' anchor='fieldtypes'>
<p>
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.
</p>
<p>
More information about how multiple devices behind a JID can be handled, is described in the XEP <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators</link>.
More information about how multiple devices behind a JID can be handled, is described in the XEP-0326
<link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>.
</p>
</section2>
<section2 topic='Reading devices from large subsystems'>
<p>
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 <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>
<note>
<link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>
</note>. In such cases, a node may have to be specified using two or perhaps
even three ID's: a <strong>sourceId</strong> identifying the data source controlling the device, a possible <strong>cacheType</strong> narrowing down the search to
a specific kind of node, and the common <strong>nodeId</strong>. For more information about this, see <link url='xep-0000-SN-Concentrators.html'>xep-0000-SN-Concentrators.html</link>.
very many sensors containing many fields have to be read, as is documented in <link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>.
In such cases, a node may have to be specified using two or perhaps even three ID's: a <strong>sourceId</strong> identifying the data source controlling the device, a possible
<strong>cacheType</strong> narrowing down the search to a specific kind of node, and the common <strong>nodeId</strong>. For more information about this, see
<link url='http://xmpp.org/extensions/xep-0326.html'>Internet of Things - Concentrators</link>.
</p>
<p>
<strong>Note:</strong> For cases where the <strong>nodeId</strong> is sufficient to uniquelly identify the node, it is sufficient to provide this attribute in the request.
<strong>Note:</strong> For cases where the <strong>nodeId</strong> 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 <strong>nodeId</strong> as requested.
</p>
</section2>
@ -1033,7 +1074,7 @@
<p>
This specification allows for localization of field names in meter data read-out. This is performed by assigning each localizable string a <strong>String ID</strong>
which should be unique within a given <strong>Language Module</strong>. A <strong>Language Module</strong> can be any string, including URI's or namespace names.
The XEP <link url='xep-0000-SN-Interoperability.html'>xep-0000-SN-Interoperability</link> details how such localizations can be made in an interoperable way.
The XEP <link url='xep-0000-IoT-Interoperability.html'>xep-0000-IoT-Interoperability</link> details how such localizations can be made in an interoperable way.
</p>
<p>
<strong>Note:</strong> Localization of strings are for human consumption only. Machines should use the unlocalized strings in program logic.
@ -1046,22 +1087,22 @@
<example caption='Localized field names'>
<![CDATA[
<iq type='get'
from='master@clayster.com/amr'
from='client@clayster.com/amr'
to='device@clayster.com'
id='7'>
<req xmlns='urn:xmpp:sn' seqnr='7' all='true'/>
id='S0009'>
<req xmlns='urn:xmpp:iot:sensordata' seqnr='7' all='true'/>
</iq>
<iq type='result'
from='device@clayster.com'
to='master@clayster.com/amr'
id='7'>
<accepted xmlns='urn:xmpp:sn' seqnr='7'/>
to='client@clayster.com/amr'
id='S0009'>
<accepted xmlns='urn:xmpp:iot:sensordata' seqnr='7'/>
</iq>
<message from='device@clayster.com'
to='master@clayster.com/amr'>
<fields xmlns='urn:xmpp:sn' seqnr='7' done='true'>
to='client@clayster.com/amr'>
<fields xmlns='urn:xmpp:iot:sensordata' seqnr='7' done='true'>
<node nodeId='Device05'>
<timestamp value='2013-03-07T22:20:45'>
<numeric name='Temperature' momentary='true' automaticReadout='true'
@ -1111,7 +1152,7 @@
different from the one used by the sensor.
</p>
<p>
<strong>Note:</strong> The XEP <link url='xep-0000-SN-Interoperability.html'>xep-0000-SN-Interoperability</link> details how such localizations can be made in an interoperable way.
<strong>Note:</strong> The XEP <link url='xep-0000-IoT-Interoperability.html'>xep-0000-IoT-Interoperability</link> details how such localizations can be made in an interoperable way.
</p>
<p>
The <strong>stringIds</strong> 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+)*([|][^,]*)?)?)*$
</code>
<p>
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]]]]
</p>
<p>
Where brackets [] mean the contents inside is optional, <strong>ID_i</strong> is an integer representing the string ID in a language module. <strong>Module_i</strong>
@ -1181,7 +1222,7 @@
<li>
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 <link url='xep-0000-SN-Multicast.html'>xep-0000-SN-Multicast</link>.
XEP <link url='xep-0000-IoT-Multicast.html'>xep-0000-IoT-Multicast</link>.
</li>
<li>
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 @@
</li>
<li>
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 <link url='sensor-network-provisioning.html'>sensor-network-provisioning</link>. In short, a device, service or user can get a
access rights to sensor information is detailed in the XEP-0324 <link url='http://xmpp.org/extensions/xep-0324.html'>Internet of Things - Provisioning</link>. In short, a device, service or user can get a
<strong>deviceToken</strong>, <strong>serviceToken</strong> and <strong>userToken</strong> 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.
</li>
@ -1200,8 +1241,9 @@
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>REQUIRED.</p>
<!-- TODO -->
<p>
The <link url="#schema">protocol schema</link> needs to be added to the list of <link url="http://xmpp.org/resources/schemas/">XMPP protocol schemas</link>.
</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code>
@ -1209,8 +1251,8 @@
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:sn'
xmlns='urn:xmpp:sn'
targetNamespace='urn:xmpp:iot:sensordata'
xmlns='urn:xmpp:iot:sensordata'
elementFormDefault='qualified'>
<xs:element name='req'>
@ -1423,6 +1465,30 @@
]]>
</code>
</section1>
<section1 topic='For more information' anchor='moreinfo'>
<p>
For more information, please see the following resources:
</p>
<ul>
<li>
<p>
The <link url='http://wiki.xmpp.org/web/Tech_pages/SensorNetworks'>Sensor Network section of the XMPP Wiki</link> contains further information about the
use of the sensor network XEPs, links to implementations, discussions, etc.
</p>
</li>
<li>
<p>
The XEP's and related projects are also available on <link url='https://github.com/joachimlindborg/'>github</link>, thanks to Joachim Lindborg.
</p>
</li>
<li>
<p>
A presentation giving an overview of all extensions related to Internet of Things can be found here:
<link url='http://prezi.com/esosntqhewhs/iot-xmpp/'>http://prezi.com/esosntqhewhs/iot-xmpp/</link>.
</p>
</li>
</ul>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Joachim Lindborg, Karin Forsell, Tina Beckman, Kevin Smith and Tobias Markmann for all valuable feedback.</p>
</section1>