XEP-xxxx: Sensor Networks - Control

Abstract:This specification describes how to control devices or actuators in an XMPP-based sensor network.
Author:Peter Waher
Copyright:© 1999 - 2013 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:ProtoXEP
Type:Standards Track
Version:0.0.1
Last Updated:2013-03-27

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Table of Contents


1. Introduction
2. Glossary
3. Use Cases
    3.1. Control commands
       3.1.1. Sending a control command using a message stanza
       3.1.2. Sending a control command using an IQ stanza
       3.1.3. Control failure response
    3.2. Setting control parameters
       3.2.1. Setting a single boolean-valued control parameter
       3.2.2. Setting a single 32-bit integer-valued control parameter
       3.2.3. Setting a single 64-bit integer-valued control parameter
       3.2.4. Setting a single string-valued control parameter
       3.2.5. Setting a single double-valued control parameter
       3.2.6. Setting a single date-valued control parameter
       3.2.7. Setting a single time-valued control parameter
       3.2.8. Setting a single date & time-valued control parameter
       3.2.9. Setting a single time-valued control parameter
       3.2.10. Setting a single duration-valued control parameter
       3.2.11. Setting a single color-valued control parameter
       3.2.12. Setting multiple control parameters at once
    3.3. Control forms
       3.3.1. Getting a control form
       3.3.2. Getting a control form, Failure
       3.3.3. Setting a (partial) control form
       3.3.4. Setting a (partial) control form, Failure
    3.4. Controlling devices behind a concentrator
       3.4.1. Sending a control command to a node behind a concentrator
       3.4.2. Sending a control command to multiple nodes
       3.4.3. Sending a control command to multiple nodes, Failure
       3.4.4. Getting a control form from multiple nodes
       3.4.5. Getting a control form from multiple nodes, Failure
       3.4.6. Setting a (partial) control form to multiple nodes
       3.4.7. Setting a (partial) control form to multiple nodes, Failure
4. Implementation Notes
    4.1. Reading current control states
    4.2. Difference between node parameters and node control parameters
    4.3. Grouping control parameters
    4.4. Node commands vs. control parameters
    4.5. Tokens
    4.6. Controlling devices in large subsystems
5. Internationalization Considerations
    5.1. Time Zones
    5.2. xml:lang
6. Security Considerations
    6.1. Encryption & Authentication
    6.2. Provisioning
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema
10. Acknowledgements

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

Actuators are devices in sensor networks that can be controlled through the network and act with the outside world. In sensor networks and Internet of Things applications, actuators make it possible to automate real-world processes. This document defines a mechanism whereby actuators can be controlled in XMPP-based sensor networks, making it possible to integrate sensors and actuators of different brands, makes and models into larger Internet of Things applications.

Note has to be taken, that these XEP's are designed for implementation in sensors, many of which have very limited amount of memory (both RAM and ROM) or resources (processing power). Therefore, simplicity is of utmost importance. Furthermore, sensor networks can become huge, easily with millions of devices in peer-to-peer networks.

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:

Table 1: Sensor Network XEPs

XEP Description
XEP-0000-ColorParameter Defines extensions for how color parameters can be handled, based on Data Forms [1]
XEP-0000-DynamicForms Defines extensions for how dynamic forms can be created, based on Data Forms [2], Data Forms Validation [3], Publishing Stream Initiation Requests [4] and Data Forms Layout [5].
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 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 This specification. Defines how to control actuators and other devices in sensor networks.
xep-0000-SN-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 Defines how sensors send events, how event subscription, hysteresis levels, etc., are configured.
xep-0000-SN-Interoperability Defines guidelines for how to achieve interoperability in sensor networks, publishing interoperability interfaces for different types of devices.
xep-0000-SN-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 Defines 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.

2. Glossary

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

3. Use Cases

Control in sensor networks is about setting output values. To make the implementation simple, it is assumed that control of a device can be made using a single message. If only a simple set operation is requested, a <message> stanza can be sent. If an acknowledgement (ACK) of the operation (or Not-acknowledgement NACK) of the operation is desired, an <iq> stanza can be used instead.

To set control parameters in a device, the set command is sent to the device. The set command allows for two different ways of setting control parameters:

What type of control parameters there are available in different types of devices is described in [6].

If the device is a concentrator, as defined in [7], an handles multiple nodes behind it, which node(s) to control is defined using node elements. If not a concentrator, the use of node elements is not necessary, and control commands are sent directly to the device itself.

3.1 Control commands

3.1.1 Sending a control command using a message stanza

Following is an example of a control command sent using a message stanza:

Example 1. Message stanza for setting a value

                    
   <message from='master@clayster.com/amr'
            to='digital.output@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <boolean name='Output' value='true'/>
      </set>
   </message>
                

Note that any response is supressed when sending a message stanza, regardless if the desired control command could be executed or not. The following example shows how the same control command could be issued using an IQ stanza instead:

3.1.2 Sending a control command using an IQ stanza

Following is an example of a control command sent using an iq stanza:

