XMPP P. Wang Internet Draft H. Wang Interned status: Standards Track F. Lan Expires: April 2, 2013 Chongqing University of Posts and Telecommunicatis C. Zhou Cisco Systems October 2, 2012 XMPP Extension Protocol for the Internet of Things draft-wang-xmpp-extension-00.txt Abstract This document defines the xmpp extension protocol for wireless sensor networks. Such as industrial automation process control and smart home applications, etc. This protocol provided the methods of interaction among applications. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 2, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Wang, et al. Expires April 2, 2013 [Page 1] Internet-Draft draft-wang-xmpp-extension-00 October 2012 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction.................................................3 1.1. Overview................................................3 1.2. Terminology.............................................3 2. Requirements.................................................3 3. Object-oriented model........................................4 3.1. Overview................................................4 3.2. Object concept..........................................4 3.3. Object definition.......................................5 3.3.1. Device management object...........................5 3.3.2. Alarm object.......................................7 3.3.3. User object........................................8 3.4. Methods................................................13 3.4.1. Public methods....................................13 3.4.2. Private methods...................................14 3.4.3. Client/Server communication mode..................14 3.4.4. Publish/Subscribe communication mode..............15 3.4.5. Source/Sink communication mode....................16 4. Protocol....................................................16 4.1. Syntax.................................................16 4.2. Element................................................17 4.3. Communicated processing examples.......................19 5. Security Considerations.....................................26 6. IANA Considerations.........................................26 7. References..................................................26 7.1. Normative References...................................26 7.2. Informative References.................................27 Appendix A. XML Schema.........................................27 Authors' Addresses.............................................30 Wang, et al. Expires April 2, 2013 [Page 2] Internet-Draft draft-wang-xmpp-extension-00 October 2012 1. Introduction 1.1. Overview Wireless sensor network contains many kinds of applications, such as intelligent transportation, industrial monitoring, green agriculture, environmental monitoring or public safety. There are also many protocols for the application of wireless sensor network, in which there exists many problems, such as for compatibility or interoperability. This document provides a generic protocol framework which could be extended for the applications. Because of the diversity of wireless sensor network, this document defined software objects to model real-world objects with concept of object-oriented, and defined the communication between object to object. 1.2. Terminology Many important terms used in this document are defined in [FRAMEWORK], [I18N-TERMS], [IDNA-DEFS], [UNICODE], and [XMPP]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Requirements This document shall reach the following requirements. Transporting monitor data in real-time, which is the typical task of WSN, protocol should submit the real-time data of data submit entity (sensor node in general) to data handle entity (server, client which is controlled by human or intelligent execute device). Alarm, WSN should have ability to report the emergencies or abnormal events to monitor device. Portability, protocol should define general data format or basic data type. Lightweight, WSN node is resource limited node, RAM and ROM of node are generally relatively small, and the process resource is limited, so the protocol must have the lightweight characteristics. Flexibility, protocol should have the function of flexible and scalable. Wang, et al. Expires April 2, 2013 [Page 3] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Compatibility, protocol should only define the extension of the existing XMPP protocol, and it should be also compatible with existing implementation. 3. Object-oriented model 3.1. Overview An object model is a protocol, platform, and language-neutral means of describing and distinguishing components (system elements) that have a unique identity. Objects separate the world into meaningful and manageable pieces. Not only do object definitions promote modularity, but also promote component reusability. An object can represent anything that has state and behavior. Object expose attributes to represent state, and provide methods that operate on the objects state to affect particular behaviors. 3.2. Object concept An object encapsulates attributes and methods. Attribute presents the characteristic of object, and method is an interface function or functions module to access object. The definition of object can be defined by different functions, functions module technology or other methods. From the user point of view, communication occurs from one object in an application to another object in an application. Each of application may contain multiple objects. It enables this protocol can meet the need of specific market, such as for industries process or factory automation. Figure 1 depicts the applications structure of object-oriented. Wang, et al. Expires April 2, 2013 [Page 4] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +----------------------------------------------+ | +-------------------------------+| | | +----------+ +----------+ || | Application | | object 1 | ... | object n | || | | +----------+ +----------+ || | +-------------------------------+| | / \ | | | | | | | | | | \ / | | +-------------------------------+| | | || | Lower layer | Transport layer || | | || | +-------------------------------+| +----------------------------------------------+ Figure 1 Applications structure of object-oriented Object uses object ID to addressing, object ID should be unique in a device. In this document, regard the object name as the unique identifier. It enables lower layer can route messages to right destination object. Parse of each message can be realized by destination object, and take action to it according to the message. This protocol defined the object name of standard. 3.3. Object definition It uses the methods of object-oriented to defining object in this document. Objects have their own attributes and methods, the content of definition contains object name, attribute name, attribute data type and supported methods. 3.3.1. Device management object Device management object (DMO) provided management functions of local device, it realized device management functions with accessing the object' attribute and calling the methods of object. Attribute which included in the object may be used in all practicable devices. Device manufacturers may extend it based on existing status. Table 1 describes the device management object attributes. About the supported methods, see 4.4.1. Table 1 DMO attributes Wang, et al. Expires April 2, 2013 [Page 5] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Attribute |Data type|Supported| Description | | name | | methods | | |-------------------------------------------------------------------| | DMO | string | - | Object name | |-------------------------------------------------------------------| | Vender ID | string | read | Manufacturer name, | | | | | designated by manufacturer | |-------------------------------------------------------------------| | Serial | string | read | Number, | | Number | | | designated by manufacturer | |-------------------------------------------------------------------| |Power Supply|Unsigned8| Read, | Power supply status of device | | Status | | alarm | 0-power supply directly | | | | | 1-power supplied by battery | | | | | than 75% | | | | | 2-power supplied by battery | | | | | between 25% to 75% | | | | | 3-power supplied by battery | | | | | than 25% | |-------------------------------------------------------------------| | Device |Unsigned32| read | Device memory, in Bytes | |Memory Total| | | | |-------------------------------------------------------------------| | Device |Unsigned32| read | Have used device memory, | | Memory Used| | in Bytes | |-------------------------------------------------------------------| | Objects |Unsigned16| read | The number of object that is | | Count | | | supported by device | |-------------------------------------------------------------------| | Object | Array | read | Object list that is supported | | List | | | by device | +-------------------------------------------------------------------+ DMO should send alarm in order to reporting the change of device power status. Table 2 describes the alarm which is provided by DMO. Table 2 DMO alarm Wang, et al. Expires April 2, 2013 [Page 6] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Alarm name | Alarm | Data type | Description | | | scale | | | |-------------------------------------------------------------------| |Device Power| Device | Unsigned8 | The value of Power Supply | | Status | | | Status in table 1 | +-------------------------------------------------------------------+ 3.3.2. Alarm object Alarm object may be used to report or deal with singularity events. It mainly contains alert reporting management object and alert receiving object. 3.3.2.1. Alert reporting management object Alert reporting management object (ARMO) may be used to manage all alert, every device should have an alert reporting management object, all singularity events use alert reporting management object to report. Table 3 describes the alert reporting management object attribute. About the supported methods, see 4.4.1. Table 3 ARMO attribute +-------------------------------------------------------------------+ | Attribute |Data type|Supported| Description | | name | | methods | | |-------------------------------------------------------------------| | ARMO | string | - | Object name | |-------------------------------------------------------------------| |Alert Master| JID or | read, | Device that receives | | Device | IP | write | device scale alarm | |-------------------------------------------------------------------| |Alert Disable| string | read, | Disable or enable device scale | | Device | | write | alarm, either enable or disable | |-------------------------------------------------------------------| |Alert Master | JID or | read, | Device that receives | | Process | IP | write | process scale alarm | |-------------------------------------------------------------------| |Alert Disable| string | read, | Disable or enable process scale | | Process | | write | alarm, either enable or disable | +-------------------------------------------------------------------+ 3.3.2.2. Alert receiving object An alert receiving object (ARO) may receive one or more alert which come from alert report source. Table 4 describes the alert receiving object attribute. About the supported methods, see 4.4.1. Wang, et al. Expires April 2, 2013 [Page 7] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Table 4 ARO attribute +-------------------------------------------------------------------+ | Attribute |Data type|Supported| Description | | name | | methods | | |-------------------------------------------------------------------| | ARO | string | - | Object name | |-------------------------------------------------------------------| | | | | Alarm scale that is supported by | | Categories | string | read | this object , either device or | | | | | process | |-------------------------------------------------------------------| | | | | The data of errors alarm, which | | Errors |Unsigned16| read | is not belongs to the alarm scale| | | | | that is supported by this object | +-------------------------------------------------------------------+ 3.3.3. User object User object is defined by practice applications. This document takes industries process control object for example to explaining how to define the user object. 3.3.3.1. Process industries control object Industries process control object collects industries process data by sensor, such as temperature, pressure, flow and so on, each of which is process data in site, and deal with these data. The industries process control object which is defined in this document contains analog input object and analog output object. The functions of industries process control object are described in follow. Range conversion(scaling) Range conversion which is convert the site data from one unit range into another unit range is a linear conversion, which is help to measuring and calculating in next. As convert the signal data from 4~20mA into 0~10Kpa. Range conversion may convert the united data into disunited data, such as percentage and so on. and vice versa. Linearization Because of the characteristic of many sensors is nonlinear, even it is irregular, therefore, it is necessary to linear in dealing with the site data. Wang, et al. Expires April 2, 2013 [Page 8] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Compensation Because of sensor may be affected by environment, which may cause the measure values become linear offset, so it is necessary to compensate the offset. Filtering Because of sensor may be interfaced by environment and make the measure values occur relatively large skip, so it is necessary to filter the measure data to eliminate the bad effects which is leaded by skip signal. Dump Dump is copy the data to a temporary storage area, in order to resending when data is lost. Engineering unit conversion Engineering unit conversion converts the engineering unit of input signal into engineering unit which can be identified by I/O subsystem. Measuring time stamp When the data that is collected by module is input, it is necessary to record the current system time, in order to determining the time of sending data between the user application object. 3.3.3.2. Analog input object Analog input object (AIO) is used to sample the industries process, and convert the physical signal into data with physical dimension. Table 5 describes the object attribute, About the supported methods, see 4.4.1. Table 5 AIO attribute Wang, et al. Expires April 2, 2013 [Page 9] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Attribute |Data type| Supported | Description | | name | | methods | | |-------------------------------------------------------------------| | AIO | string | - | Object name | |-------------------------------------------------------------------| | Process | Float | read | Process variables | | Value | | | | |-------------------------------------------------------------------| | | | read, |Measure values that is presented| | Out Value | Float | publish, | by engineering unit | | | | alarm | | |-------------------------------------------------------------------| | | | |It could start/stop the measure | | Action | string | read, |process of AIO by setting the | | | | write |attribute of Action, the value | | | | |may be stop or start | |-------------------------------------------------------------------| | Sample |Unsigned32| read, |Sample period, the unit may be | | Period | | write | s, m, h | |-------------------------------------------------------------------| | High Limit | Float | read, | The high value of AIO | | | | write | | |-------------------------------------------------------------------| | Low Limit | Float | read, | The low value of AIO | | | | write | | |-------------------------------------------------------------------| | Alarm | string | read |Alarm status, only three values | | | | |could be selected: normal, high | | | | | alarm, low alarm | +-------------------------------------------------------------------+ Table 6 AIO alarm Wang, et al. Expires April 2, 2013 [Page 10] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Alarm name| Alarm | Data | Description | | | scale | type | | |-------------------------------------------------------------------| | High Alarm|Process| Float| When object detected the attribute of | | | | | supporting alarm methods exceed the | | | | | highest value, reporting it to ARMO, | | | | |and the attribute is the current value. | |-------------------------------------------------------------------| | | | |When object detected the attribute of | | Low Alarm |process| Float|supporting alarm methods less than the | | | | |highest value, reporting it to ARMO, | | | | |and the attribute is the current value. | +-------------------------------------------------------------------+ 3.3.3.3. Analog output object Analog output object (AOO) is used to convert the output value into value which is needed by hardware channel. Table 7 describes the attribute of object, About the supported methods, see 4.4.1. Table 7 AOO object Wang, et al. Expires April 2, 2013 [Page 11] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Attribute |Data type| Supported | Description | | name | | methods | | |-------------------------------------------------------------------| | AOO | string | - | Object name | |-------------------------------------------------------------------| | Out Value | Float |read, write,|Output value calculated from | | | | publish, | the input value | | | | reporte | | |-------------------------------------------------------------------| | Read Back | Float | read | Feedback data obtained from | | Value | | | the actuator | |-------------------------------------------------------------------| | | | read, | Input data or manually input | | Input Value| Float | write | data from other user | | | | | application object | |-------------------------------------------------------------------| | | | read, | Set AOO start/stop output data | | Action | string | write | to actuator, the value may be | | | | | stop or start | |-------------------------------------------------------------------| | Output |Unsigned32| read, |Output period, the unit may be | | Period | | write |s, m, h | |-------------------------------------------------------------------| | High Limit | Float | read, | The highest value of alarm | | | | write | | |-------------------------------------------------------------------| | Low Limit | Float | read, | The lowest value of alarm | | | | write | | |-------------------------------------------------------------------| | | | |Alarm status, only three values | | Alarm | string | read |could be selected: normal, high | | | | |alarm, low alarm | +-------------------------------------------------------------------+ AOO alert is the same as AIO alert. 3.3.3.4. System monitor object System monitor object is used to monitor system. Table 8 describes the attribute of object. Table 8 System monitor object Wang, et al. Expires April 2, 2013 [Page 12] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Attribute |Data type | Supported | Description | | name | | methods | | |-------------------------------------------------------------------| | SMO | string | - | Object name | |-------------------------------------------------------------------| | Device |Unsigned32| read | The number of device in | | count | | | monitoring | |-------------------------------------------------------------------| | Device | String | read | The list of device in | | List | array | | monitoring | +-------------------------------------------------------------------+ 3.4. Methods Methods represent specific interface (function) of object, which is used to access the data in object. This document divided the methods into two types: public methods and private methods. The public methods can be used in all objects, but the private methods only can be used in one or a few object that own it, if the methods which are defined to be public methods or private methods can realize the same function, then it is unnecessary to redefine it. 3.4.1. Public methods Table 9 describes the public methods which are defined in this document. Table 9 public methods Wang, et al. Expires April 2, 2013 [Page 13] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------------------------------+ | Methods | Description | Communication mode | | name | | | |-------------------------------------------------------------------| | read | Read the attribute values from | Client/Server | | read | one object | | |-------------------------------------------------------------------| | write |Write to the attribute of one object| Client/Server | |-------------------------------------------------------------------| | execute |Implementation the private methods | Client/Server | | | of one object | | |-------------------------------------------------------------------| | publish |Publish one or more attribute data | Publish/Subscribe | |-------------------------------------------------------------------| | report |Reporting alarm data | Source/Sink | +-------------------------------------------------------------------+ 3.4.2. Private methods This protocol may add private methods of object to the document in future. 3.4.3. Client/Server communication mode Client/Server communication mode supports non-period communication that is one-to-one. In this communication mode, both the any communication point could play the role of client or server. Client may send request to server, while the server must send response to client. It is similar to the communication mode that is request- response mode. Figure 2 represents the client/serve communication mode. Wang, et al. Expires April 2, 2013 [Page 14] Internet-Draft draft-wang-xmpp-extension-00 October 2012 +-------------------------------------------+ | usr usr | | +-----+ +-----+ | | | | | | | | +-----+ +-----+ | | | client/server | | | | request | | | |----------------------------->| | | | | | | | client/server | | | | response | | | |<-----------------------------| | | | | | | +-----+ +-----+ | | | | | | | | +-----+ +-----+ | +-------------------------------------------+ Figure 2 Client/Serve communication mode 3.4.4. Publish/Subscribe communication mode Publish/Subscribe communication mode supports pre-configured and periodic communication, which is no ACK or response. Configuration is either configured by configure tool or configured by human. Figure 3 describes the publish/Subscribe communication mode. +-------------------------------------------+ | usr usr | | +-----+ +-----+ | | | | | | | | +-----+ +-----+ | | | publish/subscribe | | | | request | | | |----------------------------->| | | | | | | | publish/subscribe | | | | request | | | |----------------------------->| | | | | | | +-----+ +-----+ | | | | | | | | +-----+ +-----+ | +-------------------------------------------+ Figure 3 publish/Subscribe communication mode Wang, et al. Expires April 2, 2013 [Page 15] Internet-Draft draft-wang-xmpp-extension-00 October 2012 3.4.5. Source/Sink communication mode Source/Sink communication mode is similar with the "push" communication mode, which is used to alarm. Figure 4 describes the source/Sink communication mode. +-------------------------------------------+ | usr usr | | +-----+ +-----+ | | | | | | | | +-----+ +-----+ | | | publish/subscribe | | | | request | | | |----------------------------->| | | | | | | +-----+ +-----+ | | | | | | | | +-----+ +-----+ | +-------------------------------------------+ Figure 4 source/Sink communication mode. 4. Protocol 4.1. Syntax One object in an application may communicate with another object in another application. Information and operation in one object can be realized by the element of , the name space of which is 'http://jabber.org/protocol/wsn-object'. The element of which is limited in 'http://jabber.org/protocol/wsn-object' should be considered as the one level sub-element of stanza or . The element of must contain the attribute of 'from' and 'to', in order to representing source object and destination object. The basic syntax is as follows. The syntax of sending request input_argument_value Wang, et al. Expires April 2, 2013 [Page 16] Internet-Draft draft-wang-xmpp-extension-00 October 2012 attribute_value The syntax of sending response output_argument_value attribute_value item_value Or text 4.2. Element Except the element of , this protocol also defined other elements. Wang, et al. Expires April 2, 2013 [Page 17] Internet-Draft draft-wang-xmpp-extension-00 October 2012 The element of represents the operation of source object, which must have the attribute of 'var', the attribute of 'var' indicate public methods that need to be executed. Take the 'var' = 'read' for example, which represent the source object need be operated on read. If the element of value is "execute", then the element of must contain an element of , and the element of must contain the attribute of 'var'. It is used to indicate private methods which need be executed. If the private methods that need be executed defined input parameter, then the element of should contain sub-element which is named by input parameter name. The element of represent object attribute that need to be read or wrote, which must contain an attribute of 'var' to indicting detail object attribute. When one attribution data type is array or structure, then using the element of , which must contain an attribute of 'var' to indicting detail one in attribute. Such as the elements of object list in DMO. The element of represent detected object of alarm events, if the attribute value of 'var' which belongs to element of is "report", then the element of must contain an element of , the element of must have an attribute of 'var', which is used to represent detected object of alarm events. The element of represent alarm that is sent, if the attribute value of 'var' which belongs to element of is "report", then the element of must contain at least one element of , the element of must have an attribute of 'type' and 'var', which are used to represent scale of alarm events and the detail alarm events. Wang, et al. Expires April 2, 2013 [Page 18] Internet-Draft draft-wang-xmpp-extension-00 October 2012 If XML stanza is response message that is succeed request, then the element of should contain the element of , the element of shall contain result of executing request, which including output parameter of executing private methods, read attribute values and so on. If the operation of request is succeed, but no content is return, then set the to null. If request operation is failed, then the element of in response message should contain the element of to describe error. The is also null, which is defined by application process. 4.3. Communicated processing examples Object operates attribute and private methods in object by public methods. The communication modes of public methods are different from one to one. The methods of reading, writing or executing are in support of the Client/Server communication mode, which is similar to the communication mode of Request/Response, therefore, when it is necessary to use these three methods, it should use stanza to transmit, which is defined in the XMPP core protocol, it uses stanza to transmit when it uses the methods of alarm or alarm ACK, the methods of publisher uses the communication mode of Publish/Subscribe, because of the publisher in this document published not only presence status, so it should not use the stanza. The methods of publisher also use the stanza to transmit. Assuming the XMPP application of host contains SMO or ARO, and the XMPP application of sensor which is included in industrial wireless sensor networks contains DMO, AIO and ARMO, The following examples describe the communication among them. Example1. Reading single attribute data: system monitoring object of host read sample values of sensor AIO. Host sends the read request Wang, et al. Expires April 2, 2013 [Page 19] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Sensor response the read request (success) 2.56 Sensor responding the read request (failed) Read failed Example2. Read multiple attribute data: system monitoring object of host reads sample values of sensor AIO and sample period. Wang, et al. Expires April 2, 2013 [Page 20] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Host sends the read request Sensor response the read request (success) 2.56 2m Sensor response the read request (failed) Read failed Wang, et al. Expires April 2, 2013 [Page 21] Internet-Draft draft-wang-xmpp-extension-00 October 2012 When reading the multiple attribute data, if reading a part of attribute data is success, but writing a part of attribute data is failed, then deal with it by failed, and return the read operate with failed. Example3: system monitoring object of host read the Object List attribute of sensor DMO. Host sends the read request Sensor response the read request (success) Wang, et al. Expires April 2, 2013 [Page 22] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Sensor response the read request (failed) Read failed Example4: Set single attribute data: system monitoring object of host write sample period of sensor AIO. Host sends write request 3h Sensor response write request (success) Wang, et al. Expires April 2, 2013 [Page 23] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Sensor response write request (failed) Example5: Set multiple attribute data: system monitoring object of host write sample period and the highest value of alarm of sensor AIO. Host sends write request 3h 20 Sensor response write request (success) Wang, et al. Expires April 2, 2013 [Page 24] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Sensor response write request (failed) When writing multiple attribute data, if writing a part of attribute data is success, but writing a part of attribute data is failed, then deal with it by failed, and return the write operate with failed. Example6: According to the pre-configured, sensor AIO sending measure values to the system monitoring object of host on time. 2.56 Example7: When the measure values of sensor AIO exceeded the highest value of alarm, sensor AIO shall report that to sensor ARMO, and set the attribute of 'alarm' to 'high alarm'. Assuming the attribute values of 'Alert Master Process' which are included in sensor ARMO are initialized to 'monitor@server', and the attribute values of Wang, et al. Expires April 2, 2013 [Page 25] Internet-Draft draft-wang-xmpp-extension-00 October 2012 'Alert Disable Process' are initialized to 'enable', then sensor ARMO send alert to host ARO. 26 5. Security Considerations This document has no requirement for a change to the security models within associated protocols. 6. IANA Considerations This document defined the protocol name space, which is the 'http://jabber.org/protocol/wsn-object'.it should add the protocol name space to 'http://xmpp.org/registrar/namespaces.html' according to the definition of XMPP Registrar Function. 7. References 7.1. Normative References [XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wang, et al. Expires April 2, 2013 [Page 26] Internet-Draft draft-wang-xmpp-extension-00 October 2012 7.2. Informative References [IMP-REQS] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000. Appendix A. XML Schema ' Wang, et al. Expires April 2, 2013 [Page 27] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Wang, et al. Expires April 2, 2013 [Page 28] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Wang, et al. Expires April 2, 2013 [Page 29] Internet-Draft draft-wang-xmpp-extension-00 October 2012 Authors' Addresses Ping Wang Chongqing University of Posts and Telecommunications Administrative Building, Chongqing University of Posts and Telecommunications Chongqing, 400065 China Phone: (86) -23- 6246- 1061 Email: wangping@cqupt.edu.cn Heng Wang Chongqing University of Posts and Telecommunications Administrative Building, Chongqing University of Posts and Telecommunications Chongqing, 400065 China Phone: (86) -23- 6248- 7845 Email: wangheng@cqupt.edu.cn Chao Zhou Cisco Systems (China) Research and Development Co., Ltd. 8Floor, Xinsi Mansion 926 Yinshan Lu, Caohejing Hi-Tech Park, Shanghai, 200233 China Phone: (86) -21- 2407- 3419 Email: czhou@cisco.com Wang, et al. Expires April 2, 2013 [Page 30]