## 5 IETF ROLL Working Group
### Research Challenges
#### 6.1.1 Base CoAP  
CoAP uses the same RESTful principles as HTTP, but it is much lighter so that it can be run on constrained devices [84,85]. To achieve this, CoAP has a much lower header overhead and parsing complexity than HTTP. It uses a 4-bytes base binary header that may be followed by compact binary options and payload. Figure 13 shows the CoAP message format as specified in version 13 of the draft. This version introduced a breaking change in the message format. However, it is expected that this will be the final change of the format. Figure 13: CoAP Message Format consisting of a 4-bytes base binary header followed by optional extensions. The CoAP interaction model is similar to the client/server model of HTTP. A client can send a CoAP request, requesting an action specified by a method code (GET, PUT, POST or DELETE) on a resource (identified by a URI) on a server. The CoAP server processes the request and sends back a response containing a response code and payload. Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport such as UDP and thus it also supports multicast CoAP requests. This allows CoAP to be used for point-to-multipoint interactions which are commonly required in automation. Optional reliability is supported within CoAP itself by using a simple stop-and-wait reliability mechanism upon request. Secure communication is also supported through the optional use of Datagram Transport Layer Security (DTLS). As can be seen in Figure 13 all CoAP messages start with a 4-bytes base binary header that consists of the following fields:  
* **Version (V)**: A 2-bit unsigned integer indicating the CoAP version number. Current version is 1. Other values are reserved for future versions. * **Type (T)**: A 2-bit unsigned integer indicating if this message is of type Confirmable (0), Non-Confirmable (1), Acknowledgement (2) or Reset (3). * **Token Length (TKL)**: A 4-bit unsigned integer indicating the length of the variable-length Token field (0-8 bytes). Lengths 9-15 are reserved. * **Code**: An 8-bit unsigned integer indicating if the message carries a request (1-31) or a response (64-191), or is empty (0). (All other code values are reserved.) In case of a request, the Code field indicates the Request Method (1: GET; 2: POST; 3: PUT; 4: DELETE); in case of a response a Response Code. Possible values are maintained in the CoAP Code Registry (see section 12 of the draft). * **Message ID**: A 16-bit unsigned integer in network byte order used for the detection of message duplication, and to match messages of type Acknowledgement/Reset to messages of type Confirmable/ Non-confirmable. The base 4-bytes header may be followed by one or more of the following optional fields:  
* **Token**: 0 to 8 bytes, as given by the Token Length field. The Token value is used to correlate requests and responses. The rules for generating a Token and correlating requests and responses are defined in Section 5 of the draft. * **Options**: An Option can be followed by the end of the message, by another Option, or by the Payload Marker and the payload. The format of the Options field is shown in Figure 14 and is described in more detail in the next paragraph. * **Payload**: If present and of non-zero length, it is prefixed by a fixed, one-byte Payload Marker (0 xFF) which indicates the end of options and the start of the payload. The payload data extends from after the marker to the end of the UDP datagram, _i.e._, the Payload Length is calculated from the datagram size. The absence of the Payload Marker denotes a zero-length payload. To be able to offer communication needs that cannot be satisfied by the base binary header alone, CoAP defines a number of options which can be included in a message. Each option instance in a message specifies the Option Number of the defined CoAP option.