Example 2. IQ stanza for setting a value

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='digital.output@clayster.com'
       id='1'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
         <boolean name='Output' value='true'/>
      </set>
   </iq>
   
   <iq type='result'
       from='digital.output@clayster.com'
       to='master@clayster.com/amr'
       id='1'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='OK'/>
   </iq>
                

In the following use cases, often a message stanza will be used to illustrate the point. However, the same operation could equally well be used using an iq stanza instead.

3.1.3 Control failure response

By using an IQ stanza, the caller can receive an acknowledgement of the reception of the command, or error information if the command could not be processed. Following is an example of a control command sent using an iq stanza, where the receiver reports an error back to the caller:

Example 3. Control failure response

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='analog.output@clayster.com'
       id='2'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
         <boolean name='Output' value='true'/>
      </set>
   </iq>
   
   <iq type='error'
       from='analog.output@clayster.com'
       to='master@clayster.com/amr'
       id='2'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='OtherError'>
          <error var='Output'>Invalid parameter type.</error>
      </setResponse>
   </iq>
                

3.2 Setting control parameters

The following sub-sections illustrate how to set parameters of different types in a device.

3.2.1 Setting a single boolean-valued control parameter

Setting single boolean-valued control parameters is a common use case, for instance when controlling digital outputs. The following example shows how a boolean value can be set in a device.

Example 4. Setting a single boolean-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='digital.output@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <boolean name='Output' value='true'/>
      </set>
   </message>
                

3.2.2 Setting a single 32-bit integer-valued control parameter

Setting single integer-valued control parameters is a common use case, for instance when controlling analog outputs. The following example shows how a 32-bit integer value can be set in a device.

Example 5. Setting a single 32-bit integer-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='analog.output@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <int name='Output' value='50000'/>
      </set>
   </message>
                

3.2.3 Setting a single 64-bit integer-valued control parameter

Setting single integer-valued control parameters is a common use case, for instance when controlling analog outputs. Even though 32-bit integers may cover most control needs, it might in some cases be limiting. Therefore, a 64-bit control parameters can be created. The following example shows how a 64-bit integer value can be set in a device.

Example 6. Setting a single 64-bit integer-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='megaprecision.analog.output@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <long name='Output' value='500000000000000'/>
      </set>
   </message>
                

3.2.4 Setting a single string-valued control parameter

Setting single string-valued control parameters is a common use case, for instance when controlling text displays. The following example shows how a string value can be set in a device.

Example 7. Setting a single string-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='text.display@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <string name='Row1' value='Temperature: 21.4 °C'/>
      </set>
   </message>
                

3.2.5 Setting a single double-valued control parameter

Setting single double-valued control parameters can be an alternative form of controlling analog outputs for instance. The following example shows how a double value can be set in a device.

Example 8. Setting a single double-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='analog.output2@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <double name='4-20mA' value='8.192'/>
      </set>
   </message>
                

3.2.6 Setting a single date-valued control parameter

Setting date-valued control parameters might be necessary when timing is an issue. Often it forms part of a larger context. The following example shows how a date value can be set in a device.

Example 9. Setting a single date-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='alarm@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <date name='TariffStartDate' value='2013-05-01'/>
      </set>
   </message>
                

3.2.7 Setting a single time-valued control parameter

Setting time-valued control parameters might be necessary when timing is an issue. Often it forms part of a larger context. The following example shows how a time value can be set in a device.

Example 10. Setting a single time-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='alarm@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <time name='Alarm Time' value='08:00:00'/>
      </set>
   </message>
                

3.2.8 Setting a single date & time-valued control parameter

Setting date & time-valued control parameters might be necessary when timing is an issue. Often it forms part of a larger context. The following example shows how a date & time value can be set in a device.

Example 11. Setting a single date & time-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='alarm@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <dateTime name='Alarm Time' value='2013-04-02T08:00:00'/>
      </set>
   </message>
                

3.2.9 Setting a single time-valued control parameter

Setting time-valued control parameters might be necessary when timing is an issue. Often it forms part of a larger context. The following example shows how a time value can be set in a device.

Example 12. Setting a single time-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='alarm@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <time name='Alarm Time' value='08:00:00'/>
      </set>
   </message>
                

3.2.10 Setting a single duration-valued control parameter

Setting duration-valued control parameters might be necessary when timing is an issue. Often it forms part of a larger context. The following example shows how a duration value can be set in a device.

Example 13. Setting a single duration-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='alarm@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <duration name='Alarm Duration' value='PT3M30S'/>
      </set>
   </message>
                

3.2.11 Setting a single color-valued control parameter

Setting single color values in a device can occur in instances where color or lighting is important. Sometimes color is set using enumerations (string-valued or integer-valued parameters), and sometimes as a color property. The following example shows how a color value can be set in a device.

Example 14. Setting a single color-valued control parameter

                    
   <message from='master@clayster.com/amr'
            to='spotlight@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <color name='Color' value='3399FF'/>
      </set>
   </message>
                

3.2.12 Setting multiple control parameters at once

Often, setting a single control parameter is not sufficient for a control action. In these cases, setting multiple control parameters at once is necessary. The set command makes this easy however, since it allows for any number of control parameters to be set at once, as the following example shows:

