Version: 2 Status: Review Woo web of Objects Project

Web Protocols

1. Hyper Text Transfer Protocol

HTTP itself is a very generic topic, it worth describing in the context of WoO rather than very generic descriptions. In WoO web based paradigm will be used as underlying technologies where HTTP will be one of the choices. In WoO, HTTP protocol will be the application layer allows any entities (applications, services or devices) request another device for their functionalities and data. By saying this, we mean HTTP will serve as one of the application layer protocols we need in device interactions in this project.

In HTTP, there are basically two entities are involved, client and server. The basic working principle of HTTP is that client always requests server what it desires for. In order to send request, client should know the unique address of the server that is provided by Unique Resource Identifier (URI). When server receives request sent by client to its address, it will then reply the client with corresponding content that client requested for. In each request, client mention to the server the resource it is looking for, server can have several resources and reply back the client based on unique reference with the help of URI.

HTTP protocol is stateless, that means every time when client request for anything to server it should provide complete information about the resource it desires for. Server doesn’t maintain any state this is the feature that has made web access flexible and be able to scale to this level.

HTTP protocol is very small also easy to understand only few standard methods are used while communicating between client and server, such as while requesting for any resource, client use GET method which is one of the mostly used method in web data transfer. Upon receiving GET method and unique resource address, server replies client with response along with data related to the resource. There are other methods that are mostly used in client server operations; such as POST is another method client use to post some information into the server. To use POST, client should be authentic. Another method that is mostly used is DELETE using which, client can delete resource from the server to which it is allowed to. PUT method can also be used by client to create new resources. Most of the operations in web are handled by these few HTTP methods that have made HTTP so popular.

In order for further details about HTTP protocol, we would like to refer readers to RFC2616 [RFC2616]; here we explain how HTTP is going to be used in WoO innovation. HTTP is the application protocol of the World Wide Web which has architectural paradigm known as Representational State Transfer (REST). In REST, standard HTTP methods are used in order to have access of resources available in server. This is lightweight mechanism of accessing resource from server (in case of WoO, devices) will be one of the paradigm that our demonstration will be involved in. as an alternative in web service domain, simple object access protocol (SOAP) are used which works normally on top of HTTP protocol. Device Profile for Web Services (DPWS), web service specification for device, uses HTTP as a transport medium for SOAP envelope. Hence, both SOAP and REST paradigms will be involved in WoO, HTTP will be one of the key protocols, however, lightweight replacement of HTTP known as CoAP will also be explored that is described in next section.

2. Constrained Application Protocol

Whereas CoAP is designed with the goal of simple, stateless translation to and from HTTP, CoAP does not provide mere compression of the HTTP protocol, but achieves message overhead reduction by selective inclusion of HTTP features and support for extra features that suit constrained networks and devices. From HTTP features, CoAP supports the following list:

• 
  Simple caching (particularly helpful when nodes sleep to save energy)
  
• 
  Proxies and reverse proxies
  
• 
  Uniform Resource Identifier (URI) for resource identification
  
• 
  Request, response, and error codes
  

Additionally, CoAP support extra features such as multicast, asynchronous message exchange, built-in discovery using the CoRE Link Format standard [She12], and support for sleeping nodes through the use of caching proxies and asynchronous messaging. A CoAP implementation assumes both client and server roles, and thus is called an end-point.

CoAP has two sub-layers: the message layer and the request-response layer. CoAP’s message layer operates on top of UDP, Secure UDP (formally named as Datagram Transport Layer Security), and optionally on TCP. CoAP messages are short (one message fits in the payload of one UDP datagram). CoAP supports both reliable and unreliable message exchange. Reliable communication is implemented at the message sub-layer using confirmable (CON) messages, ACK and NACK (called Reset, RST, in CoAP) messages (which can be piggybacked on responses), retransmission with exponential back-off, and retransmission limit. Unreliable communication is realized using non-confirmable (NON) messages.

CoAP request methods are GET (for querying resource information), PUT (for resource state update or optional resource creation), POST (for resource creation), and DELETE. Example CoAP responses are not-found (4.04) and content (2.05) (response code is structured as class.detail, whereby class can be 2 for success, 4 for client error, 5 for server error).

Messages carry message IDs and requests (and responses) carry token IDs for duplicate detection and for matching ACKs and RSTs to messages and responses to requests.

CoAP supports controlling resources on constrained devices using push, pull, and notify approaches. CoAP end-points can establish observation relationships, in which a CoAP client receives notifications when resource state changes at a CoAP server.

A number of research efforts that integrate CoAP networks with the Internet have been proposed. Maenpaa, Bolonio, and Loreto [MBL12] proposed architecture for connecting geographically distributed sensor-actuator networks. Sensors and actuators use CoAP for local communication. For remote connections, the RELOAD protocol is used. RELOAD is a peer-to-peer overlay network-based protocol that uses distributed hash tables for rendezvous, distributed storage, and NAT traversal. CoAP traffic is tunneled in RELOAD messages to achieve CoAP communication across wide-area networks.

Carballido et al. [CPP12] provided a performance evaluation of some network configurations in CoAP networks. They considered SOAP-over-COAP as compared to SOAP-over-UDP and SOAP-over-HTTP, EXI (Efficient XML Exchange)-over-COAP as compared to EXI-over-UDP. They also considered the use of Electronic Product Code (EPC) as an object identifier in CoAP URI.

Whereas CoAP pushes towards the standardization of device connectivity to the Internet, several attempts were made to integrate CoAP with legacy, proprietary machine-to-machine protocols (e.g., in smart-home applications [BHG12]).

3. Extensible Messaging and Presence Protocol

Main reasons for the utilization of the XMPP protocol are: decentralization, open standards, main support of worldwide companies (e.g. Google or Sun Microsystems), security, ability to connect with other protocols (e.g. SMS or email) and flexibility.

Main weakness it’s inefficient in-band binary data transference. XMPP is not yet encoded as efficient XML Interchange, but as a single long XML document, binary data must be first base64 encoded before it can be transmitted in-band.

Standards that have been made regarding XMPP technology include:

The IETF XMPP working group has produced a number of RFC protocol documents: RFC 3920, RFC 3921, RFC 3922, RFC 3923, RFC 4622, RFC 4854 and RFC 4979

• 
  RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core, which describes client–server messaging using two open-ended XML streams. XML streams consist of
  , and (info/query). A connection is authenticated with Simple Authentication and Security Layer (SASL) and encrypted with Transport Layer Security (TLS).
  
• 
  RFC 3921, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence describes instant messaging (IM), the most common application of XMPP.
  
• 
  RFC 3922, Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) relates XMPP and the Common Presence and Instant Messaging (CPIM) specifications.
  
• 
  RFC 3923, End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) describe end-to-end encryption of XMPP messages using S/MIME. Instead of this proposal, many clients currently use GPG for encrypting messages.
  

• 
  Data Forms
  
• 
  Service Discovery
  
• 
  Multi-User Chat
  
• 
  XHTML-IM
  
• 
  File Transfer
  
• 
  Entity Capabilities
  
• 
  HTTP Binding
  
• 
  Personal Eventing Protocol
  

22. Data Representation

1. Extensible Markup Language

XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.

1. 
   XML Document
   

Each XML document has both a logical and a physical structure. Physically, the document is composed of units called entities. An entity may refer to other entities to cause their inclusion in the document. A document begins in a "root" or document entity. Logically, the document is composed of declarations, elements, comments, character references, and processing instructions, all of which are indicated in the document by explicit markup. The logical and physical structures must nest properly. An XML document is a string of characters. Almost every legal Unicode character may appear in an XML document.