CoAP specification (at the time of this writing, draft-18) does isn't clearly set out rules which define what would be a resp Onse for a given CON or a NON request. Embedded within the specification is various rules that is outlined. While many rules was still open and not clearly defined, the table below was a guidance that we had started following. Please note, this should being treated only as a guidance and not as something that's clearly defined by the CoAP specificat Ions.
Client sends |
Message successfully parsed and understood by Server |
Server have all information to process the Request and can successfully process |
Server sends Message Type |
Server sends Message Code |
Remarks |
CON |
YES |
YES |
Ack |
One of Success response codes |
Happy Day Scenario |
CON |
YES |
NO |
Ack |
One of failed response codes |
URI path in request is wrong and 4.04 not found is sent in ACK |
CON |
NO |
NO |
Rst |
One of failed response codes |
e.g. Unknown message code |
NON |
YES |
YES |
|
|
No Response sent back |
NON |
YES |
YES |
NON |
One of Success response codes |
Response sent back as NON message |
NON |
YES |
NO |
Rst |
One of failed response codes |
URI path in request was wrong and 4.04 not found was sent in RST |
NON |
NO |
NO |
Rst |
One of failed response codes |
e.g. Unknown message code |
Ooo |
YES |
YES |
CON |
One of the request codes |
e.g. Previous NON request is for a data, requires confirmation from the sender on whether it reached the client or no T |
CoAP Request and Response Rules