Example 15. Setting multiple control parameters at once

                    
   <message from='master@clayster.com/amr'
            to='dimmer@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <int name='FadeTimeMilliseconds' value='500'/>
         <int name='OutputPercent' value='10'/>
      </set>
   </message>
                

Sometimes the order of control parameters are important in the device, and sometimes the parameters form part of a whole. It depends on the context of the device. In the above example, the order is important. When the OutputPercent control parameter is set, it will start to fade in or out to the desired setting (10%), using the fade time set previously. If the FadeTimeMilliseconds control parameter would have been set after the OutputPercent parameter, the fading would have been started using the previous setting, which might be unknown.

The order of control parameters to use depends on the device. The Control Form lists available control parameters of the device in the order they are expected to be sent to the device. The XEP xep-0000-SN-Interoperability details what control parameters must be available for different interfaces, and if the order of control parameters is important.

3.3 Control forms

3.3.1 Getting a control form

A client can get a control form containing available control parameters of the device. This is done using the getForm command, as is shown in the following example:

Example 16. Getting a control form

                    
   <iq type='get'
       from='master@clayster.com/amr'
       to='dimmer@clayster.com'
       id='3'>
      <getForm xmlns='urn:xmpp:sn:control' xml:lang='en'/>
   </iq>
   
   <iq type='result'
       from='dimmer@clayster.com'
       to='master@clayster.com/amr'
       id='3'>
      <getFormResponse xmlns='urn:xmpp:sn: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'>
              <title>Dimmer</title>
              <xdl:page label='Output'>
                  <xdl:fieldref var='FaceTimeMilliseconds'/>
                  <xdl:fieldref var='OutputPercent'/>
                  <xdl:fieldref var='MainSwitch'/>
              </xdl:page>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='FadeTimeMilliseconds' type='text-single' label='Fade Time (ms):'>
                  <desc>Time in milliseconds used to fade the light to the desired level.</desc>
                  <value>300</value>
                  <xdv:validate datatype='xs:int'>
                      <xdv:range min='0' max='4095'/>
                  </xdv:validate>
                  <xdd:notSame/>
              </field>
              <field var='OutputPercent' type='text-single' label='Output (%):'>
                  <desc>Dimmer output, in percent.</desc>
                  <value>100</value>
                  <xdv:validate datatype='xs:int'>
                      <xdv:range min='0' max='100'/>
                  </xdv:validate>
                  <xdd:notSame/>
              </field>
              <field var='MainSwitch' type='boolean' label='Main switch'>
                  <desc>If the dimmer is turned on or off.</desc>
                  <value>true</value>
                  <xdd:notSame/>
              </field>
          </x>
      </getFormResponse>
   </iq>
                

IMPORTANT: The device MUST mark all control parameters in the form as notSame, as defined in [8]. If an end user would open the control form and press OK (submitting the form) without having entered a value, no value would be written, and no action taken. If only a few parameter would be edited, only those parameters would be sent to the device and only the corresponding actions taken.

All parameters in the form MUST also have validation rules defined according to XEP-0122, specifically validation data types and ranges where appropriate. This to give type information to the client, which the client later can use to send typed control commands directly, without the need to get and send data forms to the device to control it.

Also, the device SHOULD group control parameters that should be written together using pages and sections, as described in XEP-0141. Parameters MUST also be ordered in a way so that when set in that order using the typed commands, the corresponding control actions can be successfully executed.

Note: There's a difference between node parameters, as described in XEP xep-0000-SN-Concentrators, and control parameters as described in this document. For more information about this, please see Difference between node parameters and node control parameters.

3.3.2 Getting a control form, Failure

A device can reject a control form request. It does this returning an error iq stanza, and detailing the error in the result attribute of the getformResponse element, as is shown in the following example:

Example 17. Getting a control form, Failure

                    
   <iq type='get'
       from='master@clayster.com/amr'
       to='dimmer@clayster.com'
       id='4'>
      <getForm xmlns='urn:xmpp:sn:control' xml:lang='en'/>
   </iq>
   
   <iq type='error'
       from='dimmer@clayster.com'
       to='master@clayster.com/amr'
       id='4'>
      <getFormResponse xmlns='urn:xmpp:sn:concentrators' result='InsufficientPrivileges'/>
   </iq>
                

3.3.3 Setting a (partial) control form

Control actions can be requested by submitting a full or partial control form back to the device. Control parameters not edited MUST not be included in the form, and the device in turn MUST ONLY invoke control actions corresponding to the parameters returned in the form.

The following example shows how control actions can be requested submitting a control parameters form to the device:

Example 18. Setting a (partial) control form

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='dimmer@clayster.com'
       id='5'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
          <x type='submit' xmlns='jabber:x:data'>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='FadeTimeMilliseconds' type='text-single'>
                  <value>500</value>
              </field>
              <field var='OutputPercent' type='text-single'>
                  <value>10</value>
              </field>
          </x>
      </set>
   </iq>
   
   <iq type='result'
       from='dimmer@clayster.com'
       to='master@clayster.com/amr'
       id='5'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='OK'/>
   </iq>
                

In this example, the FadeTimeMilliseconds and OutputPercent control parameters are sent, while the MainSwitch control parameter is left as is. Fading is therefore parformed only if the dimmer is switched on.

3.3.4 Setting a (partial) control form, Failure

A device can reject a control form submission. It does this returning an error iq stanza, and detailing the error in the result attribute of the setResponse element. If there are errors in the form, details are listed using error elements in the response, as is shown in the following example:

Example 19. Setting a (partial) control form, Failure

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='dimmer@clayster.com'
       id='6'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
          <x type='submit' xmlns='jabber:x:data'>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='FadeTimeMilliseconds' type='text-single'>
                  <value>500</value>
              </field>
              <field var='OutputPercent' type='text-single'>
                  <value>200</value>
              </field>
          </x>
      </set>
   </iq>
   
   <iq type='error'
       from='dimmer@clayster.com'
       to='master@clayster.com/amr'
       id='6'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='FormError'>
          <error var='OutputPercent'>Invalid parameter value.</error>
      </setResponse>
   </iq>
                

3.4 Controlling devices behind a concentrator

Controlling devices behind a concentrator can be done by specifying what device(s) to control using node elements within the command elements sent to the concentrator. The following sub-sections show examples of how this is done.

3.4.1 Sending a control command to a node behind a concentrator

To send a control message to a specific node behind a concentrator, the node element can be used to identify the node, as is shown in the following example:

Example 20. Sending a control command to a node behind a concentrator

                    
   <message from='master@clayster.com/amr'
            to='concentrator@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <node nodeId='DigitalOutput1'/>
         <boolean name='Output' value='false'/>
      </set>
   </message>
                

3.4.2 Sending a control command to multiple nodes

The client can send the same control command to multiple nodes behind a concentrator by simply adding more node elements in the request, as is shown in the following example:

Example 21. Sending a control command to multiple nodes

                    
   <message from='master@clayster.com/amr'
            to='concentrator@clayster.com'>
      <set xmlns='urn:xmpp:sn:control'>
         <node nodeId='DigitalOutput1'/>
         <node nodeId='DigitalOutput2'/>
         <node nodeId='DigitalOutput3'/>
         <node nodeId='DigitalOutput4'/>
         <boolean name='Output' value='false'/>
      </set>
   </message>
                

3.4.3 Sending a control command to multiple nodes, Failure

By using an IQ stanza, the caller can receive an acknowledgement of the reception of the command, or error information if the command could not be processed. When sending a control command to multiple nodes at a time the device must validate all parameters against all nodes before taking any control action. If validation fails, an error message is returned and no control action is taken. The following example shows an example of an erroneous control message made to multiple nodes on a device:

Example 22. Sending a control command to multiple nodes, Failure

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='concentrator@clayster.com'
       id='7'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
         <node nodeId='DigitalOutput1'/>
         <node nodeId='DigitalOutput2'/>
         <node nodeId='DigitalOutput3'/>
         <node nodeId='DigitalOutput4'/>
         <node nodeId='AnalogOutput1'/>
         <node nodeId='AnalogOutput2'/>
         <node nodeId='AnalogOutput3'/>
         <node nodeId='AnalogOutput4'/>
         <boolean name='Output' value='true'/>
      </set>
   </iq>
   
   <iq type='error'
       from='concentrator@clayster.com'
       to='master@clayster.com/amr'
       id='7'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='OtherError'>
          <error var='Output'>Invalid parameter type.</error>
      </setResponse>
   </iq>
                

3.4.4 Getting a control form from multiple nodes

A client can get a control form containing available control parameters common between a set of nodes controlled by the concentrator. This is done adding a sequence of node elements to a getForm command sent to the concentrator, as is shown in the following example:

Example 23. Getting a control form

                    
   <iq type='get'
       from='master@clayster.com/amr'
       to='concentrator@clayster.com'
       id='8'>
      <getForm xmlns='urn:xmpp:sn:control' xml:lang='en'>
          <node nodeId='DigitalOutput1'/>
          <node nodeId='DigitalOutput2'/>
          <node nodeId='DigitalOutput3'/>
          <node nodeId='DigitalOutput4'/>
      </getForm>
   </iq>
   
   <iq type='result'
       from='concentrator@clayster.com'
       to='master@clayster.com/amr'
       id='8'>
      <getFormResponse xmlns='urn:xmpp:sn: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'>
              <title>DigitalOutput1, DigitalOutput2, ...</title>
              <xdl:page label='Output'>
                  <xdl:fieldref var='Output'/>
              </xdl:page>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='Output' type='boolean' label='Output'>
                  <desc>If the digital output is high (checked) or low (uncheckd).</desc>
                  <value>true</value>
                  <xdd:notSame/>
              </field>
          </x>
      </getFormResponse>
   </iq>
                

Note that only parameters that are common between the nodes defined in the request must be returned. However, all parameters must have the >notSame flag set, regardless of current output status.

3.4.5 Getting a control form from multiple nodes, Failure

A device can reject a control form request. It does this returning an error iq stanza, and detailing the error in the result attribute of the getformResponse element. The following example shows the device rejecting a control form request, because it does not support the handling of common parameters between multiple nodes:

Example 24. Getting a control form from multiple nodes, Failure

                    
   <iq type='get'
       from='master@clayster.com/amr'
       to='concentrator@clayster.com'
       id='9'>
      <getForm xmlns='urn:xmpp:sn:control' xml:lang='en'>
          <node nodeId='DigitalOutput1'/>
          <node nodeId='DigitalOutput2'/>
          <node nodeId='DigitalOutput3'/>
          <node nodeId='DigitalOutput4'/>
      </getForm>
   </iq>
   
   <iq type='error'
       from='concentrator@clayster.com'
       to='master@clayster.com/amr'
       id='9'>
      <getFormResponse xmlns='urn:xmpp:sn:concentrators' result='NotImplemented'/>
   </iq>
                

3.4.6 Setting a (partial) control form to multiple nodes

You set a control form to multiple nodes controlled by a concentrator by adding node elements to the set command sent to the concentrator, as is shown in the following example:

Example 25. Setting a (partial) control form to multiple nodes

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='concentrator@clayster.com'
       id='10'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
          <node nodeId='DigitalOutput1'/>
          <node nodeId='DigitalOutput2'/>
          <node nodeId='DigitalOutput3'/>
          <node nodeId='DigitalOutput4'/>
          <x type='submit' xmlns='jabber:x:data'>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='Output' type='boolean'>
                  <value>true</value>
              </field>
          </x>
      </set>
   </iq>
   
   <iq type='result'
       from='concentrator@clayster.com'
       to='master@clayster.com/amr'
       id='10'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='OK'/>
   </iq>
                

3.4.7 Setting a (partial) control form to multiple nodes, Failure

A device can reject a control form submission. It does this returning an error iq stanza, and detailing the error in the result attribute of the setResponse element. The following example shows the device rejecting a control form submission because one of the control parameters, even though it exists on all nodes, is not of the same type on all nodes.

Example 26. Setting a (partial) control form to multiple nodes

                    
   <iq type='set'
       from='master@clayster.com/amr'
       to='concentrator@clayster.com'
       id='11'>
      <set xmlns='urn:xmpp:sn:control' xml:lang='en'>
          <node nodeId='DigitalOutput1'/>
          <node nodeId='DigitalOutput2'/>
          <node nodeId='DigitalOutput3'/>
          <node nodeId='DigitalOutput4'/>
          <node nodeId='AnalogOutput1'/>
          <node nodeId='AnalogOutput2'/>
          <node nodeId='AnalogOutput3'/>
          <node nodeId='AnalogOutput4'/>
          <x type='submit' xmlns='jabber:x:data'>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='Output' type='boolean'>
                  <value>true</value>
              </field>
          </x>
      </set>
   </iq>
   
   <iq type='result'
       from='concentrator@clayster.com'
       to='master@clayster.com/amr'
       id='11'>
      <setResponse xmlns='urn:xmpp:sn:control' responseCode='FormError'>
          <error var='Output'>Invalid type</error>
      </setResponse>
   </iq>
                

4. Implementation Notes

4.1 Reading current control states

If a client wants to know the current status of control parameters, it must perform a readout of Momentary and Status values from the device, according to [9], and from the returned set of values take the current control parameter value according to the following rules, ordered by priority:

Even though getting the the control form could provide the client with a quicker and easier way of retrieving control parameter values, the form is not guaranteed to contain correct current values. In some cases, retrieving current values might take time and only be retrieved using an asynchronous read-out process described in this section.

The following table shows how corresponding field values should be converted to the corresponding control parameter value based on field type (x-axis) and control parameter type (y-axis). N/A means conversion has no meaning and types are not compatible.

Table 2: Conversion of Field Value to Control Parameter Value based on types

numeric string boolean dateTime timeSpan enum
boolean !=0 N/A x N/A N/A N/A
color N/A RRGGBB N/A N/A N/A N/A
date N/A (1) N/A Date part N/A N/A
dateTime N/A (2) N/A x N/A N/A
double x (3) Z2 N/A N/A N/A
duration N/A (4) N/A N/A x N/A
int x (5) Z2 N/A N/A N/A
long x (5) Z2 N/A N/A N/A
string (6) x xs:boolean xs:dateTime xs:duration x
time N/A (7) N/A Time part (8) N/A

The following table lists notes with details on how to do conversion, if in doubt.

Table 3: Conversion rules

Note Description
(1) The client should try to convert the string to a date value, first according to the format specified by the XML data type xs:date, and if not possible by RFC 822.
(2) The client should try to convert the string to a date & time value, first according to the format specified by the XML data type xs:dateTime, and if not possible by RFC 822.
(3) The client should try to convert the string to a double-precision floating-point value, first according to the format specified by the XML data type xs:double, and if not possible using system-local string to floating-point conversion using local decimal and throusand separator settings.
(4) The client should try to convert the string to a duration value, first according to the format specified by the XML data type xs:duration, and if not possible using the XML data type xs:time.
(5) The client should try to convert the string to an integer value according to the corresponding XML data type formats xs:int and xs:long.
(6) The numeric field value consists of three parts: Numeric value, number of decimals and optional unit. If no unit is provided, only the numeric value should be converted to a string (compatible with the XML data type xs:double), using exactly the number of decimals provided in the field. If a unit is provided (non-empty string) it must not be appended to the value, if the value is to be used for control output. For presentation purposes however, a space could be appended to the number and the unit appended after the space.
(7) The client should try to convert the string to a time value according to the format specified by the XML data type xs:time.
(8) A timeSpan field value contains a xs:duration value. The xs:duration has a larger domain than xs:time, and contains all xs:time values, but xs:time does not contain all possible xs:duration values. So, conversion of an xs:duration value to an xs:time value should be performed only if a duration lies between 00:00:00 and 23:59:59.
x Use the canonical conversion method.
Z2 true = 1, false = 0.
N/A Not applicable. Conversion has no meaning. Value types are not compatible.
!=0 Nonzero = true, Zero = false.
RRGGBB A string of six hexadecimal characters, the first two the red component of the color, the next two the green component and the last two the blue component.
Date part Only the date part of the xs:dateTime value should be used.
Time part Only the time part of the xs:dateTime value should be used.
xs:boolean Conversion to a string should follow the rules specified for the XML datatype xs:boolean.
xs:dateTime Conversion to a string should follow the rules specified for the XML datatype xs:dateTime.
xs:duration Conversion to a string should follow the rules specified for the XML datatype xs:duration.

Note: the namespace prefix xs is here supposed to be linked with the XML Schema namespace http://www.w3.org/2001/XMLSchema.

4.2 Difference between node parameters and node control parameters

A node defined in a concentrator, as defined by xep-0000-SN-Concentrators.html, supporting control has two sets of parameters that are different: First a set of node parameters and then a set of control parameters.

Node parameters are defined by the node type in the concentrator, as described in xep-0000-SN-Concentrators.html, and they are typically used by the concentrator to define the node and how to communicate or interact with the underlying device. The important part here is to know that the node parameters are maintained by the concentrator, not the underlying device.

Control parameters however, are parameters that reside on the underlying device. When set, they change the actual state or behaviour of the underlying device. The connection to the device however, controlled by the concentrator, remains unchanged by such a control parameter update.

4.3 Grouping control parameters

Many control actions avilable in a device can be controlled using only one control parameter. If a device only publishes such control parameters, the order of control paramters is not that important.

However, there are many control actions that require the client to set multiple control parameters at the same time, for the device to have a complete understanding what the client wants to do.

XEP-0141 defines a way to group parameters in a data form by including the concept of pages and sections. Even though these pages and sections are used for layout purposes, it should be used by devices to mark parameters that should be used together to perform control actions.

The following set of rules should be adhered to, by devices as well as clients, to minimize confusion and resulting errors:

Note however, that one cannot always make the assumption that parameters on the same page or same section in a control form belong to the same control action. For instance, a PLC with 16 digital outputs might publish a control form containing a single page with 16 check boxes on (boolean parameters), that can be controlled individually.

To solve the problem of grouping parameters together, so a client can know which parameters belong together, a new element is defined that can be used in data forms: parameterGroup. It is optional, but can be added to control parameters in forms, as a way to tell the client that parameters having the same parameterGroup belong together and should be written together. The following example illustrates this.

Example 27. Grouping control parameters

                
   <iq type='get'
       from='master@clayster.com/amr'
       to='spotlight@clayster.com'
       id='12'>
      <getForm xmlns='urn:xmpp:sn:control' xml:lang='en'/>
   </iq>
   
   <iq type='result'
       from='spotlight@clayster.com'
       to='master@clayster.com/amr'
       id='12'>
      <getFormResponse xmlns='urn:xmpp:sn: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'>
              <title>Spotlight</title>
              <xdl:page label='Output'>
                  <xdl:fieldref var='MainSwitch'/>
              </xdl:page>
              <xdl:page label='Direction'>
                  <xdl:fieldref var='HorizontalAngle'/>
                  <xdl:fieldref var='ElevationAngle'/>
              </xdl:page>
              <field var='xdd session' type='hidden'>
                  <value>325ED0F3-9A9A-45A4-9634-4E0D41C5EA06</value>
              </field>
              <field var='MainSwitch' type='boolean' label='Main switch'>
                  <desc>If the spotlight is turned on or off.</desc>
                  <value>true</value>
                  <xdd:notSame/>
              </field>
              <field var='HorizontalAngle' type='text-single' label='Horizontal angle:'>
                  <desc>Horizontal angle of the spotlight.</desc>
                  <value>0</value>
                  <xdv:validate datatype='xs:double'>
                      <xdv:range min='-180' max='180'/>
                  </xdv:validate>
                  <xdd:notSame/>
                  <parameterGroup xmlns='urn:xmpp:sn:concentrators' name='direction'/>
              </field>
              <field var='ElevationAngle' type='text-single' label='Elevation angle:'>
                  <desc>Elevation angle of the spotlight.</desc>
                  <value>0</value>
                  <xdv:validate datatype='xs:double'>
                      <xdv:range min='-90' max='90'/>
                  </xdv:validate>
                  <xdd:notSame/>
                  <parameterGroup xmlns='urn:xmpp:sn:concentrators' name='direction'/>
              </field>
          </x>
      </getFormResponse>
   </iq>
            

The above example informs the client that the two parameters HorizontalAngle and ElevationAngle should be written together to control a control action (named direction).

For more information about common control actions and their parameters, see xep-0000-SN-Interoperability.html, which defines a set of interoperable interfaces and their abilities.

4.4 Node commands vs. control parameters

Nodes behind a concentrator, as defined in xep-0000-SN-Concentrators.html, have an additional means of publishing control interfaces: Node Commands.

However, there are many differences between Node Commands and Control Parameters, as shown in the following list:

If implementing a device with many complex control actions (like an advanced PLC), consideration should be made to divide the device into logical groups and implement the concentrators interface as well. Then the more complex control actions could be implemented as Node Commands instead of control actions as defined in this document, and implementing the simpler more intuitive control actions as described in this document.

4.5 Tokens

If control interaction is performed in a context of delegated trust, as defined in the Sensor Network Provisioning XEP [10], tokens should always be included in all calls. This to allow devices to check privileges with provisioning servers.

The set and getForm commands support the following token attributes:

For more information about provisioning, see sensor-network-provisioning.html.

4.6 Controlling devices in large subsystems

Most examples in this document have been simplified examples where a few devices containing a few control parameters have been used. However, in many cases large subsystems with very many actuators containing many different control actions have to be controlled, as is documented in 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.

Note: For cases where the nodeId is sufficient to uniquelly 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.

5. Internationalization Considerations

5.1 Time Zones

All timestamps and dateTime values use the XML data type xs:dateTime to specify values. These values include a date, an optional time and an optional time zone.

Note: If time zone is not available, it is supposed to be undefined. The client reading the sensor that reports fields without time zone information should assume the sensor has the same time zone as the client, if not explicitly configured otherwise on the client side.

If devices report time zone, this information should be propagated throughout the system. Otherwise, comparing timestamps from different time zones will be impossible.

5.2 xml:lang

Control commands sent using IQ stanzas instead of messages, should consider using the xml:lang attribute to specify the desired language used (if possible) when returning information back to the caller, like error messages, localized control forms, etc.

6. Security Considerations

Controlling devices in a large sensor network is a hackers wet dream. Therefore, consideration of how network security is implemented should not be underestimated. The following sections provide some general items that should be considered.

6.1 Encryption & Authentication

Consider to always use an encrypted connection with any XMPP Server used in the network. Also, make sure the server is properly authenticated and any server certificate properly validated.

Control commands should only be accepted by trusted parties. A minimum is to make sure only authenticated and validated clients (friends) can perform control actions on the device.

6.2 Provisioning

Consider using provisioning servers to allow for detailed control of who can do what in a sensor network. Implementing proper provisioning support decreases the risk for adverse effects, not only from intentional hacking, but also from unintentional errors.

If using delegated trust, make sure the provisioning servers are properly authenticated and validated before trusting them.

More information about provisioning can be found in sensor-network-provisioning.html.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [11].

8. XMPP Registrar Considerations

REQUIRED.

9. XML Schema

            
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:sn:control'
    xmlns='urn:xmpp:sn:control'
    xmlns:sn='urn:xmpp:sn'
    xmlns:xd="jabber:x:data"
    xmlns:xdv="http://jabber.org/protocol/xdata-validate"
    xmlns:xdl="http://jabber.org/protocol/xdata-layout"
    elementFormDefault='qualified'>
 
    <xs:import namespace='urn:xmpp:sn'/>
    <xs:import namespace='jabber:x:data'/>
    <xs:import namespace='http://jabber.org/protocol/xdata-validate'/>
    <xs:import namespace='http://jabber.org/protocol/xdata-layout'/>
 
    <xs:element name='set'>
        <xs:complexType>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
                <xs:element name='node' type='NodeReference'/>
                <xs:element name='boolean' type='BooleanParameter'/>
                <xs:element name='color' type='ColorParameter'/>
                <xs:element name='date' type='DateParameter'/>
                <xs:element name='dateTime' type='DateTimeParameter'/>
                <xs:element name='double' type='DoubleParameter'/>
                <xs:element name='duration' type='DurationParameter'/>
                <xs:element name='int' type='IntParameter'/>
                <xs:element name='long' type='LongParameter'/>
                <xs:element name='string' type='StringParameter'/>
                <xs:element name='time' type='TimeParameter'/>
                <xs:element name='form'>
                    <xs:complexType>
                        <xs:sequence>
                            <xs:any minOccurs="1" maxOccurs="1" namespace="jabber:x:data"/>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
            </xs:choice>
            <xs:attributeGroup ref='tokens'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='setResponse'>
        <xs:complexType>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
                <xs:element name='node' type='NodeReference'/>
                <xs:element name='parameter'>
                    <xs:complexType>
                        <xs:attribute name='name' type='xs:string' use='required'/>
                    </xs:complexType>
                </xs:element>
                <xs:element name='error' type='ParameterError'/>
            </xs:choice>
            <xs:attributeGroup ref='responseCode'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='getForm'>
        <xs:complexType>
            <xs:sequence minOccurs='0' maxOccurs='unbounded'>
                <xs:element name='node' type='NodeReference'/>
            </xs:sequence>
            <xs:attributeGroup ref='tokens'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='getFormResponse'>
        <xs:complexType>
            <xs:sequence>
                <xs:any minOccurs="0" maxOccurs="1" namespace="jabber:x:data"/>
            </xs:sequence>
            <xs:attributeGroup ref='responseCode'/>
        </xs:complexType>
    </xs:element>
 
    <xs:element name='parameterGroup'>
        <xs:complexType>
            <xs:attribute name='name' type='xs:string' use='required'/>
        </xs:complexType>
    </xs:element>
 
    <xs:attributeGroup name='nodeReference'>
        <xs:attribute name='nodeId' type='xs:string' use='required'/>
        <xs:attribute name='sourceId' type='xs:string' use='optional'/>
        <xs:attribute name='cacheType' type='xs:string' use='optional'/>
    </xs:attributeGroup>
 
    <xs:attributeGroup name='tokens'>
        <xs:attribute name='serviceToken' type='xs:string' use='optional'/>
        <xs:attribute name='deviceToken' type='xs:string' use='optional'/>
        <xs:attribute name='userToken' type='xs:string' use='optional'/>
    </xs:attributeGroup>
 
    <xs:attributeGroup name='responseCode'>
        <xs:attribute name='result' type='ResponseCode' use='required'/>
    </xs:attributeGroup>
 
    <xs:complexType name='Parameter' abstract='true'>
        <xs:attribute name='name' type='xs:string' use='required'/>
    </xs:complexType>
 
    <xs:complexType name='BooleanParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:boolean' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='ColorParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='Color' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='DateParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:date' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='DateTimeParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:dateTime' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='DoubleParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:double' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='DurationParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:duration' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='IntParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:int' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='LongParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:long' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='StringParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:string' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='TimeParameter'>
        <xs:complexContent>
            <xs:extension base='Parameter'>
                <xs:attribute name='value' type='xs:time' use='required'/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
 
    <xs:complexType name='ParameterError'>
        <xs:simpleContent>
            <xs:extension base='xs:string'>
                <xs:attribute name='var' type='xs:string' use='required'/>
            </xs:extension>
        </xs:simpleContent>
    </xs:complexType>
 
    <xs:complexType name='NodeReference'>
        <xs:attributeGroup ref='nodeReference'/>
    </xs:complexType>
 
    <xs:simpleType name='Color'>
        <xs:restriction base='xs:string'>
            <xs:pattern value='^[0-9a-fA-F]{6}$'/>
        </xs:restriction>
    </xs:simpleType>
 
    <xs:simpleType name='ResponseCode'>
        <xs:restriction base='xs:string'>
            <xs:enumeration value='OK'/>
            <xs:enumeration value='NotFound'/>
            <xs:enumeration value='InsufficientPrivileges'/>
            <xs:enumeration value='Locked'/>
            <xs:enumeration value='NotImplemented'/>
            <xs:enumeration value='FormError'/>
            <xs:enumeration value='OtherError'/>
        </xs:restriction>
    </xs:simpleType>
 
</xs:schema>
        

10. Acknowledgements

Thanks to Joachim Lindborg for all valuable feedback.


Appendices


Appendix A: Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2013-03-27
Approving Body: XMPP Council
Dependencies: XEP-0001, XEP-0004, XEP-0030, XEP-0122, XEP-0137, XEP-0141, sensor-data, sensor-network-provisioning, xep-0000-DynamicForms, xep-0000-ColorParameter
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
This document in other formats: XML  PDF


Appendix B: Author Information

Peter Waher

Email: peter.waher@clayster.com
JabberID: peter.waher@jabber.org
URI: http://se.linkedin.com/pub/peter-waher/1a/71b/a29/


Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.


Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.


Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Appendix G: Notes

1. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

2. XEP-0004: Data Forms <http://xmpp.org/extensions/xep-0004.html>.

3. XEP-0122: Data Forms Validation <http://xmpp.org/extensions/xep-0122.html>.

4. XEP-0137: Publishing Stream Initiation Requests <http://xmpp.org/extensions/xep-0137.html>.

5. XEP-0141: Data Forms Layout <http://xmpp.org/extensions/xep-0141.html>.

6. XEP-xxxx: Sensor Networks - Interoperability <xep-0000-SN-Interoperability.html>

7. XEP-xxxx: Sensor Networks - Concentrators <xep-0000-SN-Concentrators.html>

8. XEP-xxxx: Dynamic Data Forms <xep-0000-DynamicForms.html>

9. XEP-xxxx: Sensor Data <sensor-data.html>

10. XEP-xxxx: Sensor Networks - Provisioning <sensor-network-provisioning.html>

11. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.


Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.0.1 (2013-03-27)

First draft.

(pwa)

END